The Digital Media Project
Interoperable Digital Rights Management Platform
Technical Specification, version 3.0
20 July 2007
NOTICE
Use of the technologies described in this DMP Approved Document may infringe patents, copyrights or intellectual property rights of DMP Members or non-members. Under no circumstance shall DMP be held responsible for identifying any or all such rights.
Neither DMP nor any of its Members accept any responsibility whatsoever arising out of or in connection with the use of this DMP Approved Document, the information contained herein and any related Information Technology expression for damages or liability, direct or consequential.
This DMP Approved Document supersedes all previous versions and is subject to change without notice.
DMP is a non profit organisation registered in accordance to the laws of Switzerland.
Copyright © 2007 – The Digital Media Project
The Digital Media Project (DMP) is a non-profit Association registered in Geneva, Switzerland. Its mission is “to promote the successful development, deployment and use of digital media that respect the rights of creators and rights holders to exploit their works, the wish of end users to fully enjoy the benefits of digital media and the interests of value-chain players to provide products and services, according to the principles laid down in the Digital Media Manifesto” [10].
Membership in DMP is open to any corporation and individual firm, partnership, governmental body or international organisation. DMP does not restrict Membership on the basis of race, colour, sex, religion or national origin. By joining DMP each Member agrees, both individually and collectively, to adhere to open competition in the development of digital media technologies, products or services. DMP Members are not restricted in any way from designing, developing, marketing or procuring digital media technologies, hardware, software, systems or services. Members are not bound to implement or use specific digital media standards, recommendations and specifications by virtue of their participation in DMP.
The goals of DMP are realised by developing Technical Specifications, Technical References and Recommended Practices enabling businesses that support new or improved end-user experiences and Recommended Actions to appropriate entities to act on removal of barriers holding up exploitation of digital media. Technical Specifications, Technical References, Recommended Practices and Recommended Actions are collectively called "DMP Approved Documents" (AD).
DMP operates on the basis of open international collaboration of all interested parties: corporations and individual firms, partnerships, governmental bodies or international organisations, supporting the DMP mission and the means to achieve its goals. DMP ADs are developed according to the DMP Procedures of Work [11]. DMP seeks the involvement of creators and end users of Digital Media through appropriate mechanisms.
DMP ADs are publicly available documents whose copyright is retained by DMP. DMP has the policy to contribute the results of its activities to appropriate formal standards bodies and other appropriate entities whenever this is instrumental to achieve the general DMP goals. Electronic copies of DMP ADs can be obtained free of charge from the DMP web site (http://www.dmpf.org/) or from the DMP Secretariat (secretariat@dmpf.org).
DMP has the intention to make ADs available in a form such that users can implement them either freely, or on a royalty-free basis or on fair and reasonable terms and non discriminatory (RAND) conditions following the IEC/ISO/ITU policy on IPR in international standards. When issuing Calls for Proposals DMP explicitly advises Respondents to the Calls of this policy. If DMP references an external standard or specification in a DMP AD, DMP expects that the same IPR policy, or a comparable one, has been adopted by the entity that produced the standard or specification.
However, it must be noted that DMP is not in a position to make any expressed or implied guarantee that licensing of any of the technologies relevant to any or all of its ADs can indeed be obtained either royalty free, or at RAND terms.
Media content has always played an important role in all societies and manifold technologies have been invented and deployed to provide means to store, distribute and consume it. The complexity of these technologies and the stimulus to provide ever-enhanced end-user experiences have created very complex media content value-chains populated by an increasing number of interacting intermediaries, each providing increasingly sophisticated services to the two extremes of the value-chains – creators and end users – as well as to the various intermediaries in between. Note that in DMP all players in the value chain – Creators, intermediaries and End-Users – are generically called Value-Chain Users or, simply, Users. Note that terms beginning with a capital letter are defined in the DMP Terminology [6].
Media value-chain technologies have been designed with two main purposes in mind: the first to provide or augment the end-user experience, and the second to provide or augment the capability to distribute media content. The latest round of technologies – the digital technologies – has augmented the end-user experience, e.g. by providing very high quality audio and video that does not deteriorate with time and use. Further digital networks have also dramatically increased the distribution potential of media content.
As a result, some of the traditional means to manage the value of media content along the value-chain are rapidly losing their established meaning. This is the source of various difficulties and is the major cause of the poor exploitation of the potential of digital media technologies. Digital Rights Management (DRM) has been advocated by many as the set of technologies that can overcome these difficulties because Users are given the possibility to manage Content while it moves along the Value-Chain. The reader is alerted to the fact that the DMP defines DRM as follows: Information Technology components and services which strive to distribute and control content and its rights.
The DMP agrees that DRM has the potential to combine the benefit of digital technologies with the need for a virtuous circle that motivates Creators to continue creating because remuneration is facilitated by DRM technologies. However, DMP sees serious problems in the introduction of DRM technologies that are lacking Interoperability.
A DRM system can be described as a particular form of communication designed to provide controlled communication between two or more Users. Therefore the implementation of a DRM system may require a broad range of communication technologies. Unless these are designed in such a way as to enable communication of Content between two different implementations, DRM becomes an obstacle that prevent Users from having the seamless and rewarding communication that digital media technologies can enable. This has particularly serious consequences in the case of the End-User because the lack of Interoperability detracts from the End-User experience and thus may seriously impede the take off of services designed to provide appropriate remuneration to relevant value-chain users.
Standards can bring benefits to the very special type of communication systems called DRM. However, the application of DRM standards obeys different rules because DRM is tightly connected to business practices that typically need different combinations of DRM technologies. As the introduction of digital technologies is currently forcing changes in the way value-chain users conduct their business, it is hard to define today what kinds of standards are required, much less to forecast what kinds of standard will be needed in the future.
The DMP approaches the problem of DRM Interoperability by specifying individual technologies – that DMP calls Tools – required to implement what DMP calls “Primitive Functions”. These are “smaller” functions obtained when the functions value-chain users perform when they do business between themselves are broken down into more atomic elements. It is expected that, while functions may undergo substantial changes as a consequence of the evolution of the media business in the value-chain, Primitive Functions will generally remain more stable and may just need to be augmented with new technologies.
Therefore the DMP is not developing a universal “DRM standard” capable of providing interoperability between every variety of different Users in arbitrary Value-Chains or across different Value-Chains. The DMP provides specifications of Tools enabling Primitive Functions along with examples of how Value-Chains serving specific goals can be set up using the standard Tools. The DMP specifications are developed in phases, so as to achieve gradual development of standards technologies.
The DMP approach to DRM standardisation is based on the following process
1. For each phase Use Cases deemed to be significant are identified and documented;
2. Primitive Functions required to implement the selected Use Cases are singled out;
3. Requirements for Primitive Functions are developed through inputs from relevant Users;
4. Tools serving the needs represented by the Use Cases are standardised;
5. Calls for Proposals for Tools with the identified requirements are issued;
6. The Tools are selected and documented through an open process. DMP favours Tools that have already been developed, standardised or adopted by other bodies, possibly adapting them to DMP needs;
7. Specifications of how Tools can be assembled to implement the selected Use Cases are developed;
8. In subsequent phases, Calls for Proposals for additional Tools needed to support new Primitive Functions or additional functionalities of existing Tools are issued.
The DMP calls the ensemble of all standardised DRM Tools “Interoperable DRM Platform (IDP)”. The IDP provides several major advantages:
1. The specifications are industry agnostic, i.e. Users are free to build a great variety of Value-Chains that suit their business models by combining just the Tools that are appropriate for them;
2. The capabilities of a Value-Chain or new Value-Chains can be extended by adding more Tools, possibly through additional standardisation;
3. The cost to access standardised Tools may be reduce because in general Tools have multiple usages and may be provided by multiple suppliers;
4. Full interoperability can be achieved within a Value-Chain;
5. An enhanced degree of interoperability can be achieved between different Value-Chains;
6. Innovation can be continuously fed in the system.
In spite of the value the DMP attaches to Interoperable DRM as the main digital media-enabling technology, the DMP has noted that DRM has the potential to substantially alter the balance that has been in existence in the analogue world between different Users of Content, in particular when one of them is the End-User. If not appropriately remedied, this imbalance may lead to a significant reduction of the scope of Traditional Rights and Usages (TRU) of Users. A possible outcome is the outright rejection of the new technology on the part of some Users, in particular End-Users who will perceive the media experience in a DRM environment as inferior.
The DMP is not claiming that an established TRU necessarily implies a right of a User to a particular Use of digital media but simply that, if Users have found a particular Use advantageous in the analogue domain, they are probably interested in continuing to exercise that Use in the digital domain as well. Leveraging upon this interest may provide multiple opportunities for new “Digital Media Business Models” that are attractive to Users but respectful of Rights Holders.
Therefore the DMP intends to add technologies to its specifications to make the exercise of a broad range of TRUs technically possible. However, even a summary analysis shows that many TRUs have a legislative/regulatory impact that needs to be addressed by proper authorities. This can only be done within individual jurisdictions by determining which TRUs shall be mandated in Interoperable DRM Platforms operating under their jurisdiction and which TRUs can be left to private deals between Users. This is a challenging task because it requires blending knowledge encompassing the legal, social and economic fields with in-depth knowledge of the highly sophisticated and unusual DRM technologies.
DMP has produced the following ADs:
1. Approved Document No. 1 – Value Chain Functions and Requirements [1]: a collection of Primitive Functions derived from today’s media value-chains with corresponding Requirements.
2. Approved Document No. 2 - Architecture [2]: a general architecture that describes some of the digital extensions of today’s media value-chains and collects the basic assumptions and technologies underlying the establishment of IDP-enabled Value-Chains.
3. Approved Document No. 3 – Interoperable DRM Platform [3]: a collection of technical specifications of basic Tools that are needed to implement Primitive Functions.
4. Approved Document No. 4 – Use Cases and Value Chains [4]: a collection of Use Cases along with normative specifications of examples of (portions of) Value-Chains implementing the Use Cases using the Tools drawn from the IDP Toolkit.
5. Approved Document No. 5 – Certification and Registration Authorities [5]: a set of operational rules for Certification Authorities established to Certify Devices and DRM Tools, and Registration Authorities established to Assign Identifiers to Content, DRM Tools, Devices, Users and Domains.
6. Approved Document No. 6 – Terminology [6]: a set of terms and corresponding definitions that are used throughout DMP ADs providedto overcome the problem of DRM being a field that impacts many existing fields with their own established and sometimes conflicting terminologies.
7. Approved Document No. 7 – Reference Software [7]: a software implementation of IDP Tools distributed, whenever possible, under the Mozilla Public Licence. When this is not possible DMP provides the reference software with a “modify, use and distribute” license.
8. Approved Document No. 8 – End-to-End Conformance [8]: a set of Recommended Practices that Value-Chain Users can reference to ascertain that the Tools employed by other parties conform to DMP Technical Specifications and Technical References.
9. Approved Document No. 9 – Mapping of Traditional Rights and Usages to the Digital Space [9]: a set of example support of TRUs using DMP Tools possibly complemented by recommendations to appropriate authorities to enable the benefit of TRUs in a DMP-enabled world of digital media.
Media and Digital Technologies
DRM requires more than technology
The suite of DMP Approved Documents
1 Value Chain Functions and Requirements
2.2.3 Navigating the Value-Chain
2.3.2 Represent Rights Data (RRD)
3.2.7 Represent DRM Information
3.2.10 Represent Rights Data (RRD)
3.2.14 Represent Authentication Messages
3.2.15 Represent Device Information
3.2.17 Represent Base Protocol
3.2.18 Represent Domain Protocol
3.2.20 Represent Access Protocol
3.2.21 Represent Device Identifier Protocol
3.2.22 Represent Identify Content Protocol
3.2.23 Represent Store Content Protocol
3.2.24 Represent Store License Protocol
3.3.1 Protocols to Identify Entities
3.3.2 Protocols to Authenticate Entities
3.3.3 Protocols to Manage Domain
3.3.6 DRM Processor Protocols.
4.2 Use Case and Value Chain No. 1 – Open Release
4.2.2 Tools for walkthrough #1
4.2.3 Tools for walkthrough #2
4.2.4 Tools for walkthrough #3
4.2.5 Tools for walkthrough #4
4.3 Use Case and Value Chain No. 2 – Open Search
4.3.2 Tools for walkthrough #1
4.4 Use Case and Value Chain No. 3 – Home Distribution #1
4.4.2 Tools for walkthrough #1
4.5 Use Case and Value Chain No. 4 – Home Distribution #2
4.5.2 Tools for walkthrough #2
4.6 Use Case and Value Chain No. 5 – Internet Distribution
4.6.2 Tools for walkthrough #1
4.6.3 Tools for walkthrough #2
4.7 Use Case and Value Chain No. 6 – Controlled Peer-to-Peer Distribution
4.7.2 Tools for walkthrough #1
4.7.3 Tools for walkthrough #2
4.8 Use Case and Value Chain No. 7 – Smart Retailer
4.8.2 Tools for walkthrough #1
4.8.3 Tools for walkthrough #2
4.8.4 Tools for walkthrough #3
4.8.5 Tools for walkthrough #4
4.8.6 Tools for walkthrough #5
4.8.7 Tools for walkthrough #6
4.9 Use Case and Value Chain no. 8 – Personal photography
4.9.2 Tools for walkthrough #1
4.10 Use Case and Value Chain No. 9 – Open Broadcast
4.10.2 Tools for walkthrough #1
4.11 Use Case and Value Chain No. 10 – Open Governed Broadcast
4.11.2 Tools for walkthrough #1
4.11.3 Tools for walkthrough #2
4.11.4 Tools for walkthrough #3
4.11.5 Tools for walkthrough #4
4.12 Use Case and Value Chain No. 11 – Smart Broadcaster
4.12.2 Tools for walkthrough #1 – Simple Play with simple condition
4.12.3 Tools for walkthrough #2 – Play with condition
4.12.4 Tools for walkthrough #3 – Export with condition
4.12.5 Tools for walkthrough #4 – Store with condition
4.12.6 Tools for walkthrough #5 - Play broadcast program with constraints
4.12.7 Tools for walkthrough #6 - Store & Export broadcast program with constraints
4.12.8 Tools for walkthrough #7 - CCI (Copy Control Information) representation
4.13 Use Case and Value Chain No. 12 – TVA Broadcaster
4.13.2 Tools for walkthrough #1 – Free-To-Air Content
4.13.3 Tools for walkthrough #2 – Pay-Per-View Content
4.13.4 Tools for walkthrough #3 – Video-On-Demand Content
4.14 Use Case and Value Chain No. 13 – Open Governed Interactive Content
4.14.2 Tools for walkthrough #1
4.15 Use Case and Value Chain No. 14 – Conversion between DRM Content Formats.
4.15.2 Tools for walkthrough #1
4.15.3 Tools for walkthrough #2
4.16 Use Cases and Value Chain Number 15 – Content Identification
4.16.1 Tools for walkthrough #1
4.17 Use Cases and Value Chain Number 16 – Value Chain Roles
4.17.2 Tools for walkthrough #1
4.18 Use Cases and Value Chain No. 17 – Domain Management
4.18.2 Rights holder defined Domain
5 Certification and Registration Authorities
5.2 DMP Certification Authorities
5.2.2 Qualification Requirements for a Certification Authority
5.2.3 Procedure to appoint a Certification Authority
5.2.4 Responsibilities of a Certification Authority
5.2.5 Responsibilities of Certification Agencies
5.3 DMP Registration Authorities
5.3.2 Qualification Requirements for a Registration Authority
5.3.3 Procedure to appoint a Registration Authority
5.3.4 Procedural responsibilities of a Registration Authority
5.3.5 Operational responsibilities of a Registration Authority
5.3.6 Responsibilities of Registration Agencies
5.4 Roles of Registration Agencies
5.4.1 Roles of DRM Tool Body Registration Agencies
5.5 Tasks of the Board of Directors regarding Certification and Registration Authorities
7.5 RRDOnto Java API specification
8.2.1 Content and Content Elements.
9 Mapping of Traditional Rights and Usages to the Digital Space
9.3 Use Case #2 – Personal Copy TRU
9.4 Use Case #3 – Space shift TRU
9.5 Use Case #4 – Time shift TRU
9.6 Use Case #5 – Alternative Compensation System DMBM
9.7 Use Case #6 – Community content sharing DMBM
9.8 Use Case #7 – Music sampling DMBM
Annex A – Introduction to some referenced standards
A.1 MPEG-21 Digital Item Declaration
A.2 MPEG-21 Digital Item Identification
A.3.3 The IPMPGeneralInfoDescriptor
A.4 MPEG-21 Rights Expression Language
A.6.1 TV-Anytime Content Description Metadata
A.6.2 Documents related through the CRID
A.7 MPEG-21 Digital Item Adaptation
A.10 MPEG-21 Digital Item Streaming
B.1 The Media Streaming Access Protocol Extensions schema
B.2 The Represent Content Identifier Protocol schema
B.3 The Represent Device Identifier Protocol schema
B.4 The Represent License Schema
B.5 The Represent Store Content Protocol schema
B.6 The Represent Store License Protocol schema
Annex C – DMP Profiles of Schemas defined by other Bodies
C.1 The MPEG-21 Digital Item Streaming schema
C.2 The MPEG-21 Digital Item Adaptation schema
C.3 The Media Streaming Application Format DIDL Profile schema
C.4 The Media Streaming DIDL Extensions Schema
C.6 The Digital Item Identification schema
C.7 The Event Reporting schema
C.8 The Media Streaming IPMPDIDL schema
C.9 The Media Streaming IPMPINFO schema
C.10 The Media Streaming IPMPINFO extensions schema
C.11 The IPMP XML Messages schema
C.13 The MPEG-7 Simple Metadata Profile schema
C.14 The Media Streaming Access Protocol schema
C.15 The Media Streaming Base Protocol schema
C.16 The Media Streaming Domain schema
C.17 The Media Streaming Domain Protocol schema
C.18 The Media Streaming MPEG-21 REL Multimedia Extension One
C.19 The MPEG-21 REL Multimedia Extension Two
C.20 The MPEG-21 REL Multimedia Extension Three
C.21 The Media Streaming MPEG-21 REL Multimedia extension profile schema
C.22 The Media Streaming MPEG-21 REL core profile schema
C.23 The Media Streaming MPEG-21 REL Standard extension profile schema
C.25 The Media Streaming TV Anytime profile schema
C.26 The XML Namespace Schema.
C.27 The Digital Signature Schema
Annex D – Compatibility between TVA RMPI and DMP Represent License
D.2 Mapping Table between RMPI and DMP Represent License
Annex E – Rights Representation Data Ontology Web Language File
Annex F – Example of Content Registration
G.1 To Be Completed By Applicant Registration Agency
DMP is developing a series of specifications for Interoperable DRM called Interoperable DRM Platform (IDP) where each phase of the IDP specifications is indicated by a sequential number. The open IDP specifications enable Users to technically execute Functions using standard Protocols through standard Interfaces with predictable results.
Because there is such a broad variety of value-chains there can hardly be a “universal DRM system” to develop specifications for. Therefore it is expected that there will be a range of “implementations” of DRM systems designed to satisfy the needs of specific value-chain users. The DMP specifications can be used to realise the digital equivalent of the media value-chains that exist today, but also to make value-chains that have no obvious equivalent with today’s value-chains.
This unpredictable environment requires a different type of standardisation than used for other standardisation efforts, e.g. video coding, that typically apply to well-defined environments. The DMP approach is based on protocols for lower-level functions (called Primitive Functions) between value-chain users. If Primitive Functions are well defined existing and possibly new Functions can be built as combinations of Primitive Functions. In the future new Functions could also be built using existing and new Primitive Functions.
This document documents the requirements upon which the Interoperable DRM specification has been developed. To achieve this, the following process – open to any party – has been invoked:
1. Ask a broad range of value-chain users to state their needs
2. Derive Functions from the stated needs
3. Develop requirements for implementing Functions
4. Identify prominent use cases used to focus the development of specifications
5. Issue Call for Proposals for technologies to implement Functions.
All documents produced at each of these steps have been made publicly available for comments on the DMP web site at http://www.digital-media-project.org/.
So far representatives of the following value-chain users have contributed to the process:
1. Civil Rights Associations
2. Association of People with Special Needs
3. Collective Management Societies
4. Device Manufacturers
5. Individuals
6. Producers
7. Public Service Broadcasters
8. Sheet Music Publishers
9. Telecommunication operators.
This document is work in progress as it is the starting point for the series of interoperable DRM specifications that DMP plans to develop. Those wishing to comment on or contribute to future versions of this Approved Document No. 1 are requested to forward their submissions to Marc Gauvin (mgauvin@sdae.net). Submissions are typically discussed within the Ad hoc Group on Requirements for Interoperable DRM Platform, whose email reflector is idp-ied-rq@dmpf.org. To subscribe to the email reflector follow the instructions.
This Approved Document No. 1 contains
1. The list of Value-Chain Users identified so far by DMP, and whose requirements the DMP expects to support (Chapter 2)
2. The list of General Requirements underpinning the DMP process (Chapter 3)
3. The table a Primitive Functions identified with indication of which IDP Phase supports the given Primitive Function (Chapter 4)
4. The full list of Functional Requirements of Primitive Functions (Chapter 5).
|
# |
Value-Chain User |
Acr. |
Definition |
|
1. |
Creator |
CRE |
A User who creates a Work and generates its first Manifestation |
|
2. |
Performer |
PRF |
A User who interprets a Manifestation of a Work making an Instance |
|
3. |
Registration Authority |
RAU |
A User managing Identifier name spaces, and appointing and overseeing Registration Agencies |
|
4. |
Registration Agency |
RAG |
A User appointed by a Registration Authority to Assign Identifiers |
|
5. |
Collective Management Society |
CMS |
A User who provides collective representation to its members, e.g. Authors, Performers, Publishers etc. |
|
6. |
Producer |
PRD |
A User who produces Content |
|
7. |
Publisher |
PBL |
A User who selects Content and makes it available to other Users |
|
8. |
Syndicator |
SND |
A User who manages and places Content to Retailers using a variety of purchasing options |
|
9. |
Metadata Resolution provider |
MRP |
A User who resolves, i.e. maps between disparate sets of Metadata |
|
10. |
Repository |
RPS |
A User who offers Services to long-term Store, Identify, describe, locate, Access, manage, and Validate Content and its Metadata |
|
11. |
Monitoring Service provider |
MNP |
A User who processes Use Data to provide information |
|
12. |
Marketer |
MKT |
A User who provides promotional, sale enhancement, brand enhancement and merchandising Services |
|
13. |
Aggregator |
AGG |
A User who provides procuring, packaging, presenting, cataloguing, archiving and indexing Services typically to Retailers |
|
14. |
Retailer |
RTL |
A User who sells or Licenses Content to an End-user |
|
15. |
Technology provider |
TCP |
A User who provides technology to make Devices |
|
16. |
Technology licensing provider |
TLP |
A User who provides Device Manufacturers with a license to utilise patented technology to make Devices |
|
17. |
Device Manufacturer |
DVM |
A User who manufactures or assembles hardware and/or software components to make Devices |
|
18. |
Connectivity provider |
CNP |
A User who provides point-to-point or point-to-multipoint connectivity between Users |
|
19. |
Network Service provider |
NTP |
A User who provides Internet Protocol (or equivalent) services and typically various other services above it, e.g. quality of service |
|
20. |
Tool provider |
TOP |
A User who sells or Licenses Tools to Users |
|
21. |
Certificate Authority |
CRA |
A User who issues digital Certificates used to create digital Signatures and public-private Keys |
|
22. |
Certification Authority |
CAU |
A User appointing and overseeing Certification Agencies |
|
23. |
Certification Agency |
CAG |
A User appointed by a Certification Authority to Certify Devices or DRM Tools |
|
24. |
Clearing House |
CLH |
A User who collects Value Expressions from other Users to distribute to Right Holders for the purchase of Use Rights over a given instance of Content |
|
25. |
Payment Service provider |
PSP |
A User who provides the infrastructure for financial transactions |
|
26. |
End-User |
ENU |
The last User in a Value-Chain |
|
27. |
Reseller |
RSL |
A User who possesses the Right to control the disposition and transfer of Content from End-users to different End-users |
|
28. |
Public Authority |
PBA |
A User who provides rules relating to the Use of Content and taxation on transactions related to Content. |
|
1. |
The IDP shall be a “tool-kit” specification |
|
2. |
The IDP shall evolve in phases, each phase introducing new Tools keeping compatibility with the Tools of preceding phases |
|
3. |
The IDP shall be open to support all legitimate needs by · Value-Chain Users · Associations of People with Special Needs |
|
4. |
The IDP shall support Rights inheritance, i.e. that the set of Rights acquired by a given Value-Chain User is subject to the set of Rights that was available to the Value-Chain User granting the Rights |
|
5. |
The IDP shall support the ability of a given Value-Chain User to mask the Value-Chain Users supplying Services to it in support of the Services that it provides to its clients |
|
6. |
Licensing of technologies required to implement IDP tools shall be RAND and preferably royalty-free |
|
7. |
The IDP shall be designed in such a way that its use shall have a minimal impact on Users, ideally that its use should be transparent |
|
8. |
The IDP Tools must satisfy the relevant requirements expressed in this document |
|
9. |
All Entities must be capable of being uniquely and unambiguously Identified |
|
10. |
Information about Devices and Domains shall be restricted to the minimum required for these to operate in the DMP Environment |
|
11. |
The IDP shall specify technologies that are native to it (e.g. the Rights Expression Language) and supported by implementations claiming conformance with IDP. DMP recognises that there may be implementations that replace the native IDP technologies with others that have the same functionality. However, no support for conformance testing to such implementations will be provided by DMP. |
The following table provides the current list of Primitive Functions grouped in categories. For each Primitive Function a cross in any of the last two right columns indicates whether or not it is currently specified and if so in which version of the Interoperable DRM Platform (AD #3). An X in both columns means that technology is provided by IDP-2 that adds to the technology already provided by IDP-1.
Table 1 – Primitive Functions
|
Category |
Primitive Function |
IDP#1 |
IDP#2 |
V.2.1 |
V.3.0 |
|
Represent |
|
|
|
|
|
|
|
Represent Identifier of Content |
X |
|
|
|
|
|
Represent Identifier of Device |
X |
|
|
|
|
|
Represent Identifier of User |
|
X |
|
|
|
|
Represent Identifier of Domain |
X |
|
|
|
|
|
Represent Identifier of DRM Tool |
|
X |
|
|
|
|
Represent Identifier of Footprint |
|
|
|
|
|
|
Represent Identifier of Class of Users |
|
|
|
|
|
|
Represent Identifier of Territory |
|
|
|
|
|
|
Represent Identifier of Jurisdiction |
|
|
|
|
|
|
Represent Content |
X |
X |
|
|
|
|
Represent Resource |
|
X |
|
|
|
|
Represent Metadata |
|
X |
|
|
|
|
Represent DRM information |
|
X |
|
|
|
|
Represent DRM Tool Body |
|
X |
|
|
|
|
Represent DRM Tool |
|
X |
|
|
|
|
Represent Rights Expression |
X |
X |
|
|
|
|
Represent Rights Data |
|
|
X |
|
|
|
Represent Key Body |
|
X |
|
|
|
|
Represent Key |
X |
X |
|
|
|
|
Represent Device Information |
|
X |
|
X |
|
|
Represent Domain Information |
|
X |
|
|
|
|
Represent Use Data |
X |
|
|
|
|
|
Represent Value Chain |
|
|
|
|
|
|
Represent Resource Format |
|
|
|
|
|
|
Represent Binarised XML |
X |
|
|
|
|
Identify |
|
|
|
|
|
|
|
Identify Content |
|
|
X |
|
|
|
Identify IP Class |
|
|
X |
|
|
|
Identify Metadata |
|
|
|
|
|
|
Identify Device |
X |
|
|
|
|
|
Identify Domain |
|
X |
|
|
|
|
Identify Role |
|
|
|
|
|
|
Identify User |
|
|
|
|
|
Recognize |
|
|
|
|
|
|
|
Recognize Items |
|
|
X |
|
|
|
Recognize Roles |
|
|
X |
|
|
Revoke |
|
|
|
|
|
|
|
Revoke Content |
|
|
|
|
|
|
Revoke Content Element |
|
|
|
|
|
|
Revoke Device |
|
|
|
|
|
|
Revoke Domain |
|
|
|
|
|
|
Revoke User |
|
|
|
|
|
Authenticate |
|
|
|
|
|
|
|
Authenticate Content |
|
|
X |
|
|
|
Authenticate Device |
X |
|
|
|
|
|
Authenticate DRM Tool |
|
X |
|
|
|
|
Authenticate User |
|
|
|
|
|
Verify |
|
|
|
|
|
|
|
Verify Content |
|
|
|
|
|
|
Verify Device |
|
|
|
|
|
Negotiate |
|
|
|
|
|
|
|
Negotiate Licence |
|
|
|
|
|
|
Negotiate Use Data |
|
|
|
|
|
|
Negotiate Licence and Use Data |
|
|
|
|
|
Report |
|
|
|
|
|
|
|
Report Use Data |
|
|
|
X |
|
Deliver |
|
|
|
|
|
|
|
Store |
|
|
|
X |
|
|
Copy |
|
|
|
|
|
|
Move |
|
|
|
|
|
|
Backup |
|
|
|
|
|
|
Export |
|
|
|
|
|
|
Access |
X |
X |
|
|
|
|
Restore |
|
|
|
|
|
|
Import |
|
|
|
|
|
|
Update |
|
|
|
|
|
|
Inter-Device communication |
|
|
|
X |
|
Manage |
|
|
|
|
|
|
|
Manage Domain |
X |
X |
|
|
|
|
Manage DRM Tool |
|
X |
|
|
|
Package |
|
|
|
|
|
|
|
Package as File |
X |
|
|
|
|
|
Package as Broadcast |
|
X |
|
|
|
|
Package as Streaming |
|
X |
|
|
|
Process |
|
|
|
|
|
|
|
Encrypt/Decrypt |
X |
|
|
|
|
Transact |
|
|
|
|
|
|
Test Conformance |
|
|
|
|
|
|
|
Test Conformance of Rights Expressions |
|
|
|
|
|
|
Test Conformance of Enforcing Rights Expressions |
|
|
|
|
|
|
Test Conformance of Tamper resistance |
|
|
|
|
|
Certify |
|
|
|
|
|
|
|
Certify Content |
|
|
|
|
|
|
Certify Device |
|
|
|
|
|
|
Certify User |
|
|
|
|
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of Content so that it can be Processed by a Device |
|
Objective |
To enable accurate Governance of a Content Item |
|
Requirements |
1. Ability to provide unique and unambiguous identification of a Content Item 2. Ability to support versioning 3. Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete 4. Ability to Identify Content by different Users to enable tracing the origin of Content when Licensed to other Users 5. Ability to Identify a Content Item for Use only within a specific Device or a Domain (e.g. a Broadcast Footprint, a company, a home) |
|
Benefits |
1. Flexible distribution schemes where different Content Elements may be supplied by different Providers 2. A given Content Element may be referenced in multiple parts of a Content Item 3. Multiple Content Items can refer to the same Content Element 4. Fine granularity of Rights Expressions. |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a Device employed in a particular instance of Use so that it can be Processed by a Device |
|
Objective |
To enable various Device-related Functions such as · To support the association of a piece of Governed Content with a Device · To support Trust management |
|
Requirements |
· Ability to work in conjunction with existing industry schemes to administer customer/device-specific uses · Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete · Ability to obtain Device capability information by reading the Device Identifier · Ability to support requirements for Domain Management |
|
Benefits |
· Allows reliable administration of Device-based Uses · Compatible with replacement strategies in cases where a Device is destroyed or otherwise replaced, or else used only for a period of time after which a different Device will be used. |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a User in a particular instance of Use so that it can be Processed by a Device |
|
Objective |
To enable various User-related Functions such as License Content to an Identified User |
|
Requirements |
· Ability to support User Authentication · Ability to support Identification of any Value-Chain User · Ability to accommodate a variety of models for human interaction with Devices e.g.: o Allow a single User to use multiple Devices, o Allow multiple Users to share a single Device, o Allow the use of a confidential identity (e.g. prepaid card) · Ability to extend the total number of Identifiers that can be Assigned in such a manner that previously Assigned Identifiers do not become obsolete · Ability to access information related to the User that may be legally required for the provision of Content |
|
Benefits |
Depending on a given device's design, allows one User to employ multiple devices or allows multiple Users to use a single device |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of Domain so that it can be Processed by a Device |
|
Objective |
To enable Value-Chain Users to License Content to Identified groupings of Users and/or Devices |
|
Requirements |
· Ability to support the following types of Domains o Device-based o User-based o Location-based (e.g. DHCP) o Mixed Device, User and Location-based o Context-based § By reference to a legally established class of special users (e.g. students, people with special needs) · Ability to support a hierarchy of Domains |
|
Benefits |
Enable more Uses of Content by Identifying groupings of Users and/or Devices instead of just individual Users or Devices |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of executable code or hardware device that implements one or more DRM Functions on a Device so that it can be Processed by a Device |
|
Objective |
To facilitate Authentication of DRM Tools |
|
Requirements |
Ability to Identify individual DRM Tools Ability to Identify groups of DRM Tools as an Entity (Tool Group) Ability to Identify complete DRM Systems (Tool Packs) |
|
Benefits |
· To obtain and classify DRM Tools · To Authenticate DRM Tools |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a primary broadcast distribution area so that it can be Processed by a Device |
|
Objective |
To enable Devices to Use Content intended for a particular Footprint |
|
Requirements |
Unique and unambiguous identification of a particular Footprint |
|
Benefits |
Enable Usage of Content within a particular Footprint |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a particular class of Users so that it can be Processed by a Device |
|
Objective |
To enable Devices to Use Content intended for a particular class of Users |
|
Requirements |
Unique and unambiguous identification of a particular class of Users |
|
Benefits |
Enable Usage of Content within a particular class of Users |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a particular geographical area so that it can be Processed by a Device |
|
Objective |
To enable Devices to Use Content intended for a particular Territory |
|
Requirements |
Unique and unambiguous identification of a particular Territory |
|
Benefits |
Enable Usage of Content within a particular Territory |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the identity of a particular Jurisdiction so that it can be Processed by a Device |
|
Objective |
To enable Devices to Use Content intended for a particular Jurisdiction |
|
Requirements |
Unique and unambiguous identification of a particular Jurisdiction |
|
Benefits |
Enable Usage of Content within a particular Jurisdiction |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the organisation and association of Content and Content Elements so that it can be Processed by a Device |
|
Objective |
To enable a predictable processing of Content and Content Elements according to the purposes of the Content Item design, i.e. to Represent the Governed Use of Work, Manifestation, Instance, Production, DRM Tool etc. |
|
Requirements |
· Ability to provide persistent association of Identifiers to Content and Content Elements · Ability to include Clear-text and Encrypted Identifiers, Content and Content Elements in a Content Item · Ability to apply Licenses to different Content Elements in a Content Item · Ability to Use individual Content Elements in a Content Item · Ability to associate to a Content Item Content Elements Stored at locations remote from each other · Ability to support temporary and permanent unavailability of Content Elements · Ability to Represent Content in a Delivery-System agnostic format · Ability to convey information related to § Key management § Encryption methods § Watermarking § Etc. · Ability of a Content Item to contain another Content Item |
|
Benefits |
· Standard format to securely communicate Resources and Governance information for Use · Multiple Uses of the same Resources (e.g. possibility to create multiple play lists) · Different Licenses for the same Content and/or Content Elements · Easy navigation · Easy repurposing |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the format of a Resource so that it can be Processed by a Device |
|
Objective |
To enable a Device to interpret the Representation so that the Resource can be Used |
|
Requirements |
· To be as simple as possible · To be as expressive as required |
|
Benefits |
Use of Resources by Devices |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe features and attributes associated with Content and Content Elements or Devices so that it can be Processed by a Device |
|
Objective |
· Facilitate interaction between Users for a plurality of purposes, e.g. o Classification o Description o Search and retrieval o Presentation o Etc. · Enable best Use of Content on Devices |
|
Requirements |
· Ability to support existing Metadata standards · Ability to signal the standard in use · Ability to employ a minimal Metadata standard set for End Users · Ability to describe Device features and capabilities |
|
Benefits |
Allow for an effective interchange of Content between Users and optimal Use of Content and Devices |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe Governance of Content so that it can be Processed by a Device |
|
Objective |
To enable a Device to interpret the information so that Content can be Used as determined by its Governance |
|
Requirements |
Ability to represent · DRM Tools required to Access Content · Initialisation and configuration data for DRM Tools · Decryption Keys · Information related to DRM Tool Management · Placeholders for Licenses |
|
Benefits |
Enable Content Governance by Devices |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the specific information used to describe DRM Tool embodiments used so that they can be Processed by a Device |
|
Objective |
To enable a Device to execute DRM Functions specific of a given Content Item |
|
Requirements |
· Ability to Represent a single Tool Body · Ability to Represent a Tool Pack Body |
|
Benefits |
Extend the number and scope of DRM Functions that a Device can execute |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the specific information used to describe the environment in which DRM Tools will operate so that they can be Processed by a Device |
|
Objective |
To provide the Device with the means to perform the required DRM functionality |
|
Requirements |
The Representation shall include: · Tool ID · DRM Processor type, including o Vendor o Model o Serial number · Target OS including o Vendor o Model o Serial number o Version o Virtual machine · CPU o Vendor o Model o Speed · Memory o Vendor o Model o Speed o Size · Auxiliary hardware o Smart card o Hard Key · Network · Downloading · RPC mechanism · Firmware · Tool API configuration o Instantiation API ID o Messaging API ID · Target HW · Format e.g. zip · Tool source · Authentication parameters · Update schedule info · Tool Validation info · License info · Others |
|
Benefits |
Upgradeable Device capable of executing multiple DRM functionalities |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe Permissions and Conditions so that it can be Processed by a Device |
|
Objective |
To allow conditional Use of Content, based on the Conditions being satisfied or fulfilled |
|
Requirements |
· Ability to interpret a Rights Expression o Without a return channel o With low payload o On a wide array of Device sophistication · Ability to unambiguously Identify o The User granting the Permission o The Device, User or Domain obtaining the Permission o The Content and Content Elements to which the Rights Expression refers · Ability to utilise (Rights data dictionary) o A User selectable Rights data dictionary o A minimal default Rights data dictionary · Ability to Represent (Permission sets) o Different subsets of Permissions o New Permissions when the need occurs · Ability to Represent (specific Permissions to Content) o Conditional expiry (e.g. Content may no longer be Used if Stored for longer than a determined period without Use) o One Rights Expression to many Content Elements o Many Rights Expressions each referring to a different Content Element § In particular a Content Item can have no Rights Expression (i.e. a Device can Use the Content without limits) o Content Uses e.g. § Period of time (e.g. play as long as the play time is greater than specified time and less than a specified time) and based on time/date § Count based (play up to a specified number of times) § User based § Device based § Domain based § Location based o Rights Expressions with Context Use limitations, e.g. age of End-User · Ability to support Delivery by: o Streaming o Broadcast o File download o Physical media · Ability to support (Conditions) o Territories o Jurisdictions o Footprints o Domains o Devices o Users o IP Entities · Ability to support (Functions) o Not to Encrypt clear-text Resources o Quote o Time-shifted Use o Annotation o Trick modes o Move/Copy § Between Devices § Within Domain § Within Footprint o Export to a movable media · Ability to support (Content types) o Reference to different IP Entities o Addition of Metadata o Use of the following types of Resources: audio, video, images, text and executables and groups/bundles thereof o Access of Content based on Rating (e.g. suitability for age) o Rights to segments of Content o Many Rights Expressions each referring to particular Content Elements of a Content Item · Ability to support (Rights of Users) o Ability to represent the sets of Rights pertaining to all Users e.g. Authors, Performers, Producers, Aggregators, Distributors, etc. o The Right of a User to License another User o Restriction to a class of Users o Multiple Licensors · Ability to support dynamic creation of Rights Expressions as a result of interaction between Users · Ability to support Creative Commons licenses |
|
Benefits |
Potentially allow the full range of human contractual agreements to be embodied in the digital domain, especially including automatic processing of agreements that are stated in rigorous forms |
|
|
Detailed description of Requirements |
|
Definition |
The semantics of the data used in Permission and Conditions so that they can be interpreted by a Device in a predictable way |
|
Objective |
To enable a device to perform the Functions in an agreed and predictable way |
|
Requirements |
· The RRD will maintain a basic core set of terms for o IP Entities o Actions o Rights o Roles · The RRD will support a number of extensions created as the need arises · The RRD extension will be consistent with the core · To support the following IP Entities o Work o Adaptation o Manifestation o Instance o Work Instance o Adaptation Instance o Work Manifestation Copy o Work Instance Copy o Adaptation Manifestation Copy o Adaptation Instance Copy o Product · To support the following Actions o Create Work o Make Manifestation o Make Work Manifestation o Make Adaptation Manifestation o Make Instance o Make Work Instance o Make Adaptation Instance o Make Copy o Make Adaptation Instance Copy o Make Adaptation Manifestation Copy o Make Work Instance Copy o Make Work Manifestation Copy o Play o Copy · To support a subset (to be defined) of the following REL Rights: o Adapt o Delete o Delist o Diminish o Embed o Enhance o Enlarge o Enlist o Execute o Export o GovernedAdapt o GovernedCopy o GovernedMove o Install o Modify o Move o Play o Print o Reduce o Uninstall · To support the following Roles o Creator o Adaptor o Instantiator o Producer o Distrubutor o End User · RRD shall support the execution of Functions, some of which may be derived from the terms in the list above or be included as new terms o Adapt (Resource) § Conversion of compression method § Video resolution § Sampling frequency o Backup o Copy o Edit o Encrypt o Export o Import o Move o Quote o Restore o Space-shifted Use o Store o Synchronise o Time-shifted Use o Transfer to an external rendering device o Etc. · It must be machine readable · It must convey a strict correspondence between machine and human based interpretation and understanding · It must be represent a wide array of Users through adoption of one or more Roles · It must describe a complete array of Actions that Users can perform on or with IP Entities. · It must be capable of discerning between Roles on the basis of different combinations of Actions and IP Entity relationships · It must be capable of associating Rights with Actions and Roles. · It must be capable of describing the transfer of Rights throughout the Value Chain · It must be able to associate which IP Entities are required by Actions and which if any are produced by Actions. |
|
Benefits |
· Users have assurance that Devices behave predictably. · Essential input for conformance testing. |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe Keys and associated parameters so that it can be Processed by a Device |
|
Objective |
To provide a Device with the necessary information to utilize a Key |
|
Requirements |
· Ability to represent o Time dependent/independent Keys o Association of Keys to particular time segment of a Resource o Key type and related data (e.g. Authentication, Certificates, etc.) o Set of Key types |
|
Benefits |
The ability to use multiple Keys and Key Management schemes |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the capabilities of a Device to perform Functions so that it can be Processed by a Device |
|
Objective |
To describe the capability of a Device |
|
Requirements |
· To identify Device capabilities, e.g. o Capability to Process (e.g. Render) certain Resource Types o Capability to determine the applicability of certain Rights Expressions o etc. |
|
Benefits |
The ability to Access Content that is suitable for the Device |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the attributes of a Domain so that it can be Processed by a Device |
|
Objective |
To describe the minimum set of attributes of a Domain that is required to License Content for that Domain |
|
Requirements |
· The Representation shall include o Information about when the Domain was created o Domain Identifier o Domain Public and Private Keys o Domain Administrator’s name and password o List of Devices/Users in the Domain o Maximum number of Devices/Users o List of Revoked Devices/Users o Expiration date of Domain · The Representation may optionally include o Type of Devices o Maximum frequency of Devices/Users leaving and joining |
|
Benefits |
· For the Content Provider the ability to determine proper Licensing of its Content · For the End-User the ability to obtain Content for Use within his Domain |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the elements making up one or more instance of Use of Content, Device or User so that it can be Processed by a Device |
|
Objective |
To enable processing of Use Data in a predictable fashion |
|
Requirements |
· Ability to Identify Use Data · Ability to support protection of Use Data · Ability to convert Use Data to a human readable form · Ability to not Identify User or Device associated with Use Data · Ability to Represent a wide range of Content Uses e.g. time of Use, combinations of Content Items, Domains, Superdistribution Uses |
|
Benefits |
Provide a machine-processable record of Uses |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe Value Chains |
|
Objective |
To digitally represent Value Chains |
|
Requirements |
· Ability to represent the actions of the Users · Ability to represent the relationships of the Users |
|
Benefits |
To enable the unambiguous replication of Value Chains |
|
|
Detailed description of Requirements |
|
Definition |
The syntax of the information used to describe the format of Resources so that it can be Processed by a Device |
|
Objective |
To provide the means to Access Content containing suitable Resources for the Device |
|
Requirements |
· The ability to express relevant parameters in a Resource format o Compression algorithm used o Video resolution o Bitrate used for encoding o Audio sampling frequency o Number of channels o Etc. |
|
Benefits |
To facilitate Access to Content To be able to Access Content that is suitable for the Device |
|
|
Detailed description of Requirements |
|
Definition |
The efficient Representation of XML data |
|
Objective |
To save memory, transmission and processing capabilities when handling XML documents |
|
Requirements |
· To reduce the amount of information required to express an XML structure to a minimum · To allow for a lossless conversion between an XML structure its binary representation and the reconverted XML structure · To make processing of a binarised XML structure at least as easy to process as the original XML structure |
|
Benefits |
Better use of computing and transmission resources |
|
|
Detailed description of Requirements |
|
Definition |
The Function resulting from a request by a User and the consequent Assignment of an Identifier to Content Entities |
|
Objective |
To associate data, e.g. a number, to Entities in a unique and unambiguous fashion |
|
Requirements |
To Assign Identifiers according to the rules laid down by the Registration Authority as implemented by the Registration Agency so that there exists a unique, unambiguous, persistent and trusted correspondence between the Identifier and the Entity it Identifies · The Registration Agency shall provide unique Identifiers · The Registration Agency shall Assign the Identifiers unambiguously · The Registration Agency shall be able to Authenticate a Content Item without the need to Access the entire Content Item |
|
Benefits |
Form trusted relationships (i.e. Authenticate) by providing Users with the ability to Identify Content Entities |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User Assigns an IP Class to a Content Item |
|
Objective |
To enable Recognition of the Content Item |
|
Requirements |
· There must be a determined set of IP Classes |
|
Benefits |
There are more possibilities to Use Content Items |
|
|
Detailed description of Requirements |
|
Definition |
The Function performed by a User when describing Entities within a DCI |
|
Objective |
To facilitate search for and Use of Content Entities |
|
Requirements |
· Ability to support the need of different Users to Assign Metadata that have mandatory descriptive fields, e.g.: o Author o Title o Genre of Authorship o Date of Creation of Work o … · Ability to facilitate cataloguing of Content for distribution to professional Users |
|
Benefits |
Secondary means to identify Entities |
|
|
Detailed description of Requirements |
|
Definition |
The Function resulting from a request by a User and the consequent Assignment of an Identifier to Devices |
|
Objective |
To enable Device Authentication |
|
Requirements |
To Assign Identifiers according to the rules laid down by the Registration Authority as implemented by the Registration Agency so that there exists a unique, unambiguous, persistent and trusted correspondence between the Identifier and the Device it Identifies · The Registration Agency shall provide unique Identifiers · The Registration Agency shall Assign the Identifiers unambiguously |
|
Benefits |
Form trusted relationships (i.e. Authenticate) by providing Users with the ability to Identify Devices |
|
|
Detailed description of Requirements |
|
Definition |
The Function resulting from a request by a User and the consequent Assignment of an Identifier to Domain |
|
Objective |
To enable Identification of a Domain so that Content can be Licensed to it |
|
Requirements |
· The Registration Agency shall provide unique Identifiers, at least for the Domain life cycle · The Registration Agency shall Assign the Identifiers unambiguously |
|
Benefits |
Content can be Licensed to Domains |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User is Assigned a Role |
|
Objective |
To enable Recognition of a Role |
|
Requirements |
· There must be a determined set of Roles |
|
Benefits |
It is possible to simplify licensing |
(Currently outside of DMP)
|
|
Detailed description of Requirements |
|
Definition |
|
|
Objective |
|
|
Requirements |
· |
|
Benefits |
|
|
|
Detailed description of Requirements |
|
Definition |
The Function that matches a given Content Item with corresponding IP Entities in the RRD |
|
Objective |
To classify Content Items with the IP that they represent |
|
Requirements |
· The ability to interface with the RRD |
|
Benefits |
Users have the means to recognize the full set of Conditions for any Role required to interact with a given Content Item |
|
|
Detailed description of Requirements |
|
Definition |
The Function that matches the Role Assigned to a User with a corresponding Role in the RRD |
|
Objective |
To classify a User’s Role with a given Content Item in terms of the RRD |
|
Requirements |
· The ability to interface with the RRD |
|
Benefits |
Users have the means to recognize the full set of Conditions for any Role required to interact with a given Content Item |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User ceases to recognise a Content Item |
|
Objective |
To prevent the further Use of a Content Item |
|
Requirements |
· Content must be Identified |
|
Benefits |
To discontinue Use of a Content Item, e.g. when the Content Item has been found unsuitable for distribution |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User ceases to recognise a Content Element |
|
Objective |
To prevent the further Use of a Content Element |
|
Requirements |
· Content Element must be Identified |
|
Benefits |
To discontinue Use of a Content Element, e.g. when the Content Element is faulty |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User ceases to recognise a device as a Device |
|
Objective |
To prevent the further Use of the Device |
|
Requirements |
· Device must be Identified |
|
Benefits |
To discontinue Use of a Device, e.g. when the Device has been compromised |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Domain Manager ceases to recognise a Domain |
|
Objective |
To prevent the further operation of the Domain |
|
Requirements |
· Domain must be Identified · Devices or Users belonging to the Domain must be Identified |
|
Benefits |
To discontinue operation of a Domain, e.g. the Devices have been compromised |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a User ceases to recognise a device as a User |
|
Objective |
To prevent the further Use of Devices or Content by a User |
|
Requirements |
· User must be Identified |
|
Benefits |
To discontinue Use of Devices by a User, e.g. when the device representing the User has been compromised |
|
|
Detailed description of Requirements |
|
Definition |
The Function of proving the identity of a Content Item to a Device |
|
Objective |
To make sure that a Device Accesses the intended Content Item |
|
Requirements |
· Content must be Identified · Content must be Signed or Hashed · Ability to compare a given Content Item with the Registered Content Item · Ability to compare the hash of a given Content Item with the Registered hash and ID of the Content Item |
|
Benefits |
To enable a Device to Use the intended Content |
|
|
Detailed description of Requirements |
|
Definition |
The Function of proving the identity of a Device to another Device a User or Domain. E.g. · A LPD Authenticates a DMD |
|
Objective |
To make sure that Content is Used by the intended Device |
|
Requirements |
· Device must be Identified · Ability to support different levels of Authentication |
|
Benefits |
To enable Content Uses on identified Devices |
|
|
Detailed description of Requirements |
|
Definition |
The Function of proving the identity of a DRM Tool to a Device |
|
Objective |
To make sure that the Content is processed by the intended DRM Tool |
|
Requirements |
· DRM Tool must be Identified |
|
Benefits |
Correct handling of Content Management and Protection |
|
|
Detailed description of Requirements |
|
Definition |
The Function of proving the identity of a User to a Device another User or Domain |
|
Objective |
To make sure that the User is the intended User |
|
Requirements |
· Shall support multiple protocols for the authentication of Users · Outside of DMP scope |
|
Benefits |
To enable Content Uses by identified Users |
|
|
Detailed description of Requirements |
|
Definition |
The procedure to detect corruption or loss of part of the Content |
|
Objective |
Delivery of the correct Content |
|
Requirements |
· Ability to detect that there is corruption or loss of part of the Content |
|
Benefits |
To assure Content Integrity and support Trust Management in the case of DRM Tools |
|
|
Detailed description of Requirements |
|
Definition |
The procedure to detect corruption of part of the software of a Device |
|
Objective |
To support Trust Management with a Device that may be remote from a User |
|
Requirements |
· Ability to detect whether there is corruption of the Device software |
|
Benefits |
The ability to support Trust Management with a Device that may be remote from a User |
|
|
Detailed description of Requirements |
|
Definition |
The procedure by which an agreement is reached between User A and User B whereby User A grants a Licence to User B and User B transfers a Value Expression to User A |
|
Objective |
To determine the terms and conditions of the Licence and corresponding compensation |
|
Requirements |
· User B can express agreement or disagreements with proposed License terms · The procedure shall support changes to any parameter of the License (e.g. Principal, types of Use such Play, Copy) · The procedure shall support automatic negotiation of license terms · At every step a human readable license must be provided · The procedure shall enable the setting of certain parameters as non subject of negotiation, e.g. setting “no copy” or “time-shifted Use” as a mandatory feature of the License · The procedure shall allow the determination of the degree of confidentiality (no eavesdrop) of the protocol · The procedure shall not require revealing the real identities until the protocol has been successfully concluded |
|
Benefits |
To allow Users to achieve the best match between demand and offer |
|
|
Detailed description of Requirements |
|
Definition |
The procedure by which an agreement is reached between User A and User B whereby User B grants to User A the right to use the User and/or Use Date of User B and User A transfers a Value Expression to User B |
|
Objective |
To let two Users determine how the information acquired during interaction with Content can be further utilised |
|
Requirements |
· User A can express agreement or disagreements with proposed License terms · The procedure shall support changes to any parameter of the License (e.g. Principal, types of Use) · The procedure shall support automatic negotiation of license terms · At every step a human readable license must be provided · The procedure shall enable the setting of certain parameters as non subject of negotiation · The procedure shall allow the determination of the degree of confidentiality (no eavesdrop) of the protocol · The procedure shall not require revealing the real identities until the protocol has been successfully concluded |
|
Benefits |
Allows User confidence that their privacy will be protected, simultaneously allowing Providers to gain knowledge from User and Use Data to the extent this is agreed. |
|
|
Detailed description of Requirements |
|
Definition |
The procedure by which an agreement is reached between User A and User B whereby User A grants to User B a Licence to Use Content and User B grants to User A a Licence to Use his User and Use Data |
|
Objective |
To let two Users determine how a Content Item can be used and User and Use Data can be used |
|
Requirements |
· Users can express agreement or disagreements with proposed License terms · The procedure shall support changes to any parameter of the License (e.g. Principal, types of Use) · The procedure shall support automatic negotiation of license terms · At every step a human readable license must be provided · The procedure shall enable the setting of certain parameters as non subject of negotiation · The procedure shall allow the determination of the degree of confidentiality (no eavesdrop) of the protocol · The procedure shall not require revealing the real identities until the protocol has been successfully concluded |
|
Benefits |
To allow Users to achieve the best match between demand and offer |
|
|
Detailed description of Requirements |
|
Definition |
The Function of generating a message containing Use Data triggered by the execution of another Function as programmed by a User |
|
Objective |
To provide information of Content Use |
|
Requirements |
· The User inserting a programmed event report (ER) should be able to specify o the conditions under which an event should trigger sending Use Data o what Use Data is to be reported o to whom the Use Data is to be reported · The delivery of the ER should be secure · No ER shall be generated without the User's consent · For any Content Item the User shall be informed if the Device generates an ER · A Device may be instructed to automatically accept or refuse DCIs containing an ER-R based on the nature of the ER to be generated · The User or Device that will generate the ER should be able not to use the Content that will trigger the reporting |
|
Benefits |
To enable a variety of business models, e.g. advertising with click counting |
|
|
Detailed description of Requirements |
|
Definition |
The Function of generating a human-perceivable signal from a Resource |
|
Objective |
To enable human perception of Content |
|
Requirements |
· A protocol to Deliver Content to a Device for Rendering |
|
Benefits |
To allow the Delivery of a Resource to the intended Rendering Device for human enjoyment in a way that was intended by the Rights Holder |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which Device A Delivers Content to Device B for the purpose of retaining it in Device B for possible Use at a different point in time |
|
Objective |
Allow a Device to retain Content and/or Resources for future Use |
|
Requirements |
· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices |
|
Benefits |
The User can Use a Content for a longer period of time as per License |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which Device A Stores Content in Device B, preserving the original Content in Device A |
|
Objective |
· To enable more use of the same Content Item · To Copy or Move as per Rights Expressions. · To accomplish the transfer of a piece of Governed Content between Devices |
|
Requirements |
· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices |
|
Benefits |
Allow controlled Copy of Content |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which Device A Stores Content in Device B deleting the original Content in Device A |
|
Objective |
· To enable more use of the same Content Item · To Move as per Rights Expressions. · To accomplish the transfer of a piece of Governed Content between Devices |
|
Requirements |
· A protocol, including the point-to-multipoint case · The protocol should be secure · The protocol should lend itself to efficient implementations on a wide variety of Devices |
|
Benefits |
Allow controlled Move of Content |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Device can Copy a Content Item (in case the Rights Expression is a Stateless Rights Expression) to and from a Device where the Content Item is not for Use, e.g. for the purpose of later Restoring the Content Item. |
|
Objective |
To be able to backup/restore Content to and from an external device |
|
Requirements |
Backup requires that the Backup does not result in a second usable copy. |
|
Benefits |
· To be able to make room for Governed Content in a Device without losing permanently the Governed Content that is removed from the Device. · Not to lose the Content in case of Device failure. |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Device makes available a Content Item for use by a non-DMP DRM system. |
|
Objective |
To enable use of a Content Item outside of an Environment. |
|
Requirements |
· A protocol to communicate with a non-DMP DRM system. This includes, as a minimum, a means to identify non-DMP DRM systems · In the event the other DRM system is not capable of accepting the encryption used the protocol should be capable of Decrypting and Exporting cleartext Resources, Metadata and Licenses so that it may be re-encrypted as required by the target DRM system. · A Secure Authenticated Channel (SAC) |
|
Benefits |
A Rights Holder has the ability to extend the range of use of their Content to other governed environments. |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which Device A obtains Content from Device B so that Device A can execute Functions |
|
Objective |
To enable a Device to process Content |
|
Requirements |
· Access Content via file download, broadcast and streaming |
|
Benefits |
Access to Content via an array of delivery mechanisms |
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Device can Copy a Content Item (in case the Rights Expression is a Stateless Rights Expression) to and from a Device where the Content Item is not for Use, e.g. for the purpose of later Restoring the Content Item. |
|
Objective |
To be able to backup/restore Content to and from an external device |
|
Requirements |
Backup requires that the Backup does not result in a second usable copy. |
|
Benefits |
· To be able to make room for Governed Content in a Device without losing permanently the Governed Content that is removed from the Device. · Not to lose the Content in case of Device failure.
|
|
|
Detailed description of Requirements |
|
Definition |
The Function by which a Device accesses a piece of content governed by a non-DMP DRM system. |
|
Objective |
To enable Use of a piece of governed content by a Device. |
|
Requirements |
· A protocol to communicate with a non-DMP DRM system. This includes, as a minimum, a means to identify non-DMP DRM systems · The protocol should be capable of obtaining Clear-text Resources, Metadata and Licenses so that these may be re-encrypted as required by the Environment. · A Secure Authenticated Channel (SAC) |
|
Benefits |
Enables Environments to be populated with governed content from sources outside of DMP. |
|
|
Detailed description of Requirements |
|
Definition |
The means by which a Content Item may replaced by a new Content Item |
|
Objective |
Allow for Content to be Governed dynamically |
|
Requirements |
· Associate Content with License · Associate Content with DRM Tool |
|
Benefits |
· Enhanced flexibility in implementing Content Delivery and Use |
|
|
Detailed description of Requirements |
|
Definition |
The means by which a DRM Processor and a Resource Processor exchange data in a Device |
|
Objective |
To support standardisation of Device components |
|
Requirements |
· Interface between DRM Processor and Resource Processor · Protocol between DRM Processor and Resource Processor |
|
Benefits |
To enable componentisation of Device |
|
|
Detailed description of Requirements |
|
Definition |
Procedures to manage a set of Devices such that only those Devices can Use the Content Licensed to the Domain |
|
Objective |
To enable groups of Devices and/or Users e.g. belonging to a family to Use the same Content on any of the Devices in the group |
|
Requirements |
· Users with an authorised entitlement (Administrator) shall be able to fully control Domain membership and Content distribution. · Setting up a Domain, including the ability to distribute Licences that can only be used by Devices in the Domain · Joining a Domain · Authorising entry to a Domain · Leaving a Domain · Directing to leave a Domain, including the ability to exclude a Device so that it cannot process Licences associated with the Domain after the time of exclusion · Users without an authorised entitlement shall not be able to obtain confidential information related to the Domain · A Domain shall be configurable to permit a variety of distribution options between Devices belonging to the Domain, e.g. superdistribution of Content to Devices belonging to a sub-Domain within the Domain (e.g., specialized interest groups) |
|
Benefits |
Enables content distribution to be both very wide and very specific, supporting many possible business models. |
|
|
Detailed description of Requirements |
|
Definition |
Procedures to manage the communication of DRM Tools between themselves and a DRM Processor (parties) to enable a Device to Process Governed Content |
|
Objective |
To enable Use of a local or external DRM Tool by a Device |
|
Requirements |
It shall be possible for a DRM Tool to require: · To be informed of all the other DRM Tools operating at any time · To be notified when a new DRM Tool is instantiated · To be informed that a particular event occurs · The instantiation of another DRM Tool · The termination of another DRM Tool · The communication of the results of a DRM Tool · The exchange of a License or any part of it between two parties · The exchange of a Decryption Key along with associated information (i.e. timing) about its use between two parties · The mutual authentication with a party · The display of information to a User and the request for a User input |
|
Benefits |
To allow enhanced flexibility in the adoption of DRM technologies in Content Delivery and Use |
|
|
Detailed description of Requirements |
|
Definition |
The Function of processing Content for the purpose of delivering it between Devices as File |
|
Objective |
To ensure proper delivery of Content as File |
|
Requirements |
· Minimum overhead compared to Content · The Content should be efficiently retrievable |
|
Benefits |
Ability to Deliver Content between Devices |
|
|
Detailed description of Requirements |
|
Definition |
The Function of processing Content for the purpose of delivering it between Devices as Broadcast |
|
Objective |
To ensure proper delivery of Content as Broadcast |
|
Requirements |
· Minimum overhead compared to Content · The Content should be efficiently retrievable · Transport of Content should be efficient and timely (e.g. an End-User should not have to wait for a long time before Using Content) |
|
Benefits |
Ability to Deliver Content between Devices |
|
|
Detailed description of Requirements |
|
Definition |
The Function of processing Content for the purpose of delivering it between Devices as Stream |
|
Objective |
To ensure proper delivery of Content as Stream |
|
Requirements |
· Minimum overhead compared to Content · The Content should be efficiently retrievable · Transport of Content should be efficient and timely (e.g. an End-User should not have to wait for a long time before Using Content) |
|
Benefits |
Ability to Deliver Content between Devices |
|
|
Detailed description of Requirements |
|
Definition |
Methods used to hide portions or totality of Content Elements |
|
Objective |
To prevent a User from Using Content, Resources or Fragments of Resources |
|
Requirements |
· Suitably flexible for a wide variety of Content · Efficiently implementable on a wide range of Devices · Based on Encryption Algorithms that are: o publicly disclosed o subject to constant scrutiny and evaluation by the worldwide cryptographic community o supporting stream and bulk ciphers o considered as secure o in broad use · The appropriate consideration of export restrictions. · Encryption methods that allow decryption by Devices with different processing capabilities · Support o Facilitate efficient prefetch and decryption of child resources. o Efficient random access to content blocks for all linear content types |
|
Benefits |
To protect Content and Rights Expressions from being read by unintended Users |
|
|
Detailed description of Requirements |
|
Definition |
Providing User, Device, Governed Content or Service information to a payment system external to an Environment |
|
Objective |
To enable flexible payment systems such as subscription, pre-payment or transaction-based payment by a single Device, a Domain or a User. |
|
Requirements |
· The ability to support multiple payment methods and mechanisms |
|
Benefits |
Automated payment |
|
|
Detailed description of Requirements |
|
Definition |
Checking that a Rights Expression is interpreted and provides the output as intended by the originator of the Rights Expression |
|
Objective |
To test conformance of the engine interpreting the Rights Expressions |
|
Requirements |
Device conformance shall be assessed and regulated according to industrial compliance regime |
|
Benefits |
It is essential for a Rights Holder that a Device will correctly interpret Rights Expressions. |
|
|
Detailed description of Requirements |
|
Definition |
Checking that the Functions corresponding to the output are executed as intended |
|
Objective |
To test conformance of the engine executing the Rights Expressions |
|
Requirements |
Device conformance shall be assessed and regulated according to industrial compliance regime |
|
Benefits |
It is essential for a Rights Holder that a Device will correctly execute the interpreted Rights Expressions. |
|
|
Detailed description of Requirements |
|
Definition |
Defining the levels of tamper resistance and the methods to be used when an implementation is put under test for tamper resistance to determine such levels |
|
Objective |
To test the robustness of a Device to attacks |
|
Requirements |
|
|
Benefits |
It is essential for a Rights Holder that a Device is implemented in a way that makes it difficult for an attacker to tamper with it. |
|
|
Detailed description of Requirements |
|
Definition |
The issuance of a statement that a given Content Item is conformant to the DMP specifications (either through Certified Content Creation Device or Authority and corresponding Agency) |
|
Objective |
To provide the means to assure when required that a Content Item is indeed Content |
|
Requirements |
· Content conformance testing tools · Procedures to Certify Content |
|
Benefits |
To guarantee system integrity |
|
|
Detailed description of Requirements |
|
Definition |
The issuance of a statement by an authority that the claim by a device to be a Device is guaranteed |
|
Objective |
To make sure that Governed Content is Used by a Device |
|
Requirements |
· Device conformance testing tools · Procedures to Certify Devices |
|
Benefits |
To provide a guarantee that a Content Item is Used by a Device |
(Currently outside of DMP)
|
|
Detailed description of Requirements |
|
Definition |
The issuance of a statement by an authority that the claim by a device (e.g. smart-card) to represent User is guaranteed |
|
Objective |
To make sure that Governed Content is Used by a User |
|
Requirements |
· Procedures to Certify Users |
|
Benefits |
To provide a guarantee that a Content Item is Used by a User |
To facilitate or enable use of content by end-users, there is often the need for a string of intermediaries whose job is to make sure that content, once created, is packaged and delivered to end-users for consumption. Because intermediaries typically exchange and add value in a chain they, including creators and end-users, are also called value-chain users or, simply, users. Particularly with the use of digital technologies value-chain users tend to operate in a network and the name value-network is also used to indicate such a “non-sequential” relationship between intermediaries. In this document, however, the still more common word “value-chain” will be used.
This document contains a high-level description of the operation of a generic media value-chain based on the assumption that those who hold rights associated with content moving along the value-chain wish to retain control of the use of that content. This type of content is called “governed” content.
The description can be considered as an architecture that is shared by value-chains handling governed content. The architecture has been designed to be capable of supporting value-chains that are by and large digital extensions of today’s analogue value-chains, even though digital value-chains can be vastly different from today’s media value-chains whose origins are rooted in the prehistory of analogue media. DMP may reconsider this architecture if and when new intrinsically digital value-chains will emerge that cannot be supported by the current architecture or its extensions.
Please note the following general remarks:
1. In this document words beginning with a capital letter have the meaning defined in Approved Document No. 6 – Terminology;
2. The DMP architecture provides a broad view that serves to illustrate how Governed Content carrying Intellectual Property (IP) is generated, passed on through the Value-Chain and eventually consumed;
3. The term User or, when stressing the importance of his role in a Value-Chain is required, Value-Chain User, will be employed to indicate a Creator, an Intermediary or an End-User;
4. Approved Document No. 3 – Interoperable DRM Platform provides elementary technologies (“Tools”) in the form of an Interoperable DRM Platform (IDP) that can be employed to set up Value-Chains that handle Governed Content in an Interoperable way;
5. DMP specifications only address interoperability of the so-called DRM-layer, i.e. issues related to media coding and below (e.g. transport layer) are not addressed.
6. DMP is continually extending the scope of the architecture and adding new Tools to the IDP toolkit.
This Approved Document No. 2 provides:
1. A walkthrough exercising the main elements of Value-Chains enabled by the Tools specified in Approved Documents No. 3 and the steps required to set up Value-Chains, including the principles of operation of Authorities and Agencies in charge of Certification and Registration specified in Approved Document No. 5;
2. A series of models:
a. Creation Model identifying the major entities for which IP is attributed and describing their relationship to the digital objects involved in Content Creation;
b. Distribution Model identifying and describing the role of the principal Value-Chain Users engaged in distribution;
c. Delivery Model describing the two basic ways – File and Stream – in which Content can be Delivered between Devices;
d. DRM Tool Model describing the general operation of DRM Tools in Devices;
e. Device Model identifying and describing the principal Devices employed by Value-Chain Users;
f. Domain Model describing the operation of Domains of Devices and Users;
g. Import/Export Model describing how governed content can be converted to Governed Content and vice versa;
h. Data Model identifying and describing the different types of Data specified by DMP.
3. A summary description of the Tools specified by IDP-3.0.
Reading the Foreword of this Approved Document is a prerequisite for a proper understanding of this and other Approved Documents. It is also highly recommended that this document be read before delving in Approved Document No. 3 – Interoperable DRM Platform (IDP) [3].
A Value-Chain is a group of interacting Users, connecting (and including) Creators to End-Users with the purpose of Delivering Content to End-Users. As indicated in the Figure below the main components are
1. Creation (including Adaptation)
2. Instantiation
3. Production
4. Content Provisioning
5. Service Provisioning
6. Consumption

Figure 1 – Value Chain
Note that dotted arrows mean that the output of a User can be Used by the same type of User to make more Resources Representing any of Work, Adaptation, Manifestation, Instance.
A Creator makes a Work that may be performed (“Instantiated”) by a performer and Used by a Producer to make a product – typically a combination of Resources – to be distributed by Content and Service Providers.
For proper management in a Value-Chain it is useful to combine different types of Resources with different types of Metadata and possibly other information types. DMP calls this combination Content. For the purpose of Using Content on Devices, Content has to be digitally Represented. DMP calls such digitally Represented Content, DMP Content Information (DCI).
As was already the practice in the analogue world, Content Items require Identification. Creators, Instantiators and Producers typically have the objects that represent their intellectual and/or commercial property (IP Entities) uniquely Identified. With Identification appropriate Metadata are also typically generated.
Approved Document No. 5 specifies how this task is performed by a number of organisations (Registration Agencies) that are properly appointed and overseen by a single root authority (Certification Authority). DMP appoints the Certification Authority after approving the Authority’s Certification policies. The figure below depicts this three-layer arrangement.

Figure 2 – Authorities appoint Agencies that Identify Content Items
A User wishing to express conditions to Use a Content Item can associate a License to it Granting Permissions under specified Conditions. The party Granting Permissions is referred to as Licensor and the party receiving them is referred to as Licensee.
Approved Document No. 3 supports the case in which the Licensee is
1. A Device
2. A User (i.e. a device representing the user)
3. A Domain (i.e. groups of Devices and Users).
A User who does not wish to express Conditions to Use a Content Item can do so by Releasing it without a License. The Content Item, however, is still Governed because it is Identified.
To enable a Device to interpret Permissions without human intervention, DMP uses a machine readable language called Rights Expressions Language (REL). REL can be applied to Content that represents different categories of Intellectual Property (IP Entities). DMP uses a Creation Model to describe IP Entity relationships and dependencies. These are captured in a standard machine-readable ontology called Represent Rights Data (RRD) which also defines a set of Roles and Functions.
A Rights Holder can prepare generic Licenses for certain Roles, Functions and Content Items. These are converted to specific Licenses made available to Users who declare their Roles, Functions and Content Items.
By interacting with a Content Item using a Device a User typically generates data called Use Data, i.e. Data related to the Use that the User has made of a Content Item and Resources therein. This Use Data may have value in and of itself and the User generating the Use Data may decide to License other Value-Chain Users to Use such Use Data. In some instances the economic value of Content is “higher” than that of Use Data, but in other instances the opposite may be the case.
A Rights Holder may decide to add technology in the DCI distributed that will trigger sending back to one or more Rights Holders information about Events related to the use of a given DCI. This is called Event Reporting.
To support different business models Approved Document No. 3 allows a License to be:
· Bundled within the Governed Content (i.e. it is part of the DCI)
· Not Bundled within the Governed Content (i.e. the DCI references an external License).
Approved Document No. 3 allows other Content Elements in the DCI (e.g. Resources) to be in-line or referenced.
The Content Elements in Governed Content can either be in a form that allows immediate Processing, e.g. for Rendering by a Device (so-called Clear-text) or in a protected (i.e. Encrypted) form. To this end Approved Document No. 3 provides various means to convey Keys and related DRM information.
Approved Document No. 3 provides a basic selection of Encryption Tools that can be employed in restricted-capability Devices such as Portable Audio and Video (PAV) Devices (i.e. Devices without direct access to network). However, to support a broader range of applications such as those enabled by Stationary Audio and Video (SAV) Devices (i.e. Devices with network or broadcast access), Approved Document No. 3 also provides the means to Represent in a DCI blocks of executable code (called DRM Tools or DRM Tool Packs) that are required to Process various types of Governed Content.
XML is the technology selected by DMP to Represent Content. XML is very powerful and flexible but Content Represented by means of XML can easily become bulky and unwieldy. Therefore DMP has selected an XML binarisation technology that not only reduces the size of a DCI but also allows simpler Processing in a Device without loss of information.
To handle relationships between Devices, e.g. for the purpose of Access a Content Item or a Licence from a Device, it is necessary to utilise Protocols . In order to Deliver Content between Device Entities it is necessary to Package a DCI (in binary form) and its referenced Resources. Approved Document No. 3 supports 2 forms of Delivery:
1. As File. This is called DMP Content File (DCF);
2. As Stream. This is called DMP Content Broadcast (DCB) in the case of an MPEG-2 Transport Stream, and DMP Content Streaming (DCS), in the case of Real Time Protocol on Internet Protocol.
A designer of a Value-Chain or individual Users may decide set up a Value-Chain that offers Content or Services to other Value-Chain Users. AD3 provides Tools to optimise the effort to achieve this result while maximising flexibility of the resultant Value Chains.
In general Users require Devices to perform the Functions proper of their Role in a Value-Chain. To entrust Content to a Device, however, a Rights Holder must have assurance that the Device will execute Functions according to Approved Document No. 3. This is achieved by having the Device Certified.
Approved Document No. 5 specifies how this task is performed by a number of organisations (Certification Agencies) that are properly appointed and overseen by a single root authority (Certification Authority). DMP appoints the Certification Authority after approving the Authority’s Certification policies. This three-layer arrangement is similar to the one used for Content Registration.
Content Registration Agencies have also the task to Authenticate, i.e. to confirm the identity of a Content Item. A Device wishing to obtain Authentication of a Content Item can either contact the relevant Content Registration Agency by reading the syntax of the Identifier or the Content Registration Authority. The Authority will then direct the Device to the relevant Agency.
In general interacting Devices require the establishment of a Trust relationship between them, e.g. when they Deliver Content between them. A precondition for this to be possible is that a Device be Identified. The task of Assigning Identifiers to Devices is performed by special Devices called Device Identification Devices. Approved Document No. 5 specifies how this task is performed by a number of organisations (Device Registration Agencies) that are appointed and overseen by a single root authority (Device Registration Authority). DMP appoints the Device Registration Authority after approving the Authority’s Registration policies. The same three-layer arrangement used for Certification is also used for Identification.
Other Entities requiring Certification and Identification are: Domain Management Devices (Devices employed to manage Domains), DRM Tools and Users. Note that in the current phase of development Users play a role only to the extent they are represented by devices, e.g. smart cards and that Certification of such devices is out of DMP scope.
In summary:
1. DMP Certification Authorities and Agencies are required for the following Entities:
a. Devices, e.g. Creation Devices, Consumption Devices and Domain Management Devices
b. DRM Tools.
2. DMP Registration Authorities and Agencies are required for the following Entities:
a. Content – License and DRM Tool
b. Devices, e.g. Creation Devices, Consumption Devices and Domain Management Devices.
Note that only once a Device or a DRM Tool has been Certified will it be eligible to be Identified.
In general interacting Devices require Authentication to achieve Trust. Approved Document No. 3 provides Protocols that can be employed to achieve this.
The figure below places the Devices mentioned above in a generic Value-Chain and identifies their principal relationships. Note that in DMP a Device is either a combination of hardware and software – or just an instance of software – that allows a User to execute Functions.

Figure 3 – Some typical Devices in a Value-Chain
In the figure
1. Devices with a yellow colour provide Identifiers to Devices or Content
2. Device with a blue colour is used to make Content
3. Devices with a green colour provide the respective Content Elements
4. Device with an orange colour verifies Roles
5. Devices with a red colour are End-User Devices
6. Device with a violet colour manages Domains
7. Device with a purple colour is a non-DMP device.
The numbers indicate the different Protocol types required for Devices to communicate.
The figure above will be used to describe a full walkthrough.
1. Content Creation Device obtains Identifier from Identification Devices for
a. Resources
b. License
c. DRM Tool
d. Content
2. Content Creation Device makes Content by combining:
a. Resources
b. License
c. DRM Tool
d. Identifiers
3. Content is Delivered to Content Provider Device
4. In case License and DRM Tool are referenced (not Bundled within the Content)
a. License is Delivered to License Provider Device
b. DRM Tool is Delivered to DRM Tool Provider Device
5. An End-User Device (SAV) Accesses
a. Content from Content Provider Device
b. License from License Provider Device if Content does not have a Bundled License
c. DRM Tools from the DRM Tool Provider Device if
i. End-User Device does not already hold the required DRM Tool
ii. DRM Tools are not Bundled within the Content
6. End-User Device (SAV) performs the following according to License Permissions
a. Packages Content as File (DCF)
b. Adapts Resources creating DCI and DCF
c. Moves/Copies DCF to another SAV or End-User Device (PAV) via PXD.
7. PXD performs the following
a. Accesses Content with Bundled Licence (as DCF) from Content Provider Device
b. If Content does not have a Bundled Licence
i. Accesses Licence from Licence Provider Device
ii. Makes DCI
iii. Makes DCF
c. Moves/Copy DCF to PAV
Value-Chains begin with Content Items that represent IP Entities. To ensure that management of Rights associated to IP are consistent, Value Chains must be able to generate copies and variations of Content without breaching the sets of Rights at every point in the Value-Chain. If such an integral treatment of Rights is not achievable in a consistent and reliable fashion, then there is little hope that Rights Holders will entrust Content representing their IP to a Value-Chain. Therefore the DMP has designs its Interoperable DRM Platform so that it can clearly identify the source of all IP and provide the means to represent all Rights associated with IP generated throughout the Value Chain.
Interoperability is key to this endeavour because it enables different IP-based business models of varying scope and depth to run their full course while at the same time providing the means to determine that the Rights expressed within them are adequately supported. Furthermore, interoperability removes the possibility that some Users in the Value Chain be capable of effecting arbitrary control over other Users by virtue of restrictions inherent in the design of technology.
The purpose of the Creation Model is to provide a generic architecture for "Creation" of Content. The model should be able to represent any case where the objects representing IP are Delivered to a Device, Stored or Rendered. For IP to be identified and managed, it is required that it be embodied in human perceivable objects to be communicated, identified and associated with an actual human source. However, the ‘objects’ referred to as ‘having’ IP in this Creation Model are really independent of physical/digital objects in that their existence depends on the mind of their Creators in the first instance although only when they are ‘fixed’ in a physical form, perceivable by other human beings, can the IP be identified and communicated.
Thus, the following objects referred to as IP Entities are defined formally in the DMP Terminology and are pivotal to the DMP vision of how IP is represented by Resources.
Work
It is the first IP Entity to which IP is attributed to in the Creation Model is Work and refers to the fruit of an effort of an individual or group of individuals that constitutes the logical construct that persists independently of the innumerable possible physical representations of that construct. A Work on the one hand can be very specific by being clearly identifiable through a large number of differing Manifestations all of which are perceived as being of the Work yet it is also intangible in that proof of its existence requires physically perceivable materials that are not of the Work.
Adaptation
An Adaptation of a Work is considered a new Work but is of dependent origination in that its existence depends on the existence of another independent Work. The law consistently requires that the Author of an original Work give his consent to the creation and distribution of the new Adaptation of the Work, possibly determining any set of restrictions both moral and economic. Also, the Author of an Adaptation must refer back to the root original Work. Thus, an original Work can spawn any number of Adaptations and Manifestations while an Adaptation can only spawn a singular Manifestation. Note that these requirements are only relevant for Works that are not in public domain.
Manifestation
A Manifestation is an object or event which is an expression of a Work, e.g. the original manuscript of a musical Work. It is clear that in order to establish the authorship of a Work, at least a first initial object – either digital or otherwise – must be produced and unequivocally attributed to the Author of the Work. Such objects are referred to as Manifestations. Although at least one Manifestation must be attributed to the Author of the Work, the Manifestations of Adaptations of a Work are also considered to be Manifestations of the Work. Thus, a given Work may have Manifestations attributable to other Authors.
Instance
An Instance is an object or event which is an example of an Identified Manifestation, e.g. a unique performance of a specific Manifestation of a musical Work. Instances are not necessarily uniquely of a particular Manifestation of a Work. The IP associated with Instances is so inextricably dependent on both the Manifestation and the Work that it is of, that it is classified separately as “Neighbouring” or “Performing” Rights. An Instance when it is fixated to a physical support constitutes the first copy, also referred to as “master”, used to make further copies, e.g. for commercial purposes.
Expression
An expression is the result of a process that an individual undertakes when generating a tangible Manifestation of a Work or that an Instantiator, e.g. a Performer, undertakes when interpreting a particular Manifestation to generate an Instance.
DMP does not currently define the term expression because the Creation Model is presently only concerned with classification of Content as it pertains to associating IP with digital Manifestations and Instances of Works and any attribution of IP for an expression is considered to be un-severable and correspond faithfully to the attribution given for the Manifestation and/or Instance in which they are contained. That is to say, that the owner of any IP attributable to an expression is necessarily the same person or persons to which the Manifestation and/or Instance is attributable.
Thus, in the Creation Model any object either analogue or digital that either embodies or represents IP – for the purpose of attributing IP Rights – can be classified necessarily under one of the categories as listed below in Table 1.
Table 1 – IP Objects and Rights
|
IP Entity |
IP type |
Associated Rights types |
|
Work |
Independent origination |
Creator |
|
Adaptation |
Dependent origination |
Creator |
|
Manifestation |
Dependent origination (Any Manifestation depends on a Work) |
Creator |
|
Instance |
Unique dependent stylistic reproduction |
Neighbouring or performing rights |
Thus, the scope of IP associated with the different IP Entities can be summarized as in Table 2 below. Authorship of a Work (independent origination) has dominion only over all its Manifestations and all Instances, copies, reproductions and communications thereof. Authorship of an Adaptation has dominion only over all its Manifestations, Instances, copies, reproductions and communications thereof. Realization of an Instance has dominion only over all copies and reproductions thereof.
Table 2 – IP Entity Scope
|
|
Entities |
||||
|
Work |
Adaptation |
Manifestation |
Instance |
||
|
IP Type |
Work |
x |
x |
x |
x |
|
Adaptation |
|
x |
x |
x |
|
|
Manifestation |
|
|
x |
x |
|
|
Instance |
|
|
|
x |
|
The figure below illustrates the dependencies between IP Entities.

Figure 4 – IP Entity dependencies
The Creation Model illustrates the process by which IP Entities are generated in terms of natural dependencies derived from the notion of an identifiable first origin of any idea. Thus, the Creation Model defines the relationship between the origin of IP Entities (ultimately residing in the mind of creators) and subsequent dependent IP Entities, Actions, and Roles. The Ontology is able to represent these concepts and their relationships.
The Creation Model is formalised so that IP Entities may be represented digitally irrespective of whether or not they were originally digital in nature. Thus, the RRD represents rights associated with IP in the analogue such as First-fixation, Mechanical-reproduction and Public-communication and associates those rights to corresponding digital functions over Resources. In this way and for example, the Right to make an Instance would correspond to the Right of First-Fixation, the Right to make an Instance-Copy to the Right of Mechanical-reproduction and the Right to stream in a multicast to the Right of Public-communication. Thus, the actions associated with for example REL that are conceived to control access to Resources can be associated with the higher level Rights associated to IP regardless of whether the IP is represented in an analogue or digital form.
Represent Rights Data (RRD) is the digital Representation of the Ontology of IP Entities and associated actions taken upon them as well as those taken on their corresponding digital representations as described in the DMP Creation Model. RRD employs the Ontology Web Language (OWL).
The IP Entities like Work, Adaptation, Manifestation or Instance are linked independently of whether their relationships are represented digitally or otherwise. In the case where objects are represented digitally, Rights over Resources must be made subordinate to the Rights over the IP Entity or Entities being represented. Thus, actions to be taken on digital files Representing different IP Entities must be associated with the hierarchy expressed by the RRD.
Since the ability to perform Functions on media files are agnostic to what those files Represent, only a DRM system can determine what IP is being Represented and how to associate that particular Representation with the set of actions or Functions available. To achieve this, the Metadata used to describe generically the object Represented by a DCI as well as the Resources within it, must be available and coincide with the terms defined in the RRD. Also, Users of Resources may be associated with generic Roles such as Adaptor, Instantiator, End-User etc. when being assigned rights in fully automated IP licensing processes.
Thus, combining both sets of actions plus Roles will allow for the determination of generic default conditions required to invoke different IDP Functions and combinations thereof. For example, a User obtains a Work-Manifestation Item and chooses the standard Role Adaptor. This then could automatically give rise to a standard set of conditions to be fulfilled such as “To Register DCI Adaptation of “Great Blue Work” approval certification XYZ is required.”
The RRD includes all the IP Entities of the Creation Model and adds corresponding Roles and Actions.
There are several levels of representation in digital media. The most common is the representation inherent in common digital files know as Resources i.e. MP3, MP2-4 files etc., that refers to the representation of any entity or event (performance, writing, acting etc.) for the purpose of conveying said event or entity directly to the human senses i.e. sight, hearing etc. through a rendering device.
Resources can be further Represented by using DCIs that provide a standard format for securely communicating all the information pertinent to the Use of a Resource such as its location, required tools to render Resources, Rights Expressions, Metadata etc., so that Resources are never isolated from the means to Use, govern and protect them.
However, DCIs need not be used only to represent Resources but rather can represent other types of entities particularly IP Entities (with or without a Resource). Thus, we may produce equally unique Representations of IP Entities for the purpose of IP management.
The DMP Creation Model extended beyond the IP Entities is sketched in Figure 5 below.

Figure 5 – Extended DMP Creation Model
In Figure 5 and between the creation of the Work and the making of Instances, derivation of IP Entities occurs at two fundamental levels denoted by the verbs: Depend and Use. Use always implies the existence of at least one copy therefore allowing further commercial copies for which rights granting is required. Depend implies a more un-severable relationship that may not necessarily refer to a physically perceivable object; for example, the Work here meant to refer to the logical construct and/or idea expressed in the Work’s physical Manifestations, exists necessarily prior to being so expressed. Therefore, we say that the Manifestation Depends on the Work rather than say that it Uses the Work.
Beginning with the last event of a chain of events, the chaining of Depend, Use and Produce defines generically what the object is (Work, Manifestation, Instance and Copy). Note that although the IP Rights considered in the Creation Model can be invoked as per different jurisdictions, the Produce-Use-Depend chains are expected to remain the same in most if not all cases.
At the end of the Creation Model the final products are copies of the IP Entities that can be communicated. These are as follows:
· Work-Instance-Copy
· Adaptation-Instance-Copy
· Work-Manifestation-Copy
· Adaptation-Manifestation-Copy
These copies constitute the basis IP Representation further down the distribution chain and are what are used in Products.
RRD Functions are divided into two types:
· RRD Functions agnostic to whether or not the relevant IP Entities are represented digitally:
o Create Adaptations: The Function by which an Adaptation is created.
o First Fixation: The Function of making an Instance.
o Synchronization: The Function of concurrently performing/displaying two distinct Works or Adaptation Instances each for a different sense e.g. text and audio or video and song.
o Mechanical Reproduction: The Function of making physical copies of a Product
o Public Communication: The Function of publicly displaying/performing, e.g. live performance, radio, television, internet streaming, multicast of Instances and Manifestations, and download.
o Distribution: the Function of selling, renting and lending of copies.
o Private Copy: The Function of Storing Content and hold it private for non commercial purposes.
· RRD Functions taken on digital files that in their essential nature are agnostic to what the digital objects may represent such as the RRD Functions represented in REL or a DMP Value Chain Functions.
Roles are defined by groupings of RRD Functions realized on objects and therefore the definition of an RRD Function implies the corresponding Role to realize the RRD Function. Six different Roles can be listed: Creator, Adaptor, Instantiator, Producer, Distributor and End-User.
The IP objects can be formalized as an ontology. A digital representation of the DMP Creation Model serves to support the development of applications based on the Creation Model. Since the Creation Model is neutral i.e. represents all Users/Roles, IP Entities and their natural dependencies, it can be used as a common foundation for ascribing rights as defined by any jurisdiction that recognizes the ownership by individuals of original ideas. Thus, such an Ontology constitutes a powerful common core in support of interoperability between Digital Rights Management systems, a central goal of the DMP’s Interoperable DRM Platform.
The RRD is expressed in OWL (Web Ontology Language). A brief summary of the precedents that have led to the tools being used to formalize the RRD follows.
The key concepts that underlie OWL are classes and their relations expressed as properties. Thus, the concepts represented in the DMP Creation Model and their relations are mapped to OWL classes and properties. The official W3C reference of OWL can be found at [46].
“Approved Document No. 3 – Interoperable DRM Platform”, describes in detail how the model here described has been transposed into the OWL Ontology representation.
In the general DMP Distribution Model the following Users operate:
1. Content Providers providing Content to End-Users and Service Providers;
2. License Providers providing Licenses to End-Users and Service Providers;
3. DRM Tool Providers providing DRM Tools to End-Users and Service Providers;
4. Service Providers providing Services to End-Users.

Figure 6 – Conceptual diagram of DMP Distribution Model
A specific Value-Chain need not involve all types of Users indicated in the Figure above, e.g.
1. The Service Provider may Deliver Content to End-Users with License and DRM Tools Bundled within it. In this case the Service Provider makes and Registers a new Content Item out of Content, License and DRM Tools received from other Users. This is represented in the top line of the figure.
2. The Service Provider may not be required as the End-User individually Accesses Content, License and DRM Tools. This is represented by removing the first line of the figure
3. The DRM Tool Provider may not be required, e.g. when Governed Content is Delivered without the use of DRM Tools. This is represented by removing the bottom line in the figure.
Note that the Service Provider makes and Registers a new Content Item out of Content, License and DRM Tools that he receives from other Users.
For the purpose of this specification all types of Data to be Delivered between Device Entities can be Represented as Content Elements, in particular Content, Licenses, DRM Tools and DRM Information. These Content Elements can be variously combined between themselves and other Content Elements.
DCI is a Representation of Content that, along with the relevant Content Elements, can be Processed by a Device. However, DCI is not suitable for Delivering Content between Devices. The Package Function enables Delivery of a Content Item over a variety of specific Delivery mechanisms. Approved Document No. 3 supports Delivery as a File (DCF), on an MPEG-2 Transport Stream (DCB) and on a Real-Time Protocol transport (DCS).
The Package Function includes
· Insert DCI in the selected transport mechanism
· Extract DCI from the selected transport mechanism
The following figure describes the DRM Tool Model.

Figure 7 – Handling of DRM Tools in a Device
Packaged Content is Delivered to a Device because the Device has Accessed it or another Device has Delivered it. The Parser extracts the DCI from the Packaged Content. In general the DCI Parser extracts the following from the DCI:
1. Resources
2. Metadata
3. DRM Information
4. DRM Tools or Tool Packs
5. Licenses
6. Keys.
Resources and Metadata are passed to the appropriate decoding pipelines while DRM Information, DRM Tools or Tool Packs, Licenses and Keys are passed on to the DRM Processor, a module within a Device that executes DRM-related Functions in a Trusted fashion.
The Device may already have all required DRM Tools e.g. because they are:
1. Embedded in the Device
2. Stored after having been previously Accessed
3. Bundled within the Content Item currently Accessed.
If none of the above holds, then the DRM Processor will Access the missing DRM Tools from the DRM Tool Provider Device. Once Used, all DRM Tools are kept in the Secure Storage of the Device.
The DRM Processor controls the critical points internal to a Device. As an example, in the Figure above there are 7 such “control points” (indicated as black nodes). The DRM Processor, using the DRM Information, instantiates the required DRM Tools as plug-in modules (called DRM Tool Bodies), and instructs them to operate on the specific control points along the Resource decoding pipelines.
As described above, DRM Tools represent one or more DRM Functions such as Authenticate, Decrypt, detect watermark signal or extract watermark payload, etc. The DRM Processor handles instantiation, initialisation, Authentication, and supervision of DRM Tools Bodies. However, DRM Tools can also be aggregated into a DRM Tool Group. In this case a DRM Tool Agent performs the same tasks above for the DRM Tools in a DRM Tool Group. The combination of a DRM Tool Agent and its DRM Tool Group is called DRM Tool Pack (see figure below).

Figure 8 – Tool Pack Interoperability
Note that a mandatory requirement for a DRM Processor is that it can interface with DRM Tool Agents and DRM Tools.
By using a DRM Tool Pack, sensitive information about the way a Resource is Governed can be placed in the DRM Tool Agent instead of placing it in the DCI. However, in those cases where a simple DRM Tool configuration is required, e.g. one DRM Tool performing AES Decryption on a Governed video stream, a single DRM Tool configuration may be a simpler option.
Figure 9 and Figure 10 below graphically compare the “stand alone” DRM Tools and. the DRM Tool Pack.
The following is an example of a complete walkthrough of the DRM Tool Model when a DRM Tool Pack is employed:
1. DRM Tool Provider
a. Obtains DRM Tool Pack ID from DRM Tool Identification Device
b. Includes DRM Tool Pack ID in Tool Pack Information with other related Metadata
c. Makes DRM Tool Pack by combining DRM Tool Pack Information, DRM Tool Agent, DRM Tool Group and Signature
d. Stores DRM Tool Pack in DRM Tool Provider Device
2. User Requests Service
3. Service Provider
a. Authenticates User
b. Sends Tool Pack ID and DRM Tool Provider Device’s URL to SAV
4. SAV requests Tool Pack with Tool Pack ID to DRM Tool Provider Device
5. DRM Tool Provider Device Delivers Tool Pack
6. DRM Processor
a. Accesses Tool Pack Information
b. Searches for requested DRM Tool Pack from Secure Storage
c. Executes DRM Tool Agent
d. Sends available Control Points to DRM Tool Agent
7. If User selects more than one Service simultaneously, DRM Processor executes all Tool Agents for each service
8. DRM Tool Agent instantiates DRM Tools, initializes DRM Tools, and connects each DRM Tool to proper Control Point
9. If there is a missing DRM Tool in the DRM Tool Group, DRM Tool Agent requests missing DRM Tool to DRM Processor
10. DRM Processor
a. Searches for missing DRM Tool in the Secure Storage
b. Gives the reference of the DRM Tool to Tool Agent
11. DRM Tool Pack Data contains information to initialize DRM Tools in DRM Tool Group, e.g. Key information for Decryption Tool or seed number for watermarking Tool
12. DRM Processor Accesses DRM Tool Pack Data and sends it to DRM Tool Agent, the only one capable of Parsing DRM Tool Pack Data
13. DRM Tool Agent uses DRM Tool Pack Data to initialise the appropriate DRM Tools in the DRM Tool Group
14. DRM Processor starts Resource decoding
15. DRM Tools perform DRM Functions on Resources
To Update a DRM Tool Pack/Tool in SAV the DRM Tool Provider Device performs the following:
1. DRM Tool Provider Device inserts a DRM Tool/Tool Pack Update message in the DCI
2. DRM Processor
a. Receives Update message
b. Recognises which DRM Tool Pack/Tool should be Updated
c. If DRM Tool Body is contained in the DCI then DRM Processor replaces the Tool Body
d. Else DRM Processor Access DRM Tool Body from DRM Tool Provider
e. Updates proper DRM Tool Pack/Tool according to the Update message
It is convenient to introduce specific Device types that are needed to set up typical Value-Chains:
Table 3 – IDP-2 Device types
|
# |
Device Name |
Acronym |
|
1. |
Device Identification Device |
DID |
|
2. |
Content Creation Device |
CCD |
|
3. |
Content Identification Device |
CID |
|
4. |
Content Provider Device |
CPD |
|
5. |
License Provider Device |
LPD |
|
6. |
Role Verification Device |
RVD |
|
7. |
DRM Tool Provider Device |
DPD |
|
8. |
Domain Management Device |
DMD |
|
9. |
Domain Identification Device |
DoID |
|
10. |
Content Consumption Device |
SAV |
|
11. |
PAV eXternal Device |
PXD |
|
12. |
Content Consumption Device |
PAV |
These are briefly described below
Approved Document No. 3 supports two kinds of Device Identification:
1. “Device info-based identification” in which a Device Identification Device generates the Device Identifier using some vendor specific information such as vendor ID, model ID or product serial number;
2. “Certificate-based identification” in which a X.509 certificate [34], generated by a Device Identification Device, is utilised as Device Identifier.
In a typical CCD walkthrough a Creator activates an application showing a GUI displaying a series of steps that the Creator is invited to follow. Therefore a Creator:
1. Selects the DCI from a number of available DCI templates
2. Gets Resources with corresponding Identifiers, e.g. from outside the CCD
3. Encrypts Resources (optional)
4. Fills the Metadata template for each Resource
5. Obtains Metadata Identifiers (optional)
6. Makes a License, e.g. by selecting one from a number of available License templates
7. Obtains a License Identifier from a License Identification Device
8. Adds License or License information within the DCI
9. Obtains Content Identifier from a Content Identification Device
10. Creates a DCF
11. Stores the DCF on a Content Provider Device.
The current phase of DMP specifications does not provide a Protocol for a Content Creation Device to obtain a Content Identifier.
A Content Creation Device Delivers Content to a Content Provider Device. A Content Consumption Device (SAV or PXD) Accesses Content from a Content Provider Device employing Access Protocols specified by Approved Document No. 3.
In case Licenses are not Bundled within the Content, Licenses are Stored on a License Provider Device and may be Accessed by a Content Consumption Device employing Access Protocols specified by Approved Document No. 3.
In case Content is Licensed to a Domain, the License Provider Device requests appropriate information from the Domain Management Device (see below).
This Device responds to queries made by other Devices to verify the appropriate relationships between Roles, RRD Functions and IP Entities. For instance a Creator by querying the RVD can know all RRD Functions he can execute.
In case DRM Tools are not Bundled within the Content, DRM Tools are Stored on a DRM Tool Provider Device and may be Accessed by a Content Consumption Device employing Access Protocols specified by Approved Document No. 3.
PAV Devices do not have network or broadcast connections to Access Content or License. However, they can be connected to a PAV eXternal Device (PXD) or a SAV, that in turn is connected to a network or broadcast channel. The following figure depicts the relationship between the four relevant Devices.

Figure 11 – A PAV and its PXD
Two cases can be considered
1. In the simplest case the PXD Accesses a Content Item in the form of a DCF with a License Bundled within it. Content can then be Copied/Moved to the PAV Device, without further action by the PXD, using a Protocol that is not specified by DMP.
2. If the PXD obtains a Content Item in the form of a DCF without a Bundled License, the following steps are performed:
To Store Content on a PAV Device the following steps are performed:
1. End-User plugs his PAV to the PXD;
2. End-User activates an application on the PXD that connects the PXD to the PAV;
3. The application displays a list of the DCFs on the PXD that are available for Use on the PAV;
4. End-User selects the DCFs to his liking;
5. End-User activates Move/Copy of those DCFs from PXD to PAV.
To Use Content on the PAV Device the following steps are performed:
1. End-User activates GUI
2. GUI
a. Reads the files Stored in PAV
b. Make a list using information from Metadata in each DCF
3. End-User selects DCF
4. PAV
a. Parses DCF to obtain DCI
b. Parse DCI to obtain
i. License
ii. Metadata
iii. Resource
c. Parses License to obtain DRM Information
5. GUI displays the list of Functions that can be executed and Metadata
6. User selects the Function
7. PAV
a. Decrypts Resource
b. Decodes Resource
c. Renders Resources.
Once a SAV has Accessed the Content, and the necessary License and DRM Tools using the Access Protocols specified in Approved Document No. 3, it can Use the Content, e.g. Play, Store or Adapt it in the SAV or Move/Copy the Content or its Adaptation to another SAV or PAV as per License terms.
These are Functions a SAV Device performs on a Content Item, in addition to the steps listed in the walkthrough of the DRM Tool Model:
1. Decrypt Resources
2. Decode (decompress) Resources
3. Deliver decompressed Resources for Rendering
4. Create DCF with Bundled License
5. Store DCF
6. Move or Copy the DCF to another SAV or a PAV
7. Adapt Content
8. Encrypt Resources.
The figure below is a conceptual model of a SAV

Figure 12 – Conceptual model of a SAV
In many instances a SAV interacts with other Devices through Interfaces defined as in the figure above. In other instances it may be useful to define interfaces between processing elements such as the DRM Processor and the Resource Processor of Fig. 13.


Figure 13 – DRM Processor and Resource Processor in a SAV
A separation between the Resource Processor and the DRM Processor increases flexibility as the vendor of the Resource Processor does not need to be concerned with the various types of DRM Processors. Likewise, the vendor of the DRM Processor does not have to be concerned with the properties of each Resource Processor. As a result, this architecture reduces the cost of integrating the DRM and Resource Processors. To achieve this, a standard Interface between both Processors and an appropriate Protocol is essential.
See Domain Model below.
See Domain Model below.
Device Certification Agencies have the task of checking the implementation of a Device and Certify that it can be Trusted up to a certain level. While a pure software implementation satisfies the DMP definition of Device, it is clear that, to operate, a complete Device must be complemented by a hardware component.
The Trusted Computing Group (TCG) has issued specification of a trusted computing platform consisting of two stacks, one is the software stack which is called “Trusted Software Stack (TSS)” and the other one is the hardware stack called “Trusted Platform Module (TPM)”. The TCG model is compatible with the DMP model in that both the TSS and the TSS can be “Devices”.
In the following some information on the TCG model is provided to clarify the role of the DMP reference software (Chillout).
The TPM provides four main functionalities implemented as hardware stack:
1. System integrity evaluation: a TPM can find that the BIOS, the OS or the software is falsified by storing the hash of these software stacks when they are correct;
2. Platform certification: a TPM can generate a secret key and store it securely in order to ensure that the correct TPM is used;
3. Secure storage: to store encryption keys, which is super-ciphered by TPM secret key;
4. Crypt-coprocessor: this contains RSA engine, Random Number Generator, Hash and so on..
TPM functionalities can be used through TSS software stacks, the APIs of which are also defined by TCG.
Devices can store any number of encryption Keys in the secure storage of the TPM. When a Device wishes to store a Keys, an application can use the TPM secret Key in order to encrypt them.

Figure 14 – Secure key storage
The hashes of the BIOS, OS and software stacks are registered in the PCR (Platform Configuration Register). So if a Device needs to Verify the TPM it requests the value of the PCR and compares it with the value of the PCR stored at the time it was shipped. If the received value of the PCR is equivalent to the stored value of the PCR, Verification succeeds.

Figure 15 – TPM Verification
In order to use the TCP, Devices should only use the TSS API when they wish to use TPM functions.
The Chillout Reference Implementation is a Java based software. A TSS Java wrapper is available as Open Source software. The trusted computing architecture is shown in Fig.15.

Figure 16 – Java based trusted computing
If the DMP Reference Software (Chillout) will adopt trusted computing technology, most of the existing software stacks are still useful. However, when Chillout stacks uses TPM functions, Chillout stacks should provide the functionality to use the TSS API.
Domains are groups of Devices or Users sharing some common properties. Using Domains it becomes possible to implement more flexible Licensing modalities, e.g. to License a Content Item to all Devices or Users in a Domain. A Domain is managed by a special Device called Domain Management Device.
The figure below represents a possible Domain configuration with:
1. Two Devices (SAV), belonging to two different End-Users;
2. One Device (PAV) belonging to another End-User connected to the network via a PXD;
3. One Device (SAV) belonging to another End-User and remotely connected to the other Devices in the Domain via the Internet.

Figure 17 – An example of Domain
In general 5 Device types are required to manage a Domain:
1. Domain Management Devices (DMD), to manage the life cycle of Domains and the list of Devices and Users belonging to the Domains;
2. Domain Identification Devices (DoID), to Assign Globally Unique Identifiers (GUID) to DMDs on behalf of Domain Registration Agencies;
3. End User Devices (EUD), e.g. SAV or PXD;
4. Users, bearing in mind that Users are represented by e.g. a device (smart card etc.) or an identity on a Device (UN/PW etc.);
5. License Provider Devices (LPD) to provide Licenses including for Use of Content in a Domain.
The combined operation of these Devices can be shown by a simple walkthrough in the figure below:

Figure 18 – The relationship of the 5 Device types in Manage Domain
1. A User (Domain Administrator) requests DMD to create a Domain
2. DMD
a. Creates Domain
b. Obtains Domain ID from Domain Identification Device;
c. Creates Domain Information containing Device/User list, maximum number of Devices/Users etc.;
d. Creates Domain Context for Device/User containing Domain ID, DMD ID, Domain Private Key, expiration etc.;
e. Delivers AccessID and AccessPassword to Domain Administrator;
f. Delivers Domain Context for Device/User to Device/User;
3. Device/User requests License to License Provider Device giving Domain ID;
4. License Provider Device sends Domain ID to DMD;
5. DMD Delivers Domain Public Key to LPD;
6. License Provider Device makes and Delivers License to Device/User.
Note: A Domain Management Device can manage one or several Domains. Ownership of a DMD can be implemented using a variety of mechanisms, e.g. End-User based or Service Provider based.
The DMP specifications enable Users to set up Value Chains and perform Functions in an Interoperable fashion. There may be, however, cases in which a Device needs to access governed content from a value-chain. An example, explicitly considered by Approved Document No. 3, is when a SAV accesses governed content broadcasted with a license expressed using the RMPI Rights Expression Language [35].
In this case a Device performs the following steps:
1. accesses content
2. translates license into a License
3. makes DCF using the received Resources, Metadata and the License just made
4. Stores DCF.
Approved Document No. 3 specifies the Tools to convert a license expressed using RMPI to a License.
Using a similar process a DCF with an appropriate License can be Exported to a device.
Approved Document No. 3 specifies the Representation of the following data types:
Table 4 – IDP-2 Data types
|
Content |
A DMP-defined structure of Content Elements, i.e. Resource, Metadata, Content, License, DRM Information, DRM Tool and Use Data |
|
Identifier |
The unique signifier Assigned by Identification |
|
Resource |
Data, whose Representation is not specified by DMP (e.g. an MP3 file or an executable code), that can be Processed by a Device |
|
Metadata |
Data that describe Content and Content Elements |
|
DRM Information |
Data that describe Governance of Content |
|
DRM Tool |
An algorithm which implements one or more DRM Functions |
|
DRM Tool Body |
An executable computer code that implements a DRM Tool |
|
Licence |
Data Representing the Permissions to a Content Entity under given Conditions expressed by Rights Expressions that are Granted by one User to another User |
|
Key |
Data used by a cryptographic method to make Clear-text Data Encrypted or, conversely, Encrypted Data Clear-text |
|
DRM Message |
A message exchanged between DRM Tool Bodies, DRM Processor and Devices |
|
Device Information |
Data characterising a Device, e.g. CPU, OS etc. |
|
Domain Information |
Data characterising a Domain that is Stored in a Domain Management Device, e.g. the list of Devices, Users, Domain Key etc. |
|
Use Data |
Data documenting the Functions performed by a Device Entity on a Content Item and the associated context |
|
DCI Signature |
Data Encrypted with a Private Key and appended to a DCI for the purpose of guaranteeing the Integrity of the DCI |
|
DCI Hash |
A number generated by applying a mathematical formula to a DCI |
The following table describes which Content Elements can be contained in another Content Element
Table 5 – IDP-2 Content Elements
|
Content Elements |
Content Elements contained |
|
Content |
· Identifier · Resources · Metadata · DRM Information · DRM Tool · DRM Tool Body · License · Key · DRM Message · Authentication Message · Device Information · Domain Information · Use Data · DCI Signature · DCI Hash |
|
Identifier |
|
|
Resources |
· Identifier · Metadata · DRM Information |
|
Metadata |
· DRM Information |
|
DRM Information |
· DRM Tool · License · Key |
|
DRM Tool |
· DRM Tool Body · Device Information · DRM Message |
|
DRM Tool Body |
|
|
License |
· Key |
|
Key |
|
|
DRM Message |
· Key · Authentication Message |
|
Device Information |
|
|
Domain Information |
· Key |
|
Use Data |
|
|
DCI Signature |
· Key |
|
DCI Hash |
|
This section provides a high-level description of the three types of Tools specified by Approved Document No. 3: Represent, Protocols and Package.
The digital Representation of Content is called DMP Content Information (DCI). The DCI is an XML structure specifying Content Identifiers, DMP-specific information, DRM information and Licenses with Content and Content Elements. See figure below for a graphical representation of a particular DCI.

Figure 19 – An example of DMP Content Information (DCI)
Approved Document No. 3 adopts a subset of the MPEG-21 Digital Item Declaration for the DCI [21].
To be Used in Value-Chains, Content Items should be unambiguously Identified for a given lifetime and within pre-assigned boundaries. Allocation of Identifier achieves this goal if the following aspects are guaranteed:
1. Persistence, i.e. the Identifier should be used as a reference to the Content Item even beyond the lifetime of the Content Item it Identifies
2. Uniqueness, i.e. the Identifier should be used across Users or globally.
Every Content Item expressed by a DCI contains a unique Identifier Assigned by a special type of User (Registration Agency). Approved Document No. 3 provides ways to Identify a Resource by means of its original Identifier inside the DCI (e.g. ISWC, ISRC) or other Metadata.
Approved Document No. 3 bases its Data Identification on the principles of MPEG-21 Digital Item Identification [22].
Resources can be typical media resources, but also DRM Tools, i.e. the executable code that is needed by a Device to Process protected Resources. As Creation and Identification of Resources are outside of the current scope of Approved Document No. 3, no Tools to Represent and Identify Resources are provided.
Approved Document No. 3 adopts a subset of TV Anytime Metadata [35] as the default Metadata specification for Media Resources. Note that AD 3 supports the use of other metadata schemes.
DRM Information is the set of data resulting from implementing the rules to manage and protect any part of a DCI. It may include any information in the DCI, e.g.:
· Content Governance Information, including the signalling of the DRM Tools required to Access Content
· Decryption Keys
· Licenses
· Data for DRM Tools’ initialisation and configuration
· Appropriate Metadata
· Etc.
DMP calls an executable computer code that implements a DRM Function a “DRM Tool Body”. This may be resident in a Device or contained or referenced in a DCI.
Approved Document No. 3 can support a wide range of business models ranging from the simple and straightforward usage models currently familiar to End-Users to innovative and possibly even speculative business models. Therefore the expression of Rights that may be required between any Users in a Value Chain and the nature and complexity of the Rights expressed may be dependent upon the role of the Users involved in this exchange.
In a Governed Content Item, the relevant Governance information is expressed within the DCI or referenced using Permissions expressed in REL statements. In order to be able to Access Governed and protected Resources, the User is required to have obtained the necessary Keys and Certificates as stipulated by the License. If the Keys are not Bundled within the DCI, they can be obtained as stipulated by the License Provider.
DMP employs two Profiles of the MPEG-21 Rights Expression Language (REL). The first (core profile) can be used in reduced-capability Devices such as PAVs. IDP-2 extends the MPEG-21 REL Dissemination and Capture (DAC) Profile [25], in order to support DMP Domain requirements.
The one-to-one association of Licenses to Content Items may entail significant logistic problems. Therefore IDP-2 also provides Tools to support alternative License distribution scenarios:
Table 6 – License Distribution Scenarios
|
License to |
Description |
Issues |
|
1 Device |
A Content Item is Licensed for Use on one specific Device. |
Device requires a unique ID or certificate. Content must be re-Licensed for each new Device. |
|
N Devices |
A Content Item is Licensed for Use on multiple Devices. |
Same as single Device. Reduced need to re-License Content as it can be Used on more than one Device. |
|
Domain |
A Content Item is Licensed to a Domain, i.e. Content can be Used on any Device within that Domain. |
Content does not need to be re-Licensed, rather a Device needs to join the Domain. IDP-2 provides specifications for Tools to join and leave a Domain. |
A Key is Data used by a cryptographic method to make Clear-text Data Encrypted or, conversely, Encrypted Data Clear-text. It can be resident in a secure storage of a Device or be carried by a DCI.
Currently DMP defines Use Data for the purpose of Domain Management.
The following Entities require Identification:
1. Content
2. DRM Tool
3. Device
4. User
5. Domain
Currently Approved Document No. 3 only specifies the Representation of Content Identification, not the Protocol to request Content Identification.
Currently Approved Document No. 3 only specifies the Representation of DRM Tool Identification, not the Protocol to request DRM Tool Identification.
Device Identification is used for following purposes:
|
Authentication |
The Licence Provider needs to verify that the target Device can properly Use Governed Content, i.e. the Licence Provider needs the Device Identifier to enable Authentication |
|
Authorisation |
The Device Identifier is important information for a User with appropriate authority to allow or disallow specific Devices to Render Governed content |
|
Domain Management |
The Device Identifier is used to Identify Devices belonging to a specific Domain in which various Devices can be Registered and managed |
|
Audit |
The Device Identifier is used to Identify participant Devices on Use of Governed Content if the audit record needs to be kept |
|
License Backup/Restore |
Use of Governed Content is controlled by the License that specifies allowed Device(s). The Device Identifier is used to Identify dedicated Device on Backup or Restoration of the License |
Approved Document No. 3 provides Protocols supporting two kinds of Device Identification:
1. “Device info-based identification” in which a Device Identification Device generates the Device Identifier using some vendor specific information;
2. “Certificate-based identification” in which a Certificate is utilised for Device Identifier.
User Identification is outside the scope of DMP.
Domain Identification is performed by a Domain Identification Device. Currently Approved Document No. 3 does not specify the Protocol for a Domain Management Device to request Domain Identification.
The following Entities: Devices, Users and DRM Tools need to establish Trust between themselves before they may perform DRM-related Functions.
Approved Document No. 3 specifies a Protocol to Authenticate Devices having unique Certificates.
User Authentication is outside the scope of DMP.
These Protocols are currently part of Manage DRM Tool Protocols.
This includes the following Protocols:
1. Protocol to Negotiate Licence to Use a Content Item
2. Protocol to Negotiate Licence to Use a Use Data Item
3. Protocol to jointly Negotiate Licence to Use a Content Item against a Licence to Use a Use Data Item
These Protocols are currently unspecified.
The following Protocols are required by the IDP to Deliver Content. Those marked in normal are provided by Approved Document No. 3, Those marked in italic will be provided by future versions.
Table 7 – Definitions of types of Delivery
|
Store |
The Function by which Device A Delivers Content to Device B for the purpose of retaining it in Device B for Use at a different point in time |
|
Move |
The Function consisting of the following actions 1. Copy of Content from a source Device to a destination Device 2. Deletion of said Content in the source Device |
|
Copy |
The Function that 1. Duplicates Content 2. Delivers the duplicate to another Device |
|
Export |
The Function of making available a Content Item to a non-DMP DRM system |
|
Backup |
The Function that supports 1. Duplication of Content 2. Duplication of Rights Expression in case this is a Stateless Rights Expression, and 3. Moving the duplicate(s) to another location that is not a Device |
|
Access |
The Function executed by a Device when making Content available to so that the Device can execute Functions on it |
|
Import |
The Function of Accessing a governed content item from a non-DMP DRM system |
|
Restore |
The Function of Moving Content and the associated Stateless Rights Expression, if any, to the Device from which Backup had been performed |
Approved Document No. 3provides the following Access Protocols:
1. Protocol to Access Content as File
2. Protocol to Access License as File
3. Protocol to Access DRM Tool Body as File
4. Protocol to Access DRM Tool Body as Stream
5. Protocols to Access Key as Stream
Additionally the following Local Access Protocols are defined
1. Local License Access Protocol
2. Local DRM Tool Body Access Protocol
To facilitate the cooperation of multiple DRM Tools to perform DRM-related Functions on Governed Resources, Approved Document No. 3 provides a message-based architecture. Such messages are XML structures allowing the exchange of information between various components of a Device, e.g. the DRM Processor and a DRM Tool, or between two DRM Tools.
The following is a non-exhaustive list of Functions enabled by the messages defined in DMP Manage DRM Tool namespace:
· A DRM Tool may require to be informed of all the other DRM Tools operating at any time
· A DRM Tool may require to be notified when a new DRM Tool is instantiated
· A DRM Tool may require the instantiation of another DRM Tool
· A DRM Tool may require the termination of another DRM Tool
· A License or any part of it may be exchanged between two parties
· A Decryption Key, along with the timing information about its use, may be exchanged between two parties
· The results of a watermarking operation may be communicated
· Two DRM Tools may mutually authenticate
Approved Document #3 provides a set of protocols that can be used to manage a Domain. See Domain Model.
For the purpose of Delivery, Content typically needs to be Packaged. Currently Approved Document #3 provides Tools to Package Content for File (DCF), Broadcast (DCB) and Stream (DCS).
The file contains the DCI with some or all of the Resources it references in ‘Boxes’ defined by the ISO Base Media File Format and the MPEG-21 File Format [28]. The link between the DCI (containing Metadata and Governance information) and the Resources is done through the Item Location Box, which specifies the physical location in the file of a Resource described in the DCI.
This is represented in the figure below.

Figure 20 – Conceptual diagram of DMP Content Format (DCF)
A number of transport mechanisms may be employed to transmit digitally Represented Content (DCI) between Devices. Currently those of highest relevance are the MPEG-2 Transport Stream (MPEG-2 TS) and the Real-Time Protocol over User Datagram Protocol over Internet Protocol (RTP/UDP/IP). When using these packet-based transmission protocols, Content must be packetised and then transmitted incrementally to the receiving Device. As Content is a combination of Content Elements, transmitting Content in a streaming fashion implies packetisation of its Content Elements.
Approved Document No. 3 specifies the means to incrementally transmit a DCI (including its component Content Elements, either referenced or included) in a piece-wise fashion and with temporal constraints in such a way that a receiving Device may incrementally Use the DCI. At the receiving end, a potentially fragmented DCI is received, where, for instance, some parts may have been removed or transformed at the transmitting end according to some rules.
Package Content as a Stream is based on MPEG-21 Digital Item Streaming (DIS) [30]. The DIS standard specifies a Bitstream Binding Language (BBL) using which it is possible to describe how a DCI may be broken down for transmission and then mapped to the transmission channels of interest: MPEG-2 Transport Streams and RTP/UDP/IP.
There are two basic types of BBL document: Instance and Binding descriptions.
1. Instance describes the streaming instructions for a DCI and contains references to the DCI and any other resources of the DCI. References may be URIs, or pointers to the location of the URI within the DCI.
2. Binding provides the abstract mapping of the DCI or part thereof to the particular set of output streams (MPEG-2 TS and RTP/UDP/IP). Bindings are instantiated as part of an Instance document, which provides the URI references for the fragments of Content to which the Binding(s) are to be applied.

Figure 21: Streaming a DCI using Digital Item Streaming
Binding is a set of abstract Bitstream Binding Language instructions which map a DCI into a collection of packets to be output to one or more handlers, as shown the Figure above.
DIS can also be used to Package binary objects over a streaming protocol. BBL uses BS Schema from MPEG-21 Digital Item Adaptation (DIA) [27] to specify the structure of binary resources which are to be streamed using BBL. This enables fragments of a binary resource to be specified using XPath [44] references.
1. The figure below shows an example DCI related to TV program P1.

Figure 22 – Conceptual diagram of DMP Content Broadcast (DCB)
In this example Program P1 is composed of:
1. Metadata of the TV program P1 (green box)
2. Metadata of the video stream (DMP Infored box)
3. Pointer to the video stream in the MPEG-2 Transport Stream
4. Metadata of the associated audio stream (DMP Infolight blue box)
5. Pointer to the audio stream in the MPEG-2 Transport Stream
6. Metadata of the audio-visual stream (DMP Info)
7. License of the audio-visual stream
8. Metadata of the DRM Tools (DRM Info)
9. The actual DRM Tools carried as Resources in the DCI.
P1 is Governed as a whole, therefore only one single license and a single DRM Information element are needed. An alternative DRM configuration not contemplated in this figure but still possible using IDP-2 Tools shows Resources Governed individually by an appropriate License and each characterised by appropriate DRM Information.
Approved Document No. 3 provides Tools to carry DCB on MPEG-2 Transport Stream.
In the figure below the DCI of Content streamed comprises
1. Metadata of the streaming Content as a whole
2. Metadata of the video stream (DMP Info)
3. Pointer to the video stream in the RTP Stream
4. Metadata of the associated audio stream (DMP Info)
5. Pointer to the audio stream in the RTP Stream
6. Descriptor of streaming text
7. Pointer to the streaming text in the RTP Stream
8. License of the Governed video stream
9. Metadata of the DRM Tools (DRM Information) Governing the video Resource
10. The actual DRM Tools for the Video Resource carried as Resources in the DCI.

Figure 23 – Conceptual diagram of DMP Content Streaming (DCS)
Approved Document No. 3 provides Tools to carry DCS on RTP.
This Approved Document No. 3 – Interoperable DRM Platform (IDP), provides specifications of basic standard technologies – called Tools – that are required to build Value-Chains. Examples of Value-Chains can be found in Approved Document No. 4 – Use Cases and Value-Chains – where it is shown how a selected number of Use Cases can be implemented employing Tools specified in this Approved Document No. 3. Of course other Value-Chains of interest to Users can be implemented employing IDP Tools.
For ease of treatment Tools are grouped in categories. In this Phase 3.0 of IDP (IDP-3.0) the following categories of Tools are specified:
1. Represent
o Content
o Metadata
o DCI Signature
o DCI Hash
o Identifier
o Resources
o DRM Information
o DRM Tool
o DRM Tool Body
o License
o Key
o DRM Messages
o Authentication Messages
o Device Information
o Domain
o Domain Protocols
o Use Data
o Access Protocols
o Binary XML
2. Protocols
o Identify
§ Device
§ User
o Authenticate
§ Device
§ User
o Manage
§ Domain
§ DRM Tool
o Access
§ Content
§ License
§ DRM Tool Body
§ Key
3. Package
o Content as File
o Content as Stream
In this Approved Document “chapters” will deal with categories and “sections” with “Tools”.
Whenever possible DMP Approved Documents do not specify new technologies, but adopt existing technologies. Therefore a number of Tools specified in this Approved Document contain references, restrictions, extensions or adaptations of technologies already standardised by other bodies. There are, however, also cases of technologies that are originally specified in this Approved Document.
Proper understanding of this Approved Document is facilitated by a careful reading of the Foreword to the Approved Document No. 3, of Approved Document No. 2 – Architecture and of Approved Document No. 6 – Terminology. Introductory information on some referenced standards, recommendations and specifications is provided in Annex A. However, proper understanding requires working knowledge of such referenced documents.
In this specification, the term Represent is used to describe the function of expressing information in a form that can be processed by a machine. This information relates to DMP Content Elements by conveying parameters and values between machines associated with the Content Elements.
This chapter specifies how to Represent various DMP Content Elements, some of their components and other Data that can be exchanged between Users. These are listed in the following table.
Table 8 – Data Represented in this specification
|
Content |
The overall structure of Content Elements and their components. |
|
Metadata |
Metadata Representation within Content and a DMP Format |
|
DCI Signature |
Description of the digital Signature of the DCI and representation within Content |
|
DCI Hash |
Description of the Hash of the DCI and representation within Content |
|
Identifier |
Description of Identifier format and representation within Content |
|
Resource |
Description of Resource Elements as an element within Content |
|
DRM Information |
The grouping together of information associated with the Governance of Content |
|
DRM Tool |
Software modules performing one or more DRM Functions such as Authentication, Decryption, watermarking, etc. |
|
DRM Tool Body |
Data associated with specific instantiation of DRM Tools |
|
License |
The representation of the DMP License |
|
Key |
The representation of the Key data |
|
DRM Messages |
Messages exchanged between DRM Tools or between a DRM Tool and a DRM Processor. |
|
Authentication Messages |
Messages exchanged between two entities to mutually Authenticate |
|
Device Information |
The parameters required to describe the Device characteristics |
|
Domain |
Information relating to the management of Domains |
|
Domain Protocols |
Information exchanged between Devices while performing Domain-related Protocols |
|
Use Data |
The Use data Representation |
|
Access Protocols |
Information exchanged between Devices while performing Access-related Protocols |
|
Binary XML |
A format for Representing Binarised XML |
The Representation of the Content and Content Elements is made up of XML schema, defined using the W3C XML schema language as specified in [44].
This Represent Section specifies a number of XML Schema, some of which are devised by the DMP and some of which are profiles of existing specifications or are adopted directly from existing specifications.
The table below summarises the namespace URIs of the schemas developed by the DMP. The column on the left indicates in which phase of IDP the schema has been developed. The column on the right indicates the namespace prefix used within this specification.
Table 9 – URIs of DMP-defined schemas.
|
Namespace URI |
Namespace prefix |
|
urn:dmp:idp:mediastreaming:accessprotocol:extensions:2007 |
dmp-msapx |
|
urn:dmp:idp:Represent:ContentIdentifierProtocol:2007 |
dmprcip |
|
urn:dmp:idp:Represent:DeviceIdentifierProtocol:2007 |
dmprdip |
|
urn:dmp:idp:Represent:License:2007 |
dmprl |
|
urn:dmp:idp:Represent:StoreContentProtocol:2007 |
dmprscp |
|
urn:dmp:idp:Represent:StoreLicenseProtocol:2007 |
dmprslp |
The following table summarises the namespace URIs of those schemas referenced by this specification.
Table 10 – URIs of referenced schemas
|
Namespace URI |
Namespace prefix |
|
urn:mpeg:mpeg21:2007:01-BBL-NS |
bbl |
|
urn:mpeg:mpeg21:2003:01-DIA-NS |
dia |
|
urn:mpeg:mpeg21:2006:07-DIDL-NS |
didl-msaf |
|
urn:mpeg:maf:schema:mediastreaming:DIDLextensions |
didl-msx |
|
urn:mpeg:mpeg21:2002:02-DIDMODEL-NS |
didmodel |
|
urn:mpeg:mpeg21:2002:01-DII-NS |
dii-msaf |
|
urn:mpeg:mpeg21:2005:01-ERL-NS |
erl |
|
urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS |
ipmpdidl-msaf |
|
urn:mpeg:mpeg21:2004:01-IPMPINFO-NS |
ipmpinfo-msaf |
|
urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007 |
ipmpinfo-msx |
|
urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007 |
ipmpmsg |
|
urn:mpeg:mpeg4:IPMPSchema:2002 |
mpeg4ipmp |
|
urn:mpeg:mpeg7:schema:2001 |
mpeg7smp |
|
urn:mpeg:mpeg7:smp:schema:2001 |
mpeg7smp |
|
urn:mpeg:maf:schema:mediastreaming:accessprotocol:2007 |
msap |
|
urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007 |
msbp |
|
urn:mpeg:maf:schema:mediastreaming:domain:2007 |
msd |
|
urn:mpeg:maf:schema:mediastreaming:domainprotocol:2007 |
msdp |
|
urn:mpeg:mpeg21:2005:01-REL-M1X-NS (*) |
rel-m1x-msaf |
|
urn:mpeg:mpeg21:2006:01-REL-M2X-NS |
rel-m2x |
|
urn:mpeg:mpeg21:2006:01-REL-M3X-NS |
rel-m3x |
|
urn:mpeg:mpeg21:2003:01-REL-MX-NS (*) |
rel-mx-msaf |
|
urn:mpeg:mpeg21:2003:01-REL-R-NS (*) |
rel-r-msaf |
|
urn:mpeg:mpeg21:2003:01-REL-SX-NS (*) |
rel-sx-msaf |
|
urn:tva:metadata:2002 |
tva |
|
urn:mpeg:maf:Profile:mediastreaming:tva:2007 |
tva-msaf |
|
urn:mpeg:mpeg21:2003:01-DIA-NS |
ued |
|
http://www.w3.org/2000/09/xmldsig# |
dsig |
|
http://www.w3.org/2001/04/xmlenc# |
xenc |
(*) These namespaces refer to the REL schemas with validation rules defined in [25] joined with those defined in [26].
Represent Content defines the basic structure for any information related to Content, which may contain, in turn, a number of other Represent technologies. The Figure in Approved Document #2 Architecture provides an example of the hierarchy of the “Represent” technologies, when these are employed to Represent Content.
The actual hierarchy may differ depending on the structure of each Content Item, e.g. the order in which the various “Represent” technologies are employed. Also the Representation of different Content Elements may:
1. recur more than once in a Content Item
2. not recur at all
3. appear in different places depending on the hierarchy
See, for example the block “Represent Key” which appears nested in two different Represent blocks.
DMP defines Content as a structured combination of Content Elements. The Representation of these elements is specified in the remaining parts of the Represent chapter. When represented together these elements are ordered within a larger framework specified here as Represent Content.
DMP refers to the Content Representation Tool as “DMP Content Information” (DCI).
Specifically, this section provides the means to:
· convey Identifiers of Content and Content Elements
· associate DMP-specific information and Metadata with Content and Content Elements
· associate DRM Information with Content and Content Elements including
o DRM Tools,
o Licenses
o Device Information
o Keys
· associate digital signatures with the DCI
· associate hash values with the DCI
Note that the Represent Content Tool defined here enables the organisation of the Content Elements that together make up the Content and is independent from the Packaging used for Content Delivery, i.e. file, broadcast or network transport.
The DCI is an XML structure, based on the MPEG-21 Digital Item Declaration Language (DIDL) [21], in particular by the DIDL profile and extensions defined by the Media Streaming Application Format standard (MSAF) [31]. Annex A provides introductory information on the Digital Item Declaration Language.
In its entirety, the DMP Content Information (DCI) consists of both the Representation of the various DMP ‘Tools’ and the DCI framework for assembling these Represented Elements as Content. The following sub sections describe the locations of Content Elements Represented by this specification within the DCI XML structure. The description of the Representation of these Content Elements follows later in the subsequent parts of this section.
The top level element in a DCI is always a didl-msaf:DIDL element, except in those cases where a DCI is nested within another DCI, in which case the top-level element of the nested component is a didl-msaf:Item element. The didl-msaf:DIDL element is specified in the figure below:
<element name="DIDL" type="didl-msaf:DIDLType"/>
<complexType name="DIDLType">
<sequence>
<element ref="didl-msaf:DIDLInfo" minOccurs="0" maxOccurs="unbounded"/>
<element ref="didmodel:Item"/>
</sequence>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
Figure 24 The didl-msaf:DIDL element
A didl-msaf:DIDL element may contain any number of didl-msaf:DIDLInfo elements and one didmodel:Item. The DIDL element can have an arbitrary number of attributes from a namespace other than the target namespace or from a null namespace.
The didl-msaf:DIDLInfo element is specified in the figure below below:
<element name="DIDLInfo" type="didl-msaf:DIDLInfoType"/>
<complexType name="DIDLInfoType">
<sequence>
<element name="DISignature" type="dsig:SignatureType"/>
</sequence>
</complexType>
Figure 25 The didl-msaf:DIDLInfo element
The DIDLInfo element may contain a Digital Signature associated with the DCI or parts thereof.
A didl-msaf:Item is specified below:
<element name="Item" type="didl-msaf:ItemType" substitutionGroup="didmodel:Item"/>
<complexType name="ItemType">
<complexContent>
<extension base="didmodel:ItemType">
<sequence>
<element ref="didmodel:Descriptor" minOccurs="0" maxOccurs="unbounded"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="didmodel:Item"/>
<element ref="didmodel:Component"/>
</choice>
</sequence>
<attributeGroup ref="didl-msaf:ID_ATTRS"/>
</extension>
</complexContent>
</complexType>
Figure 26 The didl-msaf:Item element
A didl-msaf:Item element may contain one or more didl-msaf:Descriptor elements, and zero or more choices between a didl-msaf:Item and a didl-msaf:Component element. A top-level didl-msaf:Item element Represents the Content Item. A didl-msaf:Item element child of another didl-msaf:Item element Represents a Content Element, eg a Resource or another Content Item.
A didl-msaf:Descriptor is specified below:
<element name="Descriptor" type="didl-msaf:DescriptorType" substitutionGroup="didmodel:Descriptor"/>
<complexType name="DescriptorType">
<complexContent>
<extension base="didmodel:DescriptorType">
<sequence>
<element ref="didmodel:Statement"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 27 The didl-msaf:Descriptor element
A didl-msaf:Descriptor element is a container for a didl-msaf:Statement element.
A didl-msaf:Statement is specified below:
<element name="Statement" type="didl-msaf:StatementType" substitutionGroup="didmodel:Statement"/>
<complexType name="StatementType" mixed="true">
<complexContent mixed="true">
<extension base="didmodel:StatementType">
<sequence>
<choice>
<element ref="dii-msaf:Identifier"/>
<element ref="dii-msaf:RelatedIdentifier"/>
<element ref="didl-msx:Metadata"/>
<element ref="ipmpinfo-msaf:IPMPGeneralInfoDescriptor"/>
<element name="ContentElementSignature" type="dsig:SignatureType"/>
</choice>
</sequence>
<attribute name="mimeType" type="string"/>
<attribute name="ref" type="anyURI"/>
</extension>
</complexContent>
</complexType>
Figure 28 The didl-msaf:Statement element
A didl-msaf:Statement element can contain any of the following:
For each didl-msaf:Statement element it is possible to specify a mimeType attribute specifying the mimeType of the content of the Statement, and a URI for the schema in use within the Statement.
A didl-msaf:Component is specified below:
<element name="Component" type="didl-msaf:ComponentType" substitutionGroup="didmodel:Component"/>
<complexType name="ComponentType">
<complexContent>
<extension base="didmodel:ComponentType">
<sequence>
<element ref="didmodel:Resource" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 29 The didl-msaf:Component element
The didl-msaf:Component element is a container for one or more didmodel:Resource elements. See 3.2.6 – Represent Resource for more information.
This sub section describes the location of the Content Identifier in the DCI. Other aspects of Content Identification, namely Represent Identifier (syntax) and Protocol to Assign Identifier to Content are specified in Sections 3.2.5 and 3.3.1, respectively.
The Identifier for a Content Item is located within the DCI according to MPEG-21 Digital Item Identification [22] as shown in the example below.
<didl-msaf:DIDL>
<didl-msaf:Item> <!--This item refers to the Content Item-->
<didl-msaf:Descriptor>
<didl-msaf:Statement mimeType="text/plain">
<dii-msaf:Identifier><!--See Represent Identifier, Section 3.2.5.1--> </dii-msaf:Identifier>
</didl-msaf:Statement>
</didl-msaf:Descriptor>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 30 Location of Identifier for a Content Item
Identifiers for Content Elements are located within the DCI according to MPEG-21 Digital Item Identification [22] whose schema is defined in C.6, as shown in the example below.
<didl-msaf:DIDL>
<didl-msaf:Item> <!--This item refers to the Content Item-->
<didl-msaf:Item id = book1> <!--This item refers to a Content Element-->
<didl-msaf:Descriptor>
<didl-msaf:Statement mimeType="text/plain">
<dii-msaf:Identifier> <!--See Represent Identifier, Section 3.2.5.1 --> </dii-msaf:Identifier>
</didl-msaf:Statement>
</didl-msaf:Descriptor>
</didl-msaf:Item>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 31 Location of Identifier for a Content Element
The location of metadata within the didl-msaf structure is shown below for both the case in which data is related to all the Content Elements within the DCI and the case in which data is related to a specific Content Element within the DCI.
Metadata can be represented in a DMP-native way as specified in Section 3.2.2
The Metadata is located within the DCI under the didl-msaf:Metadata element.
The didl-msaf:Metadata element residing at the top level in the DCI is meant to convey Metadata about the whole Content Item, (ie all elements represented within the DCI).
The figure below below shows where the didl-msaf:Metadata element is located in the DCI for this case.
<didl-msaf:DIDL>
<didl-msaf:Item> <!--This item refers to the Content Item-->
<didl-msaf:Descriptor>
<didl-msaf:Statement mimeType="text/plain">
<dii-msaf:Identifier>dmpID:012345</dii-msaf:Identifier> <!--The DMP identifier for this content-->
</didl-msaf:Statement>
</didl-msaf:Descriptor>
<didl-msaf:Descriptor>
<didl-msaf:Statement mimeType="text/xml">
<didl-msx:Metadata>
<!-- Conveying general Metadata for the Content Item -->
</didl-msx:Metadata>
</didl-msaf:Statement>
<didl-msaf:Descriptor>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 32: Location of Metadata related to the Content Item
The Figure below shows where the didl-msx:Metadata element for a specific Content Element is located within the DCI in this case.
<didl-msaf:DIDL>
<didl-msaf:Item> <!--the one representing the Content Item-->
<didl-msaf:Item id="Resource1"> <!-- the one representing the Resource-->
</didl-msaf:Descriptor>
<didl-msaf:Statement mimeType ="text/xml">
<dii-msaf:Identifier>ISWC: 01234567890</dii-msaf:Identifier>
</didStatement>
</didl-msaf:Descriptor>
<didl-msaf:Descriptor>
<didl-msaf:Statement mimeType="text/xml">
<didl-msx:Metadata>
<!--conveying Metadata for a Content Element-->
</didl-msx:Metadata>
</didl-msaf:Statement>
</didl-msaf:Descriptor>
<didl-msaf:Component>
<didl-msaf:Resource ref="funky1.mp3" mimeType="audio/mpeg"/>
</didl-msaf:Component>
</didl-msaf:Item>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 33: Location of Metadata related to a Content Element
DCI signatures can be inserted in a didl-msaf:DIDLInfo element contained in a didl-msaf:DIDL element, as represented in the example below.
<didl-msaf:DIDL>
<didl-msaf:DIDLInfo>
<didl-msaf:DISignature>
<dsig:SignedInfo>
<dsig:CanonicalizationMethod Algorithm=""/>
<dsig:SignatureMethod Algorithm=""/>
<dsig:Reference>
<dsig:DigestMethod Algorithm=""/>
<dsig:DigestValue>888880AB</dsig:DigestValue>
</dsig:Reference>
</dsig:SignedInfo>
<dsig:SignatureValue>098765CC</dsig:SignatureValue>
</didl-msaf:DISignature>
</didl-msaf:DIDLInfo>
<didl-msaf:Item id="A1">
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 34: Location of DCI Signatures in the DCI
A Content Item may contain or reference any number of Resources.
A DCI Representing a Content Item which contains a number n of Resources, e.g. an MP3 file and an MPEG-1 video file, is characterised by n didl-msaf:Item elements as child elements of the top level didl-msaf:Item. Each inner Item contains a didl-msaf:Resource element Representing the Resource within a didl-msaf:Component element, as shown in the example below.
<didl-msaf:DIDL>
<didl-msaf:Item id="A1">
<didl-msaf:Item id="B1">
<didl-msaf:Component>
<didl-msaf:Resource mimeType="audio/mp3"/>
</didl-msaf:Component>
</didl-msaf:Item>
<didl-msaf:Item id="B2">
<didl-msaf:Component>
<didl-msaf:Resource mimeType="video/mpg"/>
</didl-msaf:Component>
</didl-msaf:Item>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 35: Location of Resources in the DCI
A DRM Tool Body, i.e. a special code to execute DRM functions, is considered a Resource. However, this Approved Document No. 3 has a dedicated section for Representation of DRM Tool Body which includes the description of the DRM Tool to enable exchange between Devices. The DRM Tools are located separately within the Content as described in Section 3.2.1.7
In cases where Content Elements are Governed Content Elements, the DCI elements that denote the locations of the Content Elements within the DCI are substituted for corresponding elements taken from the MPEG-21 IPMP Components, specifically those defined in the ipmpdidl-msaf namespace.
The following elements: ipmpdidl-msaf:Item and ipmpdidl-msaf:Statement can be used in lieu of the elements with the same name defined in the didl-msaf namespace to indicate that the Content Element they Represent is Governed. Therefore the rule specifying the location of an IPMP DIDL element is the same that specifies the position of the element with the same name in the didl-msaf namespace defined in [21] and described in Section 3.2.1.1 – The DCI Structure.
In addition to the element substitution defined, Governed Resources have an extra DCI child element within their respective didl-msaf:Resource; namely the ipmpdidl-msaf:ProtectedAsset child element described in Represent DRM Information section 3.2.7 and shown in Figure 58: The ipmpdidl-msaf:ProtectedAsset element
Metadata can also be Governed. This is described in Section 3.2.7.1 - Represent Governed Elements.
The DCI is able to convey within its structure a number of Content Elements that carry information relating to Governed Content Elements that may be required for correct operation of the IDP. These include Licences and DRM Tools that may be associated with the Use of specific Content Elements. Such items are represented in the DCI by the MSAF profile of the MPEG-21 IPMP information descriptor <ipmpinfo-msx:IPMPInfoDescriptor> as descibed in Section 3.2.7.2
The ipmpinfo-msaf:IPMPInfoDescriptor element is located as a child element of an ipmpdidl-msaf:Info element which, in turn, may be contained in one of the following:
· ipmpdidl-msaf:Item
· ipmpdidl-msaf:Statement
· didl-msx:Metadata
· ipmpdidl-msaf:ProtectedAsset.
The Figure below shows the case where the IPMPInfoDescriptor conveys DRM Information for a Resource.
<didl-msaf:DIDL>
<didl-msaf:Item> <!--the one representing the Content Item-->
<didl-msaf:Item id="Resource1"> <!-- representing a Content Element within a Content Item -->
<didl-msaf:Component>
<didl-msaf:Resource mimeType="application/ipmp">
<ipmpdidl-msaf:ProtectedAsset mimeType="video/mpeg">
<ipmpdidl-msaf:Info>
<ipmpinfo-msaf:IPMPInfoDescriptor>...<ipmpinfo-msaf:IPMPInfoDescriptor>
</ipmpdidl-msaf:Info>
<ipmpdidl-msaf:Contents> <!--in line Governed Resource here --></ipmpdidl-msaf:Contents>
</ipmpdidl-msaf:ProtectedAsset>
</didl-msaf:Resource>
</didl-msaf:Component>
</didl-msaf:Item>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 36: Example location of an IPMPInfoDescriptor within the DCI
Note: Where a ipmpinfo-msaf:IPMPInfoDescriptor element appears as a child of a didl-msaf:Resource contained in the top didl-msaf:Item (the one referring to the Content Item as a whole), all the Resources part of that Content Item are Governed in the same way as specified in that ipmpinfo-msaf:IPMPInfoDescriptor, hence there is no need to replicate IPMPInfoDescriptors for all Resources, if these are Governed by the same rules.
The DCI uses the IPMPGeneralInfoDescriptor to convey lists of all the DRM Tools required to Access all the Governed Content Elements. See Section 3.2.7.3 for a description of the Representation of these components.
The ipmpinfo-msaf:IPMPGeneralInfoDescriptor element is located in a didl-msaf:Statement element which is child of a didl-msaf:Descriptor element describing the top-level didl-msaf:Item in a DCI (the one referring to the Content Item as a whole), as shown in the figure below.
<didl-msaf:DIDL>
<didl-msaf:Item> <!--This item refers to the Content Item-->
<didl-msaf:Descriptor>
<didl-msaf:Statement>
<ipmpinfo-msaf:IPMPGeneralInfoDescriptor> <!--General DRM Information here --> </ipmpinfo-msaf:IPMPGeneralInfoDescriptor>
</didl-msaf:Statement>
</didl-msaf:Descriptor>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 37 Location of ipmpinfo-msaf:IPMPGeneralInfoDescriptor
Depending on the scope of a License, this shall be signalled in different positions within the DCI. Licenses are required to;
1. Grant the Right to Use Content
2. Govern the Use of DRM Tools
3. Attribute properties to its Principal
For the first and second case, the location of Licenses is specified in this sub-section, while when the scope of a License is to attribute a property to its Principal, as in the case of a License attributing a User or a Device the property of belonging to a Domain, Licenses are obtained as specified in Section 3.3.3 – Protocols to Manage Domain.
A License (or a reference to a License or a License Service) whose scope refers to the first two cases is signalled by employing the ipmpinfo-msaf:RightsDescriptor element, shown in the Figure below:
<element name="RightsDescriptor" type="ipmpinfo-msaf:RightsDescriptorType"/>
<complexType name="RightsDescriptorType">
<sequence>
<choice minOccurs="0">
<element ref="ipmpinfo-msaf:License"/>
<element ref="ipmpinfo-msaf:LicenseReference"/>
</choice>
</sequence>
</complexType>
Figure 38: The ipmpinfo-msaf:RightsDescriptor element
An ipmpinfo-msaf:RightsDescriptor may contain a number of Licenses of type ipmpinfo-msaf:License, which is described below. In addition, the License Provider Device URL from where the License can be retrieved, of type “xsd:anyURI”, can be specified in element ipmpinfo-msaf:LicenseReference.
The ipmpinfo-msaf:RightsDescriptor is one of the nested child elements associated with Governed Content Elements hierarchy described in 3.2.7.1 – Represent Governed Elements, and is a child of the IPMPInfoDescriptor outlined in Section 3.2.7 – Represent DRM Information, located as DRM Information as described in Section 3.2.1.7.
The element ipmpinfo-msaf:License is shown in the Figure below:
<element name="License" type="ipmpinfo-msaf:LicenseType"/>
<complexType name="LicenseType" mixed="true">
<sequence>
<element ref="r-msaf:license" maxOccurs="unbounded"/>
</sequence>
</complexType>
Figure 39: The ipmpinfo-msaf:License element
The ipmpinfo-msaf:License element contains an rel-r-msaf:license., as defined in rel-r-msaf Schema [C.22].
In cases where Content is Packaged in a File, Licenses may alternatively be contained in the License_Container Box, as specified in Section 3.4.1.2.9 - License_Container Box.
The following sub-sections examine the cases 1 and 2 above in detail.
As specified in Section 3.2.7 – Represent DRM Information, DMP support the Governance of several types of Content Element: didl-msaf:Item, didl-msaf:Statement, didl-msaf:Resource, didl-msx:Metadata. If any of these Content Elements are Governed, their Use may be regulated by a License. The presence of a License in these cases is signalled by the ipmpinfo-msaf:RightsDescriptor in an ipmpinfo-msaf:IPMPInfoDescriptor element contained in an ipmpdidl-msaf:Info element child of any Governed Element.
The example below shows the location of a License governing the Use of a Governed Content Element
<didl-msaf:DIDL>
<didl-msaf:Item id="A1">
<didl-msaf:Item id="B1">
<didl-msaf:Component>
<didl-msaf:Resource mimeType="application/mp21-ipmp">
<ipmpdidl-msaf:ProtectedAsset mimeType="video/MP2P">
<ipmpdidl-msaf:Identifier>urn:mpegRA:mpeg21:dii:isan:006A-B</ipmpdidl-msaf:Identifier>
<ipmpdidl-msaf:Info>
<ipmpinfo-msaf:ipmpinfo-msafDescriptor>
<ipmpinfo-msaf:RightsDescriptor>
<ipmpinfo-msaf:License>
<r:license licenseId="012345">
....
</r:license>
</ipmpinfo-msaf:License>
</ipmpinfo-msaf:RightsDescriptor>
</ipmpinfo-msaf:ipmpinfo-msafDescriptor>
</ipmpdidl-msaf:Info>
<ipmpdidl-msaf:Contents ref="myserver.com/coolmovie"/>
</ipmpdidl-msaf:ProtectedAsset>
</didl-msaf:Resource>
</didl-msaf:Component>
</didl-msaf:Item>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 40: An Example of License Governing a Content Element
In those cases where the Use of a DRM Tool is subject to a License, as for instance “DRM Tool T can only work on Devices certified by Agency A”, the License is conveyed by the ipmpinfo-msaf:RightsDescriptor element child of an ipmpinfo-msaf:Tool element.
The following example shows a DRM Tool whose Use is subject to a License that can be obtained from a given License Service.
<didl-msaf:Resource mimeType="application/mp21-ipmp">
<ipmpdidl-msaf:ProtectedAsset mimeType="video/MP2P">
<ipmpdidl-msaf:Identifier>urn:mpegRA:mpeg21:dii:isan:006A-15FAB</ipmpdidl-msaf:Identifier>
<ipmpdidl-msaf:Info>
<ipmpinfo-msaf:IPMPInfoDescriptor>
<ipmpinfo-msaf:Tool>
<ipmpinfo-msaf:RightsDescriptor>
<ipmpinfo-msaf:LicenseReference>
http://www.DRMTools.org/LicenseService
</ipmpinfo-msaf:LicenseReference>
</ipmpinfo-msaf:RightsDescriptor>
</ipmpinfo-msaf:Tool>
</ipmpinfo-msaf:IPMPInfoDescriptor>
</ipmpdidl-msaf:Info>
<ipmpdidl-msaf:Contents ref="myserver.com/mynewmovie"/>
</ipmpdidl-msaf:ProtectedAsset>
</didl-msaf:Resource>
Figure 41: An example of DRM Tool in which Use is subject to a License
There are two types of Keys identified in this specification: time-dependent and time-independent.
A non-exhaustive list of locations where such a type of Key is delivered is given below:
Time-dependent Keys are Represented as specified in Section 3.2.12.2 – Represent Time-dependent Keys and are located within a ipmpmsg:KeyData element for updating the Decryption Key for a DRM Tool used to Decrypt Resources.
A DRM Tool Body, the executable instructions implementing a DRM Function, may be conveyed in the DCI enclosed in ipmpinfo-msaf:Binary elements, as shown in the Figure below
<ipmpinfo-msaf:Tool>
<ipmpinfo-msaf:ToolBaseDescription>
<ipmpinfo-msaf:IPMPToolID>urn:Manufacturer:ToolPack:ToolID:ABCDEF9</ipmpinfo-msaf:IPMPToolID>
<ipmpinfo-msaf:ConfigurationSettings>
<ipmpinfo-msaf:Configuration>
<ipmpinfo-msx:ToolBody>
<!-- See Section 3.2.9 – Represent DRM Tool Body -->
</ipmpinfo-msx:ToolBody>
</ipmpinfo-msaf:Configuration>
</ipmpinfo-msaf:ConfigurationSettings>
</ipmpinfo-msaf:ToolBaseDescription>
</ipmpinfo-msaf:Tool>
Figure 42: An example showing the location of DRM Tool Body
For more information on DRM Tool Bodies, see Section 3.2.9 – Represent DRM Tool Body.
In order to select an appropriate DRM Tool with matching hardware and software characteristics, Device Information, a set of data describing hardware and software characteristics of a Device, is required. The ipmpinfo-msx:DeviceInformation element may be located in ipmpinfo-msx:Tool or ipmpinfo-msx:ToolPack elements within a ipmpinfo-msx:ToolBody element.
<ipmpinfo-msx:ToolBody>
<ipmpinfo-msx:ToolPack>
<ipmpinfo-msx:DeviceInformation>
<!--See 3.2.14 – Represent Device Information -- >
</ipmpinfo-msx:DeviceInformation>
</ipmpinfo-msx:ToolPack>
</ipmpinfo-msx:ToolBody>
Figure 43: An example showing the location of Device Information
For more information on Device Information, see 3.2.15 – Represent Device Information.
The IDP-3.0 gives the freedom to place any Metadata scheme desired into the designated location in the DCI.
In addition DMP natively supports a specific type of Metadata taken from the TV-Anytime Content Description Schema described in [36], defined in the tva-msaf namespace and given in Annex C.25. In order to suit the DMP requirements of describing resources to the End User, the DMP Metadata profile has been derived from the TV-Anytime Content Description by defining a smaller version of the TVAMain element that does not include the UserDescription table. It includes the remaining elements namely: CopyrightNotice, ClassificationSchemeTable and ProgramDescription. However, ProgramDescription has also been reduced by defining a dmp:ProgramDescriptionType based on the TV-Anytime ProgramDescriptionType but including only the TV-Anytime elements ProgramInformationTable, GroupInformationTable and CreditsInformationTable.
The TV-Anytime elements not included in the MSAF profile mentioned above are defined as optional (minOccurs=0) in the TV-Anytime specification, and so instance documents conforming to this profile are compatible with the larger TV-Anytime specification.
Metadata is included under the didl-msx:Metadata element defined in the DMP Represent Content namespace and described below:
Metadata:
The didl-msx:Metadata element allows the inclusion of either Governed Metadata or Metadata in clear format. In the first case, Governed Metadata is conveyed as specified in 3.2.7.1 – Represent Governed Elements, while in the second case, Metadata is conveyed in the didl-msx:StructuredData element. A Metadata Identifier can be conveyed by means of the optional attribute "id". Furthermore, a Digital Signature of the whole didl-msx:Metadada element may be conveyed in the dsig:Signature element. The didl-msx:Metadata is shown in the Figure below:
<element name="Metadata" type="didl-msx:MetadataType"/>
<complexType name="MetadataType">
<sequence>
<choice>
<group ref="ipmpdidl-msaf:IPMPDIDLChildGroup" minOccurs="0"/>
<element ref="didl-msx:StructuredData" maxOccurs="unbounded"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="id" type="anyURI" use="optional"/>
</complexType>
Figure 44: The didl-msx:Metadata element
StructuredData:
This element can contain data from any namespace.
The native type of Metadata supported in IDP-3.0 is of type tva-msaf:TVAMain, which is denoted by the attribute 'ref ' value of "urn:dmp:idp2:Represent:Metadata:2006:02". If this attribute is omitted, Metadata contained in tva-msaf:StructuredData is of type tva-msaf. Alternatively, any other Metadata schema can be employed. In this case the attribute 'ref' shall specify the URI of the Metadata namespace employed.
<element name="StructuredData" type="didl-msx:StructuredDataType">
<complexType name="StructuredDataType">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"/>
</sequence>
<attribute name="ref" type="anyURI" default="urn:dmp:idp2:Represent:Metadata:2006:02"/>
</complexType>
Figure 45: The didl-msx:StructuredData
The MSAF profile of TV-Anytime Metadata is built upon a modification of the TVA Main type to include only the Copyright, Classification and ProgramDescription elements. The syntax of ipmpmsg:TVAMain element is specified in the Figure below, while for the semantics refer to [35]:
<element name="TVAMain" type="tva-msaf:TVAMainType"/>
<complexType name="TVAMainType">
<sequence>
<element name="CopyrightNotice" type="string" minOccurs="0"/>
<element name="ClassificationSchemeTable" type="tva:ClassificationSchemeTableType" minOccurs="0"/>
<element name="ProgramDescription" type="tva-msaf:ProgramDescriptionType" minOccurs="0"/>
</sequence>
<attribute ref="xml:lang" use="optional" default="en"/>
<attribute name="publisher" type="string" use="optional"/>
<attribute name="publicationTime" type="dateTime" use="optional"/>
<attribute name="rightsOwner" type="string" use="optional"/>
<attribute name="version" type="unsignedInt" use="optional"/>
</complexType>
Figure 46: The tva-msaf:TVAMain element
The ProgramDescription element defined in [35] has been reduced to include only the ProgramInformation, GroupInformationTable and CreditsInformationTable elements. The tva-msaf:DMP ProgramDescriptionType is related to the TV-Anytime elements as follows;
<complexType name="ProgramDescriptionType">
<sequence>
<element name="ProgramInformationTable" type="tva:ProgramInformationTableType" minOccurs="0"/>
<element name="GroupInformationTable" type="tva:GroupInformationTableType" minOccurs="0"/>
<element name="CreditsInformationTable" type="tva:CreditsInformationTableType" minOccurs="0"/>
</sequence>
</complexType>
Figure 47: The tva-msaf:TVAMain element
Note: Since the elements omitted from the TV-Anytime Specification are all defined as optional, an instance document complying with the DMP profile of the TV-Metadata will also be compliant with a TV-Anytime phase 1 implementations.
The DCI may be signed by Users who took part in its creation or modification.
A signature is contained in the DISignature element child of a didl-msaf:DIDLInfo element.
In order to allow for the authentication of the DCI integrity without relying on a signature and associated key distribution, a DCI may be simply hashed such that a comparison of a newly generated hash with that of an earlier stored version by another party can be made. Although the hash value itself will need to be recalculated, a hash value can be conveyed in the DCI for reference along with the associated algorithm.
Hash values can be contained in a DISignature element, as specified in [42].
Identifiers for Content or Content Elements (e.g. a Resource) are expressed according to a DMP profile of MPEG-21 Digital Item Identification (DII) [22], as shown in the schema fragment figure below.
<element name="Identifier" type="anyURI"/>
<element name="RelatedIdentifier">
<complexType>
<simpleContent>
<extension base="anyURI">
<attribute name="relationshipType" type="anyURI"/>
</extension>
</simpleContent>
</complexType>
</element>
Figure 48: Identifier and Related Identifier
The dii-msaf:Identifier element contains the Uniform Resource Identifier (URI) of the Content or Content Element, while the RelatedIdentifier element expresses the URI to which the Identifier is related, for example the identification of an abstraction of the work (e.g. a composition as an abstraction of a sound recording).
The Content Identifier satisfies the characteristics of the URN (Uniform Resource Names) scheme defined in RFC 1737 [37]. Therefore Identifiers that conform to URN schemes can be used to Identify Content. Currently, there are several registered URN schemes such as International Standard Book Number (ISBN) and International Standard Serial Number (ISSN), each of them serving a specific purpose and having a unique namespace under Internet Assigned Numbers Authority (IANA).
The syntax of Content Identifier should be conformant to the URN syntax described in RFC 2141 [39] as follows:
urn:{a urn namespace for dmp}:{a subordinate namespace}:{subordinate-specific Content Identifier}
or
urn:{a urn namespace for 3rd party}:{namespace-specific Content Identifier}
Figure 49: Content Identifier Syntax
As shown in the Figure below, any rel-msaf:License is characterised by a licenseId attribute specifying the Identifier for the License.
<xsd:complexType name="License">
<xsd:choice>
<xsd:sequence>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="r:grant"/>
</xsd:choice>
<xsd:element ref="r:issuer" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:choice>
<xsd:attribute name="licenseId" type="xsd:anyURI" use="optional"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
Figure 50: The rel-msaf:License element
Metadata related to a Content Item or to a Content Element shall be inserted in a didl-msx:Metadata element, as specified in Section 3.2.2 – Represent Metadata. Metadata can be identified by means of an attribute to the didl-msx:Metadata element, named didl-msx:id, as shown in the Figure below:
<attribute name="id" type="anyURI" use="optional"/>
Figure 51: The container for Metadata Identifier
DRM Tool ID syntax should conform to ‘xsd:anyURI’ format. This is the same format as for Tool and ToolPack, but with the appropriate parent elements.
<element name="ipmpinfo-msaf:IPMPToolID" type="anyURI"/>
Figure 52: Tool Identifier Representation
The Device Identifier is Represented by means of the dmprdip:DeviceIdentifier element. The Represent Device Identifier Protocol namespace, dmprdip, defines an abstract base type element from which the rest of the elements are derived. This is the following:
<complexType name="IdentifierBaseType" abstract="true"/>
Figure 53: The dmprdip:IdentifierBaseType complex type
A Device Identifier is Represented by the dmprdip:DeviceIdentifier element, as described in the Figure below:
<element name="DeviceIdentifier" type="dmprdip:IDType"/>
<complexType name="IDType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element name="id" type="anyURI"/>
<element ref="dsig:X509Data"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 54: The dmprdip:DeviceIdentifier element
The dmprdip:IDType complex type in the Figure above contains the Identifier of the Device, which can be either of type anyURI and conveyed by the id element, or an X.509 certificate, in which case it shall be expressed according to the dsig:X509Data element and conformant to RFC 2459 [41].
IDP-3.0 does not provide Tools to Identify Users. However, several IDP-3.0 Use Cases require User Identification. This can be achieved with a variety of technologies such as:
· Certificates
· Globally unique Identifiers
· Devices (Smart cards, USB devices etc.)
Every Domain of Devices or Users is characterised by Domain Identifier, which is defined in the msd namespace and shown in the Figure below:
<element name="DomainID" type="msd:DomainIDType"/>
<complexType name="DomainIDType">
<complexContent>
<extension base="msd:IDType">
<sequence>
<element ref="msd:DomainManagerID"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="IDType">
<sequence>
<choice>
<element name="id" type="anyURI"/>
<element ref="dsig:X509Data" minOccurs="0"/>
</choice>
</sequence>
</complexType>
Figure 55: The msd:DomainID element
For more information on the msd:DomainID element, refer to Section 3.2.16 – Represent Domain.
A Resource such as an audio track, a video clip, executable code, etc. is Represented in the DCI by the element didl-msaf:Resource, as shown in the box below.
<element name="Resource" type="didl-msaf:ResourceType" substitutionGroup="didmodel:Resource"/>
<complexType name="ResourceType" mixed="true">
<complexContent mixed="true">
<extension base="didmodel:ResourceType">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"/>
</sequence>
<attribute name="mimeType" type="string" use="required"/>
<attribute name="ref" type="anyURI"/>
<attribute name="encoding" type="string"/>
<attribute name="contentEncoding" type="NMTOKENS"/>
</extension>
</complexContent>
</complexType>
Figure 56: The Resource element
The data type of the Resource represented by the didl-msaf:Resource element is identified by the mimeType attribute, as defined in IETF RFC 2045 [38]. A Resource is either defined in a didl-msaf:Resource element by reference, specifying the Resource’s URI in the ref attribute, or by value, including it inline. The encoding attribute specifies the encoding format used when the Resource is included in the didl-msaf xml document. Lastly, the contentEncoding attribute, if present, specifies the content-encoding(s) as defined in IETF RFC 2616 [40] indicating what additional content-encodings have been applied to the Resource.
DRM Information is the class of information contained in the DCI that relate to the Governance of Content or Content Elements. It includes
1. The Representation of the DRM Tools required to Access Content.
2. Any initialisation and configuration data, possibly including decryption Keys and information related to DRM Tool management
3. Placeholders for Licenses when these are Bundled within the DCI (see sub section 3.2.1.9).
DRM Information is expressed in XML and is based on the MPEG-21 IPMP Components [31] profile defined in the MSAF standard, included in Annexes C.8, C.9 and C.10.
The process of indicating that a Content Item or some of its Content Elements are Governed is done using one of the three MPEG-21 IPMP Components technologies described below, depending on the Content Item.
· IPMP DIDL: The use of an element belonging to IPMP Digital Item Declaration Language namespace to Represent the Governed Content Element. These elements are denoted with the ipmpdidl-msaf: namespace prefix in this specification. These elements are used to replace the corresponding elements of the same name from the Digital Item Declaration Language namespace (prefix didl-msaf:) for the case when the Content Element is Representing a Governed Element. In contrast, the didl-msaf: elements are used when the Content Element it is Representing is not Governed.
· IPMPInfoDescriptor: This descriptor is part of the MPEG-21 IPMPINFO namespace and has been profiled in this specification, denoted ipmpinfo-msaf. The IPMPInfoDescriptor is used as a child of the ipmpdidl-msaf:Info element to describe the DRM Tools that Process (e.g. Decrypt) the Governed Content Item or its Content Elements, therefore enabling Users to Access the Governed Elements. Refer to Annex A.3.2 for an overview of MPEG-21 IPMP Information Descriptor. The ipmpinfo-msaf schema is given in Annex C.9.
· IPMPGeneralInfoDescriptor: The use of an IPMPGeneralInfoDescriptor to convey the list of all DRM Tools required to Access all Governed Content Elements. Refer to Annex A.3.3 for an overview of MPEG 21 IPMP General Information Descriptor. Also the IPMP General Information Descriptor is defined in the ipmpinfo-msaf schema, given in Annex C.9.
The following sub-Sections provide more details on how these technologies are employed in IDP-3.0.
The following elements of the DCI can be Governed: didl-msaf:Item, didl-msaf:Statement, didl-msx:Metadata, didl-msaf:Resource. The left column in the table below shows elements from the didl-msaf namespace which can be replaced by the elements with the same name defined in the ipmpdidl-msaf namespace:
Table 11 – Conversion from the didl-msaf to the ipmpdidl-msaf namespaces
|
Un-Governed element |
Governed element |
|
didl-msaf:Item |
ipmpdidl-msaf:Item |
|
didl-msaf:Statement |
ipmpdidl-msaf:Statement |
All the elements defined in the ipmpdidl-msaf contain the following child elements:
· an optional ipmpdidl-msaf:Identifier element, specifying an Identifier for the Governed Element;
· a ipmpdidl-msaf:Info element, containing information about the Governance of the Governed Element
· a ipmpdidl-msaf:Contents element, containing the Governed Element.
There are two other elements used for Representing the Governed content elements. These are for Representing Metadata and for Representing a Resource.
The case of didl-msx:Metadata does not have an IPMP substitution as this element is not part of the DIDL Model but is DMP-native. As explained in 3.2.2 Represent Metadata, this element may contain either un-Governed data (when the child element didl-msx:StructuredData is employed) or Governed, in which case it inherits all properties of ipmpdidl-msaf elements, including the child elements; Identifier, Info and Contents.
The Figure below shows an example of Governed Metadata for a Content Element represented by an didl-msaf:Item element:
<didl-msaf:Item>
<didl-msaf:Descriptor>
<didl-msaf:Statement mimeType="text/xml">
<didl-msx:Metadata>
<ipmpdidl-msaf:Info>
<ipmpinfo-msaf:IPMPInfoDescriptor></ipmpinfo-msaf:IPMPInfoDescriptor>
</ipmpdidl-msaf:Info>
<ipmpdidl-msaf:Contents>01234567890ABCDEF</ipmpdidl-msaf:Contents>
<!-- Insert the Governed - obfuscated metadata in ipmpdidl-msaf:Contents-->
</didl-msx:Metadata>
</didl-msaf:Statement>
</didl-msaf:Descriptor>
</didl-msaf:Item>
Figure 57: An example of Governed Metadata
A similar solution is employed when a Governed Resource is Represented. As this contains a specific Resource, rather than replacing a didl-msaf:Resource element with the ipmpdidl-msaf:Resource element, a Governed Resource is a Resource Element that has a special child element: ipmpdidl-msaf:ProtectedAsset. By virtue of being part of the ipmpdidl-msaf namespace, the ipmpdidl-msaf:ProtectedAsset possesses all properties of ipmpdidl-msaf elements and additionally allows extra attributes. The Figure below shows the ipmpdidl-msaf:ProtectedAsset element:
<element name="ProtectedAsset" type="ipmpdidl-msaf:ProtectedAssetType"/>
<complexType name="ProtectedAssetType">
<sequence>
<group ref="ipmpdidl-msaf:IPMPDIDLChildGroup"/>
</sequence>
<attribute name="mimeType" type="string" use="required"/>
<attribute name="contentEncoding" type="string"/>
</complexType>
Figure 58: The ipmpdidl-msaf:ProtectedAsset element
The ipmpdidl-msaf:IPMPDIDLChildGroup refers to the ipmpdidl: child elements; ipmpdidl-msaf:Identifier, ipmpdidl-msaf:Info and ipmpdidl-msaf:Contents used to protect all the Governed elements.
The mimeType attribute defines the mimeType of the protected Resource when in the unprotected state, while the contentEncoding attribute defines the content encoding of the Resources when in unprotected state.
When including a ipmpdidl-msaf:ProtectedAsset element, the mimeType attribute of the parent didl-msaf:Resource element is set to "application/ipmp".
The ipmpinfo-msaf:IPMPInfoDescriptor is shown in the Figure below:
<element name="IPMPInfoDescriptor" type="ipmpinfo-msaf:IPMPInfoDescriptorType"/>
<complexType name="IPMPInfoDescriptorType">
<sequence>
<element ref="ipmpinfo-msaf:Tool" minOccurs="0" maxOccurs="unbounded"/>
<element ref="ipmpinfo-msaf:RightsDescriptor" minOccurs="0" maxOccurs="unbounded"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
Figure 59: The ipmpinfo-msaf:IPMPInfoDescriptor
The ipmpinfo-msaf:IPMPInfoDescriptor element may contain:
1. ipmpinfo-msaf:Tool, to convey information on the DRM Tool or Tools that are necessary to Process (e.g. Decrypt) the Governed Content Item or its Content Elements. Refer to Section 3.2.8 – Represent DRM Tool for more information on the Use of the ipmpinfo-msaf:Tool element.
2. ipmpinfo-msaf:RightsDescriptor, to convey one or more Licenses Governing the use of the parent element with which the IPMPInfoDescriptor is associated, as described in Section 3.2.11 – Represent License.
3. A digital Signature, which can be applied to the IPMPInfoDescriptor, and conveyed by means of the dsig:Signature element.
The location of the IPMPInfoDescriptor is given in Section 3.2.1.7 - Location of DRM Information including Tools.
The scope of the IPMPGeneralInfoDescriptor is to convey all the required information needed by the Device for presenting the Governed Content to Users, thereby enabling the Device to Access all DRM Tools before they are instantiated in the Device.
The ipmpinfo-msaf:IPMPGeneralInfoDescriptor is shown in the Figure below:
<element name="IPMPGeneralInfoDescriptor" type="ipmpinfo-msaf:IPMPGeneralInfoDescriptorType"/>
<complexType name="IPMPGeneralInfoDescriptorType">
<sequence>
<element ref="ipmpinfo-msaf:ToolList" minOccurs="0"/>
<element ref="ipmpinfo-msaf:LicenseCollection" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
<!--Signature for the IPMPGeneralInfoDescriptor element and children -->
</sequence>
</complexType>
Figure 60 The ipmpinfo-msaf:IPMPGeneralInfoDescriptor element
The location of the IPMPGeneralInfoDescriptor is given in Section 3.2.1.8 - Location of General DRM Information including ToolList.
A Governed Content Item, or a Content Item containing one or more Governed Content Elements, shall have one and only one IPMPGeneralInfoDescriptor in the DCI. This may contain the following elements:
1. ipmpinfo-msaf:ToolList element listing the descriptions of all DRM Tools (if any) involved in the Use of the Governed Elements
2. ipmpinfo-msaf:LicenseCollection containing all the Licenses (or a reference to them, i.e. the License Provider Device URL) Governing the Use of such Governed Content Elements. Note: the use of this element is deprecated in IDP-3.0
3. Signature in the dsig:Signature element.
For more information on the ipmpinfo-msaf:ToolList element, refer to Section 3.2.8 – Represent DRM Tool.
This section describes how to indicate within the DRM Information which DRM Tool or DRM Tools are required to Access the Content. DRM Tools are software modules performing one or more DRM Functions such as Authentication, Decryption, watermarking, etc.
Represent DRM Tool is MSAF profile of MPEG-21 IPMP Components [23] and MPEG-2/4 IPMP Extensions [12] and [14] to enable the Representation of single DRM Tools. A further extension enables the Representation of DRM Tool Packs.
DRM Tool related information is divided between two parent location elements within the DCI as follows:
1. IPMPGeneralInfoDescriptor is used with the ipmpinfo-msaf:ToolList element to convey specific information about DRM Tools that may be used by a Device to Access the required DRM Tools before they are needed
2. IPMPInfoDescriptor is used to trigger the instantiation of a DRM Tool and contains the DRM Tool Representation.
The two paragraphs below describe in detail these two DRM Tool Representations.
The ipmpinfo-msaf:ToolList is shown in the figure below:
<element name="ToolList" type="ipmpinfo-msaf:ToolListType"/>
<complexType name="ToolListType">
<sequence>
<element ref="ipmpinfo-msaf:ToolDescription" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="ToolDescription" type="ipmpinfo-msaf:ToolDescriptionType"/>
<complexType name="ToolDescriptionType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID"/>
<element ref="ipmpinfo-msaf:MemberOf" minOccurs="0"/>
<choice minOccurs="0">
<element ref="ipmpinfo-msaf:Inline"/>
<element ref="ipmpinfo-msaf:Remote"/>
</choice>
<element ref="ipmpinfo-msaf:RightsDescriptor" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="localID" type="ID" use="required"/>
</complexType>
Figure 61: The ipmpinfo-msaf:ToolList element
The dmp2_ipmp:ToolList makes it possible to specify information related to a DRM Tool to enable a Device to locate the Tool, as specified in Section 3.3.4.3 - Protocol to Access DRM Tool Body.
A ToolList may contain one or more ipmpinfo-msaf:ToolDescription elements, each specifying:
For more information on the use of the ipmpinfo-msaf:ToolList element, refer to [23].
The ipmpinfo-msaf:ToolList element is a child of a ipmpinfo-msaf:IPMPGeneralInfoDescriptor element, which in turn is contained in a didl-msaf:Statement contained in a didl-msaf:Descriptor below the top-level didl-msaf:Item in a DCI. An example is shown in the Figure below:
<didl-msaf:DIDL>
<didl-msaf:Item id="Program1">
<didl-msaf:Descriptor>
<didl-msaf:Statement mimeType="text/xml">
<ipmpinfo-msaf:IPMPGeneralInfoDescriptor>
<ipmpinfo-msaf:ToolList>
<!-- Insert the Tool List here -->
</ipmpinfo-msaf:ToolList>
</ipmpinfo-msaf:IPMPGeneralInfoDescriptor>
</didl-msaf:Statement>
</didl-msaf:Descriptor>
</didl-msaf:Item>
</didl-msaf:DIDL>
Figure 62: Location of the ipmpinfo-msaf:ToolList element
The ipmpinfo-msaf:Tool element is inserted in a ipmpinfo-msaf:IPMPInfoDescriptor to indicate that a specific DRM Tool should be operational on the Device. If, whilst parsing the Represent DRM Information portion of the DCI describing a Governed Resource the DRM Processor encounters an ipmpinfo-msaf:Tool element in a ipmpinfo-msaf:IPMPInfoDescriptor, the DRM Processor instantiates the DRM Tool Represented within it to operate on that Resource.
The ipmpinfo-msaf:Tool is shown in the Figure below:
<element name="Tool" type="ipmpinfo-msaf:ToolType"/>
<complexType name="ToolType">
<sequence>
<choice>
<element ref="ipmpinfo-msaf:ToolBaseDescription"/>
<element ref="ipmpinfo-msaf:ToolRef"/>
</choice>
<element ref="ipmpinfo-msaf:InitializationSettings" minOccurs="0"/>
<element ref="ipmpinfo-msaf:RightsDescriptor" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="order" type="positiveInteger"/>
</complexType>
Figure 63: The ipmpinfo-msaf:Tool element
In order to instantiate a DRM Tool, the DRM Processor will require additional information contained in the ipmpinfo-msaf:ToolBaseDescription, as described in sub-section 3.2.8.2.1. Once the DRM Tool is instantiated, the DRM Processor forwards to the DRM Tool any information included in the ipmpinfo-msaf:InitializationSettings for initialising the DRM Tool as described in sub-section 3.2.8.2.2. The DRM Tool usage may be subject to usage rules, in which case the corresponding Licenses will be provided in the ipmpinfo-msaf:RightsDescriptor element, as specified in Section 3.2.7.2 – Represent Local DRM Information. A signature may be applied to the ipmpinfo-msaf:Tool element.
For more information on the ipmpinfo-msaf:Tool, refer to [23].
The ipmpinfo-msaf:ToolBaseDescription is shown in the Figure below:
<element name="ToolBaseDescription" type="ipmpinfo-msaf:ToolBaseDescriptionType"/>
<complexType name="ToolBaseDescriptionType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID"/>
<choice minOccurs="0">
<element ref="ipmpinfo-msaf:Inline"/>
<element ref="ipmpinfo-msaf:Remote"/>
</choice>
<element ref="ipmpinfo-msaf:ConfigurationSettings" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
Figure 64: The ipmpinfo-msaf:ToolBaseDescription element
The ipmpinfo-msaf:IPMPToolID element specifies the URI of the DRM Tool. With this URI, the DRM Processor can Access the appropriate DRM Tool Body, as specified in Section 3.3.4.3 – Access DRM Tool, and instantiate it as described in Approved Document No. 2 – Architecture.
The DRM Tool Body may be either referenced in the ipmpinfo-msaf:Remote element or conveyed in the ipmpinfo-msaf:ToolBaseDescription in the two following ways:
· by including it in the ipmpinfo-msaf:Inline element as specified in [23]
· by including it in the ipmpinfo-msx:ToolBody element, child of ipmpinfo-msaf:Configuration as specified in section 3.2.9 - Represent DRM Tool Body.
Additionally, the optional element ipmpinfo-msaf:ConfigurationSettings may specify parameters used by the DRM Processor to configure a DRM Tool, including the ipmpinfo-msaf:Update element which specifies the location from which any update information may be obtained and the conditions under which a DRM Tool shall receive updates.
The ipmpinfo-msaf:InitializationSettings and its child elemen ipmpinfo-msaf:InitializationData is shown in the Figure below:
<element name="InitializationSettings" type="ipmpinfo-msaf:InitializationSettingsType"/>
<complexType name="InitializationSettingsType" mixed="true">
<sequence>
<element ref="ipmpinfo-msaf:InitializationData"/>
</sequence>
</complexType>
<element name="InitializationData" type="ipmpinfo-msaf:InitializationDataType"/>
<complexType name="InitializationDataType" mixed="true">
<sequence>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="ipmpmsg:ControlPointID" minOccurs="0"/>
<element ref="ipmpmsg:ControlPointAddress" minOccurs="0"/>
</sequence>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
Figure 65: The ipmpinfo-msaf:InitializationSettings element
The ipmpinfo-msaf:InitializationSettings contains one ipmpinfo-msaf:InitializationData element which conveys information required by a DRM Tool for initialization after its instantiation. The DRM Processor shall extract this information and forward it to the appropriate DRM Tool.
As specified in [23] and further explained in Section 3.2.7 – Represent DRM Information, the ipmpinfo-msaf:Tool is always a child element of an ipmpinfo-msaf:IPMPInfoDescriptor within a ipmpdidl-msaf:Info which in turn is contained in any of the Governed Content Elements defined in Section 3.2.7.1– Represent Governed Elements. The figure below shows the location of an ipmpinfo-msaf:Tool describing a DRM Tool designed to Govern a Resource.
<didl-msaf:Resource mimeType="application/ipmp">
<ipmpdidl-msaf:ProtectedAsset mimeType="video/mpeg">
<ipmpdidl-msaf:Info>
<ipmpinfo-msaf:IPMPInfoDescriptor>
<ipmpinfo-msaf:Tool>
......
</ipmpinfo-msaf:Tool>
<ipmpinfo-msaf:IPMPInfoDescriptor>
</ipmpdidl-msaf:Info>
</ipmpdidl-msaf:ProtectedAsset>
</didl-msaf:Resource>
Figure 66: Location of the ipmpinfo-msaf:Tool element
This approved document specifies the following fixed DRM Tools that implementers can utilise without the need of the full DRM Tool infrastructure.
· AES in cbc mode with a 128 bit key identified as follows:
o <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
· AES in ecb mode with a 128 bit key identified as follows:
o <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-ecb"/>
· RSA with a variable key length identified as follows (for a 1024 bit key):
o <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa1024"/>
This section specifies the Representation of specific information associated with DRM Tool embodiments. When signalled, such Tool embodiments shall be instantiated on a Device to enable Access to the Governed Content.
DRM Tools are software modules performing one or more DRM functions such as Authentication, Decryption, watermarking, etc. They may operate as “stand alone” Tools or they can be aggregated in a single entity called a DRM Tool Pack. A DRM Tool Pack is a special case of a DRM Tool because it consists of a group of DRM Tools, named DRM Tool Group, plus a special component named the DRM Tool Agent. The role of the DRM Tool Agent is to instantiate, initialise, Authenticate and supervise any operation performed by the DRM Tools that form part of the Tool Group.
The Figure below shows a graphical representation of the Represent Tool Body schema:
<element name="ToolBody" type="ipmpinfo-msx:ToolBodyType"/>
<complexType name="ToolBodyType">
<sequence>
<choice maxOccurs="unbounded">
<element ref="ipmpinfo-msx:SingleTool"/>
<element ref="ipmpinfo-msx:ToolPack"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
Figure 67: The ipmpinfo-msx:ToolBody element
Represent DRM Tool Body, denoted by the namespace prefix ipmpinfo-msx, conveys the executable code of a DRM Tool including specific information describing the DRM Tool (a Single DRM Tool or a DRM Tool Pack) and an optional Digital Signature.
If a Tool Body is not already available on the Device, the DMP Processor must first Access and, after signature verification, determine the nature of the DRM Tool from the presence of either ipmpinfo-msx:SingleTool or ipmpinfo-msx:ToolPack.
Note: The DRM Tool ID conveyed by the ipmpinfo-msaf:IPMPToolID element child of ipmpinfo-msaf:ToolBaseDescription (see Section 3.2.8 – Represent DRM Tool) can either identify a DRM Tool or a DRM Tool Pack, but not both. However, for achieving platform interoperability, implementations of the same DRM Tool (i.e. implementing the very same DRM algorithm) may exist for different platforms. In this case all of them share the same DRM Tool ID.
The Represent Tool Body namespace is defined in C.10 - The Media Streaming IPMPINFO extensions schema.
When the DRM Tool is a single DRM Tool, the body of this DRM Tool (the executable code) will be Delivered employing the ipmpinfo-msx:SingleTool element, shown in the figure below.
<element name="SingleTool" type="ipmpinfo-msx:DRMToolType"/>
<complexType name="DRMToolType">
<sequence>
<element ref="ipmpinfo-msx:ToolBodyID"/>
<element ref="ipmpinfo-msx:DeviceInformation" minOccurs="0"/>
<element name="ToolPackageType" type="string" minOccurs="0"/>
<element name="ToolCode" type="base64Binary"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
Figure 68: The ipmpinfo-msx:SingleTool element
The actual body of the DRM Tool is contained within the ipmpinfo-msaf:Binary element, as shown earlier in Section 3.2.1.11 - 2.1.12 Location of DRM Tool Body. The DRM Tool Body Identifier is contained in ipmpinfo-msx:ToolBodyID element.
The element ipmpinfo-msx:DeviceInformation provides the means to specify Device Information of the Devices on which the DRM Tool can operate (see Section 3.2.15 – Represent Device Information). Information related to the type of package of the DRM Tool Body (Zip, TAR, etc...) can be conveyed by specifying the corresponding MIME Type in the ipmpinfo-msx:ToolPackageType.
The DRM Processor, after verifying any Signature and ensuring that the Device matches the supported platform conditions, processes the pack containing the code of the DRM Tool (e.g. un-zips the archive) and instantiates the DRM Tool as described in [2].
When the DRM Tool is a DRM Tool Pack, the Tool Pack Body will be delivered by the ipmpinfo-msx:ToolPack element, shown in the figure below.
<element name="ToolPack" type="ipmpinfo-msx:ToolPackType"/>
<complexType name="ToolPackType">
<sequence>
<element ref="ipmpinfo-msx:ToolBodyID"/>
<element ref="ipmpinfo-msx:DeviceInformation" minOccurs="0"/>
<element name="ToolPackageType" type="string" minOccurs="0"/>
<element name="ToolAgent" type="ipmpinfo-msx:ToolAgentType"/>
<element name="ToolGroup" type="ipmpinfo-msx:ToolGroupType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="ToolAgent" type="ipmpinfo-msx:ToolAgentType"/>
<complexType name="ToolAgentType">
<sequence>
<element name="ToolAgentID" type="anyURI"/>
<element name="ToolAgentCode" type="base64Binary"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="ToolGroup" type="ipmpinfo-msx:ToolGroupType"/>
<complexType name="ToolGroupType">
<sequence>
<element name="ToolGroupID" type="anyURI"/>
<element name="ToolGroupCode" type="base64Binary"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
Figure 69: The ipmpinfo-msx:ToolPack
The ipmpinfo-msx:ToolPack element delivers a Tool Agent and an (optional) Tool Group. For more information about a Tool Agent and a Tool Group, refer to Approved Document No. 2 – Architecture [2]. The DRM Tool Pack Body Identifier is contained in ipmpinfo-msx:ToolBodyID element. The Tool Agent Body is conveyed by the ipmpinfo-msx:ToolAgentBody element, and its Tool Agent Identifier is conveyed by the ipmpinfo-msx:ToolAgentID.
Note: The Tool Agent ID and Tool Group ID must not be confused with the DRM Tool ID, the latter being the Identifier of a specific DRM Tool which can be a Single DRM Tool or a DRM Tool Pack. Every DRM Tool Pack contains a Tool Agent which in turn is characterised by a Tool Agent ID, and may have a Tool Group, characterised by its own ipmpinfo-msx:ToolGroupID.
As in the case of the single DRM Tool, it is also possible to specify information on the package type and supported platform for the Tool Pack.
The DRM Processor, after verifying all Signatures and ensuring that the Device matches the supported platform conditions, processes the package containing the code of the Tool Pack (e.g. un-zips the archive) and instantiates the DRM Tool Agent. Once the DRM Tool Agent is instantiated (and possibly Authenticated) the Tool Agent obtains the reference of the Tool Group and intantiates the Tools from the ToolGroup, if available. If not available, the DRM Tool Agent will request the reference of the remaining DRM Tools. The DRM Processor locates the missing tools on behalf of the Agent. The Agent subsequently instatiates these tools. For detailed information on DRM Tool Pack instantiation, initialisation and DRM Tool Pack management in general refer to Section 3.3.6.2.
The Figure below is an example of the Represent Tool Body namespace.
<ipmpinfo-msx:ToolBody>
<ipmpinfo-msx:ToolPack>
<ipmpinfo-msx:ToolBodyID>urn:foo:toolpack:001</ipmpinfo-msx:ToolBodyID>
<ipmpinfo-msx:DeviceInformation>
<ipmpinfo-msx:SupportedPlatform>
<mpeg4ipmp:OperatingSystem>
<mpeg4ipmp:Vendor>Red Hat</mpeg4ipmp:Vendor>
<mpeg4ipmp:Model>Enterprise</mpeg4ipmp:Model>
<mpeg4ipmp:Version>9.0</mpeg4ipmp:Version>
</mpeg4ipmp:OperatingSystem>
</ipmpinfo-msx:SupportedPlatform>
</ipmpinfo-msx:DeviceInformation>
<ipmpinfo-msx:ToolPackageType>application/zip</ipmpinfo-msx:ToolPackageType>
<ipmpinfo-msx:ToolAgent>
<dmprtb:ToolAgentID>urn:Origin:ToolPack:ToolID:ABC9:ToolAgentID:01
</ipmpinfo-msx:ToolAgentID>
<!-- Include the code implementing the DRM Tool in the element below -->
<ipmpinfo-msx:ToolAgentBody>AB67543EF5554CD0</ipmpinfo-msx:ToolAgentBody>
</ipmpinfo-msx:ToolAgent>
</ipmpinfo-msx:ToolPack>
</ipmpinfo-msx:ToolBody>
Figure 70: An example of the Represent Tool Body namespace
Represent Rights Data (RRD) is an ontology for representing IP Entities and associated actions taken upon them as well as those taken on their corresponding digital Representations as prescribed by the DMP Creation Model. The Creation Model as well as the rationale of the RRD has been described in [2] while a Java API for the RRD is provided in [7].
The RRD is fomalised in a single OWL file defined in Annex E.
At the OWL root level, the following three classes have been defined; IP Entity, Actions and Roles. Roles operate on IP Entities, by invoking Actions. The relations between these three classes are illustrated in the figure below.

Figure 71. Root Level Classes of the Ontology and their relations
Users (Creator, Adaptor, Instantiator, Producer...) have Roles associated to them that attribute to them rights over Actions that can be exercised on correspondng IP Entities. As stated in the specifications, “each creation model level is associated with characteristic Actions that correspond with specific functions that relate to activities at different points of the value chain”.

Figure 72. Roles
IP Entities refer to abstract entities that may be represented digitally such as Work, Adaptation, Manifestation, Instance… Further specialization is given so each can be further refined: For example, “Manifestation” can be either of an Adaptation or of a Work.
The figure below shows the IP Entity classes represented in the RRD.
Actions refer to both those that are applied over digital objects and those that are not. The result of some actions may imply the creation of another IPEntity (for example, a MakeAdaptation action generates a new IP Entity of the kind Adaptation) while others do not, for example the action “play”. The following figure depicts the actions represented in the RRD.

Figure 73 – IP Entities

Figure 74 – Actions
In the OWL file, the following definitions of each class are given in the rdfs:comment attribute. For all terms defined by the DMP the DMP definition has been used.
Note that a special helper class called Permit has also been defined as follows:
Permit: Transfers capability to perform Actions from one User to one or more Users.
The following IP Entities are defined:
1. Work: A creation that retains intellectual or artistic attributes independently of its Manifestations
2. Adaptation: A Work that has been derived from another Work.
3. Manifestation: An object or event which is an expression of a Work.
a. WorkManifestation: An object or event which is an expression of a Work
b. AdaptationManifestation: An object or event which is an expression of an Adaptation
4. Instance: An object or event which is an example of an Identified Manifestation (e.g. a File)
a. WorkInstance: An object or event which is an example of an Identified Work Manifestation (e.g. a File)
b. AdaptationInstance: An object or event which is an example of an Identified Adaptation Manifestation (e.g. a File).
5. Copy: The parent class of DMP defined Copies
a. WorkManifestationCopy: A Copy of a WorkManifestation
b. WorkInstanceCopy: A Copy of a WorkInstance
c. AdaptationManifestationCopy: A copy of an AdaptationManifestation
d. AdaptationInstanceCopy: A Copy of an AdaptationInstance
6. Product: A Content Item that adds value to IP Entities by including them with an appropriate Licence for the purpose of Publishing
The following actions are defined:
1. Synchronization. Concurrent performance/display of two distinct Works or Adaptation Instances each for a different sense e.g. tet and audio or video and song
2. MakeAdaptation: The action of making an Adaptation
3. Produce: The Function of making Products
4. Distribute: The Right to sell, rent and lend.
5. PublicCommunication: The action of publicly displaying/performing, e.g. live performance, radio, television, internet
a. Stream. The Function of Delivering Content to a Device where the transferred Content is processed for Rendering only and not Stored
b. Broadcast. The Function that Delivers Content to a Device in a point-to-multipoint modality
c. Download. Transfer a file or program from a central computer to a smaller computer or to a computer at a remote location
6. CreateWork: The action of creating a Work without any previous material.
7. MakeCopy. The Function by which Device A Stores Content in Device B, preserving the original Content in Device A. Similar to MechanicalCopy.
8. MakeManifestation. The action of making a Manifestation
9. MakeInstance. The action of making an Instance from a Manifestation. (Called First Fixation when it is the first time)
10. MakeWorkManifestation: The action of making a Manifestation.
11. MakeAdaptationManifestation: The action of making an AdaptationManifestation.
12. MakeWorkInstance: The action of making an Instance from a WorkManifestation.
13. MakeAdaptationInstance: The action of making an Instance from an Adaptation
14. MakeAdaptationInstanceCopy: The action of making a Copy of an AdaptationInstance
15. MakeAdaptationManifestationCopy: The action of making a Copy of a Manifestation
16. MakeWorkInstanceCopy: The action of making a Copy of a WorkInstance
17. MakeWorkManifestationCopy: The action of making a Copy of a WorkManifestation
18. ModifyCopy. Action of modifying a copy.
a. Enlarge. (MPEG-21 REL)Enlarge represents the Right to modify a resource by making it larger.
b. Reduce. (MPEG-21 REL) Represents the right to modify a resource by taking away from it
c. Extract. (MPEG-21 REL) Extract represents the Right to derive a new resource by taking a fragment out of an existing resource.
d. Embed. (MPEG-21 REL) Embed represents the Right to include a resource in another resource.
e. Export. (MPEG-21 REL) This element represents the right to export the associated broadcast program to another rendering or storage device
f. Modify (MPEG-21 REL) Modify represents the Right to make and save changes to a resource without creating a new resource.
g. Delete. (MPEG-21 REL) Delete represents the right to destroy a digital resource.
h. ExtendRights. (MPEG21 REL) This element represents the right to extend the rights which are the originally transmitted.
i. GovernedAdapt. (MPEG-21 REL) This element represents the right to adapt the resource and results in certain rights being associated with the adapted resource.
19. Render. The Function of generating a human-perceivable signal from a Resource
a. Install (MPEG-21 REL) Install represents the right to follow the instructions provided by an installing resource.
b. Uninstall. (MPEG-21 REL) Uninstall represents the right to follow the instructions provided by an uninstalling resource.
c. Print. (MPEG-21 REL) Print refers to the making of a fixed physical representation, such as hard-copy prints of images or text, that may be perceived directly (that is, without any intermediary process) with one or more of the five human senses.
d. Execute. (MPEG-21 REL) Execute represents the right to execute a digital resource.
e. Play. (MPEG-21 REL) Represents the Right to derive a transient and directly perceivable representation of the Resource. The Function of Rendering a Resource
20. MoveContent. (DMP-Move) The Function by which Device A Stores Content in Device B deleting the original Content in Device A.
a. Move. (MPEG-21 REL) Represents the right to relocate one resource from one place to another.
b. GovernedMove. (MPEG-21 REL) This element represents the right to copy the resource and at the same time to result in certain rights being associated to the copied resource.
The following Roles are supported:
1. Adaptor: A User who produces an Adaptation
2. Creator: A User who generates a Work and makes its first Manifestation, also referred to as author
3. Distributor: A User who distributes a Product including public communication
4. EndUser: A User in a Value-Chain who ultimately consumes Content
5. Instantiator: A User who produces an Instance
6. Producer: A User who produces a Product from an Instance.
Relations relate classes in the Ontology. Every relation has a domain corresponding to values from one class resulting in a range of values of another or the same class. A functional property is a property that can have only one (unique) value of the range for each value of the domain. When the functional property is absent, it is understood there may be any number of values corresponding between domain and range.
The following basic relations have been defined:
|
Relation |
Definition |
Funct. |
Domain |
Range |
|
Supports |
Declares which actions are meaningful over an IP Entity. |
N |
IPEntity |
Action |
|
RightsGivenBy |
Declares which role can give rights over an action |
Y |
Action |
Role |
|
ResultsIn |
Declares which IP Entity arises as a result of the execution of an action. It is a functional relation (i.e. the result of an action is a single individual) |
Y |
Action |
IPEntity |
|
Can |
Defines the actions that a role can do. |
N |
Role |
Action |
|
RightsOwner |
Defines the owner of the rights over an IP Entity. |
N |
IPEntity |
Role |
|
Origin |
Defines the original ip entity of another IP Entity (or itself for Work) |
N |
IPEntity |
IPEntity |
|
HasConsentOver |
Determines whether a role has the consent given by the Creator over an IP Entity to perform the actions that require it. |
N |
Role |
IPEntity |
|
PermitActions |
Relation used to express the Actions that are allowed to be performed. |
N |
Permit |
Action |
|
PermitIPEntity |
Relation used to express over which IP Entity Actions can be exercised |
N |
Permit |
IPEntity |
|
SourceOfPermit |
Relation used to express the User who issues the permit |
Y |
Permit |
Role |
|
ObjectOfPermit |
Relation used to express which User receives a given permit |
N |
Permit |
Role |
To represent variations of a range domain correspondence operators such as min, max and exactly can be used. For example, every product has min 1 copies as sources and a WorkInstanceCopy exactly 1 WorkInstance Origin.
The next table shows some examples for the relations defined above
|
Relation |
Example |
|
Supports |
Work Supports (MakeAdaptation or MakeWorkManifestation) |
|
RightsGivenBy |
Distribute RightGivenBy Producer |
|
ResultsIn |
MakeAdaptation ResultsIn Adaptation |
|
Can |
Adaptor Can (MakeAdaptation or MakeAdaptationManifestation) |
|
RightsOwner |
MyWork RightsOwner Alice |
|
Origin |
Adaptation Origin (Work or Adaptation) |
|
HasConsentOver |
Bob HasConsentOver MyInstaneCopy |
Note: The first four relations serve to establish general restrictions. While in the RightsOwner and HasConsentOver do not establish restrictions but illustrate how the RRD can operate with individuals of the Work (MyWork), Creator (Alice) and User (Bob) respetively.
Below is an excerpt of the RRD Ontology OWL file where the use of relations in the context of defining Adaptation and related RRD classes:
<owl:Class rdf:about="#Adaptation"> ß The class Adaptation is defined
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
|
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Work"/>
<owl:Class rdf:about="#Adaptation"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Manifestation"/>
<owl:disjointWith rdf:resource="#Instance"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf
rdf:parseType="Collection">
<owl:Class
rdf:about="#MakeAdaptation"/>
|
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Copy"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>It is a Work that has been derived from another Work.</rdfs:comment>
<rdfs:subClassOf>
<owl:Class rdf:about="#IPEntity"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Product"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Work"/>
</owl:disjointWith>
</owl:Class>
Figure 75 – excerpt of the RRD Ontology OWL file
The RDD Ontology specified in this document has a wide scope beyond the use of REL statements.
The terms of the Ontology that may be used in a REL statement presently within the IDP are those defined by the DAC and ORC profile of REL.
This section specifies the Tool to express usage rules associated with Content that in turn map onto specific Device behaviour consistent with the semantics of the Rights Expressions.
Licenses may be used for different purposes; a non-exhaustive list is given below:
· To Grant the Right to Use Content (e.g. Device D can Play Content Item X five times)
· To attribute properties to a Principal (Device D belongs to Domain B)
· To Govern the Use of DRM Tools (DRM Tool T can only work on Devices Certified by Agency A)
Licenses in IDP-3.0 are based on a extends the MPEG-21 REL Dissemination and Capture (DAC) [25] and Open Access Content (OAC) [26] Profile, in order to support DMP Domain requirements. For an overview of the MPEG-21 REL Standard, refer to Annex A.3.3. For examples of how this namespace can be used to support various external Rights and Conditions for SAV Use Cases such as Copy Control Information (CCI) and TV-Anytime’s Rights Management and Protection Information (RMPI) see [36].
The dmprl:DomainResource element is an extension to the rel-msaf:Resource complex type, defined in the MPEG-REL core schema, with elements from the DMP Represent Domain schema (msd), and is specified in the Figure below:
<element name="DomainResource" type="dmprl:DomainResourceType" substitutionGroup="rel-msaf:resource"/>
<complexType name="DomainResourceType">
<complexContent>
<extension base="rel-msaf:Resource">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:DomainKey"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 76: The dmprl:DomainResource element
The dmprl:DomainResource is used to Grant to a User or a Device the membership of a Domain, and therefore it conveys all the information that the Device or the User requires. In detail, this element conveys:
A Domain Resource is always contained in a License, where:
For more information on these elements, refer to Section 3.2.16 – Represent Domain.
DRM applications may require the use of encryption and decryption Keys during their execution. There are two types of Keys:
· Content Keys: keys used to encrypt Resources, and inserted into the Content (i.e. in the DCI) possibly encrypted using a License Key. Content Keys may be of two types:
· time-independent Keys, ie, keys that do not need to be synchronised to the content delivery
· time-dependent Keys, ie, keys that are synchronised to timely packet delivery, for instance for the timely decoding of streamed content.
· License Keys: Keys typically used to encrypt Content Keys, and Delivered in a License, possibly encrypted using the License Principal's public Key.
The sub-sections below state how to Represent the different types of Keys.
When a Key that can be employed to Decrypt Resources without the need to synchronise the key delivery with Resource delivery between Devices, this shall be done using the ipmpmsg:Key element specified in the figure below.
<element name="Key" type="ipmpmsg:KeyType"/>
<complexType name="KeyType">
<complexContent>
<extension base="ipmpmsg:KeyBaseType">
<sequence>
<choice>
<element ref="xenc:EncryptedData"/>
<element ref="xenc:EncryptedKey"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="KeyBaseType" abstract="true"/>
Figure 77: The ipmpmsg:Key element
Where a Key to be employed to Decrypt Resources with time synchronisation constraints associated with packetised Resource delivery has to be Delivered between Devices, this shall be conveyed within the ipmpmsg:TimeKey element represented in the Figure below:
<element name="TimeKey" type="ipmpmsg:TimeKeyType"/>
<complexType name="TimeKeyType">
<complexContent>
<extension base="ipmpmsg:KeyType">
<sequence>
<element name="startDTS" type="unsignedLong" minOccurs="0"/>
<element name="startPacketID" type="unsignedInt" minOccurs="0"/>
<element name="expireDTS" type="unsignedLong" minOccurs="0"/>
<element name="expirePacketID" type="unsignedInt" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 78: The ipmpmsg:Key element
The ipmpmsg:TimeKey element conveys a Decryption Key and further information about its use by the DRM Tool that receives it.
Whenever a Key has to be Delivered to a DRM Tool, this is done by employing a ipmpmsg:KeyData element, as specified in Section 3.2.13 - Represent DRM Messages. Further information on the Protocols to Manage DRM Tool is given in Section 3.3.6.2.
Whenever a Resource has been Protected by one or more DRM Tools employing either an ipmpmsg:Key or an ipmpmsg:TimeKey, the Key or the various TimeKeys are in turn encrypted by employing a further Key (typically referred as the Master Key) which is Delivered in a License, by means of the rel-m1x-msaf:ProtectedResource element specified in the figure below.
<xsd:complexType name="ProtectedResource">
<xsd:complexContent>
<xsd:extension base="r-msaf:Resource">
<xsd:sequence minOccurs="0">
<xsd:element ref="r-msaf:digitalResource"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="xenc:EncryptedData"/>
<xsd:element ref="xenc:EncryptedKey"/>
</xsd:choice>
<xsd:element name="resourceLocator" type="xsd:anyURI" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Figure 79: The rel-m1x-msaf:ProtectedResource element
This section provides the means to Represent Information exchanged between different components on a Device, such as two DRM Tools or a DRM Processor and a DRM Tool.
DRM Messages are a translation of messages originally defined in the MPEG-2 and MPEG-4 IPMPX standards (see [12] and [14]) from a binary representation to XML. See Annex A.5 - MPEG-2/4 IPMP Extension for an overview of those standards.
Note: In the sub-sections below a DRM Tool can be either a single DRM Tool or a DRM Tool Agent of a DRM Tool Pack
As specified in Sections 3.2.8 – Represent DRM Tool and 3.3.6.2 – DRM Processor – DRM Tools Protocols, the DRM Processor instantiates a DRM Tool to Govern a Content Element every time it encounters a ipmpinfo-msaf:Tool element within the Governed Content Representation in the DCI.
The DRM Processor assigns an Identifier to each instance of DRM Tool, named the DRM Tool Context ID. The Tool Context ID serves a different role from the DRM Tool ID. In particular, two instances of a DRM Tool with a common DRM Tool ID will be assigned different values of Tool Context ID.
Once the DRM Tool is instantiated, the Governance of the Governed Content Element through the DRM Tool may involve the exchange of information between the DRM Processor and the DRM Tool or between the various DRM Tools. This information is coded in DRM Messages, which are encapsulated in two different containers depending on the way the Message is originated:
1) MessageFromDCI: this container Message is sent from the DRM Processor to a DRM Tool conveying information extracted from the DCI and addressed to the DRM Tool (e.g. a Key to Decrypt a Resource);
2) MessageFromTool: this container Message is sent either from the DRM Processor or from a DRM Tool to another DRM Tool and contains information originated internally by the sender. For example, a Message requesting mutual Authentication.
Both Containers: MessageFromDCI and MessageFromTool, share the same abstract XML element Base Type: ipmpmsg:IPMPBaseType, shown in the Figure below:
<complexType name="IPMPBaseType" abstract="true"/>
Figure 80: The ipmpmsg:IPMPBaseType type
All DRM Message Containers are based on the ipmpmsg:ToolMessageBase element, defined in the following Figure:
<element name="ToolMessageBase" type="ipmpmsg:ToolMessageBaseType" abstract="true"/>
<complexType name="ToolMessageBaseType" abstract="true">
<complexContent>
<extension base="ipmpmsg:IPMPBaseType">
<sequence>
<element name="Sender" type="xsd:unsignedInt"/>
<element name="Recipient" type="xsd:unsignedInt"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 81: The ipmpmsg:ToolMessageBase element
The abstract element ipmpmsg:ToolMessageBase extends ipmpmsg:IPMPBaseType by adding Sender and Recipient elements to the message. These elements contain an unsigned integer representing the unique Identifier that the DRM Processor assigns to each instance of a DRM Tool, the DRM Tool Context ID. The DRM Processor shall be Identified by the value ‘0’.
All DRM Messages extend the ipmpmsg:Data_BaseClass element, as specified in the Figure below:
<element name="Data_BaseClass" type="ipmpmsg:Data_BaseClassType" abstract="true"/>
<complexType name="Data_BaseClassType" abstract="true">
<complexContent>
<extension base="ipmpmsg:IPMPBaseType">
<sequence>
<element name="dataID" type="unsignedInt"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 82: The ipmpmsg:Data_BaseClass element
The abstract element ipmpmsg:Data_BaseClass extends the ipmpmsg:IPMPBaseType element by adding the dataID element, which shall contain an unsigned integer value identifying a Message. The same value of dataID shall be used in any reply to that message.
Any DRM Message extracted from the DCI during its Parsing by the DRM Processor and addressed to a DRM Tool shall be conveyed to that DRM Tool by encapsulation in a ipmpmsg:MessageFromDI message, which is specified in the Figure below:
<element name="MessageFromDI" type="ipmpmsg:MessageFromDIType" substitutionGroup="ipmpmsg:ToolMessageBase"/>
<complexType name="MessageFromDIType">
<complexContent>
<extension base="ipmpmsg:ToolMessageBaseType">
<sequence>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 83: The ipmpmsg:MessageFromDCI element
The ipmpmsg:MessageFromDCI element (indirectly) extends the ipmpmsg:ToolMessageBase element by adding a sequence of DRM Messages extending the ipmpmsg:Data_BaseClass.
Any DRM Message originated spontaneously from a DRM Processor or a DRM Tool and addressed to another DRM Tool shall be conveyed to that DRM Tool by encapsulation in a ipmpmsg:MessageFromTool message, which is specified in the Figure below:
<element name="MessageFromTool" type="ipmpmsg:MessageFromToolType" substitutionGroup="ipmpmsg:ToolMessageBase"/>
<complexType name="MessageFromToolType">
<complexContent>
<extension base="ipmpmsg:ToolMessageBaseType">
<sequence>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 84: The ipmpmsg:MessageFromTool element
The ipmpmsg:MessageFromTool element (indirectly) extends the ipmpmsg:ToolMessageBase element by adding a sequence of DRM Messages extending the ipmpmsg:Data_BaseClass.
DRM Messages express in an interoperable way a vast quantity of DRM-related information which can be exchanged by two parties by Representing it with the Messages specified by the DMP Represent DRM Messages namespace.
The delivery of DRM Messages exchanged between two DRM Tools on a Device shall be handled by the DRM Processor. Hence, a compliant DRM Processor shall be able to forward all DRM Messages defined in this specification to a recipient DRM Tool. However, a compliant DRM Processor is not required to be able to process all DRM Messages, as some of them may contain information that is only meaningful for a specific DRM Processor. A compliant DRM Processor shall be able to process all DRM Messages labelled “DP” in the Table below.
DRM Messages are divided into two categories: those belonging to a base and those belonging to an extended profile of this specification. All DRM Tools shall be able to process DRM Messages belonging to the base profile, labelled with “B” in the table below. DRM Tools may also be able to process DRM Messages belonging to the extended profile, labelled with “X” in the table below, in which case they will be compliant with the extended profile.
The following table specifies the DRM Messages to be exchanged by two DRM Tools or between a DRM Tool and the DRM Processor to achieve Mutual Authentication.
Table 12 – Mutual Authentication Messages
|
DRM Message |
DP |
Profile |
Purpose |
|
SecureContainer |
DP |
B |
Secure container message for any message extending the IPMP_Data_BaseClass. |
|
InitAuthentication |
DP |
B |
Message that initiates a mutual authentication process |
|
MutualAuthentication |
DP |
B |
Messages exchanged during mutual authentication process |
The InitAuthentication and MutualAuthentication DRM Messages are described in Section 3.2.14.
The following table specifies the DRM Messages to be exchanged by a DRM Tool and a DRM Processor to trigger the instantiation of a new DRM Tool, or to obtain specific information about DRM Tools.
Table 13 – DRM Tool Connection and Disconnection Messages
|
DRM Message |
DP |
Profile |
Purpose |
|
GetTools |
DP |
B |
Message sent by a DRM Tool to the DRM Processor to find all the tools, instantiated or not, that are available on the Device. |
|
GetToolsResponse |
DP |
B |
Message sent by the DRM Processor to a DRM Tool in reply to a GetTools Message |
|
ToolParamCapabilitiesQuery |
DP |
X |
Messages allowing a DRM Processor to query a DRM Tool as for support for a specific parametric description |
|
ToolParamCapabilitiesResponse |
DP |
X |
Message in response to the above parametric capabilities query. Returns a boolean value as to whether or not the parametric description is supported by the tool |
|
ConnectTool |
DP |
B |
A Request Message from a DRM Tool to the DRM Processor to create a connection to a tool identified by the ipmpinfo-msaf:Tool element |
|
DisconnectTool |
DP |
B |
Message allowing a DRM Tool to disconnect a DRM Tool it has previously connected |
|
GetToolContext |
DP |
B |
Message sent from a DRM Tool to the DRM Processor to find the DRM Tool context ID of all DRM Tools operating on the same Governed Content Element |
|
GetToolContextResponse |
DP |
B |
Message sent from the DRM Processor to a DRM Tool that has required to find the DRM Tool context IDs of all DRM Tools operating on the same Governed Content Element. |
The following table specifies the DRM Messages to be exchanged between a DRM Tool and a DRM Processor when being notified of particular events related to DRM Tools on the Device.
Table 14 – DRM Tool Notification Messages
|
DRM Message |
DP |
Profile |
Purpose |
|
AddToolNotificationListener |
DP |
B |
Message sent from a DRM Tool to the DRM Processor to request notification of certain events. |
|
RemoveToolNotificationListener |
DP |
B |
Message sent from a DRM Tool to the DRM Processor to stop the notification of certain events |
|
NotifyToolEvent |
DP |
B |
Message to notify a DRM Tool of an event for which it had previous registered as a listener. A list of events is given in the Represent DRM Messages schema. |
The list of events described in NotifyToolEvent row above are listed in the table below.
Table 15 – Event types
|
"00" – CONNECTED |
|
"01" - CONNECTION_FAILED |
|
"02" - DISCONNECTED |
|
"03" - DISCONNECTION_FAILED |
|
"04" - WATERMARKDETECTED |
|
"05" - PARSE_TOOLPACKDATA_SUCCESS |
|
"06" - PARSE_TOOLPACKDATA_FAILED |
|
"07" - UNABLE_TO_PROCESS |
|
"08" - TOOL_GROUP_NOT_FOUND |
|
"09" - TERMINATION_FAILED |
|
"10" - CONTROLPOINT_NOT_SUPPORTED |
|
"11" - UNABLE_TO_PARSE_LICENSE |
|
"12" - NO_VALID_LICENSE |
|
"13" - LICENSE_VALIDATION_FAILED |
|
"14" - READY_TO_PLAY |
|
"15" - READY_TO_BE_TERMINATED |
The following table specifies the DRM Messages to be exchanged between two DRM Tools or between a DRM Processor and a DRM Tool for different purposes.
Table 16 – DRM Processing Messages
|
DRM Message |
DP |
Profile |
Purpose |
|
KeyData |
DP |
B |
Message conveying either a time-dependent or time-independent Decryption Key |
|
RightsData |
DP |
B |
Message conveying a License |
|
CanProcess |
DP |
B |
Sent from a DRM Tool to the DRM Processor to allow or deny content processing |
|
OpaqueData |
DP |
B |
General-purpose container Message for any type of data |
|
AudioWatermarkingInit |
|
X |
Message for delivering to a DRM Tool performing audio watermarking specific information about the audio content and a payload and possibly other related proprietary data required by the Tool |
|
VideoWatermarkingInit |
|
X |
Message for delivering to a DRM Tool performing audio watermarking specific information about the audio content and a payload and possibly other related proprietary data required by the Tool |
|
SendAudioWatermark |
|
X |
Message conveying an audio watermark payload and other related information obtained by a DRM Tool performing Audio Watermarking on audio data |
|
SendVideoWatermark |
|
X |
Message conveying a video watermark payload and other related information obtained by a DRM Tool performing Video Watermarking on video data |
|
SelectiveDecryptionInit |
|
X |
Message to initialise a DRM Tool performing decryption |
Two Messages among those defined in the Table above are specified below. These are ipmpmsg:KeyData and ipmpmsg:RightsData.
<element name="KeyData" type="ipmpmsg:KeyDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="KeyDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<choice maxOccurs="unbounded">
<element ref="ipmpmsg:Key"/>
<element ref="ipmpmsg:TimeKey"/>
</choice>
<element ref="ipmpmsg:opaqueData" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 85: The ipmpmsg:KeyData element
The ipmpmsg:RightsData Message shall be employed to Deliver a License to a DRM Tool.
<element name="RightsData" type="ipmpmsg:RightsDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="RightsDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="rightsInfo" type="r-msaf:License"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 86: The ipmpmsg:RightsData element
The following table specifies the DRM Messages to allow the communication between a DRM Tool and the User.
Table 17 – User Interaction Messages
|
DRM Message |
DP |
Profile |
Purpose |
|
UserQuery |
DP |
B |
Message used to query the User for information |
|
UserQueryResponse |
DP |
B |
Message containing the User response to a UserQuery message |
The following table specifies additional DRM Messages to be exchanged between a DRM Tool and a DRM Processor for different purposes:
Table 18 – DMP-defined DRM Messages
|
DRM Message |
DP |
Profile |
Purpose |
|
InitialiseTool |
DP |
B |
Message conveying initialisation data to a DRM Tool |
|
GetToolGroupReference |
DP |
B |
Message sent by a DRM Tool Agent to the DRM Processor requesting the reference to the Reference of the associated DRM Tool Group |
|
GetToolGroupReferenceResponse |
DP |
B |
Message sent by a DRM Processor to a DRM Tool Agent conveying the reference to the reference of the associated DRM Tool Group |
|
GetToolReference |
DP |
B |
This message is to get the reference of specific Single DRM Tool which is not in the DRM Tool Group. This message is sent by the DRM Tool Agent to the DRM Processor. |
|
GetToolReferenceResponse |
DP |
B |
This message is to convey the reference of a requested Single DRM Tool. This message is sent by the DRM Processor to the DRM Tool Agent. |
|
GetToolPackData |
DP |
B |
Message sent by a DRM Tool Agent to the DRM Processor requesting DRM Tool Pack data |
|
ToolPackData |
DP |
B |
Message sent by a DRM Processor to a DRM Tool Agent conveying DRM Tool Pack Data. |
Note: a compliant single DRM Tool does not need to be able to process DRM Tool Pack messages.
The syntax of these messages is specified in the DMP namespace ipmpmsg in Annex C.11 – The IPMP XML Messages Schema. An overview of these messages now follows.
ipmpmsg:InitialiseTool
This Message is specified in the Figure below:
<element name="InitialiseTool" type="ipmpmsg:InitialiseToolType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="InitialiseToolType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="DRMProcessorInstance" type="base64Binary"/>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="ipmpmsg:ControlPointID"/>
<element ref="ipmpmsg:ControlPointAddress" minOccurs="0"/>
</sequence>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="ControlPointID" type="ipmpmsg:ControlPointType"/>
<complexType name="ControlPointType">
<sequence>
<element name="ID" type="integer"/>
</sequence>
</complexType>
<element name="SequenceCode" type="short"/>
<element name="ControlPointAddress" type="base64Binary"/>
Figure 87: The ipmpmsg:InitialiseTool element
An ipmpmsg:InitialiseTool element delivers the following information:
· DRMProcessorInstance: a handle of the DRM Processor required by the Tool to send Messages back to the DRM Processor. The format of this handle may depend on the particular Device on which the DRM Processor is running, and such information depends on the Instantiation_API_ID value in the ipmpinfo-msx:ToolAPI_Config defined in 3.2.15 - Represent Device Information.
· ControlPointID: an ID indicating the point where the DRM Tool can operate along the Resource processing pipelines. This ID should be registered by the authorized agency before being used. The ipmpmsg:ControlPointID assignments are given in the below table;
Table 19 – List of available Control Points
|
ControlPointID |
Description |
|
00 |
NO_CONTROL_POINT |
|
01 |
CONTROL_POINT_BEFORE_DEMULTIPLEXING |
|
02 |
CONTROL_POINT_BEFORE_AUDIO_DECODING |
|
03 |
CONTROL_POINT_AFTER_AUDIO_DECODING |
|
04 |
CONTROL_POINT_BEFORE_VIDEO_DECODING |
|
05 |
CONTROL_POINT_AFTER_VIDEO_DECODING |
|
06 |
CONTROL_POINT_BEFORE_STORING |
|
07 |
CONTROL_POINT_BEFORE_PLAYBACK |
|
08 |
CONTROL_POINT_BEFORE_TRANSFERRING |
· ControlPointAddress: a local address on the Device, that the DRM Tool can be connected to, and have an input Resource. The format of this address may depend on the particular Device on which the DRM Processor is running, and such information depends on the Instantiation_API_ID value in the ipmpinfo-msx:ToolAPI_Config element.
· Other messages derived from ipmpmsg:Data_BaseClass.
ipmpmsg:GetToolGroupReference
Each DRM Tool Pack optionally contains the DRM Tool Group. The DRM Tool Agent requires the DRM Tool Group to perform proper DRM functions. This message is sent by the DRM Tool Agent to request the reference of the DRM Tool Group.
<element name="GetToolGroupReference" type="ipmpmsg:GetToolGroupReferenceType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolGroupReferenceType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
Figure 88: The ipmpmsg:GetToolGroupReference element
ipmpmsg:GetToolGroupReferenceResponse
This message is sent by the DRM Processor to deliver the reference of the DRM Tool Group. This message delivers the following information:
· ToolGroupReference: the reference of the DRM Tool Group. The reference indicates either the handle or the local address of the DRM Tool Group depending on the Instantiation_API_ID value in the ipmpinfo-msx:ToolAPI_Config element.
<element name="GetToolGroupReferenceResponse" type="ipmpmsg:GetToolGroupReferenceResponseType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolGroupReferenceResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="ToolGroupReference" type="base64Binary"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 89: The ipmpmsg:GetToolGroupReferenceResponse element
ipmpmsg:GetToolReference
The DRM Tool Agent may need a Single DRM Tool to perform proper DRM functions. This message is sent by the DRM Tool Agent to request the reference of the Single DRM Tool. This message delivers the following information:
· IPMPToolID: ID of the Single DRM Tool that the DRM Tool Agent request. More than one ID can be given.
<element name="GetToolReference" type="ipmpmsg:GetToolReferenceType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolReferenceType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 90: The ipmpmsg:GetToolReference element
ipmpmsg:GetToolReferenceResponse
This message is sent by the DRM Processor to deliver the reference of the Single DRM Tool. This message delivers the following information:
· IPMPToolID: the ID of the Single DRM Tool that the DRM Tool Agent request. More than one ID can be given.
· ToolReference: the reference of the Single DRM Tool given by the IPMPToolID. The reference indicates either the handle or the local address of the DRM Tool Group depending on the Instantiation_API_ID value in the ToolAPI_Config.
<element name="GetToolReferenceResponse" type="ipmpmsg:GetToolReferenceResponseType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolReferenceResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<sequence maxOccurs="unbounded">
<element ref="ipmpinfo-msaf:IPMPToolID"/>
<element name="ToolReference" type="base64Binary"/>
</sequence>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 91: The ipmpmsg:GetToolReferenceResponse element
ipmpmsg:GetToolPackData
The DRM Tool Agent may need Tool Pack Data to initialize the DRM Tool Group or the Single DRM Tool. This message is sent by the DRM Tool Agent to request the Tool Pack Data.
<element name="GetToolPackData" type="ipmpmsg:GetToolPackDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolPackDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
Figure 92: The ipmpmsg:GetToolPackData element
ipmpmsg:ToolPackData
This message is sent by the DRM Processor to deliver the Tool Pack Data. This message delivers the following information:
· OpaqueData: the information to initialize the DRM Tool Group or the Single DRM Tool. Only the proper DRM Tool Agent can parse this information.
<element name="ToolPackData" type="ipmpmsg:ToolPackDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="ToolPackDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="opaqueData" type="base64Binary"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 93: The ipmpmsg:ToolPackData element
The following table specifies DMP-defined Messages to be exchanged between the Resource Processor and a DRM Processor for different purposes. Resource Processors and DRM Processors only conformant to the Base profile do not need to know how to process and react upon receiving one of the Messages in the table below. However, this is a requirement for those Resource Processors and DRM Processors seeking conformance to the extended profile.
Table 20 – Resource Processor - DRM Processor Messages
|
DRM Message |
Purpose |
Expected Response |
|
ipmpmsg:InitialiseIPMPProcessor |
Message sent by the Resource Processor to the DRM Processor conveying initialisation data |
null |
|
ipmpmsg:GetProtectedAsset |
Message sent by the DRM Processor to the Resource Processor requesting the didl-msaf:ProtectedAsset Representing the Governed Content Element that needs to be processed |
ipmpmsg:GetProtectedAssetResponse |
|
ipmpmsg:GetProtectedAssetResponse |
Message sent by the Resource Processor to a DRM Processor conveying the requested didl-msaf:ProtectedAsset |
null |
|
ipmpmsg:GetRightsData |
Message sent by the DRM Processor to the Resource Processor requesting all Licenses available for specific Content Elements |
ipmpmsg:RightsData |
|
ipmpmsg:NotifyIPMPProcessorEvent |
Message sent by the DRM Processor to the Resource Processor to indicate an event has occurred |
null |
|
ipmpmsg:TerminateIPMPProcessor |
Message sent by the Resource Processor to the DRM Processor requesting to free all the allocated resources because the DRM Processor will be shut down |
null |
ipmpmsg:InitialiseIPMPProcessor
Message sent by the Resource Processor to the DRM Processor conveying initialisation data. This message delivers the following information:
· Which Control Points (and optional ControlPointAddress) are available on the Resource Processor
· The ipmpinfo-msaf IPMPGeneralInfoDescriptor of the Governed Content selected
· Any number of ipmpdidl-msaf:ProtectedAsset on which the DRM Processor needs to operate
<element name="InitialiseIPMPProcessor" type="ipmpmsg:InitialiseIPMPProcessorType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="InitialiseIPMPProcessorType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="ipmpmsg:ControlPointID"/>
<element ref="ipmpmsg:ControlPointAddress" minOccurs="0"/>
</sequence>
<element ref="ipmpinfo-msaf:IPMPGeneralInfoDescriptor" minOccurs="0"/>
<element ref="ipmpdidl-msaf:ProtectedAsset" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 94: The ipmpmsg:InitialiseIPMPProcessor element
ipmpmsg:GetProtectedAsset
Message sent by the DRM Processor to the Resource Processor requesting the didl-msaf:ProtectedAsset Representing the Governed Content Element that needs to be processed. This message is specified as in the figure below:
<element name="GetProtectedAsset" type="ipmpmsg:GetProtectedAssetType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetProtectedAssetType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
Figure 95: The ipmpmsg:GetProtectedAsset element
ipmpmsg:GetProtectedAssetResponse
Message sent by the Resource Processor to a DRM Processor conveying the requested didl-msaf:ProtectedAsset. This message conveys a number of ProtectedAsset elements in response to a ipmpmsg:GetProtectedAsset or in case a ProtectedAsset is received via Streaming
<element name="GetProtectedAssetResponse" type="ipmpmsg:GetProtectedAssetResponseType"/>
<complexType name="GetProtectedAssetResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpdidl-msaf:ProtectedAsset" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 96: The ipmpmsg: GetProtectedAssetResponse element
ipmpmsg:GetRightsData
Message sent by the DRM Processor to the Resource Processor requesting all Licenses available for specific Content Elements. This Message contains the following information:
· The Content ID/Resource ID whose associated Licenses are sought
<element name="GetRightsData" type="ipmpmsg:GetRightsDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetRightsDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="dii-msaf:Identifier" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 97: The ipmpmsg:GetRightsData element
ipmpmsg:NotifyIPMPProcessorEvent
Message sent by the DRM Processor to inform the events such as an error or status of the DRM Processor. NotifyDRMProcessorEvent message extends the Data_BaseClass Type by conveying:
· The result of the User Query validation conveyed by the ipmpmsg:EventType.
<element name="NotifyIPMPProcessorEvent" type="ipmpmsg:NotifyIPMPProcessorEventType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="NotifyIPMPProcessorEventType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpmsg:EventType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 98: The ipmpmsg:NotifyIPMPProcessorEvent element
Possible event types are included in Table 15 – Event types.
ipmpmsg:TerminateIPMPProcessor
Message sent by the Resource Processor to the DRM Processor requesting to free all the allocated resources because the DRM Processor will be shut down.
This message is specified as in the figure below:
<element name="TerminateIPMPProcessor" type="ipmpmsg:TerminateIPMPProcessorType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="TerminateIPMPProcessorType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
Figure 99: The ipmpmsg:TerminateIPMPProcessor element
This specification defines two Messages to establish Authentication between two Entities. These are: ipmpmsg:InitAuthentication and ipmpmsg:MutualAuthentication.
The use of the Messages described in this section is mandated for local environments (e.g. the establishment of Mutual Authentication between the DRM Processor and any DRM Tool). Other authentication technologies may be used to achieve Mutual Authentication in other environments (e.g. the establishment of Mutual Authentication between two Devices communicating over IP networks may very well employ other techniques such as SSL/TLS).
The syntax and semantics of these messages is specified in the sub-sections below.
The ipmpmsg:InitAuthentication Message shall be employed by an entity to initialise the mutual authentication process with another. The syntax of the Message is specified in the Figure below:
<element name="InitAuthentication" type="ipmpmsg:InitAuthenticationType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="InitAuthenticationType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="ContextID" type="anyURI" minOccurs="0"/>
<element name="AuthType" type="ipmpmsg:AUTType"/>
<!--Context ID of the logical instance of the Tool with which mutual authentication is to be performed-->
</sequence>
</extension>
</complexContent>
</complexType>
Figure 100: The ipmpmsg:InitAuthentication Message
The ipmpmsg:InitAuthentication Message extends the ipmpmsg:Data_BaseClass Type (see Section 3.2.13 – Represent DRM Messages) by conveying:
· ContextID: the local ID of the DRM Tool with which mutually Authentication is to be initialised (see Section 3.2.13.2.1 - ipmpmsg:ToolMessageBase). This element is used when mutual Authentication involves two DRM Tools or a DRM Processor and a DRM Tool, or any time the sender knows the URI of the entity it is requesting to Authenticate with.
· AuthType: the type of Authentication required, specified in the Figure below:
<simpleType name="AUTType">
<restriction base="integer">
<enumeration value="01"/>
<enumeration value="02"/>
<enumeration value="03"/>
<enumeration value="04"/>
</restriction>
</simpleType>
Figure 101: The ipmpmsg:InitAuthentication Message
The ipmpmsg:AUTType simple type can only be given one of the values listed in the Table below, with the semantics specified in the right column.
Table 21 – List of available Authentication Request types
|
01 |
No Authentication Required |
|
02 |
No ID verify, Do secure channel |
|
03 |
Do ID verify, No secure channel |
|
04 |
Do ID verify, Do secure channel |
The recipient of a ipmpmsg:InitAuthentication Messages shall reply with a ipmpmsg:MutualAuthentication Message as defined in the sub-Section below.
The ipmpmsg:MutualAuthentication is employed by two entities (e.g. the DRM Processor and a DRM Tool) for the purpose of:
1. negotiating the Authentication protocol
2. carrying out the agreed upon protocol
3. negotiating how the secured communication channel has to be used.
The syntax of the ipmpmsg:MutualAuthentication is specified in the Figure below:
<element name="MutualAuthentication" type="ipmpmsg:MutualAuthenticationType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="MutualAuthenticationType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<choice>
<element name="requestNegotiation" type="ipmpmsg:requestNegotiationType"/>
<element name="successNegotiation" type="ipmpmsg:successNegotiationType"/>
<element name="failedNegotiation" type="boolean" fixed="true"/>
</choice>
<element name="authenticationData" type="hexBinary" minOccurs="0"/>
<element name="authCodes" type="ipmpmsg:AuthCodesType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 102: The ipmpmsg:MutualAuthentication element
The ipmpmsg:MutualAuthentication Message extends the ipmpmsg:Data_BaseClass Type (see Section 3.2.13 – Represent DRM Messages) by conveying:
· the choice between:
o ipmpmsg:requestNegotiation element, when the Message is employed in the initial phase of the Authentication Protocol in reply to a ipmpmsg:InitAuthentication message, to indicate that the sender is requesting negotiation about an authentication algorithm to be used in the subsequent communication
o ipmpmsg:successNegotiation element, when the Message is employed to indicate that the negotiation of an Authentication protocol was successful, and for specifying the selected protocol.
o ipmpmsg:failedNegotiation, indicating that no proposed Authentication algorithms are supported.
· ipmpmsg:authenticationData, an optional element specifying data to be used for mutual authentication and whose value depends on method specific processing
· ipmpmsg:authCodes, optional authentication codes to this message.
The syntax of the ipmpmsg:requestNegotiationType complex type is specified in the Figure below:
<complexType name="requestNegotiationType">
<sequence>
<element name="candidateAlgorithms" type="ipmpmsg:AlgorithmDescriptorType"/>
</sequence>
</complexType>
Figure 103: The ipmpmsg:requestNegotiationType complex type
The ipmpmsg:requestNegotiationType complex type conveys the list of Authentication algorithms supported by means of the ipmpmsg:candidateAlgorithms element. The ipmpmsg: AlgorithmDescriptorType complex type is specified in the Figure below.
<complexType name="AlgorithmDescriptorType">
<sequence>
<element name="algoID" type="anyURI" maxOccurs="unbounded"/>
<element ref="ipmpmsg:opaqueData" minOccurs="0"/>
</sequence>
</complexType>
Figure 104: The ipmpmsg:AlgorithmDescriptorType complex type
Each of the supported Algorithms are characterised by an Identifier of type xsd:anyURI. Optionally, ipmpmsg:opaqueData containing related data to the algorithm can be conveyed.
The syntax of the ipmpmsg:successNegotiationType complex type is specified in the Figure below:
<complexType name="successNegotiationType">
<sequence>
<element name="agreedAlgorithms" type="ipmpmsg:AlgorithmDescriptorType" maxOccurs="unbounded"/>
</sequence>
</complexType>
Figure 105: The ipmpmsg:successsNegotiationType complex type
The ipmpmsg:MutualAuthentication message containing the ipmpmsg:successNegotiation element is sent by the entity initiating the mutual Authentication process in reply to a ipmpmsg:MutualAuthentication message proposing a list of candidate algorithms. The ipmpmsg:agreedAlgorithms element conveys the list of the Authentication algorithms supported, among the ones proposed by the entity that was challenged.
The syntax of the ipmpmsg:AuthCodesType complex type is specified in the Figure below:
<complexType name="AuthCodesType">
<sequence>
<element name="certificates" type="dsig:KeyInfoType" maxOccurs="unbounded"/>
<element name="trustData" type="hexBinary" minOccurs="0"/>
</sequence>
</complexType>
Figure 106: The ipmpmsg:AuthCodesType complex type
The ipmpmsg:authCodes element conveys
· a number of certificates and/or trust data belonging to the entity involved in the Authentication process
· (optional) trust and security data, mostly used when Mutual Authentication involves DRM Tools.
This section specifies the Tools used to Represent the technical characteristics of a Device. This can be used to negotiate between a Device and a DRM Tool Provider for the correct DRM Tools. Represent Device includes information such as type of operating system, memory, CPU, etc., as shown in the figure below:
<element name="DeviceInformation" type="ipmpinfo-msx:DeviceType"/>
<complexType name="DeviceType">
<complexContent>
<extension base="mpeg4ipmp:TerminalIDType">
<sequence>
<element ref="ipmpinfo-msx:ToolAPI_Config" minOccurs="0" maxOccurs="unbounded"/>
<element ref="ipmpinfo-msx:Others" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 107: The ipmpinfo-msx:DeviceInformation element
For the syntax of the elements in the Figure above defined in the mpeg4ipmp namespace, refer to Annex C.12, while for their semantics refer to [14].
The ipmpinfo-msx:ToolAPI_Config element was originally defined in [14] in a binary format and has been transferred to the ipmpinfo-msx:ToolAPI_Config as shown here. The syntax of the ipmpinfo-msx:ToolAPI_Config element is specified in the Figure below:
<element name="ToolAPI_Config" type="ipmpinfo-msx:ToolAPI_ConfigType"/>
<complexType name="ToolAPI_ConfigType">
<sequence>
<element name="Instantiation_API_ID" type="anyURI" minOccurs="0"/>
<element name="Messaging_API_ID" type="anyURI" minOccurs="0"/>
<element name="OpaqueData" type="hexBinary" minOccurs="0"/>
</sequence>
</complexType>
Figure 108: The ipmpinfo-msx:ToolAPI_Config element
This element specifies two identifiers: ipmpinfo-msx:Instantiation_API_ID and ipmpinfo-msx:Messaging_API_ID, both of type xsd:anyURI. These API identifiers serve the following purpose.
· Instantiation_API_ID: An Identifier that indicates the API for instantiation of the DRM Tool.
· Messaging_API_ID: An Identifier that indicates the API to pass messages to/from a DRM Tool
A DMP-appointed Registration Authority shall register for different implementations of DRM Tool instantiation API and DRM Tool messaging API. An optional field ipmpinfo-msx:OpaqueData shall be used to convey further data from any namespace.
The optional element ipmpinfo-msx:Others is specified in the Figure below:
<element name="Others" type="ipmpinfo-msx:OtherTypes"/>
<complexType name="OtherTypes">
<sequence>
<any namespace="##any" processContents="lax"/>
</sequence>
<attribute name="ref" type="anyURI" use="required"/>
</complexType>
Figure 109: The ipmpinfo-msx:Others element
By employing the optional ipmpinfo-msx:Others element, which can host data from any namespace, further Information about the Device can be specified. Its mandatory attribute 'ref' of type xsd:anyURI specifies the namespace URI of the data.
The elements specified above are defined in Annex C.10 – The Media Streaming IPMPInfo Extensions Schema.
This Section specifies the elements that enable Domains to be described.
The Represent Domain namespace, msd, defines an abstract base type element from which the rest of the elements are derived, as follows:
<complexType name="DomainBaseType" abstract="true"/>
Figure 110: The msd:DomainBaseType complex type
The msd namespace defines the following elements:
<element name="DomainManagerID" type="r:KeyHolder"/>
<element name="AccessPassword" type="string"/>
<element name="AccessID" type="r:KeyHolder"/>
<element name="DomainKey" type="xenc:EncryptedKeyType"/>
<element name="UserID" type="msd:IDType"/>
<element name="DeviceID" type="msd:IDType"/>
<element name="LocalDomainID" type="msd:IDType"/>
<element name="ContentGroupID" type="anyURI"/>
<element name="MaximumNumberOfDevices" type="unsignedInt"/>
<element name="MaximumNumberOfUsers" type="unsignedInt"/>
<element name="MaximumFrequencyOfUpdateDevice" type="duration"/>
<element name="MaximumFrequencyOfUpdateUser" type="duration"/>
<element name="Expiration" type="sx:ValidityTimeMetered"/>
Figure 111: Some msd elements
The semantics for the elements above are as below. The reader is refered to AD2 - Technical Architecture [2] for an overview of the architecture and Device functions and concepts referred to here.
· msd:DomainManagerID: the identifier assigned to a Domain Manager Device (DMD) by the Domain Authority.
· msd:AccessID: the Access ID given to the Domain Administrator
· msd:AccessPassword: the Access Password given to the Domain Administrator
· msd:DomainKey: the Decryption Key for Domain-Encrypted Content Key
· msd:UserID: the Identifier associated with the User, which is of type ipmpinfo-msxp:IDType (See the Figure below)
· msd:DeviceID: the Identifier associated with the Device, which is of type ipmpinfo-msxp:IDType (See the Figure below)
· msd: LocalDomainID: The Local Domain Identifier issued by the DID
· msd:ContentGroupID: the Identifier assigned to a group of Content Items for the Management of Domains
· msd:MaximumNumberOfDevices: the maximum number of Devices allowed in a Domain
· msd:MaximumNumberOfUsers: the maximum number of Users allowed in a Domain
· msd:MaximumFrequencyOfUpdateDevice: the minimum time interval before a Device that has left a Domain may be allowed to re-join it.
· msd:MaximumFrequencyOfUpdateUser: the minimum time interval before a User who has left a Domain may be allowed to re-join it.
· msd:Expiration: the expiration date for the Domain membership
<complexType name="IDType">
<sequence>
<choice>
<element name="id" type="anyURI"/>
<element ref="dsig:X509Data" minOccurs="0"/>
</choice>
</sequence>
</complexType>
Figure 112: The msd:IDType complex type
The msd:IDType complex type contains an Identifier, which can be either of type anyURI and conveyed by the msd:id element, or an X.509 certificate, in which case it shall be expressed according to the dsig:X509Data element and conformant to RFC 2459 [41].
A Domain is established when a Domain Administrator requests a new Domain from a Domain Manager Device (DMD). The Protocol for Creating a Domain is given in Section 3.3.3.2.1 – Create Domain Protocol.
The result of this Protocol is the creation by the DMD of a msd:DomainManageInfo element specified in the Figure below:
<element name="DomainManageInfo" type="msd:DomainManageInfoType"/>
<complexType name="DomainManageInfoType">
<complexContent>
<extension base="msd:DomainBaseType">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:DACredentials" minOccurs="0"/>
<element ref="msd:DomainMembershipCredentials" minOccurs="0"/>
<choice minOccurs="0" maxOccurs="2">
<element ref="msd:User"/>
<element ref="msd:Device"/>
</choice>
<element ref="msd:DomainKey"/>
<element name="Registration" type="dateTime"/>
<element name="Expiration" type="sx:ValidityTimeMetered"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 113: The msd:DomainManageInfo element
In the figure above, the following semantics apply.
· DomainID: a unique Identifier for the Domain, as specified in 3.2.5.8.
· The msd:DACredentials element contains the Domain Administrator Credentials, the ones by which a Domain Administrator may Create a Domain, Renew a Domain and Delete a Domain
· The msd:DomainMembershipCredentials element contains the Credentials needed by any Device or User in order to Join a Domain (Add Device and Add User), Renew the membership to a Domain (Renew Device, Renew User) and Leave a Domain (Leave Device, Leave User)
· The msd:Registration element indicates the time at which the Domain is created.
· The msd:Expiration element indicates the time at which the Domain expires.
The msd:DACredentials and msd:DomainMembershipCredentials are specified in the figure below:
<element name="DACredentials" type="msd:DomainCredentialType"/>
<element name="DomainMembershipCredentials" type="msd:DomainCredentialType"/>
<complexType name="DomainCredentialType">
<sequence>
<element ref="msd:AccessID"/>
<element ref="msd:AccessPassword"/>
</sequence>
</complexType>
Figure 114: The msdp:DACredentials and msdp:DMCredentials elements
The msd:DomainID element is defined as follows:
<element name="DomainID" type="msd:DomainIDType"/>
<complexType name="DomainIDType">
<complexContent>
<extension base="msd:IDType">
<sequence>
<element ref="msd:DomainManagerID"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 115: The msd:DomainID element
This DomainID element shown above conveys an Identifier assigned to a specific Domain. This contains:
· the msd:DomainManagerID element, an Identifier Assigned by the Domain Authority
· the choice between two different representations of the Identifier of the Domain assigned by the Domain Manager Device, as shown in Figure 112.
The msd:User element is defined in the Figure below:
<element name="User" type="msd:UserType"/>
<complexType name="UserType">
<complexContent>
<extension base="msd:DomainBaseType">
<sequence>
<element ref="msd:UserIDList"/>
<element ref="msd:MaximumNumberOfUsers" minOccurs="0"/>
<element ref="msd:MaximumFrequencyOfUpdateUser" minOccurs="0"/>
<element ref="msd:UserRevocationList" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 116: The msd:User element
The msd:User element conveys a set of properties associated with Users in a Domain. This conveys the following:
· the msd:UserIDList, as defined in the Figure below
· the msd:MaximumNumberOfUsers, the maximum number of Users allowed in a Domain
· the msd:MaximumFrequencyOfUpdateUser: the shortest duration permitted between a User leaving and re-registering with this Domain. Note that the UserID shall not be removed from the UserIDList until after the time indicated in the msd:MaximumFrequencyOfUpdateUser element.
· the msd:UserRevocationList: the list of Users which are no longer allowed to be members of this Domain.
The msd:UserIDList element is defined in the Figure below:
<element name="UserIDList">
<complexType>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="msd:UserID"/>
<element ref="msd:Expiration"/>
</sequence>
</complexType>
</element>
Figure 117: The msd:UserIDList element
This element is used to convey a list of User Identifiers associated with this Domain. Each User has an expiration time, allocated by the Domain Managed Device at the time of joining the Domain.
The msd:Device element is defined in the Figure below:
<element name="Device" type="msd:DeviceType"/>
<complexType name="DeviceType">
<complexContent>
<extension base="msd:DomainBaseType">
<sequence>
<element ref="msd:DeviceIDList"/>
<element ref="msd:MaximumNumberOfDevices" minOccurs="0"/>
<element ref="msd:MaximumFrequencyOfUpdateDevice" minOccurs="0"/>
<element ref="msd:DeviceRevocationList"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 118: The msd:Device element
The msd:Device element shown above conveys the following set of properties associated with Devices in a Domain.
· the msd:DeviceIDList, as defined in the Figure below
· the msd:MaximumNumberOfDevices, the maximum number of Devices allowed in a Domain
· the msd:MaximumFrequencyOfUpdateDevice: the shortest duration permitted between a Device leaving and re-registering with this Domain.
· the msd:DeviceRevocationList: the list of Devices which are no longer allowed to be members of this Domain.
The msd:DeviceIDList element is defined in the Figure below:
<element name="DeviceIDList">
<complexType>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="msd:DeviceID"/>
<element ref="msd:Expiration" />
</sequence>
</complexType>
</element>
Figure 119: The msd:DeviceIDList element
This element is used to convey a list of Device Identifiers associated with this Domain. Each Device has an expiration time, allocated by the Domain Managed Device at the time of joining the Domain.
The Represent Base Protocol namespace, msbp, defines a number of elements and complex types common to all Protocols.
The DomainProtocolBaseType is an abstract base type from which the rest of the elements are derived. This is the following:
<complexType name="ProtocolBaseType" abstract="true"/>
Figure 120: The msbp:ProtocolBaseType complex type
A number of elements defined in msdp namespace derive from the following complex type:
<complexType name="ProtocolType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="TransactionID" type="unsignedByte"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 121: The msbp:ProtocolType complex type
The msbp:ProtocolType contains the TransactionID element which is used to track a message exchange session.
Several messages require an acknowledgement to be returned to the sender after a messsage has been received. This is achieved by employing the msbp:Ack message specified in the figure below.
<element name="Ack" type="msbp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
Figure 122: The msbp:Ack element
The msdp:Ack element extends the msdp:ProtocolType complex type by specifying a required boolean attribute: Result, which shall indicate whether the Protocol was carried out with success or otherwise. The ProtocolResult element specified in the figure below may be employed to convey additional information.
<element name="ProtocolResult" type="msbp:ProtocolResultType"/>
<complexType name="ProtocolResultType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element name="ResultCode" type="msbp:ResultCodeType"/>
<element name="UserDefinedResult" type="string"/>
</choice>
<element name="DisplayString" type="string" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="ResultCodeType">
<restriction base="hexBinary">
<enumeration value="00"/>
<enumeration value="01"/>
<enumeration value="02"/>
<enumeration value="03"/>
<enumeration value="04"/>
<enumeration value="05"/>
<enumeration value="06"/>
<enumeration value="07"/>
</restriction>
</simpleType>
Figure 123: The msbp:ProtocolResult element
The msbp:ProtocolResult element may either employ the msbp:ResultCode element to convey a return value among a set defined in the MSAF specification, or a custom value. Furthermore, the message allows conveying a textual value to be displayed to the user as a result of the protocol.
Table 22 – List of available Authentication Request types
|
00 |
RESERVED |
|
01 |
OK |
|
02 |
UNKNOWN MESSAGE |
|
03 |
TIMEOUT |
|
04 |
UNABLE_TO_PROCESS |
|
05 |
UNKNOWN_FAILURE |
|
06 |
PERMISSION_DENIED |
|
07 |
BUSY |
This message is sent by any entity involved in the Protocols to Manage Domain, with the purpose of acknowledging an entity involved in the Protocol of the success or failure of the Protocol.
This Section specifies the messages exchanged between entities when managing Domains, for instance when creating a Domain, or when Devices join or leave a Domain. The representation of the messages includes a number of Domain Representation namespace elements, msd, described in section [3.2.16] and introduces new elements in the Represent Domain Protocol namespace, msdp, as shown in the figures below. A number of protocols for the exchange of these messages to perform Domain management are specified in Section 3.3.3 – Protocols to Manage Domain.
The base type for all Domain Protocol messages is defined in the figure below.
<complexType name="DomainProtocolType">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
Figure 124: The msdp:DomainProtocolType complex type
The msdp:AuthenticationReq message is defined in the figure below.
A choice between DACredentials and DomainMembershipCredentials elements (depending on whether it is the Domain Administrator or a Device/User in the Domain who is requesting authentication with the DMD) shown above is contained within the message specified below.
<element name="AuthenticateReq" type="msdp:AuthenticateReqType"/>
<complexType name="AuthenticateReqType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DomainID" minOccurs="0"/>
<choice>
<element ref="msd:DACredentials"/>
<element ref="msd:DomainMembershipCredentials"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 125: The msdp:AuthenticateReq element
The msdp:Ack message, defined in the figure below, is sent in response to an msdp:AuthenticateReq message and can also be employed to acknowledge the success of an operation or to convey an error message in case of failure.
<element name="Ack" type="msdp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
Figure 126: The msdp:Ack element
For the semantics of the msdp:Ack message, refer to Figure 122: The msbp:Ack element
The msdp:LocalDomainIDRequest message is sent by a Domain Management Device to a Domain Identification Device to request an Identifier for a new Domain.
<element name="LocalDomainIDRequest" type="msdp:RequestLocalDomainIDType"/>
<complexType name="RequestLocalDomainIDType">
<complexContent>
<extension base="msdp:DomainProtocolType"/>
</complexContent>
</complexType>
Figure 127: The msdp:LocalDomainIDRequest element
The msdp:LocalDomainIDResponse message is a message sent by the Domain Identification Device to the Domain Management Device in response to an msdp:LocalDomainIDRequest. If the request was successful, this message conveys the requested LocalDomainID.
<element name="LocalDomainIDResponse" type="msdp:LocalDomainIDResponseType"/>
<complexType name="LocalDomainIDResponseType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:LocalDomainID"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 128: The msdp:LocalDomainIDResponse element
The msdp:RequestKey message is sent by a License Provider Device to a Domain Management Device to request the Domain Key of a specific Domain.
<element name="RequestKey" type="msdp:RequestKeyType"/>
<complexType name="RequestKeyType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:ContentGroupID" minOccurs="0" maxOccurs="unbounded"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="msd:DeviceID"/>
<element ref="msd:UserID"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 129: The msdp:RequestKey element
The semantics are given below:
· DomainID: The Domain Identifier of the Domain for which the License Provider is asking the Domain Key
· ContentGroupID: The list of Content Groups (group of Content Items for management within domains) Licensed to the Domain for which the LPD issues a License
· DeviceID: The Identifier of the Device requesting a Domain-bound License.
· UserID: The Identifier of the User requesting a Domain-bound License
The msdp:RequestKeyResponse message is a message sent by the Domain Management Device to the License Provider Device in response to an msdp:RequestKey message. If the request was successful, this message conveys the requested Domain Key.
<element name="RequestKeyResponse" type="msdp:RequestKeyResponseType"/>
<complexType name="RequestKeyResponseType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DomainKey"/>
<element ref="msd:UserID" minOccurs="0" maxOccurs="unbounded"/>
<element ref="msd:DeviceID" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 130: The msdp:RequestKeyResponse element
The semantics for msdp:RequestKeyResponse are given below:
· msd:DomainKey: element used to convey the encrypted Domain key of the Domain indicated by DomainID in the preceding msdp:RequestKey message. This is used subsequently by the License Provider Device to encrypt Content Keys so that only those Devices with the corresponding Domain decryption Key can Use Content encrypted with the Content Key.
· msd:DeviceID: the identifiers of the member Devices of the Domain indicated by msd:DomainID in the preceding msdp:RequestKey. Each msd:DeviceID can be used to encrypt a Content Key and create a License with a set of encrypted Content Keys such that any of the Devices indicated can Use the Content with the License.
· msd:UserID: the identifiers of member Users of the Domain indicated by msd:DomainID in the preceding RequestKey. Each msd:UserID can be used to encrypt a Content Key and to create a License with a set of encrypted Content Keys so that any User indicated can use the Content with the License.
The msdp:AddDevice message is sent by a Device to a Domain Management Device to request to join a Domain.
<element name="AddDevice" type="msdp:AddDeviceType"/>
<complexType name ="AddDeviceType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msdp:DeviceID"/>
<element ref="msd:Expiration" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 131: The msdp:AddDevice element
This message conveys the Identifier of the Device requesting Domain membership.
The msdp:AddUser message is sent by a User to a Domain Management Device to request to join a Domain.
<element name="AddUser" type="msdp:AddUserType"/>
<complexType name ="AddUserType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:UserID"/>
<element ref="msd:Expiration" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 132: The msdp:AddUser element
This message conveys the Identifier of the User requesting Domain membership.
The msdp:RenewDevice message above is sent by a Device to a Domain Management Device to request a renewal of its membership of a Domain.
<element name="RenewDevice" type="msdp:RenewDeviceType"/>
<complexType name="RenewDeviceType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DeviceID"/>
<element ref="msdp:UseData" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 133: The msdp:RenewDevice element
This message conveys the Identifier of the Device requesting the renewal of Domain membership, and the Use Data generated.
The msdp:RenewUser message above is sent by a User to a Domain Management Device to request a renewal of the membership of a Domain.
<element name="RenewUser" type="msdp:RenewUserType"/>
<complexType name ="RenewUserType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:UserID"/>
<element ref="msdp:UseData" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 134: The msdp:RenewUser element
The following Messages are sent in Response to msdp:AddDevice, msdp:AddUser, msdp:RenewDevice, msdp:RenewUser.
<element name="AddDeviceResponse" type="msdp:LicenseResponseType"/>
<element name="AddUserResponse" type="msdp:LicenseResponseType"/>
<element name="RenewDeviceResponse" type="msdp:LicenseResponseType"/>
<element name="RenewUserResponse" type="msdp:LicenseResponseType"/>
<complexType name="LicenseResponseType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence>
<element ref="r-msaf:license"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 135: Messages extending the LicenseResponseType complex type
If the request was successful, the message in response would contain a Domain membership License. An example of a Domain Membership License is provided in the figure below.
<license>
<grant>
<keyHolder>
<info>
<dsig:KeyName>My_SAV_public_key</dsig:KeyName>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>01234567</dsig:Modulus>
<dsig:Exponent>89ABCDEF</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</info>
</keyHolder>
<possessProperty/>
<m1x:protectedResource>
<digitalResource>
<nonSecureIndirect URI="urn:foo:domains:5555"/>
</digitalResource>
<xenc:EncryptedKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa1024"/>
<xenc:CipherData>
<xenc:CipherValue>ABABABAB</xenc:CipherValue>
</xenc:CipherData>
<xenc:CarriedKeyName>Domain Key encrypted with My_SAV_public_key</xenc:CarriedKeyName>
</xenc:EncryptedKey>
</m1x:protectedResource>
<r:allConditions>
<validityInterval>
<notBefore>2007-03-01T00:00:00</notBefore>
<notAfter>2007-04-30T00:00:00</notAfter>
</validityInterval>
</r:allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>DMD_Public_Key</dsig:KeyName>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>12121212</dsig:Modulus>
<dsig:Exponent>34343434</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</info>
</keyHolder>
</issuer>
</license>
Figure 136: An example of Domain membership License
The msdp:LeaveDevice message is sent from a Device to the DMD to request to be removed from a Domain.
<element name="LeaveDevice" type="msdp:LeaveDeviceType"/>
<complexType name="LeaveDeviceType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence>
<element ref="msd:DeviceID"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 137: The msdp:LeaveDevice element
The msdp:LeaveUser message is sent from a User to the DMD to request to be removed from a Domain.
<element name="LeaveUser" type="msdp:LeaveUserType"/>
<complexType name="LeaveUserType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence>
<element ref="msd:UserID"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 138: The msdp:LeaveUser element
The following messages are employed by the Domain Administrator to create a new domain and managing it.
<element name="CreateDomain" type="msdp:CreateDomainType"/>
<complexType name="CreateDomainType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DACredentials"/>
<element ref="msd:Expiration"/>
<element ref="msd:MaximumNumberOfUsers" minOccurs="0"/>
<element ref="msd:MaximumNumberOfDevices" minOccurs="0"/>
<element ref="msd:MaximumFrequencyOfUpdateUser" minOccurs="0"/>
<element ref="msd:MaximumFrequencyOfUpdateDevice" minOccurs="0"/>
<element ref="msd:UserRevocationList" minOccurs="0"/>
<element ref="msd:DeviceRevocationList" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 139: The msdp:CreateDomain element
The msdp:CreateDomain message is sent from a Domain Administrator to the DMD for asking the set-up of a new Domain.
In response to a msdp:CreateDomain message, the DMD replies with a msdp:CreateDomainResponse message, as specified in the figure below:
<element name="CreateDomainResponse" type="msdp:CreateDomainResponseType"/>
<complexType name="CreateDomainResponseType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:DomainMembershipCredentials"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 140: The msdp:CreateDomainResponse element
The msdp:CreateDomainResponse conveys the DomainID and the DomainMembershipCredentials to the Domain Administrator, who can make them available to any Device or User for allowing them to join the Domain he has just created.
The msdp:RenewDomain message is sent from a Domain Administrator to the DMD requesting the renewal of a Domain when this has expired or is the expiration date is near.
<element name="RenewDomain" type="msdp:RenewDomainType"/>
<complexType name="RenewDomainType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence>
<element ref="msd:Expiration"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 141: The msdp:RenewDomain element
The msdp:DeleteDomain message above is sent from a Domain Administrator to the DMD requesting a Domain to be Deleted.
<element name="DeleteDomain" type="msdp:DeleteDomainType"/>
<complexType name="DeleteDomainType">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
Figure 142: The msdp:DeleteDomain element
A detailed explanation of the use of the msdp:UnlicensedSimultaneousUseNotice is given in Section 3.3.3.5 – Protocols to Detect Simultaneous Usage.
<element name="UnLicensedSimultaneousUseNotice" type="msdp:UnLicensedSimultaneousUseNoticeType"/>
<complexType name="UnLicensedSimultaneousUseNoticeType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence>
<element ref="msd:UseData" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 143: The msdp:UnLicensedSimultaneousUseNotice element
The Representation of Use Data required for the management of Domains is given below. The way msd:UseData and msd:Record elements are employed as described in Section 3.3.3.5 – Protocols to Detect Simultaneous Usage.
<element name="UseData" type="msd:UseDataType"/>
<complexType name="UseDataType">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:Record" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
Figure 144: The msd:UseData element
The msd:Record element is given in the figure below.
<element name="Record" type="msd:RecordType"/>
<complexType name="RecordType">
<sequence>
<element ref="msd:DeviceID"/>
<element name="StartTime" type="dateTime"/>
<element name="EndTime" type="dateTime"/>
<element name="NumberOfContentGroups" type="integer"/>
<element ref="msd:ContentGroupID" minOccurs="0" maxOccurs="unbounded"/>
<element name="NotificationFlag" type="boolean"/>
</sequence>
</complexType>
Figure 145: The msd:Record element
The semantics for msd:Record is given below:
· DeviceID: the Identifier of the Device on which the Content Item was Used
· StartTime: the time the Device started to Use a Content Item belonging to a Content Group
· EndTime: the time the Device ended Using a Content Item belonging to a Content Group
· NumberOfContentGroups: the number of Content Groups to which the Content Item being Used belongs to. Each Content Group may consist of multiple Content Items, where only one Content Item in a Content Group is allowed to be Used simultaneously.
· ContentGroupID: The Content Group Identifier
· NotificationFlag: a Boolean value set to TRUE when this Use Data record has been notified to the DMD. The communication of the Use Data to another Device in the Domain doesn't change the value of this flag in the Use Data.
This Section specifies the messages exchanged between entities when carrying out Access Protocols, for instance when Accessing Content or Accessing License, as specified in Section 3.3.4 – Protocols to Access.
The base type for all Domain Protocol messages is defined in the figure below.
<complexType name="AccessProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
Figure 146: The msap:AccessProtocolType complex type
The msap:Ack message, defined in the figure below, is used to acknowledge the success of an operation or to convey an error message in case of failure.
<element name="Ack" type="msdp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
Figure 147: The msdp:Ack element
For the semantics of the msdp:Ack message, refer to Figure 122: The msbp:Ack element
The Represent Access Protocol namespace, msap, defines a complex type named msap:ContentIdentifierType which is employed to specify the Content Identifier of a Content Item, or in the case of a Resource, the Content Identifier of the Content Item containing the Resource, and the Resource Identifier:
<complexType name="ContentIdentifierType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ContentIdentifier" type="anyURI"/>
<element name="ResourceIdentifier" type="anyURI" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 148: The msap:ContentIdentifierType complex type
The RequestIPMPToolBody protocol is intended for use by both the SAV and the CCD devices
<element name="RequestIPMPToolBody" type="msap:RequestIPMPToolBodyType"/>
<complexType name="RequestIPMPToolBodyType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID"/>
<element ref="ipmpinfo-msx:DeviceInformation"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 149: The msap:RequestIPMPToolBody element
The msap:RequestIPMPToolBody element is employed by a Device to obtain a DRMToolBody (See section 3.2.9 – Represent ToolBody) from a DRM Tool Provider Device. The semantics is given below:
· ipmpinfo-msaf:IPMPToolID: The DRM Tool Identified of the requested DRM Tool Body
· ipmpinfo-msx:DeviceInformation: Device Information allowing the DRM Tool Provider Device to send an appropriate DRM Tool Body
The msap:RequestIPMPToolBodyResponse element is employed by a DRM Tool Provider Device to either Deliver a DRM Tool Body in the message or to convey the location from where the DRM Tool Body is available.
<element name="RequestIPMPToolBodyResponse" type="msap:RequestIPMPToolBodyResponseType"/>
<complexType name="RequestIPMPToolBodyResponseType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<choice maxOccurs="unbounded">
<element ref="ipmpinfo-msx:ToolBody"/>
<element name="ToolURL" type="anyURI"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 150: The msap:RequestDRMToolBodyResponse element
The following are intended for communication between the Stationary Audio Visual Device (SAV) and supporting Devices.
A PAV (through the PXD) or a SAV sends the following message to the Content Provider in order to Access Content:
<element name="RequestContent" type="msap:RequestContentType"/>
<complexType name="RequestContentType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence>
<element name="ContentIdentifier" type="msap:ContentIdentifierType"/>
<element name="MimeType" type="string"/>
<element ref="r-msaf:license" minOccurs="0"/>
<element name="UsageEnvironmentDescription" type="dia:UsageEnvironmentType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 151: The msap:RequestContent element
The semantics for the msap:RequestContent message are given below:
· ContentIdentifier: The Content ID of the requested Content Item. In the case a specific Resource part of a Content item is the target of the request, the ResourceID field part of ContentIdentifierType must specify the Resource Identifier.
· MimeType: The Mime Type of the requested content[1]. The following values are supported:
1. application/mp21 – The DCF is requested
2. application/xml – The DCI is requested
· license: an optional License indicating the type of License the entity performing the request is interested in (where this is applicable)
· UsageEnvironmentDescription: The capabilities of the Device on which the Content Item or Resource will be rendered
· dsig:Signature: an optional digital Signature of the msap:RequestContent message by the PAV or SAV
The msap:RequestContentResult element is sent in response to an msap:RequestContent message, and is specified as follows:
<element name="RequestContentResult" type="msap:RequestContentResultType"/>
<complexType name="RequestContentResultType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element name="DI" type="didl-msaf:DIDLType" minOccurs="0"/>
<element name="ContentURL" type="msap:ContentURLType" minOccurs="0" maxOccurs="unbounded"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ContentURLType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="MimeType" type="string"/>
<element name="URL" type="anyURI"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 152: The msap:RequestContentResult element
The RequestContentResult message may convey the DCI in the DI element if this was the target of the request. The ContentURL element may convey either the remote location from where the Content Item may be obtained, including the information concerning the Mime Type of the Content item or Content Element being made available either for download or as a stream[2].
<?xml version="1.0" encoding="UTF-8"?>
<RequestContentResult>
<msbp:TransactionID>3456</msbp:TransactionID>
<ContentURL>
<MimeType>application/mp4</MimeType>
<URL>rtp://localhost:8888</URL>
</ContentURL>
<ContentURL>
<MimeType>application/xml</MimeType>
<URL>http://localhost:9999</URL>
</ContentURL>
</RequestContentResult>
Figure 153: The msap:RequestContentResult element
The figure above shows that the mp4 video is streamed by employing the rtp protocol to port 8888 on the requesting Device, while the metadata associated to the requested Resource is streamed by employing the http protocol to port 9999.
A PAV (through the PXD) or a SAV sends the following message to the License Provider in order to Access License:
<element name="RequestLicense" type="msap:RequestLicenseType"/>
<complexType name="RequestLicenseType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence>
<choice>
<element name="ContentIdentifier" type="msap:ContentIdentifierType"/>
<element name="LicenseID" type="anyURI"/>
</choice>
<element ref="r-msaf:license" minOccurs="0"/>
<element name="DISignature" type="dsig:SignatureType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 154: The msap:RequestLicense element
The semantics for the msap:RequestLicense message are given below:
· ContentIdentifier: The Content ID or, if a Resource ID is specified in the ContentIdentifier element, a specific Resource within a Content Item, for which a License is sought.
· LicenseID: An Identifier for the sought License.
· license: an optional License indicating the License that the requesting party is seeking.
· didl-msx:DISignature: the optional container for a signature or hash value of the DCI whose License is requested.
· dsig:Signature: an optional digital Signature of the msap:RequestLicense message.
The msap:RequestLicenseResult message is sent in response to a msap:RequestLicense message.
<element name="RequestLicenseResult" type="msap:RequestLicenseResultType"/>
<complexType name="RequestLicenseResultType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence>
<element ref="r-msaf:license"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 155: The msap:RequestLicenseResult element
The msap:RequestLicenseResult element is employed by the License Provider to Deliver a License, which if present shall be contained in the r-msaf:license element. This message may also be signed by the License Provider and the Signature of the message may be conveyed.in the dsig:Signature element.
The following messages are designed for the communication between the Content Creation Device (CCD) and the Tool Provider Device (TPD). The messages defined in this section belong to the DMP Media Streaming Access Protocol Extensions (dmp-msapx) namespace.
The dmp-msapx:RequestDRMToolsInfoList is sent by a CCD to a TPD for requesting the list of all DRM Tool bodies available.
<element name="RequestDRMToolInfoList" type="dmp-msapx:RequestDRMToolInfoList"/>
<complexType name="RequestDRMToolInfoList">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element ref="ipmpinfo-msx:DeviceInformation" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 156: The dmp-msapx:RequestDRMToolInfoList element
The msap: RequestDRMToolsInfoList element is employed by the CCD to request to a TPD the list of available DRMTools. The message may contain the information about the CCD hardware and software characteristics in the DeviceInformation element.
The msap: RequestDRMToolsInfoListResponse element is employed by TPD to convey the list of all the DRMTool Identifiers (including further information) to the CCD.
<element name="RequestDRMToolInfoListResponse" type="dmp-msapx:RequestDRMToolInfoListResponseType"/>
<complexType name="RequestDRMToolInfoListResponseType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element ref="dmp-msapx:DRMToolInfo" minOccurs="0" maxOccurs="unbounded"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="DRMToolInfo" type="dmp-msapx:DRMToolInfoType"/>
<complexType name="DRMToolInfoType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID" />
<element ref="ipmpmsg:ParametricDescription" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 157: The msap:RequestDRMToolInfoListResponse element
For every DRM Tool available, the dmp-msapx:RequestDRMToolInfoListResponse element conveys the Tool Identifier and a parametric description of the DRM Tool allowing the CCD to choose the most appropriate DRM Tool(s) from the list.
This section specifies the format of the messages employed by a Device when obtaining a Device Identifier from a Device Identification Device. The exchange protocol of these messages between the two devices is specified in Section 3.3.1.1 – Protocols to Identify Device.
The base type for all Device Identifier Protocol messages is defined in the figure below.
<complexType name="DeviceIdentifierProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
Figure 158: The dmprdip:DeviceIdentifierProtocolType complex type
The dmprdip:Ack message, defined in the figure below, is used to acknowledge the success of an operation or to convey an error message in case of failure.
<element name="Ack" type="dmprdip:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="dmprdip:DeviceIdentifierProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
Figure 159: The dmprdip:Ack element
For the semantics of the dmprdip:Ack message, refer to Figure 122: The msbp:Ack element
The dmprdip:DeviceIDRequest message, sent from any Device to a Device Identification Device for the purpose of obtaining an Identifier, is specified in the Figure below:
<element name="DeviceIDRequest" type="dmprdip:DeviceIDRequestType"/>
<complexType name="DeviceIDRequestType">
<complexContent>
<extension base="dmprdip:DeviceIdentifierProtocolType">
<sequence>
<element name="VendorID" type="dmprdip:IDType"/>
<element name="ModelID" type="anyURI"/>
<element name="SerialNumber" type="anyURI" minOccurs="0"/>
<element name="DeviceKey" type="dsig:KeyInfoType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="IDType">
<complexContent>
<extension base="dmprdip:DeviceIdentifierProtocolType">
<sequence>
<choice>
<element name="id" type="anyURI"/>
<element ref="dsig:X509Data"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 160: The ipmpinfo-msxp:DeviceIDRequest
The dmpmdi:RequestDeviceID element extends the ipmpinfo-msxp:IdentifierProtocolType, by conveying the following data:
· VendorID: An Identifier or Certificate of the Device vendor.
· ModelID: The Identifier for the Device model. This value is generated and managed by the Device vendor.
· SerialNumber: A value of type xsd:anyURI, generated by the Device vendor and registered by the Device Identification Device.
· DeviceKey: The Device Public Key for which the DID will possibly provide an X.509 Certificate
· An optional digital Signature of the message by the Device
If the requesting Device is eligible for a Device Identifier, the Device Identification Device sends to the requesting device a dmprdip:DeviceIDResponse message as specified in the Figure below:
<element name="DeviceIDResponse" type="dmprdip:DeviceIDResponseType"/>
<complexType name="DeviceIDResponseType">
<complexContent>
<extension base="dmprdip:DeviceIdentifierProtocolType">
<sequence>
<element name="DeviceID" type="dsig:KeyInfoType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 161: The dmprdip:DeviceIDResponse element
The dmprdip:DeviceIDResponse element extends the ipmpinfo-msxp:IdentifierProtocolType, by conveying the following data:
· DeviceID, the certificate for the requesting Device, Issued by the DID
· Signature: the Digital Signature of the whole message
This section specifies the payload of the messages employed by a Device (e.g. a Content Creation Device) to obtain a Content Identifier for a new Content Item from a Content Identification Device (CID, which is likely run by a Content Identification Agency). The exchange protocol of these messages between the two devices is specified in Section 0 – Protocol to Identify Content.
The base type for all Content Identifier Protocol messages is defined in the figure below.
<complexType name="ContentIdentifierProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
Figure 162: The dmprcip:ContentIdentifierProtocolType complex type
The dmprcip:Ack message, defined in the figure below, is used to acknowledge the success of an operation or to convey an error message in case of failure.
<element name="Ack" type="dmprcip:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
Figure 163: The dmprcip:Ack element
For the semantics of the dmprcip:Ack message, refer to Figure 122: The msbp:Ack element
The dmprcip:IdentifyContentRequest message is specified in the figure below:
<element name="IdentifyContentRequest" type="dmprcip:IdentifyContentRequestType"/>
<complexType name="IdentifyContentRequestType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element name="DCI" type="didl-msaf:DIDLType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 164: The dmprcip:IdentifyContentRequest element
This message shall include the DCI Representing the new Content Item without any Content ID specified in the dii:Identifier, as this will be generated and inserted by the CID. This message can be digitally Signed, and the value of the Signature can be inserted in the dsig:Signature element.
The CID will return an IdentifyContentResponse message in response to the CCD.
The dmprcip:IdentifyContentResponse message is specified in the figure below:
<element name="IdentifyContentResponse" type="dmprcip:IdentifyContentResponseType"/>
<complexType name="IdentifyContentResponseType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element name="DCI" type="didl-msaf:DIDLType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 165: The dmprcip:IdentifyContentResponse element
The didl-msxip:IdentifyContentResponse message contains the DCI which now includes the Content ID. The DCI conveyed in the response message may have been digitally Signed or Hashed by the Content Identification Device. Moreover, an optional Digital Signature can be applied to the whole didl-msxip:IdentifyContentResponse message.
An alternative means by which a Content Creation Devices may request a new Content Identifier to a Content Identification Device is provided by the dmprcip:RequestContentIdentifier message.
<element name="RequestContentIdentifier" type="dmprcip:RequestContentIdentifierType"/>
<complexType name="RequestContentIdentifierType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType"/>
</complexContent>
</complexType>
Figure 166: The dmprcip:RequestContentIdentifier element
A Content Creation Device may request an Identifier for a new Content Element (e.g. a Resource) to a Content Identification Device by employing the dmprcip:RequestContentElementIdentifier message.
<element name="RequestContentElementIdentifier" type="dmprcip:RequestContentElementIdentifierType"/>
<complexType name="RequestContentElementIdentifierType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element name="ContentElementSignature" type="dsig:SignatureType"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 167: The dmprcip:RequestContentElementIdentifier element
The RequestContentElementIdentifier shall convey the digital Signature or Hash value of the Content Element for which an Identifier is Requested to the Content Identification Device.
An dmprcip:RequestIdentifierResponse message is sent to a CCD in response to an dmprcip:RequestContentIdentifier or dmprcip:RequestContentElementIdentifier message.
<element name="RequestIdentifierResponse" type="dmprcip:RequestIdentifierResponseType"/>
<complexType name="RequestIdentifierResponseType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element ref="dii-msaf:Identifier"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 168: The dmprcip:RequestIdentifierResponse element
The message conveys the requested Content or Content Element identifier.
The dmprcip:RegisterIdentifier message is sent in response to an dmprcip:RequestIdentifierResponse to convey the digital Signature or Hash value of the Identified DCI to the Content Identification Device together with the Content Identifier received in the RequestIdentifierResponse message previously received.
<element name="RegisterIdentifier" type="dmprcip:RegisterIdentifierType"/>
<complexType name="RegisterIdentifierType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element ref="dii-msaf:Identifier"/>
<element name="DCISignature" type="dsig:SignatureType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 169: The dmprcip:RegisterIdentifier element
Any Device can authenticate a Content Item at any time. For this purpose, the following message is defined:
<element name="AuthenticateContentRequest" type="dmprcip:AuthenticateContentRequestType"/>
<complexType name="AuthenticateContentRequestType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<choice>
<element name="DCIInfo" type="dmprcip:InfoType"/>
<element name="DCI" type="didl-msaf:DIDLType"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="InfoType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ID" type="anyURI"/>
<element name="Signature" type="dsig:SignatureType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 170: The dmprcip:AuthenticateContentRequest element
The dmprcip:AuthenticateContentRequest message conveys a choice between DCI information (the Content ID and an optional DCI Signature) and the whole DCI (conveyed in the didl-msaf:DIDL element). The dmprcip:AuthenticateContentRequest message can be digitally Signed, and the Signature can be conveyed in the dsig:Signature element.
Any Device can authenticate a Content Element (e.g. a Resource) at any time. For this purpose, the following message is defined:
<element name="AuthenticateContentElementRequest" type="dmprcip:AuthenticateContentElementRequestType"/>
<complexType name="AuthenticateContentElementRequestType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element name="ContentElementInfo" type="dmprcip:InfoType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 171: The dmprcip:AuthenticateContentElementRequest element
The dmprcip:AuthenticateContentElementRequest message conveys the Content Element ID and the Content Element Signature.) and the whole DCI (conveyed in the didl-msaf:DIDL element). The dmprcip:AuthenticateContentElementRequest message can be digitally Signed, and the Signature can be conveyed in the dsig:Signature element.
Upon receiving either an Authenticate Content or Content Element Request message, a CID may reply by means of the following message
<element name="AuthenticateResponse" type="dmprcip:AuthenticateResponseType"/>
<complexType name="AuthenticateResponseType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<choice>
<element name="Signature" type="dsig:SignatureType"/>
<element name="AuthenticationResult" type="boolean"/>
<element name="ErrorCode" type="dmprcip:ErrorCodeType"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="ErrorCodeType">
<restriction base="string">
<enumeration value="HASH_MISSING"/>
<enumeration value="HASH_CORRUPTED"/>
</restriction>
</simpleType>
Figure 172: The ipmpinfo-msxp:AuthenticateContentResponse element
The ipmpinfo-msxp:AuthenticateContentResponse message conveys a choice between
· the Signature of either the Content Item or the Content Element (depending on the request made) in the case the task of verifying the Signature or the Hash is made by the requesting Device
· the result of the Authentication (in the AuthorisationResult element) in the case the Authentication was made on the CID. In the case of failure for impossibility of verifying either the Signature or the Hash, an error code is returned.
More information on the use of such messages to Identify and Authenticate Content are given in Sections 3.3.1 and 3.3.2
The Represent Store Content Protocol is performed between a Content Creation Device and a Content Provider Device with the purpose of transferring a Content Item from the former to the latter.
The base type for all Store Content Protocol messages is defined in the figure below.
<complexType name="StoreContentProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
Figure 173: The dmprscp:StoreContentProtocolType complex type
The dmprscp:Ack message, defined in the figure below, is used to acknowledge the success of an operation or to convey an error message in case of failure.
<element name="Ack" type="dmprscp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
Figure 174: The dmprscp:Ack element
For the semantics of the dmprscp:Ack message, refer to Figure 122: The msbp:Ack element
The dmprscp:TransferProtocolRequest message, defined in the figure below, is sent by a CCD to a CPD for requesting the permission to Store a new Content Item in the CPD database/file system.
<element name="TransferProtocolRequest" type="dmprscp:TransferProtocolRequestType"/>
<complexType name="TransferProtocolRequestType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence maxOccurs="unbounded">
<element name="TransferPrtocol" type="dmprscp:TransferProtocolType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="TransferProtocolType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element name="StandardProtocol" type="dmprscp:StandardProtocolType"/>
<element name="CustomProtocol" type="dmprscp:CustomProtocolType"/>
</choice>
</sequence>
<attribute name="priority" type="int" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="StandardProtocolType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="Option" type="dmprscp:ProtocolOptionType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute type="dmprscp:ProtocolCodeType" name="ProtocolCode" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="CustomProtocolType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="Option" type="dmprscp:ProtocolOptionType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute type="string" name="ProtocolCode" use="required"/>
</extension>
</complexContent>
</complexType>
<simpleType name="ProtocolCodeType">
<restriction base="string">
<enumeration value="TCP"/>
<enumeration value="FTP"/>
<enumeration value="SFTP"/>
<enumeration value="HTTPS"/>
<enumeration value="HTTP"/>
<enumeration value="SOAP"/>
<enumeration value="SMB"/>
</restriction>
</simpleType>
<complexType name="ProtocolOptionType">
<simpleContent>
<extension base="string">
<attribute name="Key" type="string"/>
</extension>
</simpleContent>
</complexType>
Figure 175: The dmprscp:TransferProtocolRequest element
The request includes the list of transfer protocols supported by the CCD, each of them characterised by a priority attribute, an integer whose value is inversely proportional to the intended priority (priority='1' means top priority). By employing the dmprscp:StandardProtocol, it is possible to specify a specific protocol among a pre-defined list of protocols provided by the ProtocolCodeType complex type. Alternatively, by employing the dmprscp:CustomProtocol, it is possible to specify protocols not present in the ProtocolCodeType list. In both cases, it is possible to specify a number of options (e.g. version, etc.) related to each protocol by means of the ProtocolOptionType complex type.
The dmprscp:TransferProtocolResponse message, defined in the figure below, is sent by a CPD to a CCD in response to a dmprscp:TransferProtocolRequest message.
<element name="TransferProtocolResponse" type="dmprscp:TransferProtocolResponseType"/>
<complexType name="TransferProtocolResponseType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<choice>
<element name="ProtocolResult" type="msbp:ProtocolResultType"/>
<element name="ProtocolOptions" type="dmprscp:TransferProtocolType" minOccurs="0"/>
</choice>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
Figure 176: The dmprscp:TransferProtocolResponse element
The response contains a confirmation or a denial of the requested service. In the former case, the Result attribute is set to true, and by means of the ProtocolOptionType complex type, further protocol options may be specified. In the latter case, the Result attribute is set to false and the ProtocolResult element conveys the reason of failure.
The dmprscp:ContentUploadRequest message, defined in the figure below, is sent by a CCD to a CPD after receiving a positive dmprscp:TransferProtocolResponse message by the CPD.
<element name="ContentUploadRequest" type="dmprscp:ContentUploadRequestType"/>
<complexType name="ContentUploadRequestType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<element name="ContentInfo" type="dmprscp:ContentInfoType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ContentInfoType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element name="DCF" type="dmprscp:DCFType"/>
<element name="DCS" type="dmprscp:DCSType"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DCFType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ContentID" type="anyURI"/>
<element name="Size" type="long"/>
<element name="ContentSignature" type="dsig:SignatureType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DCSType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element ref="didl-msaf:DIDL"/>
<element name="ContentID" type="anyURI"/>
</choice>
<element name="Resource" type="dmprscp:ResourceType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ResourceType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ResourceID" type="anyURI"/>
<element name="Size" type="long"/>
<element name="ResourceSignature" type="dsig:SignatureType"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 177: The dmprscp:ContentUploadRequest element
The dmprscp:ContentUploadRequest message is employed to transmit to the CPD the information about the Content to Store. The Content Item to Store may be of two types:
· DCF: in this case the CCD conveys the following information:
o The Content ID
o The size of the DCF file
o The digital Signature or hash value of the DCF
· DCS: in this case the CCD conveys the following information:
o A choice between
§ The DCI – The first time this message is sent, the DCI shall be sent. If it is intended not to Store all the Resources in a Content Item at the same time, for the subsequent times the DCI may be omitted and replaced with the Content ID
§ The Content ID – When a dmprscp:ContentUploadRequest message for a Content Item has already been sent once, and only additional Resources part of a Content Item shall be Stored
o The list of all Resources intended to be Stored. For each Resource the following information is provided:
§ Resource ID
§ Resource Size
§ The digital Resource or Hash value of the Resource.
The dmprscp:ContentUploadResponse message, defined in the figure below, is sent by a CPD to a CCD in response to an dmprscp:ContentUpload Request message.
<element name="ContentUploadResponse" type="dmprscp:ContentUploadResponseType"/>
<complexType name="ContentUploadResponseType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<choice>
<element name="StoragePath" type="dmprscp:StoragePathType" maxOccurs="unbounded"/>
<element name="StoreFailure" type="dmprscp:StoreFailureType"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="StoragePathType">
<simpleContent>
<extension base="anyURI">
<attribute name="EntityID" type="anyURI"/>
</extension>
</simpleContent>
</complexType>
<complexType name="StoreFailureType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ResultCode" type="msbp:ProtocolResultType"/>
</sequence>
<attribute name="EntityID" type="anyURI"/>
</extension>
</complexContent>
</complexType>
Figure 178: The dmprscp:ContentUploadResponse element
The dmprscp:ContentUploadResponse message is employed to transmit to the CCD the information needed to Store the Content Item and/or its Resources. If the dmprscp:ContentUploadRequest message was successful, this message will convey in element dmprscp:StoragePath the information required to perform the Content upload: the URL to connect for performing the file transfer and either the Content ID or the Content Element (i.e. Resource) ID conveyed in the EntityID attribute, indicating the corresponding Content/Resource identifier. The dmprscp:StoragePath occurs only once in the case a DCF is Stored, and repeated n times in case of a DCS with n Resources.
The dmprscp:UploadStatusRequest defined in the figure below, allows a CCD to query for the status of a Content Item or Content Element in the process of being uploaded.
<element name="UploadStatusRequest" type="dmprscp:UploadStatusRequestType"/>
<complexType name="UploadStatusRequestType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<element ref="dii-msaf:Identifier"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 179: The dmprscp:UploadStatusRequest element
In the request message it is possible to specify the specific Content Item or Content Element Identifier whose upload status is the target of the request.
The dmprscp:UploadStatusResponse messags, defined in the figure below, conveys the response from a CPD to the CCD related to a dmprscp:UploadStatusRequest about the status of a Content Item or Content Element in phase of uploading.
<element name="UploadStatusResponse" type="dmprscp:UploadStatusResponseType"/>
<complexType name="UploadStatusResponseType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<element ref="msbp:ProtocolResult"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 180: The dmprscp:UploadStatusResponse element
The response message contains some information on the status of the Content or Content Element upload in the msbp:ProtocolResult element.
This Protocol is intended for communication between CCD and LPD to indicate to the LPD how to deal with Licence requests from SAVs. This protocol communicates type of Licences that can be issued or are not allowed to be issued when msap:RequestLicense [Request License] messages are received by an LPD.
The base type for all Store License Protocol messages is defined in the figure below.
<complexType name="StoreLicenseProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
Figure 181: The dmprslp:StoreLicenseProtocolType complex type
The dmprslp:Ack message, defined in the figure below, is used to acknowledge the success of an operation or to convey an error message in case of failure.
<element name="Ack" type="dmprslp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="dmprslp:StoreLicenseProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
Figure 182: The dmprslp:Ack element
For the semantics of the dmprslp:Ack message, refer to Figure 122: The msbp:Ack element
The dmprslp:StoreLicenserequest message, defined in the figure below, is used to send License information to the LPD.
<element name="StoreLicenseRequest" type="dmprslp:StoreLicenseRequestType"/>
<complexType name="StoreLicenseRequestType">
<complexContent>
<extension base="dmprslp:StoreLicenseProtocolType">
<sequence>
<element name="ContentItem" type="dmprslp:ItemType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 183: The dmprslp:StoreLicenseRequest element
A dmprslp:StoreLicenseRequest message conveys the information related to the rights governing a Content Item, conveyed by the ContentItem element of type dmprslp:Item specified in the figure below. Further on, a dmprslp:StoreLicense message may be digitally Signed.
<complexType name="ItemType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ID" type="anyURI"/>
<element name="LicenseTemplate" type="r-msaf:License" minOccurs="0"/>
<element ref="dmprslp:LicensingDirectives" minOccurs="0"/>
<element name="ContentElement" type="dmprslp:ItemType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 184: The dmprslp:ItemType complex type
An dmprslp:ItemType complexType conveys the following information:
· ID: Either the Content ID or a Content Element ID, depending on the position of the element of type dmprslp:ItemType in the dmprslp:StoreLicenseRequest message: top level implies Content ID, nested into another element implies ContentElement (e.g. Resource) ID
· LicenseTemplate: an r-msaf:license containing information needed by the LPD to Issue Licenses when requests are received (e.g. the decryption Key needed to Access a Protected Content Item).
· LicensingDirectives: Rules the LPD needs to follow when Issuing Licenses, as specified in the figure below.
· ContentElement: An ItemType can recursively contain other elements of type ItemType, in the same way as a Content Item may contain Content Elements. This allows to replicate in the dmprslp:StoreLicenseRequest the same structure as the Content Item for which License Information is being Stored on the CPD.
<element name="LicensingDirectives" type="dmprslp:LicensingDirectivesType"/>
<complexType name="LicensingDirectivesType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="DenyDirective" type="r-msaf:License" minOccurs="0" maxOccurs="unbounded"/>
<element name="ExclusiveGrantDirective" type="r-msaf:License" minOccurs="0" maxOccurs="unbounded"/>
<element name="MandatoryGrantDirective" type="r-msaf:License" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
Figure 185: The dmprslp:LicensingDirectives complex type
Licensing directives are expressed in the form of r-msaf:license elements. There are 3 types of licencing directives:
1. DenyDirective: LPD SHALL NOT issue license that satisfies conditions included in this directive.
2. ExclusiveGrantDirective: LPD SHALL issue license that satisfies all the conditions included in this directive. LPD SHALL NOT issue license that conflicts with any condition in this directive.
3. MandatoryGrantDirective: LPD SHALL issue license that satisfies all the conditions included in this directive.
The following rules apply:
· Multiple directives of the same type can be used in a single LicencingDirectives element.
· Directives are processed according to the following priority: DenyDirective > ExclusiveDirective > MandatoryDiretive.
The figure below shows an example of License which could be included in one of the three directives above:
<license>
<grant>
<dmp1_rel_mx:play/>
<ns3:allConditions>
<ns4:territory>
<ns4:location>
<ns4:country xmlns:iso="urn:mpeg:mpeg21:2003:01-REL-SX-NS:country">iso:IT</ns4:country>
</ns4:location>
</ns4:territory>
</ns3:allConditions>
</grant>
</license>
Figure 186: An example of License for Licensing Directives
If the License in the figure above appears as a:
1. DenyDirective: when a User from Italy requests a License Granting the Right to play the Content, LPD must deny. If a US User requests a License to play or an Italian user requests a License to e.g. Adapt, LPD may Issue a License containing such Grant if no other Licensing Directives have been specified.
2. ExclusiveGrantDirective: when a User from Italy requests a License Granting the Right to play the Content, LPD shall Issue the requested License. If an US user requests to play or an Italian User requests a License to e.g. Adapt, LPD shall deny the request.
3. MandatoryGrantDirective: the conditions in a MandatoryGrantDirective shall always appear in any License requested.
This Tool enables the transformation of XML documents representing any of the Entities in this chapter to a binary format for transmission, processing or storage.
DMP selects the XML binarisation technology called BiM standardised by MPEG-7 part 1 [15] and MPEG-B part 1 [33].
The MPEG-21 Event Reproting (ER) technology allows a Content creator to specify, detect and act upon “reportable events”. These may relate either to the usage of a DCI by a device, e.g. Play, or to the occurrence of events related to the device itself, such as when a device connects to another device.
A Content creator wishing to have one or more users receive information about reportable events adds to the DCI an Event Report Request (ER-R) to specify:
· Conditions that must be fulfilled in order for the reportable event to “occur”
· Information to be reported within an ER when the reportable event occurs
· Intended recipient(s) of the ER
· Parameters related to delivery of the ER (e.g. transport mechanism and protocol, delivery timing constraints, priority, etc.).
The mechanics of the ER technology is the following
· A device receiving a DCI will parse the DCI and the ER-R
· The device waits for Events to occur
· An Event Watchdog checks to see if the Events need to be reported on, according to the ER-R’s received by the DCI
· When all event conditions associated with an ER-R have been fulfilled, the device constructs an ER
· The device dispatches the resulting ER towards the recipient devices specified by the ER-R
The Event Reporting schema, identified by the prefix “erl”, is provided in Annex C.7 – The Event Reporting schema.
This section collects the specification of the Protocols to Identify Entities. This Approved Document No. 3 currently specifies Protocols to Identify Devices. The payload of the messages exchanged between any Device and a Device Identification Device are specified in section 3.2.21 – Represent Device Identifier Protocol.
The Protocol comprises the protocol to generate a Device Identifier, and the Protocol to request a Device Identifier, for the two kinds of Device Identification supported:
1. “Device info-based identification” in which a Device Identification Device generates the Device Identifier using some vendor specific information such as vendor ID, model ID or product serial number;
2. “Certificate-based identification” in which a X.509 certificate [34] is utilised for Device Identifier. Identifiers are uniquely generated by a Device Identification Device run by a Registration Agency [5].
A Device Identification Device generates Device Identifiers. If a Device contains recognised Trusted elements (i.e. Certified Devices) these are Delivered for Storage on the Device.
The ID Generation Protocol is implemented as in Table 15.
Table 23 – ID Generation Protocol for Device Info-Based Identification
|
Initialization |
The Device confirms that the DID is ready to communicate between each other through simple ping process |
|
Request Identifier: |
Requestor of Device Identifier sends ipmpinfo-msxp:RequestDeviceID message to the Device Identification Device (see Figure 160: The ipmpinfo-msxp:DeviceIDRequest). If there is no specific product serial number on the Device, the requestor may omit the ipmpinfo-msxp:SerialNumber element in the requesting message. |
|
Assign Identifier: |
The Device Identification Device verifies the information contained in the ipmpinfo-msxp:RequestDeviceID message. If the verification is successful, the Device Identification Device replies with a ipmpinfo-msxp:DeviceID message (see Figure 161: The dmprdip:DeviceIDResponse element )containing a new ipmpinfo-msxp:DeviceIdentifier. If the ipmpinfo-msxp:RequestDeviceID message does not contain a product serial number, a newly created product serial number is generated inserted, and the requesting Device shall record this information. |
|
Exception handling |
If there is no response from either Device within certain time, an exception handler is invoked. |
Note: For the purpose of backward compatibility with IDP-1, an IDP-3.0 Device Identification Device shall be able to recognise the IDP-1 message for obtaining a Device Identifier in addition to the IDP-3.0 one. In this case the DID shall respond with an Identifier expressed in the IDP-1 format (14 bytes) according to the IDP-1 specification.
Device A may obtain a Device Identifier from a Device Identification Device (DID) by performing the following steps:
1 Device A:
1.1 generates a public/private Key pair
1.2 generates an dmp2rdip:DeviceIDRequest message [3.2.21.3] and inserts the public key in the DeviceKey element
1.3 Signs the dmp2rdip:DeviceIDRequest message by employing the Device manufacturer private Key
1.4 sends the dmp2rdip:DeviceIDRequest message to the DID
2 The DID, upon receiving the message, performs the following steps:
2.1 Verifies the digital Signature of the request message and the Device characteristics specified in it.
2.2 If the requesting Device is entitled to obtain the requested Certificate, the DID:
2.2.1 Issues an X.509 certificate for Device A's public Key
2.2.2 generates an dmp2rdip:DeviceIDResponse message [3.2.22.4] containing the generated certificate in the DeviceID field
2.2.3 Sends the dmp2rdip:DeviceIDResponse message to Device A
2.3 If the requesting Device is not entitled to obtain the requested Certificate, or an error occurs, the DID sends an dmp2rdip:Ack message [3.2.22.2] notifying Device A the failure.
Under the Certificate-based Identification system, the Device Registration Agency has the task of issuing Device Certificates using a Device Registration Agency Certificate issued by the Device Registration Authority [5].
The following provide 2 protocols. In the first, the Content Item itself (i.e. the DCI) is sent to the CID from the CCD. In the second only the hash is communicated.
This Protocol specifies how to obtain an identifier for a Content Item from a Content Identification Device (CID). This protocol requires the CCD to send the complete DCI to the CID. This Protocol is as follows:
1 CCD and CID mutually Authenticate
2 The CCD sends to the CID an didl-msxip:IdentifyContentRequest [3.2.22.3];
3 The CID
3.1 Assigns a new Content Identifier to the received DCI
3.2 Adds the Identifier to received DCI
3.3 Digitally Signs or otherwise Hashes the received DCI
3.4 Stores the Content ID and the generated Hash value in the CID database
3.5 Returns the modified DCI to requesting party by including it in an dmprcip:IdentifyContentResponse message [3.2.22.4].
This Protocol specifies how to obtain an identifier for a Content Item from a Content Identification Device (CID). This protocol requires the CCD to send only the Hash of the Identified DCI to the CID. This Protocol is as follows:
1 CID and CCD mutually Authenticate
2 CCD request a Content Identifier from the CID by sending a dmprcip:RequestContentIdentifier [3.2.22.5]
3 If the request from the CCD can be satisfied, the CID
3.1 generates the requested Identifier
3.2 generates an dmprcip:RequestIdentifierResponse message containing the Identifier [3.2.22.7]
4 CCD
4.1 Adds the received Identifier to the DCI to be Identified
4.2 Computes the hash of the DCI with the Identifier included
4.3 Sends a dmprcip:RegisterIdentifier message to the CID (See Figure 169: The dmprcip:RegisterIdentifier element)
5 The CID
5.1 Stores the Identifier together with the Hash in the CID database for future reference.
5.2 Replies with an dmprcip:Ack message to the CCD [3.2.22.2]
This Protocol specifies how to obtain an identifier for a Content Element (e.g. a media Resource) from a Content Identification Device. This protocol requires the CCD to send the hash value of the Content Element to be Identified. This Protocol is carried out in the following steps:
1 The CCD:
1.1 generates the Hash value or the digital Signature of the Content Element to be Identified and inserts it in a dmprcip:RequestContentElementIdentifier message [3.2.22.6]
1.2 sends the message to the CID
2 The CID, if the request from the CCD can be satisfied
2.1 generates an Identifier
2.2 stores the Identifier together with the Hash value/digital Signature in the CID database
2.3 returns an dmprcip:RequestIdentifierResponse message to the CCD [3.2.22.7 ].
This section collects the specification of the Protocols to Authenticate Entities, i.e. Protocols to recognise and enable Trust between Entities. This Approved Document No. 3 currently specifies Protocols to Authenticate Devices.
The Protocols to Authenticate Device are closely related to the Protocols to Identify Device (see Section 3.3.1.1). This sub-section will provide means to Authenticate Devices for the classes of Devices: Devices having unique Certificates ("Certificate-based identification”)
Each Device has a digital Certificate issued by a Device Identification Device as it was described in the Protocols to Identify Device sub-Section [3.3.1.1]. This includes secret Data Stored in the Device, and the corresponding Certificate containing the public Data.
If two Devices are identified by certificates they can mutually authenticate and/or establish a secure channel using the two messages ipmpmsg:InitAuthentication and ipmpmsg:MutualAuthentication as defined in 3.2.14 or other means.
The sequence diagram below shows how the two messages are employed to achieve Mutual Authentication, in the case the negotiation of the Authentication algorithms was successful:

Figure 187: Sequence diagram of Authentication Messages exchange
The Protocol to Authenticate Content is employed by any User wishing to verify the authenticity of a Content Item.
In order to Authenticate a Content Item, the following steps shall be performed:
1 The requesting Device (e.g. the SAV):
1.1 Generate an dmprcip:AuthenticateContentRequest message [3.2.22.9] containing
1.1.1 either:
1.1.1.1 the Content ID of the Content Item to be Authenticated
1.1.1.2 (optionally) the DISignature element containing the hash value of the DCI
1.1.2 or
1.1.2.1 the full DCI Representing the Content Item to be Authenticated
1.2 Mutually Authenticate with CID
1.3 Sends the dmprcip:AuthenticateContentRequest to the CID
2 The CID:
2.1 Parses the received dmprcip:AuthenticateContentRequest message and if the request can be satisfied generates an dmprcip:AuthenticateContentResponse message [3.2.22.11] containing:
2.1.1 either:
2.1.1.1 the DISignature for the Content Item (if this exists in the CID database), if the dmprcip:AuthenticateContentRequest contained the ContentID field. The DISignature may contain either the digital Signature of the DCI, or its Hash value only, and the Signature/Hash calculation an verification is left to the requesting Device.
2.1.2 or:
2.1.2.1 the AuthenticationResult boolean value, if the dmprcip:AuthenticateContentRequest contained the whole DCI in the didl-msaf:DIDL field. In this case the Signature/Hash calculation and verification is done on the CID
2.1.3 or:
2.1.3.1 An error code specifying that the requested service could not be performed.
A Domain is set up by a Domain Management Device (DMD) at the request of a Domain Administrator, a User who is responsible for the Use of Content on all Devices by all Users in the Domain. The Domain is Registered to a Domain Identification Device (DID) which provides an Identifier, msd:LocalDomainID. The Domain Identifier, msd:DomainID is composed of two parts: the DomainManagerID, and the LocalDomainID provided by the DID.
The DMD originates the Domain Information (msd:DomainManageInfo) and Stores it. For each Device or User joining the Domain the DMD will make a License containing the Domain Resource (dmp2rl:DomainResource) and will Deliver this to the Device or User joining the Domain.
A Device or a User requests a License to Use Content in a Domain from a License Provider Device (LPD). The License, possibly Bundled within the Content, or obtained at a later stage, is then Delivered to a User or a Device (SAV or PAV, the latter via PXD). To be able to Use Domain-bound Content, a Device or User must verify that the Domain Resource Stored in the Device or stored in the User matches the Domain Resource in the License of the Domain bound Content.
This “Protocols to Manage Domain” section specifies the Domain Management Protocols. The functionality of these Protocols includes:
1. Setting up a Domain described by Domain Information represented in msd:DomainManageInfo .
2. Managing Device and User membership of a Domain, i.e. joining, renewing and leaving.
3. Controlling the Use of Content within the Domain.

Figure 188 - Schematic Overview of Manage Domain
In summary, the establishment of a Domain is characterised by the following sequence of steps. Note: a more detailed protocol is given in the following sub-section.
1 The Domain Administrator requests the creation of a new Domain
2 The DMD creates a new Domain and Registers the Domain with a DID
3 A Device or a User join a Domain:
3.1 Authenticates itself with the DMD
3.2 Sends the account ID and password to the DMD. (The way account ID and password are communicated to the Device or User by the Domain Administrator is not specified by the DMP)
4 The DMD:
4.1 creates a Domain Membership License Granting the Device or User the membership to the Domain.
4.2 Delivers the Membership License to the Device or User.
The DMD maintains a list of Devices and Users for all registered Domains managed. Every time a new Device or User joins a Domain, the Device Manager adds the DeviceID (msd:DeviceID) or UserID (msd:UserID) to the corresponding Device or User list in msd:DomainManageInfo.
Content Items may be grouped in Content Groups for being managed within Domains. A Content Item belonging to a Content Group is indicated in a License. Content Groups are employed with the purpose of managing the simultaneous usage of Content Items within a Domain of Devices or Users, as specified in Section 3.3.3.5 – Protocols to detect simultaneous usage. Multiple Content Group IDs may appear within a License. Where required, it is possible to limit the number of Content Groups permitted within a Domain.
Note: In the Protocols below:
· the Representation of the messages exchanged is given in Section 3.2.18 Represent Domain Protocol
· references to the figures defining the payload of the messages are included where appropriate.
This subsection collects the following Protocols
1. Create Domain Protocol
2. Renew Domain Protocol
3. Delete Domain Protocol
Note that in order to perform the three Protocols listed above, a Domain Administrator needs to know the Domain Administrator Credentials, to be included in the msdp:AuthenticateReq.
This Protocol is initiated when a Domain Administrator requests the creation of a Domain. The Protocol for creating a Domain is specified below.
1 Domain Administrator and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2 Domain Administrator issues msdp:CreateDomain and sends it to the DMD [Figure 139]
3 DMD requests a new msd:LocalDomainID [Figure 111] to a Domain Identification Device (DoID) by sending an msdp:LocalDomainIDRequest message [Figure 127]
4 DoID sends msdp:LocalDomainIDResponse [Figure 128] to DMD
5 DMD
5.1 Generates the Domain Key, msd:DomainKey
5.2 Generates msd:DomainManageInfo
5.3 Stores msd:DomainManageInfo
5.4 Sends a msdp:CreateDomainResponse [Figure 118] message containing the msd:DomainID and msd:DomainMembershipCredentials to the Domain Administrator
6 The Domain Administrator may distribute the msdp:DomainMembershipCredentials to any User or Device he would like being part of the Domain.
A Domain Administrator will be given as many pairs of msdp:DomainMembershipCredential as the number of Domains he has requested the membership of.
Renewing a Domain can be invoked after a Domain has expired.
1. Domain Administrator and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2. Domain Administrator issues msdp:AuthenticateReq [Figure 125].
3. DMD returns msdp:Ack [Figure 104].
4. Domain Administrator issues msdp:RenewDomain [Figure 141].
5. DMD renews msd:DomainManageInfo
6. DMD returns msdp:Ack [Figure 104] acknowledging the success of the Protocol or otherwise.
The Domain Administrator requests the deletion of a Domain to DMD. The Protocol for deleting a Domain is shown below.
1. Domain Administrator and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2. Domain Administrator issues msdp:AuthenticateReq [Figure 125].
3. DMD returns msdp:Ack [Figure 104].
4. Domain Administrator issues DeleteDomain [Figure 142]
5. DMD deletes Domain
6. DMD returns msdp:Ack [Figure 104] acknowledging the success of the Protocol or otherwise.
When an LPD is requested to issues a License for Domain-bound Content, it requests that the DMD sends the Public Key(s) for the Domain.
1. DMD and LPD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2. LPD issues msdp:RequestKey [Figure 129]
3. DMD Delivers the Key to LPD using dmp2:RequestKeyResponse [Figure 130]
4. LPD replies with msdp:Ack [Figure 104].
This subsection collects the following Protocols
· Add Device Protocol
· Add User Protocol
· Renew Device Protocol
· Renew User Protocol
· Leave Device Protocol
· Leave User Protocol
Note that in order to perform any of the Protocols listed above, a User or a Device needs to know the Domain Membership Credentials, to be included in the msdp:AuthenticateReq.
A Device may request the DMD to be added to a Domain. Following this request the DMD will add the Device unless the number of Devices exceeds maximum number of Devices defined in msd:Device part of the msd:DomainManageInfo. The Protocol for adding a Device is shown below.
1. Device and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2. Device issues msdp:AuthenticateRequest message [Figure 103]
3. DMD returns msdp:Ack message[Figure 104]
4. Device issues msdp:AddDevice [Figure 131].
5. DMD adds the Device Identifier to the Device list in msd:Device [Figure 118] part of msd:DomainManageInfo.
6. DMD sends a msdp:AddDeviceResponse to the requesting Device, containing a Domain Membership License Granting the Device the membership to the Domain and posibly containing the Domain Key.
7. (Optionally) The Device replies with msdp:Ack [Figure 104].
Successful execution of the Add Device Protocol adds a new DeviceID to the Device ID list of the DMD.
The figure below shows an example of Domain Membership License:
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:dmp2rl="urn:dmp:idp2:Represent:License:2006:02" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:msd="urn:dmp:idp2:Represent:Domain:2006:02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:dmp:idp2:Represent:License:2006:02 http://www.dmpf.org/schemas/dmp2rl-2006-02.xsd">
<grant>
<keyHolder>
<info>
<dsig:KeyName>Martin_s_SAV_public_key</dsig:KeyName>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>01234567</dsig:Modulus>
<dsig:Exponent>89ABCDEF</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</info>
</keyHolder>
<possessProperty/>
<dmp2rl:DomainResource>
<msd:DomainID>
<msd:id>urn:Joji_s_domains:5555</msd:id>
<msd:DomainManagerID>
<info>
<dsig:KeyName>Joji_s_DomainManager_Certificate</dsig:KeyName>
</info>
</msd:DomainManagerID>
</msd:DomainID>
<msd:DomainKey>
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
<xenc:CipherData>
<xenc:CipherValue>ABABABAB</xenc:CipherValue>
</xenc:CipherData>
</msd:DomainKey>
</dmp2rl:DomainResource>
<r:allConditions>
<validityInterval>
<notBefore>2007-03-01T00:00:00</notBefore>
<notAfter>2007-04-30T00:00:00</notAfter>
</validityInterval>
<sx:territory>
<sx:location>
<sx:country>IT</sx:country>
</sx:location>
</sx:territory>
</r:allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>DMD_Public_Key</dsig:KeyName>
<dsig:KeyValue>
<dsig:RSAKeyValue>
<dsig:Modulus>12121212</dsig:Modulus>
<dsig:Exponent>34343434</dsig:Exponent>
</dsig:RSAKeyValue>
</dsig:KeyValue>
</info>
</keyHolder>
</issuer>
</license>
Figure 189: An example of Domain Membership License
A User may request the DMD to be added to a Domain. Following this request the DMD will add the User unless the number of Users exceeds maximum number of Users defined in msd:User part of msd:DomainManageInfo. The Protocol for adding a User is shown below.
1. User and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2. User issues msdp:AuthenticateReq [Figure 125].
3. DMD returns msdp:Ack [Figure 104].
4. User issues msdp:AddUser [Figure 132].
5. DMD adds the User Identifier to the User list in msd:User [Figure 116] part of msd:DomainManageInfo.
6. DMD sends a msdp:AddUserResponse to the requesting User, containing a Domain Membership License Granting the User the membership to the Domain and posibly containing the Domain Key. License containing the dmp2rl:DomainResource to the User
7. The User replies with msdp:Ack [Figure 104].
Successful execution of the Add Device Protocol adds a new UserID to the User ID list of the DMD.
Renewing a Device is invoked when the Domain Membership License for the Device expires. After mutual Authentication, the Device sends the msdp:RenewDevice message to the DMD with the Device ID and any Use Data in the Device.
If the DMD does not detect unLicensed simultaneous Use from the Use Data (see 3.3.3.5), the DMD sends a new License containing the new Domain Membership License for the Device with a new expiration period of the Domain. Otherwise, the DMD applies the policy.
The Protocol for Renewing a Device is shown below.
1 Device and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2 Device issues msdp:AuthenticateReq [Figure 125]
3 DMD returns msdp:Ack [Figure 104].
4 Device issues msdp:RenewDevice [ Figure 133 ]
5 If DMD does not detect unLicensed simultaneous Use from the Use Data then DMD:
5.1 issues a new Domain Membership License for the Device
5.2 sends a msdp:RenewDeviceResponse to the Device
6 Else DMD applies policy and sends a msdp:Ack [Figure 104] with attribute "Result" set to "false" to the Device
7 The Device replies with msdp:Ack [Figure 104].
Renewing a User is invoked when the Domain Membership License for a User expires. If the Domain Membership License is renewed, this will include a new Expiration period for the User.
The Protocol for Renewing a User is shown below.
1. User and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2. User issues msdp:AuthenticateReq [Figure 125].
3. DMD returns msdp:Ack [Figure 104].
4. User issues msdp:RenewUser [Figure 134]
5. DMD issues a License containing a new Domain Membership License for the User and sends it to the User, or applies policy and sends a msdp:Ack [Figure 104] with attribute "Result" set to "false" to the User.
6. The User replies with msdp:Ack [Figure 104].
To leave a Domain, a Device sends a request to the DMD. Following this request the DMD will exclude the requesting Device from the Domain.
1 Device and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2 Device issues msdp:AuthenticateReq [Figure 125].
3 DMD returns msdp:Ack [Figure 104].
4 Device issues msdp:LeaveDevice [Figure 137]
5 DMD
5.1 removes Device ID from the msd:Device part of msd:DomainManageInfo
5.2 replies with msdp:Ack [Figure 104] with attribute "Result" indicating whether the requested operation was successful or otherwise
6 Device Deletes the Domain Membership License
Successful execution of the Leave Device Protocol erases a Domain Membership License in the Device and the Device ID in the Device ID list of the DMD.
A User may request DMD to leave the Domain. Following this request DMD excludes the requesting User from the Domain.
1 User and DMD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device)
2 User issues msdp:AuthenticateReq [Figure 125].
3 DMD returns msdp:Ack [Figure 104].
4 User issues msdp:LeaveUser [Figure 138].
5 DMD
5.1 removes User ID from the msd:User part of msd:DomainManageInfo
5.2 replies with msdp:Ack [Figure 104] with attribute "Result" indicating whether the requested operation was successful or otherwise
6 User Deletes the Domain Membership for the User.
Successful execution of the Leave User Protocol erases the Domain Membership License for the User in the Device and the User ID in the User ID list of the DMD.
Flexible Content Licensing models can be implemented through the use of Content Groups, i.e. a set of Content Items with a common Identifier.
A License for a Content Item or Content Group may be Granted to any Device in a Domain with the Condition that the Content Item belongs to a Content Group. In this case such Content Item can be Used by as many Devices in the Domain as the number of Content Groups this Content Item belongs to. In order to verify that this Condition is fulfilled, the DMD and the Devices belonging to the Domain must have at least intermittent connections, so that the DMD can get the Use Data of the Devices and verify that no simultaneous Use of Content has occurred since the last time the DMD and the Devices were connected. A Trusted clock is clearly also required.
An example of License for a Content Item Identified by "urn:foo:1234" belonging the Content Group "content_group_ID_1" is given below:
<r:license>
<r:grant>
<m1x:identityHolder>
<m1x:idValue>urn:Joji_s_domains:5555</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:foo:1234"/>
</r:digitalResource>
<m2x:simultaneousAccess>
<m2x:count>1</m2x:count>
<m2x:isPartOf>
<m1x:protectedResource>
<r:digitalResource>
<r:nonSecureIndirect URI="content_group_ID_1"/>
</r:digitalResource>
</m1x:protectedResource>
</m2x:isPartOf>
</m2x:simultaneousAccess>
</r:grant>
</r:license>
Figure 190: An example of License for Content Group Content
Note: Assigning a Content Item to a Content Group implies that this Item cannot be used within the Domain at the same time as other Items of the same Content Group are being used. This mechanism shall not be confused with the m2x:simultaneousAccessCount Condition, which only limits the Use of the Content Item to a number of Devices at a time, irrespective of other Content Items. Setting m2x:simultaneousAccessCount to a specific value is equivalent to a Content Item being in its own unique group, and therefore having no other items but itself to consider when testing for simultaneous use. DMP at the moment does not specify a Protocol to enforce such Condition.
This section specifies a Protocol to detect when two Devices belonging to the same Domain Use a Content Item simultaneously.
In order to implement the Simultaneous Usage Detection mechanism, the Device must record Use Data on the Device i.e. by adding a record for each Content Use event. Each record consists of a msd:UseData element defined in Section 3.2.19 ‘Represent Use Data’, and contains the information that the Device Identified by msd:Device ID Used a Content Item belonging to msd:ContentGroupID in the time frame between “Start Time” and “End Time”.
If the Device leaves a Domain, the Device must hold the Use Data of that Domain in case it needs to rejoin the same Domain. Note that Use Data does not contain the Identifier of the Content Item being Used, but rather the ContentGroupID.
When two or more Devices belonging to the same Domain are connected, each Devices shall merge its Use Data with those of the other Devices, in order to increase the possibilities that the DMD discovers un-Licensed simultaneous Use of Content before a Device connects to renew its membership to a Domain.
Each Device adds the Use Data of the other Devices to its Use Data. If this operation causes duplicated records in the Use Data, the duplication will be deleted from the Use Data. If two records have the same information except for the value of the Notification Flag element [Figure 145], the record having NotificationFlag with a "FALSE" value will be overwritten by the record with a Notification Flag set to TRUE. Eventually all Devices will integrate the Use Data of each other.
When the Devices are connected via an unsecure network or server, the Use Data must be exchanged over a secure channel (SAC). See Section 3.3.2.1 – Protocols to Authenticate Device for the establishment of a SAC.
All the Devices in a Domain that simultaneously Used Content Elements part of a Content Item belonging to a Content Group are considered as having performed un-Licensed Simultaneous Use. This is detected by Devices or DMD through inspection of the Use Data.
If the Use Data has any overlapped records in time then the Devices indicated by the DeviceID in the overlapped record are considered to have incurred un-Licensed Simultaneous Use. However, if a Content Item is Licensed to more than one ContentGroupID, then the Use is allocated to the ContentGroupID that avoids un-Licensed Simultaneous Use. This is assessed at the time the Use Data is merged or the totality of Use Data are Delivered to the DMD.
The Figure below describes how Un-Licensed Simultaneous Use is detected. In this figure, Device A Uses Content1 during the period of time shown by the thick line. Similarly Device B is shown Using Content2 during the thick line segment of the lower line. In this case, the usage of Content1 on Device A and the usage of Content2 on Device B occur at the same time, shown by the overlapping of their respective thick line segments. Both Content1 and Content2 are given “CG1” as a ContentGroupID. As this ContentGroupID is subject to the rule that only one content item from the group shall be Used at any time this is an example of Un-Licensed Simultaneous Use

Figure 191 Un-Licensed Simultaneous Use Schematic
The figure above also shows Device C Using firstly Content3 and later Content4 during the time shown by the two thick line segments of the Device C timeline. In this case, the usage of Content1 on Device A and the usage of Content3 on Device C overlap in time. However, Content1 and Content3 are given different ContentGroupId values so this case does not violate the rule.
The usage of Content2 on Device B and the usage of Content4 on Device C also overlaps in time. As Content4 is given both “CG1” and “CG2” as ContentGroupIDs “CG2” will be chosen in order to avoid unnecessary detection of Un-Licensed Simultaneous Usage.
Whenever a Device connects to the DMD it notifies the DMD if simultaneous Use has been detected. This is done by employing the msdp:UnLicensedSimultaneousUseNotice message[Figure 143], containing all msd:UseData elements where an overlapping was detected by the Device. The DMD replies by sending a msdp:Ack [Figure 104] acknowledging the receipt of the message, and applies its own policy.
Once an un-Licensed Simultaneous Use Notice is sent to DMD the Notification Flag element of the record in the Use Data is set to “True” by the Device, so that an un-Licensed Simultaneous Use Notice will not be issued again when all the records involved in the simultaneous Use have a ‘True’ Notification Flag.
Note: the rel-msaf:validityInterval Condition in the License containing the Domain Resource for the Device or User is set by the DMD to ensure the Device or the User will renew its Domain membership with an appropriate frequency. This provides the opportunity for the DMD to receive un-Licensed Simultaneous Use Notices at the time of Domain renewal. According to policy, the Domain Manager may decide to add the Device ID to the Revocation List.
This section provides the Protocols to Access Content Elements, namely
· Content
· License
· DRM Tool
These Content Elements may be Packaged for Delivery as File or Stream for Use by a PAV Device (via PXD) or a SAV Device
For reason of economy of space most of the Protocols to Access Content Elements will be given for the PAV/PXD case as the SAV case becomes then a particular case where the PAV and the PXD are the same Device.
Protocols to Access Content Elements as File are based on a transactional Protocol called Remote Access Protocol (RAP) that is supported over an existing network protocol (TCP/IP or HTTP in the case of Internet/WWW access). In terms of security, the RAP uses two security layers:
· Application-Level: this corresponds to the messages described in the RAP in this Approved Document No. 3;
· Network-Level: this is represented by an underlying security Protocol, i.e. the SSLv3/TLSv1 Protocol.

Figure 192 – RAP Security Layers
The Remote Access Protocol is built on top of the following premises:
1. The User has acquired some Permissions to use a Content Item, e.g. via a transaction;
2. There is a License Provider responsible for producing and managing Licenses;
3. The License is given to an Identified and Authenticated Device that is capable of Parsing the Licenses and enforce the acquired Rights on the Governed Content;
4. Licenses should be protectable against eavesdropping attacks;
5. Licenses should be Signed by the License Provider;
6. Content Decryption Keys in a License should be protected;
7. Certificate-based Device Identification is used [3.3.1.1.2];
8. The License Provider Device can Authenticate a Device;
9. When the Device is a PAV, the Function of Accessing Content and License is performed by the PAV eXternal Device (PXD), otherwise it is the SAV itself.
10. Confirmation that a License was received by a PXD is possible (to avoid repudiation attacks).
If a Resource referenced by the DCI is Governed, Licenses or references to Licenses or references to License Services are stored in the DCI as specified in 3.2.1.9 – Location of Licenses.
This section specifies the Remote Content Access Protocol (RCAP) employed by a SAV to Request a Content Item or parts thereof. This protocol is based on the exchange of messages between two basic components: the SAV and the Content Provider Device (CPD).
The RCAP involves the following steps:
1 SAV and Content Provider Device mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device);
2 SAV:
2.1 generates a msap:RequestContent message [Figure 151] that contains the following elements:
2.1.1 The Content ID if the whole Content Item is requested, or the Content ID and Content Element ID if a Content Element in the Content Item is requested;
2.1.2 The Mime Type of the requested content:
2.1.2.1 application/mp21 if the DCF is requested
2.1.2.2 application/xml if the DCI is requested
2.1.2.3 the Content Element Mime Type (e.g. Resource Mime Type) in the case a Content Element is requested.
2.1.3 An optional License indicating the type of License the entity performing the request is interested in (where this is applicable)
2.1.4 The capabilities of the Device on which the Content Item or Resource will be rendered
2.2 (Optionally) digitally signs the message and inserts the Signature value in the dsig:Signature element. Note that in the PXD case, the PXD asks the PAV Device to Sign the message.
2.3 Sends the msap:RequestContent message to Content Provider Device;
3 The CPD:
3.1 Verifies that the digital Signature is valid
3.2 Verifies that the Content ID and the Content Element ID (the latter only if present) are valid and available in the Content Provider Device database/file system.
3.2.1 Determines whether the target of the request is the whole Content Item (in which case the Mime Type parameter will tell whether the target of the request is the DCI or the DCF) or a specific Resource, in which case the Resource will be streamed to the requesting Device.
3.3 (Optionally) performs the Protocol with the License Provider Device to asks the License Provider Device whether there is a License for the specific Content ID, PAV Device ID and/or Domain (e.g. because the transaction has been previously completed between a User and a License Provider). If a License is obtained, this is Bundled within the DCI
3.4 If the UsageEnvironmentDescription parameter contains a valid Usage Environment Description and the adaptation requested is possible, the requested content item or the specific resource is adapted.
4 In the case the request can be satisfied, the CPD generates and conveys to the requesting Device an msap:RequestContentResult message [Figure 130] containing:
4.1 (optionally) the Digital Item representing the requested content
4.2 (optionally) one or more URLs from where the whole content item can be retrieved, in the case no ResourceID was specified
4.3 (optionally) one or more URLs specifying the location from where the specific resource identified by the ResourceID parameter in the request can be retrieved
4.4 (optionally) the digital signature for the response message
5 In the case the request cannot be satisfied, the CPD generates and conveys to the requesting Device an msdp:Ack message [Figure 125] conveying the information related to the reason of failure. The requesting Device:
5.1 (optionally) replies with a msbp:Ack message [Figure 125]
The Remote License Access Protocol (RLAP) is used by a device to access Licenses from a License Provider Device (LPD). At the application level RLAP is based on the exchange of messages between two basic components: the requesting Device and the PLD.
The RLAP involves the following steps:
1 The requesting Device and the LPD mutually authenticate (See 3.3.2.1 – Protocols to Authenticate Device);
2 The requesting Device:
2.1 verifies that the Content Item is protected and that a License needed to access Content Item or Content Element is not available;
2.2 extracts the Content Identifier (in the case the governance applies to the whole Content Item) or a Resource Identifier (in the case there is the need to access a specific Resource only)from the DCI;
2.3 retrieves the ipmpinfo:LicenseReference URI from the ipmpinfo:RightsDescriptor element in the DCI;
3 The requesting Device and the License Provider Device specified in the ipmpinfo:LicenseReference mutually authenticate;
4 The requesting Device generates a msap:RequestLicense message [Figure 132] containing the following elements:
4.1 A choice between:
4.1.1 the Content Identifier or the couple [Content Identifier, Resource Identifier]
4.1.2 the License Identifier, in the case the identifier of a specific license that would grant the needed rights is known
4.2 (optionally) the License the requesting Device is interested in
4.3 (optionally) The hash value of the DI;
5 The requesting Device
5.1 (optionally) signs the message;
5.2 sends the msap:RequestLicense message to the License Provider Device;
6 The License Provider Device, upon receiving the message:
6.1 Verifies the signature (if present);
6.2 Verifies that either
6.2.1 a valid Content Identifier or Content ID plus Resource ID are specified in the request. In this case, the optional License element may indicate the type of License requested.
6.2.2 a valid License ID is specified in the request
6.3 Verifies that there is a License on the system, or that the requesting Device is entitled to be Issued a License
6.3.1.1 for the specific Content ID or
6.3.1.2 for a specific Resource identified by the ResourceID parameter contained within a Content Item identified by the ContentID parameter
7 In the case the request can be satisfied, the License Provider Device:
7.1 generates a msap:RequesLicenseResult message [Figure 133] containing the License. The License may include decryption Keys that are encrypted with:
7.1.1 The Device public Key in the case of Device License;
7.1.2 The Domain public Key in case of Domain License;
7.2 Delivers the msap:RequesLicenseResult message to the requesting Device:
8 In the case the request cannot be satisfied, the License Provider Device generates and sends to the requesting Device an msdp:Ack message [Figure 125] conveying the information related to the reason of failure.
9 The requesting Device:
9.1 receives the message from the License Provider Device, verifies the message contents and:
9.2 (optionally) replies with a msbp:Ack message [Figure 125]
This protocol is performed by a SAV or a CCD when the DRM Tool Body is not available on the SAV (and not conveyed in the DCI) for allowing the access to Protected Resources or on the CCD for Protecting Resources. This Protocol comprises of the following steps:
1 The requesting Device and the TPD mutually Authentiate (See 3.3.2.1 – Protocols to Authenticate Device);
2 The requesting Device
2.1 Mutually Authenticates with the DRM Tool Provider Device. The URL of the DRM Tool Provider Device is contained in the ipmpinfo:Remote element in the DI
2.2 Sends a msap:RequestIPMPToolBody message [Figure 127] to the IPMP Tool Provider Device, containing:
2.2.1 The requested IPMP Tool ID
2.2.2 The Represent Device Information Structure describing the hardware and software characteristics of the Device on which the requested DRM Tool will run.
2.2.3 The digital Signature of the whole message
3 The DRM Tool Provider Device:
3.1 Receives the message;
3.2 Verifies the signature if present;
3.3 Reads Device Information
3.4 Locates the DRM Tool Body matching the requesting Device's characteristics contained within Device Information
3.5 Wraps the DRM Tool Body in an ipmpinfo-msxToolBody structure;
3.6 Delivers the msap:RequestIPMPToolBodyResponseToolBody [Figure 128] to the requesting Device.
4 The requesting Device:
4.1 Receives msap:RequestIPMPToolBodyResponse
4.2 (optionally) Sends an msdp:Ack message [Figure 125] to the IPMP Tool Provider Device to notify the successful receipt (or otherwise) of the IPMP Tool Body
4.3 Reads the ipmpinfo-msxToolPackageType information
4.4 Unpackages the ipmpinfo-msxToolBody
4.5 Stores the DRM Tool Body in the local Storage.
The Protocol to Access the DRM Tool list is performed between a Content Creation Device (CCD) and a DRM Tool Provider Device (TPD). The former initiates the Protocol for the purpose of requesting to the latter the list of DRM Tool Bodies, including related information about each DRM Tool Body which is necessary to determine the capabilities of each DRM Tool. Once the Protocol has been successfully carried out, the CCD may Access one or more DRM Tool Bodies from the TPD by employing 3.3.4.3and use them to protect Resources.
The Protocol is composed of the steps below:
1 The CCD and the TPD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device);
2 The CCD
2.1 generates an dmp-msapx:RequestDRMToolInfoList message [Figure 134] containing an optional description of the CCD hardware and software characteristics
2.2 optionally signs the message
2.3 sends the message to the TPD of its choice
3 The TPD verifies the request message, the digital Signature if available and:
3.1 if the request can be satisfied, generates an dmp-msapx:RequestDRMToolInfoListResponse [Figure 135] containing the following information:
3.1.1 an dmp-msapx:DRMToolInfo element for each DRM Tool Body available and satisfying the hardware and software requirements expressed in the request. Each DRMToolInfo element contains the DRM Tool ID of the DRM Tool and a parametric description of the capabilities of the DRM Tool
3.1.2 an optional digital Signature.
3.2 if the request cannot be satisfied, an msap:Ack message [Figure 104] is returned instead, specifying the reason of failure.
The Protocol to Store Content is employed by a Content Creation Device (CCD) to Store a Content Item on a Content Provider Device (CPD). The Protocol to Store content is composed by two Protocols: the Protocol to Store a Content Item, and the Protocol to verify the upload status of the Content Item or Content Element while it is being Stored. The Content Item to Store can be either a single DCF file, or multiple files in case of a DCS, as further explained in the sections below.
The Protocol to Store a Content Item is composed by the following steps.
1 The CCD and the CPD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device);.
2 The CCD generates an dmprscp:TransferProtocolRequest message [Figure 153] requesting to Store a new Content Item. This message contains the list of all protocols supported by the CCD (e.g. ftp, http, etc.) which can be employed by the CCD to transfer the Content Item, including a priority attribute and protocol options for each protocol. If the CCD supports more protocols than those listed in the dmprscp:StandardProtocol element, these can be expressed by employing the dmprscp:CustomProtocol element.
3 The CPD upon receiving the TransferProtocolRequest message, generates an dmprscp:TransferProtocolResponse message [Figure 154] indicating, by means of the Result attribute, if the Content can be Stored or not. If yes, the ProtocolOptions element will indicate the Protocol selected by the CPD based on the best match between the CCD preferences and the CPD capabilities, including any configuration options that might be necessary for the Protocol to be carried out. If not, the ProtocolResult element will convey the reason of failure.
4 In case of an affirmative response from the CPD, the CCD generates an dmprscp:ContentUploadRequest message [Figure 155] specifying the information about the Content Item to Store.
4.1 In the case of a DCF, the following information is specified:
4.1.1 The Content ID
4.1.2 The size of the DCF file
4.1.3 The Hash value or digital Signature of the whole DCF file
4.2 In the case of a DCS, the following information is specified:
4.2.1 The choice between
4.2.1.1 The DCI – The first time a ContentUploadRequest is sent for Storing a DCS, the DCI shall always be specified. It is conceivable, though, that not all the Resources that make up a Content Item shall be Stored at the same time. Thus if this approach is taken, starting from the second time the ContentUploadRequest is sent for the same Content Item, the ContentID shall be sent instead of the DCI.
4.2.1.2 The Content ID
4.2.2 The BBL document specifying how a ContentItem shall be Streamed by employing the Digital Item Streaming technology
4.2.3 A number of dmprscp:Resource elements, which shall be smaller or equal to the number of Resources listed in the DCI. For each Resource the following information shall be specified:
4.2.3.1 The Resource ID
4.2.3.2 The size of the Resource file
4.2.3.3 The digital Signature or hash value of the Resource file
5 The CPD, upon receiving the dmprscp:ContentUploadRequest message, generates an dmprscp:ContentUploadResponse message [Figure 156] containing the following information:
5.1 The Result attribute, indicating whether the CCD can start uploading Content or not.
5.2 In the affirmative case, the StorePath element may indicate one or more remote locations where the file(s) can be uploaded. In the case of multiple locations, the StorePath element specifies the Content ID or Resource ID of the file which should be uploaded at the specified location.
5.3 In the negative case, the StoreFailure element(s) may indicate the reason of failure for the DCF or for each individual Resource.
6 The CCD:
6.1 Receives the dmprscp:ContentUploadResponse message from the CPD
6.2 verifies that it contains an affirmative response, and in this case retrieves from the message the remote location where the file(s) shall be Stored
6.3 proceed with transferring the file(s).
The Protocol to verify the upload status is employed by a CCD to verify the status of the upload of a Content Item or Content Element. This Protocol is composed by the following steps:
1 The CCD and the LPD mutually authenticate (See 3.3.2.1 – Protocols to Authenticate Device);
2 The CCD generates an dmprscp:UploadStatusRequest message [Figure 157] containing the Identifier of the Content or Content Element whose upload status is sought.
3 The CPD, upon receiving the request, replies with an dmprscp:UploadStatusResponse message [Figure 158] containing information related to the status of the upload of the Content Item or Content Element specified in the request.
The Protocol to Store License is performed between a Content Creation Device (CCD) and a License Provider Device (LPD). The scope of this Protocol is to Store on the LPD a set of information that will enable the latter to Issue Licenses to Devices requesting them. The information transmitted to the LPD includes special directives that state which Principals are or are not entitled to be Issued a License, which Rights shall or shall not be Granted, and at which Conditions.
The Protocol to Store License involves following steps:
1 The CCD and the LPD mutually Authenticate (See 3.3.2.1 – Protocols to Authenticate Device);
2 The CCD generates an dmprslp:StoreLicenseRequest message [Figure 161] containing:
2.1 the dmprslp:ContentItem element of type dmprslp:ItemType and conveying the Rights information for the whole Content Item
2.2 a number of dmprslp:ContentElement elements of type dmprslp:ItemType and conveying the Rights information for every Governed Content Element.
2.3 the digital Signature for the whole message.
3 The License Provider Device, upon receiving the request message, if the request can be satisfied,
3.1 verifies the digital Signature;
3.2 Stores the Rights information related to the Content Item and the Content Elements into a persistent location, so that every time a SAV will perform the Protocol to Access License specifying either the Content ID or the Content ID together with the ResourceID, the LPD will have the information required at its disposal.
4 LPD sends an msap-msaf:Ack message back to CCD, indicating the result of the Store License.
The following sequence diagram shows the message flow between the DRM Manager and the DRM Processor required to play protected Content Elements. Note that the diagram doesn't show the message communication between the DRM Processor and the Tool Agent, as this is the subject of the next section.

Figure 193: Message flow between the DRM Manager and the DRM Processor
The message flow in the figure above is described in the walkthrough below:
1 User U by employing the SAV decides to play a Protected Resource part of a Content Item
2 The DRM Manager parses the DCF and/or the DCI and extracts the DRM Information, Licenses etc. If the User or the Device has the Right to play the Protected Content Item, the DRM Manager
2.1 instantiates the DRM Processor
2.2 authenticates the DRM Processor
2.3 initialises the DRM Processor with the ipmpmsg:InitialiseIPMPProcessor containing:
2.3.1 the Control Point list
2.3.2 the GeneralInfoDescriptor
2.3.3 the protectedAsset
3 The DRM Processor may requests to the DRM Manager one or more Licenses using a ipmpmsg:GetRightsData
4 The DRM Manager replies with a ipmpmsg:RightsData containing the License(s) if these are available
Every time an event occurs on the DRM Processor, an ipmpmsg:NotifyDRMProcessorEvent message is sent by the DRM Processor to the DRM Manager providing information on the occurred event.
When a User terminates any action on the Content, the following apply:
1 DRM Manager sends ipmpmsg:TerminateIPMPProcessor message to the DRM Processor.
2 The DRM Processor
2.1 terminates all DRM Tools and
2.2 replies with an ipmpmsg:NotifyDRMProcessorEvent.
This Section describes the Protocols between DRM Processor and DRM Tools or between DRM Tools involved in the Governance of Content, as described in Section 3.2.8
When a DRM Processor locates a Governed Content Element protected by a DRM Tool it needs to locate the appropriate DRM Tool Body implementing the DRM Tool. The DRM Processor extracts the DRM Tool ID from the DCI and then locates the DRM Tool Body corresponding to the required DRM Tool or DRM Tool Pack. At this point the DRM Processor instantiates the DRM Tool as indicated in the ipmpinfo-msx:Instantiation_API_ID, specified in 3.2.15 – Represent Device Information.
The Managing of a DRM Tool by the DRM Processor involves the delivery of DRM Messages defined in Section 3.2.13 – Represent DRM Messages. DRM Messages are exchanged between a DRM Processor and a DRM Tool according to a Messaging API which is particular to each Device. The DRM Processor chooses the DRM Tool characterised by the Messaging_API_ID supported by the Device on which it is resident. The Messaging_API_ID is specified in 3.2.15 – Represent Device Information.
DRM Messages are conveyed in either ipmpmsg:MessageFromTool or ipmpmsg:MessageFromDCI messages which extend ipmpmsg:ToolMessageBase. These are shown in Section 3.2.13 – Represent DRM Messages. The DRM Tool receiving such messages will obtain from the container Message the information about the Context ID of the Sender (the “Sender” element) and its own Context ID (the “Recipient” element).
The instantiation of a DRM Tool involves the connection of the DRM Tool instance to a specific Control Point and with a specific Sequence Code. The DMP establishes a Registration Authority for registering Control Points on Devices, Instantiation APIs and Messaging APIs [5].
Depending on the nature of the DRM Tool - a Single DRM Tool or a DRM Tool Pack - the DRM Processor will act as specified in the two sections below.
In the case the DRM Tool is a Single DRM Tool, the DRM Processor instantiates it according to the mechanisms of the platform on which it is running. According to the Represent Device Information associated with the DRM Tool Body, in particular the ipmpinfo-msx:ToolAPI_Config element, the DRM Processor knows the Instantiation_API_ID information of the DRM Tool and acts appropriately in order to get a handle of an instance of the DRM Tool.
When the DRM Tool is a DRM Tool Pack, the DRM Processor instantiates the DRM Tool Agent part of the DRM Tool Pack, according to the mechanisms of the platform on which it is running. According to the Represent Device Information associated with the DRM Tool Pack Body, in particular the ipmpinfo-msx:ToolAPI_Config element, the DRM Processor knows the Instantiation_API_ID information of the DRM Tool Agent and acts appropriately in order to get a handle of an instance of the DRM Tool Agent. The instantiation of the DRM Tool Pack at this point is not complete yet because the DRM Processor still needs to instantiate the DRM Tools in the DRM Tool Group. Before these can be instantiated, the DRM Tool Agent has to be initialised as specified below.
Once the DRM Processor possesses a handle of an instance of the DRM Tool, the DRM Processor initialises the DRM Tool instance as specified below, depending on whether the DRM Tool is a Single DRM Tool or a DRM Tool Agent.
The DRM Processor initialises a Single DRM Tool by sending it a ipmpmsg:InitialiseTool Message. This Message conveys to the DRM Tool:
· the DRM Processor Instance, a handle of the DRM Processor that is needed by the Tool to send Messages back to the DRM Processor,
· the Control Point in which the DRM Tool will operate (optional),
· the Sequence Code that the DRM Tool has with regards to other DRM Tools operating in the same Control Point (optional),
· any DRM Message addressed to that DRM Tool found in the DCI (optional).
The Initialisation of a DRM Tool Pack involves first the initialisation of the DRM Tool Agent.
The DRM Processor initialises a DRM Tool Agent by sending it a ipmpmsg:InitialiseTool Message.
This Message conveys to the DRM Tool Agent:
· the DRM Processor Instance, a handle of the DRM Processor that is needed by the Tool to send Messages back to the DRM Processor. The format of this handle may depend on the particular Device on which the DRM Processor is running and such information depends on the Instantiation_API_ID value in the ToolAPI_Config defined in 3.2.15 -Represent Device Information.
· the list of all available Control Points on the Device where the DRM Tool Agent may instantiate the DRM Tools in the Tool Group with the associate ControlPointAddress where the DRM Tool Pack operates.
· any DRM Message addressed to that DRM Tool found in the DCI (optional).
After the DRM Tool Agent is instantiated, initialised and Authenticated, the DRM Processor chooses from the available Control Points the ones on which to instantiate the DRM Tools in the DRM Tool Group.
Where the DRM Tool Agent needs the instantiation of another DRM Tool to operate, the DRM Tool Agent requests the reference of the DRM Tool Group from the DRM Processor by sending a ipmpmsg:GetToolGroupReference Message [Figure 88]. The DRM Processor replies by sending the required information contained in the ipmpmsg:GetToolGroupReferenceResponse, [Figure 89] if the DRM Processor can Access it (either locally or by employing the DRM Tool Access Protocol, Section 3.3.4.3). In the case this operation fails, the DRM Processor replies with a ipmpmsg:NotifyToolEvent, specifying an event of type “TOOL_GROUP_NOT_FOUND”.
Where the DRM Tool Agent needs the instantiation of a Single DRM Tool to operate, then the DRM Tool Agent requests the reference of the Single DRM Tool to the DRM Processor by sending a ipmpmsg:GetToolReference Message [Figure 90] specifying a list of DRM Tool IDs of the required DRM Tools. In the case where the DRM Processor can Access the requested DRM Tool, it replies with a ipmpmsg:GetToolReferenceResponse [Figure 91] conveying a list of DRM Tool IDs and the associated references of each DRM Tool.
Once the DRM Tool Agent obtains the reference of the DRM Tool Group or the reference of a Single DRM Tool, the DRM Tool Agent connects each DRM Tool in the Tool Group or the Single DRM Tool to the proper Control Point.
The initialisation information for each DRM Tool is contained in the Tool Pack Data. The DRM Tool Agent may use the Tool Pack Data to initialise the DRM Tools in the Tool Group. In this case, the DRM Tool Agent requests the Tool Pack Data from the DRM Processor by sending a ipmpmsg:GetToolPackData message [Figure 92]. The DRM Processor searches for the Tool Pack Data associated with the Tool Pack of the requesting Tool Agent and sends the ipmpmsg:ToolPackData [Figure 93] to the DRM Tool Agent by including it in a ipmpmsg:MessageFromDCI Message [Figure 83].
Finally, the DRM Tool Agent initialises each DRM Tool with Tool Pack Data.
In a secure environment, DRM Processor and DRM Tools should mutually Authenticate before any other action is performed in the Device after DRM Tool Initialisation. This also has the advantage of allowing the establishment of a secure channel for communication among parties.
Mutual Authentication can be triggered by either a DRM Tool or the DRM Processor by sending to the counterpart an ipmpmsg:InitAuthentication Message for negotiating the mutual Authentication Algorithms supported by both parties. Following, a number of ipmpmsg:MutualAuthentication messages will be exchanged between the parties involved until mutual Authentication is achieved. For more information on the use of these two messages refer to Sections 3.2.14 – Represent Authentication Messages.
When the DRM Tool involved in the Authentication process is a DRM Tool Pack, the Authentication process will be performed by the DRM Tool Agent, as the Authentication between this and the DRM Tools in the Tool Group is performed by the Tool Agent in a proprietary fashion.
Approved Document No. 2 [2] describes several scenarios where DRM Messages are employed to achieve certain goals. For more information on the use of DRM Messages for achieving these goals, refer to [12] and [14].
The DRM Processor searches the required DRM Tool Pack and instantiates the DRM Tool Agent. The DRM Tool Agent may need the DRM Tools part of the DRM Tool Group. In this case, the DRM Tool Agent sends a ipmpmsg:GetToolGroupReference message [Figure 89] to the DRM Processor to request a reference to the DRM Tool Group.
The DRM Tool Agent may also employ a Single DRM Tool for performing DRM Functions. In this case, the Tool Agent sends ipmpmsg:GetToolReference message to the DRM Processor to request the reference of the Single DRM Tool [Figure 90].
In response to a ipmpmsg:GetToolReference message, the DRM Processor sends a ipmpmsg:GetToolReferenceResponse message [Figure 91] to the DRM Tool Agent to convey the reference of the Single DRM Tool
Content must be Packaged so that it can be Delivered to Devices. IDP-3.0 provides Tools to achieve this for the following types of transport:
1. File
2. Stream
IDP-3.0 identifies these 3 forms of Content Package as DCF (DMP Content Format), DCB (DMP Content Broadcast) and DCS (DMP Content Stream).
The DMP specifies to Package Content as a Stream using the ISO/IEC CD 21000-18 Digital Item Streaming (DIS) [30] technology.
This section specifies how to Package Content into the DMP Content File (DCF).
IDP-1 provides Tools to Package Content in files whose format using a DMP-defined subset of the MPEG-21 File Format [28], which contains the DCI with some or all of its ancillary Resources, potentially in a single package. The MPEG-21 File Format is based on the ISO Base Media File Format [13], which defines how to contain timed media information for a presentation. The file structure is object-oriented; a file can be decomposed into constituent objects very simply, and the structure of the objects inferred directly from their type.
In [28], files are formed as a series of objects, called boxes. All data is contained in boxes; there is no other data within the file. Each Box is represented as in the figure below and it is characterised by two attributes: boxtype and size.
aligned(8) class Box (unsigned int(32) boxtype,
optional unsigned int(8)[16] extended_type) {
unsigned int(32) size;
unsigned int(32) type = boxtype;
if (size==1) {
unsigned int(64) largesize;
} else if (size==0) {
// box extends to end of file
}
if (boxtype==‘uuid’) {
unsigned int(8)[16] usertype = extended_type;
}
}
The size field is an integer that specifies the number of bytes in this box, while the type field identifies the box type, which is normally made of four human-readable characters represented using four bytes (4 Character Code, 4CC), to permit the identification of the box. Boxes with an unrecognized type shall be ignored and skipped. Class Box is extended in the ISO specification by Class FullBox, which conveys additional information.
aligned(8) class FullBox (unsigned int(32) boxtype, unsigned int(8) v, bit(24) f)
extends Box(boxtype) {
unsigned int(8) version = v;
bit(24) flags = f;
}
Table 16 is a subset of the table described in [28], section 3.1 and provides a view of the encapsulation of boxes. The first two columns represent the 4CC identifying the box type; this information is displayed on two columns in order to show the nesting level of the boxes.
Table 24: Logical box structure diagram
|
|
|
Mandatory
|
Description |
|
ftyp |
|
yes |
file type and compatibility |
|
free |
|
no |
free space |
|
meta |
|
yes |
Metadata |
|
|
hdlr |
yes |
handler, declares the metadata (handler) type |
|
|
bxml |
yes |
binary XML container |
|
|
xml |
no |
XML container |
|
|
iloc |
no |
item location |
|
mdat |
|
no |
media data container |
|
licc |
|
no |
License_Container Box |
|
|
licb |
no |
License Box |
|
sign |
|
no |
Digital signature of the file |
The next section will give an overview on the entries in the table above, and specify DMP-defined values for particular variables.
This section specifies syntax and semantics of the ISO Base Media File Format box elements adopted by the DMP to Package Content in the DMP File Format (DCF).
The ftyp box is mandatory and specifies to which specification this file is conformant. The brand for a DMP file is ‘dmpf’ and this value should appear in the compatible_brands as described below.
aligned(8) class FileTypeBox
extends Box(‘ftyp’) {
unsigned int(32) major_brand;
unsigned int(32) minor_version;
unsigned int(32) compatible_brands[]; // to end of the box
}
The following table describes the variables of class FileTypeBox
|
major_brand |
An identifier for the specification this file is conforming to. For a file conforming to this specification this variable is set to ‘mp21’. |
|
minor_version |
A variable representing the version of the brand. For files conforming to this specification this variable is set to ‘0x00000000’ |
|
Compatible_brands |
A list of brands to which the content of this box is compatible. ‘dmpf’ should appear among the brands in this list. |
NOTE: DCF files must have exactly one DMP File Type Box at the beginning of the file.
The Free Box is optional and may contain any kind of data and follows the syntax and semantics as defined in [12]. A Device may ignore the content of this box. If this box, if present, its content is skipped for the calculation of any digital signature or hash value.
aligned(8) class FreeSpaceBox extends Box(free_type) {
unsigned int(8) data[];
}
The Meta Box defined in [13] is shown in the figure below:
aligned(8) class MetaBox (handler_type)
extends FullBox(‘meta’, version = 0, 0) {
HandlerBox(handler_type) theHandler;
PrimaryItemBox primary_resource;
DataInformationBox file_locations;
ItemLocationBox item_locations;
ItemProtectionBox protections;
ItemInfoBox item_infos;
IPMPControlBox IPMP_control;
Box other_boxes[];
}
However this specification will only consider meaningful three of those boxes:
· the HandlerBox: For indicating the structure or format of the ‘meta’ box contents. The handler_type for this box should be ‘dmpf’
· the ItemLocationBox: as described in 3.4.1.2.7 below
· the field other_boxes: containing the ‘bxml’ and ‘xml’ boxes described below.
Two boxes may be contained in the other_boxes array: the Binary XML Box (‘bxml’) which is mandatory, and the XML Box (‘xml’) which is optional. Both will contain the DMP Content Information (DCI) as defined in Section 3.2.1 - Represent Content.
aligned(8) class BinaryXMLBox extends FullBox(‘bxml’, version = 0, 0) {
unsigned int(8) data[]; // to end of box
}
aligned(8) class XMLBox extends FullBox(‘xml ’, version = 0, 0) {
string xml;
}
The ItemLocationBox provides a link between Content Element s Represented in the DCI and the phisical location of them within this file or other files, their offset within the file and their length.
aligned(8) class ItemLocationBox extends FullBox(‘iloc’, version = 0, 0) {
unsigned int(4) offset_size;
unsigned int(4) length_size;
unsigned int(4) base_offset_size;
unsigned int(4) reserved;
unsigned int(16) item_count;
for (i=0; i<item_count; i++) {
unsigned int(16) item_ID;
unsigned int(16) data_reference_index;
unsigned int(base_offset_size*8) base_offset;
unsigned int(16) extent_count;
for (j=0; j<extent_count; j++) {
unsigned int(offset_size*8) extent_offset;
unsigned int(length_size*8) extent_length;
}
}
}
The following table describes the variables of class ItemLocationBox.
Table 25 – Variables of class ItemLocationBox
|
offset_size |
A value from the set {0, 4, 8} which indicates the length in bytes of the offset field. |
|
length_size |
A value from the set {0, 4, 8} which indicates the length in bytes of the length field. |
|
base_offset_size |
A value from the set {0, 4, 8} which indicates the length in bytes of the base_offset field. |
|
item_count |
An integer value indicating the number of resources in the following array. |
|
item_ID |
An arbitrary integer ‘name’ for this resource which can be used to refer to it (e.g. in a URL). |
|
data-reference-index |
A value which is either zero (‘this file’) or a 1-based index into the data references in the data information box. |
|
base_offset |
An integer which provides a base value for offset calculations within the referenced data. If base_offset_size is 0, base_offset takes the value 0, i.e. it is unused. |
|
extent_count |
An integer which provides the count of the number of extents into which the resource is fragmented; it must have the value 1 or greater. |
|
extent_offset |
An integer which provides the absolute offset in bytes from the beginning of the containing file, of this item. If offset_size is 0, offset takes the value 0 |
|
extent_length |
An integer which provides the absolute length in bytes of this metadata item. If length_size is 0, length takes the value 0. If the value is 0, then length of the item is the length of the entire referenced file. |
This box contains the Content Element Represented and Identified in the DCI, and is defined in [28] as follows:
aligned(8) class MediaDataBox extends Box(‘mdat’) {
bit(8) data[];
}
The License_Container Box contains an array of License Boxes each of them containing a License for any Governed Content Item described in the DCI.
The License_Container box, if present, is placed at the beginning of a DCF, and is defined as below:
aligned(8) class License_Container extends FullBox(‘licc’) {
unsigned int(16) item_count;
for (i=0; i<item_count; i++) {
string License_ID;
Box License_Box;
}
}
Table 26 – Variables of class License_Container Box
|
item_count |
An integer value indicating the number of License Boxes in the container |
|
License_ID |
A string of characters containing the License_ID |
|
License_Box |
A box containing a License |
The License box contains a License Governing a Content Item described in the DCI.
aligned(8) class LicenseBox extends FullBox(‘licc’) {
bit(8) License[];
}
Table 27 – Variables of class Licens Box
|
License |
An array of bytes |
This box contains digital Signature of the DCF. The digital Signature shall be calculated from the beginning to the end of the last container, but excluding any content in the Free box.
The Signature box, if present, is placed at the end of a DCF, and is defined as below:
aligned(8) class SignatureBox extends Box(‘sign’) {
bit(8) data[];
}
This Approved Document No 4 specifies how the informative Use Cases described in Approved Document No. 1 can normatively be implemented using the Tools specified in Approved Document No. 3.
|
Disclaimer By giving a normative value to this Approved Document DMP does not imply that Use Cases of Approved Document No. 1 can only be implemented as specified in this Approved Document. DMP simply intends to provide example normative implementation so that those Users who assemble the Tools as specified in this Approved Document will be able to interoperate with other Users who will assemble the Tools in a similar way. |
In the Use Cases below “Out of scope” and “None” in the IDP Tool column indicate that the Function is “not required” and “not yet provided” by IDP-2, respectively.
Prerequisites for proper understanding of this Approved Document are; reading of this Foreword, Approved Document No. 2 – Architecture, Approved Document No. 3 – Interoperable DRM Platform and Approved Document No. 6 – Terminology.
There are many cases where Users (companies or even individuals) own Rights to Content, have an interest in Releasing it in such a way that other Users can freely Access it but do not want to make it public domain. In other words the Content is Governed in a “light-weight” form, i.e. without using Technical Protection Measures (TPM). Examples are publicity material, movie trailers, a garage band’s song or an amateur video on a blog. Note that in the DMP, Content means more than just Resources as it is defined as “A structured combination of Content and Content Elements”, the latter being “Any of the following Data types: Resource, Metadata, Content, License, DRM Information, DRM Tool Pack and Use Data”.
In this Use Case such a type of Release is called “Open Release”.
This form of Release is clearly contiguous to other forms of commercial Release. Therefore it would be advantageous if such other more sophisticated forms could be built on top of this simple form, e.g. if it was possible to add more “heavy-weight” DRM technologies when the context so demands.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
Leonardo has been invited to give a presentation at a conference but at the last minute he is unable to attend. As a fallback he decides to send some audio-visual material and related data to the conference organisers as Open Release. His material will be given to conference participants first and to the general public in selected jurisdictions later, in the form of Governed Content for distribution.
Leonardo knows that in this form his Content will not prevent people from doing what he would not like them to do. If he or one of his robots should find Resources taken from his Content on some web sites he will have the option of taking action against the infringers.
Therefore Leonardo performs the following steps. Note that some of these steps (e.g. Resource and Content Identification) could be performed automatically by an “Open Release authoring tool”.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Leonardo |
Create |
Resource |
PowerPoint file |
Out of scope |
|
|
Leonardo |
Create |
Metadata |
Of Powerpoint file |
Out of scope |
|
|
Leonardo |
Create |
Audio and video |
|
Out of scope |
|
|
Leonardo |
Create |
Resource |
Audio-visual Resource file |
Out of scope |
|
|
Leonardo |
Create |
Metadata |
Of audio-visual Resource file |
None |
|
|
Registration Agency |
Identify |
Resources and Metadata |
PowerPoint file and audio-visual file |
None |
|
|
Leonardo |
Represent |
Identifier |
In Resources and Metadata |
Represent Content |
2.5.1 |
|
Leonardo |
Create |
Human-readable License |
4. Play 5. Time of Use: 6.until conference ends (Users who are conference participants) 7.after conference ends (all Users in the selected jurisdiction) 8. # of times: unlimited 9. Store: unrestricted 10. Print PowerPoint file: unrestricted 11. Move: unrestricted 12. Copy: unrestricted |
Out of scope |
|
|
Registration Agency |
Assign: Identifier to |
Human readable license |
Lower case "L" because this is not a License |
Out of scope |
|
|
Leonardo |
Create |
Machine-readable License |
Corresponding to the human-readable license (expressed in verbose XML) |
Represent License |
2.10 |
|
Registration Agency |
Identify |
License |
|
None |
2.5.2 |
|
Leonardo |
Create |
Content Item |
Containing · Resources · Metadata · Human-readable license for the selected jurisdiction · Licence |
Represent Content |
2.1 |
|
Registration Agency |
Identify |
Content Item |
|
None |
|
|
Leonardo |
Represent |
Content Identifier |
In the Content Item |
Represent Content |
2.5.1 |
|
Leonardo |
Binarise XML |
Content Item |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
Leonardo |
Package |
Content |
As file |
Package Content |
4.1.1 |
|
Leonardo |
Release |
Content file |
To conference organisers |
None |
|
Example DCI
The Figure below shows an example DCI for the Open Release Use Case. Such DCI contains all the information described in the walkthrough above, including the Licence (both in human- and machine-readable format), Metadata for the whole Content Item and shows the location of Metadata for the various Content Elements.
<?xml version="1.0" encoding="UTF-8"?>
<DIDL xmlns="urn:dmp:idp2:mpeg21:2002:02-DIDL-NS:2006:02" xmlns:dmp2rc="urn:dmp:idp2:Represent:Content:2006:02" xmlns:dmp2rl="urn:dmp:idp2:Represent:License:2006:02" xmlns:dmp1_dii="urn:dmp:idp1:mpeg21:2002:01-DII-NS:2005:04" xmlns:dmp2_ipmpdidl="urn:dmp:idp2:mpeg21:2004:01-IPMPDIDL-NS:2006:02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dmp2_ipmpinfo="urn:dmp:idp2:mpeg21:2004:01-IPMPINFO-NS:2006:02" xmlns:dmp2rdm="urn:dmp:idp2:Represent:DRMMessages:2006:02" xmlns:dmp2ram="urn:dmp:idp2:Represent:AuthenticationMessages:2006:02" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:bpx="urn:mpeg:mpeg21:2005:01-REL-BPX-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:mpeg7="urn:mpeg:mpeg7:smp:schema:2001" xsi:schemaLocation="urn:dmp:idp2:mpeg21:2002:02-DIDL-NS:2006:02 dmp2didl-2006-02.xsd">
<Container>
<Item>
<Descriptor>
<Statement mimeType="text/plain">
<dmp1_dii:Identifier>urn:myPresentations:presentation:444</dmp1_dii:Identifier>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2rc:DMPInformation>
<dmp2rc:Metadata>
<dmp2rc:StructuredData ref="urn:mpeg:mpeg7:smp:schema:2001">
<mpeg7:Mpeg7>
<mpeg7:Description xsi:type="mpeg7:CreationDescriptionType">
<mpeg7:CreationInformation>
<mpeg7:Creation>
<mpeg7:Title type="ContentTitle">Slide presentation with Audio and Video</mpeg7:Title>
<mpeg7:Creator>
<mpeg7:Role href="urn:mpeg:mpeg7:RoleCS:2001:AUTHOR"/>
<mpeg7:Agent xsi:type="mpeg7:PersonType">
<mpeg7:Name>
<mpeg7:GivenName>Leonardo</mpeg7:GivenName>
</mpeg7:Name>
</mpeg7:Agent>
</mpeg7:Creator>
<mpeg7:CreationCoordinates>
<mpeg7:Date>
<mpeg7:TimePoint>2006-04-18T09:00:00</mpeg7:TimePoint>
</mpeg7:Date>
</mpeg7:CreationCoordinates>
</mpeg7:Creation>
</mpeg7:CreationInformation>
</mpeg7:Description>
</mpeg7:Mpeg7>
</dmp2rc:StructuredData>
</dmp2rc:Metadata>
</dmp2rc:DMPInformation>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2_ipmpinfo:IPMPGeneralInfoDescriptor>
<dmp2_ipmpinfo:LicenseCollection>
<dmp2_ipmpinfo:RightsDescriptor>
<dmp2_ipmpinfo:License>
<dmp2rl:License>
<r:license licenseId="urn:myLicenses:6789A">
<!-- All participant to the Conference can play until the end of the Conference -->
<r:grant>
<r:forAll varName="conferenceParticipants">
<r:propertyPossessor>
<sx:propertyUri definition="urn:MyConference:participant"/>
</r:propertyPossessor>
</r:forAll>
<r:principal varRef="subscriber"/>
<mx:play/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:myPresentations:presentation:444"/>
</r:digitalResource>
<r:validityInterval>
<r:notAfter>2006-07-29T18:00:00</r:notAfter>
</r:validityInterval>
</r:grant>
<!-- Every Device in Italy can play after the end of the Conference -->
<r:grant>
<mx:play/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:myPresentations:presentation:444"/>
</r:digitalResource>
<r:allConditions>
<r:validityInterval>
<r:notBefore>2006-07-29T18:00:00</r:notBefore>
</r:validityInterval>
<sx:territory>
<sx:location>
<sx:country>ITALY</sx:country>
</sx:location>
</sx:territory>
</r:allConditions>
</r:grant>
<!-- Every Device can Print the presentation -->
<r:grant>
<mx:print/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:myPresentations:presentation:444"/>
</r:digitalResource>
</r:grant>
<!-- Every Device can Copy the presentation-->
<r:grant>
<bpx:governedCopy/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:myPresentations:presentation:444"/>
</r:digitalResource>
</r:grant>
<!-- Every Device can Move the presentation-->
<r:grant>
<bpx:governedMove/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:myPresentations:presentation:444"/>
</r:digitalResource>
</r:grant>
<r:issuer>
<r:keyHolder>
<r:info>
<dsig:KeyName>Leonardo_s Certificate</dsig:KeyName>
</r:info>
</r:keyHolder>
</r:issuer>
</r:license>
</dmp2rl:License>
</dmp2_ipmpinfo:License>
</dmp2_ipmpinfo:RightsDescriptor>
</dmp2_ipmpinfo:LicenseCollection>
</dmp2_ipmpinfo:IPMPGeneralInfoDescriptor>
</Statement>
</Descriptor>
<Item>
<Descriptor>
<Statement mimeType="text/xml">
<dmp1_dii:Identifier>urn:Leonardo:Licenses:HumanReadableLicense:12</dmp1_dii:Identifier>
</Statement>
</Descriptor>
<Component>
<Resource mimeType="text/plain">
This License allows you to:
1. Play
a. Time of Use:
i. until conference ends (Users who are conference participants)
ii. after conference ends (all Users in Italy)
b. # of times: unlimited
2. Store: unrestricted
3. Print PowerPoint file: unrestricted
4. Move: unrestricted
5. Copy: unrestricted
</Resource>
</Component>
</Item>
<Item>
<Descriptor>
<Statement mimeType="text/xml">
<dmp1_dii:Identifier>urn:Leonardo:AudioRecording:1234</dmp1_dii:Identifier>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2rc:DMPInformation>
<dmp2rc:Metadata>
<dmp2rc:StructuredData ref="urn:mpeg:mpeg7:schema:2001">
<!-- Metadata for audio track-->
</dmp2rc:StructuredData>
</dmp2rc:Metadata>
</dmp2rc:DMPInformation>
</Statement>
</Descriptor>
<Component>
<Resource mimeType="application/mp21-ipmp">
<dmp2_ipmpdidl:ProtectedAsset mimeType="audio/mpeg">
<dmp2_ipmpdidl:Info>
<dmp2_ipmpinfo:IPMPInfoDescriptor>
<dmp2_ipmpinfo:RightsDescriptor>
<dmp2_ipmpinfo:LicenseReference>urn:myLicenses:6789A</dmp2_ipmpinfo:LicenseReference>
</dmp2_ipmpinfo:RightsDescriptor>
</dmp2_ipmpinfo:IPMPInfoDescriptor>
</dmp2_ipmpdidl:Info>
<dmp2_ipmpdidl:Contents ref="AudioRecording1234.mp3"/>
</dmp2_ipmpdidl:ProtectedAsset>
</Resource>
</Component>
</Item>
<Item>
<Descriptor>
<Statement mimeType="text/xml">
<dmp1_dii:Identifier>urn:Leonardo:VideoRecording:5678</dmp1_dii:Identifier>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2rc:DMPInformation>
<dmp2rc:Metadata>
<dmp2rc:StructuredData ref="urn:mpeg:mpeg7:schema:2001">
<!-- Metadata for video track-->
</dmp2rc:StructuredData>
</dmp2rc:Metadata>
</dmp2rc:DMPInformation>
</Statement>
</Descriptor>
<Component>
<Resource mimeType="application/mp21-ipmp">
<dmp2_ipmpdidl:ProtectedAsset mimeType="video/mpeg">
<dmp2_ipmpdidl:Info>
<dmp2_ipmpinfo:IPMPInfoDescriptor>
<dmp2_ipmpinfo:RightsDescriptor>
<dmp2_ipmpinfo:LicenseReference>urn:myLicenses:6789A</dmp2_ipmpinfo:LicenseReference>
</dmp2_ipmpinfo:RightsDescriptor>
</dmp2_ipmpinfo:IPMPInfoDescriptor>
</dmp2_ipmpdidl:Info>
<dmp2_ipmpdidl:Contents ref="VideoRecording5678.mpg"/>
</dmp2_ipmpdidl:ProtectedAsset>
</Resource>
</Component>
</Item>
<Item>
<Descriptor>
<Statement mimeType="text/xml">
<dmp1_dii:Identifier>urn:Leonardo:Presentations:2222</dmp1_dii:Identifier>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2rc:DMPInformation>
<dmp2rc:Metadata>
<dmp2rc:StructuredData ref="urn:mpeg:mpeg7:schema:2001">
<!-- Metadata for the slide presentation-->
</dmp2rc:StructuredData>
</dmp2rc:Metadata>
</dmp2rc:DMPInformation>
</Statement>
</Descriptor>
<Component>
<Resource mimeType="application/mp21-ipmp">
<dmp2_ipmpdidl:ProtectedAsset mimeType="application/vnd.ms-powerpoint">
<dmp2_ipmpdidl:Info>
<dmp2_ipmpinfo:IPMPInfoDescriptor>
<dmp2_ipmpinfo:RightsDescriptor>
<dmp2_ipmpinfo:LicenseReference>urn:myLicenses:6789A</dmp2_ipmpinfo:LicenseReference>
</dmp2_ipmpinfo:RightsDescriptor>
</dmp2_ipmpinfo:IPMPInfoDescriptor>
</dmp2_ipmpdidl:Info>
<dmp2_ipmpdidl:Contents ref="conferencePresentation33.ppt"/>
</dmp2_ipmpdidl:ProtectedAsset>
</Resource>
</Component>
</Item>
</Item>
</Container>
</DIDL>
Figure 194 – Example DCI for the Open Release Content
End User Luigi, a conference participant, wishing to Use an Open Release Content Item, performs the following steps:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Luigi |
Access |
Content Item |
|
Access Content |
3.6.1 |
|
Luigi |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Luigi |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
Note that an “Open Release browser” would facilitate Access and Use of Open Release Content according to the Licence terms. For instance the browser could display a human-readable notice to the user about the permissions given in the Licence.
Licence for every conference participant
The following Figure shows an example Licence for Luigi's Device, obtained by Luigi from Leonardo after communicating him his SAV Content ID. The Licence Grants Luigi's Device to Use the Resources part of the Content Item under some conditions.
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:bpx="urn:mpeg:mpeg21:2005:01-REL-BPX-NS" xmlns:dacx="urn:mpeg:mpeg21:2006:01-REL-DACX-NS" xmlns:dmp2rl="urn:dmp:idp2:Represent:License:2006:02" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:dmp:idp2:Represent:License:2006:02 dmp2rl-2006-02.xsd">
<grant>
<keyHolder>
<info>
<dsig:KeyName>Luigi's Device identifier</dsig:KeyName>
</info>
</keyHolder>
<possessProperty/>
<sx:propertyUri definition="urn:MyConference:participant"/>
<validityInterval>
<notAfter>2006-04-30T00:00:00</notAfter>
</validityInterval>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Leonardo's Certificate</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 195 – Example of a Licence for Luigi's Device
In this case Leonardo wants to Release his Content with a Licence that is derived from a Creative Commons licence.
The following example gives a possible DCI for this case where the following information is represented:
7. The container has the identifier “urn:mpegRA:mpeg21:dii:or:1110” and contains one Item
8. The Item is declared as “Photo of Bob” with the identifier “urn:mpegRA:mpeg21:dii:or:1111”
9. The content was derived of the item with the identifier• “urn:mpegRA:mpeg21:dii:or:0010”
10. The title of the image is “My Photo1”.
11. The Licence does not allow commercial use and modification of the item.
12. It is annotated that the item with the identifier “urn:mpegRA:mpeg21:dii:or:5500” is an adapted version of this item.
<?xml version="1.0"?>
<DIDL xmlns="urn:mpeg:mpeg21:2002:01-DIDL-NS" xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2006:07-DIDL-OR-NS didl_OR-MAF.xsd">
<Container>
<Descriptor>
<Statement mimeType="text/xml">
<!-- Identifier of the OR-File -->
<dii:Identifier>urn:mpegRA:mpeg21:dii:or:1110</dii:Identifier>
</Statement>
</Descriptor>
<Item id="content_01">
<Descriptor>
<Statement mimeType="text/plain">Photo of Bob</Statement>
</Descriptor>
<Component id="comp_01">
<Descriptor>
<Statement mimeType="text/xml">
<!-- Identifier of the Content_ 01 -->
<dii:Identifier>urn:mpegRA:mpeg21:dii:or:1111</dii:Identifier>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<!-- Related Identifier to the original content-->
<dii:RelatedIdentifier relationshipType="urn:mpeg:mpeg21:2002:01-RDD-NS:IsAdaptationOf">urn:mpegRA:mpeg21:dii:or:0010</dii:RelatedIdentifier>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<Mpeg7 xmlns="urn:mpeg:mpeg7:schema:or:2007" xsi:schemaLocation="urn:mpeg:mpeg7:schema:or:2007 mpeg7_OR.xsd">
<Description>
<CreationInformation>
<Creation>
<Title>My Photo1</Title>
</Creation>
</CreationInformation>
</Description>
</Mpeg7>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<!--The following license doesn't allow the commercial use and modification of the item. -->
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:m3x="urn:mpeg:mpeg21:2006:01-REL-M3X-NS" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M3X-NS rel-m3x-v1.xsd">
<grant>
<mx:play/>
<digitalResource licensePartId="di_1">
<nonSecureIndirect URI="urn:mpegRA:mpeg21:dii:or:1111"/>
</digitalResource>
<m3x:notice noticeType="ShowBeforeExercise">
<m3x:copyRights>Written by Bob, AAA Company, 2007.1.1 </m3x:copyRights>
<m3x:nonCommercialUse/>
</m3x:notice>
</grant>
<grant>
<m1x:governedCopy/>
<digitalResource licensePartIdRef="di_1"/>
<m3x:notice>
<m3x:copyRights>Written by Bob, AAA Company, 2007.1.1 </m3x:copyRights>
<m3x:nonCommercialUse/>
</m3x:notice>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
</Statement>
</Descriptor>
<Resource ref="myFirstPicture.jpg" mimeType="image/jpeg"/>
</Component>
<Annotation target="#comp_01">
<Descriptor>
<Statement mimeType="text/xml">
<!-- Related Identifiers, which adapted this content. As annotation because it changes over time. -->
<dii:RelatedIdentifier relationshipType="urn:mpeg:mpeg21:2002:01-RDD-NS:HasAdaptation"> urn:mpegRA:mpeg21:dii:or:5500</dii:RelatedIdentifier>
</Statement>
</Descriptor>
</Annotation>
</Item>
</Container>
</DIDL>
Figure 196 – Example of an Open Release DCI
The following example gives a DCI containing a License representing[3] a Creative Commons (CC) license “Attribution Non-commercial No Derivatives” (by-nc-nd) 1.0 for the purpose of having it processed by a machine where the following information is contained:
· The author, John Smith, created a digital item named, “My Photo1”.
· He is from the organization, “Smith Inc.” and has an email address “john.smith@iso.ch”.
· The place the content is created is in Piruli in Spain, on 10-3-1998 14:13.
· The content is licensed under a CC license scheme, with a licensing information page at http://creativecommons.org/licenses/by-nd-nc/1.0/
<?xml version="1.0" encoding="UTF-8"?>
<Mpeg7 xmlns="urn:mpeg:mpeg7:schema:or:2007" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg7:schema:or:2007 mpeg7_OR.xsd">
<Description>
<CreationInformation>
<Creation>
<Title>My Photo1</Title>
<Creator>
<Agent>
<Name>
<GivenName>John</GivenName>
<FamilyName>Smith</FamilyName>
</Name>
<Affiliation>
<Organization>
<Name>Smith Inc.</Name>
</Organization>
</Affiliation>
<ElectronicAddress>
<Email>john.smith@iso.ch</Email>
</ElectronicAddress>
</Agent>
</Creator>
<CreationCoordinates>
<Location>
<Name>Piruli</Name>
<Region>es</Region>
</Location>
<Date>
<TimePoint>1998-10-03T14:13+01:00</TimePoint>
</Date>
</CreationCoordinates>
<CopyrightString> Creative Commons (CC) License: Attribution Non-commercial No Derivatives (by-nc-nd) </CopyrightString>
</Creation>
<RelatedMaterial>
<MaterialType>
<Name>Licensing Information Page</Name>
</MaterialType>
<MediaLocator>
<MediaUri>http://creativecommons.org/licenses/by-nd-nc/1.0/</MediaUri>
</MediaLocator>
</RelatedMaterial>
</CreationInformation>
</Description>
</Mpeg7>
Figure 197 –
In this case Leonardo wishes to be informed of how many “hits” his Content receives, i.e. how many times Users Access the Licence not Bundled within the Content file to Use it.
This time Leonardo performs the following steps.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Leonardo |
Create |
Resource |
PowerPoint file |
Out of scope |
|
|
Leonardo |
Create |
Metadata |
Of Powerpoint file |
Out of scope |
|
|
Leonardo |
Create |
Audio and video |
|
Out of scope |
|
|
Leonardo |
Create |
Resource |
Audio-visual Resource file |
Out of scope |
|
|
Leonardo |
Create |
Metadata |
Of audio-visual Resource file |
None |
|
|
Registration Agency |
Identify |
Resource and Metadata |
PowerPoint file and audio-visual file |
None |
|
|
Leonardo |
Represent |
Identifier |
In Resources and Metadata |
Represent Identifier |
2.5.1 |
|
Leonardo |
Create |
Human-readable license |
With the following permissions: · Play a. Time of Use: i. until end of conference (Users who are conference participants) ii. after end of conference (all Users in the selected jurisdiction) b. Number of times: 1 · Store: unrestricted · Print PowerPoint file: unrestricted · Move: unrestricted · Copy: unrestricted · Territoriality: for the selected jurisdiction |
Out of scope |
|
|
Registration Agency |
Identify |
Human readable license |
Lower case "L" because this is not a Licence |
Out of scope |
|
|
Leonardo |
Create |
Machine-readable Licence |
Corresponding to the human-readable license (expressed in verbose XML) |
Represent Licence |
2.10 |
|
Registration Agency |
Identify |
Licence |
|
None |
|
|
Leonardo |
Binarise XML |
Licence |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
Leonardo |
Store |
Licence |
In own server |
Out of scope |
|
|
Leonardo |
Create |
Content Item |
Containing 4. Resources 5. Metadata 6. Human-readable license for the selected jurisdiction 7. Pointer to the binary Licence 8. Identifiers of all the above |
Represent Content |
2.1 |
|
Registration Agency |
Identify |
Content Item |
|
None |
|
|
Leonardo |
Represent |
Identifier |
In Content Item |
Represent Content Identifier |
2.5.1 |
|
Leonardo |
Binarise XML |
Content Item |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
Leonardo |
Package |
Content |
As file |
Package Content As File |
4.1.1 |
|
Leonardo |
Release |
Content file |
To conference organisers |
None |
|
End User Luigi wishing to Use an Open Release Content Item would perform the following steps:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Luigi |
Access |
Content Item |
|
Access Content as File |
3.5.1 |
|
Luigi |
Access |
Licence |
Every time Licence is Accessed, Licence server adds a hit |
Access Licence as File |
3.5.2 |
|
Luigi |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Luigi |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
In this case Leonardo wants to cover a broader number of jurisdictions with a license for each of them. The steps of the previous walkthrough are repeated with the difference that for each selected jurisdictions separate license will be created.
End User Luigi wishing to Use an Open Release Content Item would perform the following steps:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Luigi |
Access |
Content Item |
|
Access Content as File |
3.5.1 |
|
Luigi |
Select |
Jurisdiction |
|
Out of scope |
|
|
Luigi |
Access |
Licence |
Every time Licence is Accessed, Licence server adds a hit |
Access Licence as File |
3.5.2 |
|
Luigi |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Luigi |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
The WWW has had the fast evolution that everybody knows on the basis of the idea that content could somehow be posted by anybody for anybody to use without much concern on whether the user posting the content actually had rights to that content and without considering the use that could be made of the posted content.
This model is clearly reaching its limits. On the one hand there is a demand, on the part of people accessing content on the web, to be assured of its legal status. On the other there is a demand, on the part of people posting content on the web, to users of that posted content to comply with some conditions.
This Use Case is about a hypothetical service provider GreatRedSearch offering services for those who post lightly Governed Content and those who Use it.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
GreatRedSearch (GRS) is a fast growing search engine company that sees the transition of the web to the new phase where Content is posted in a light-weight Governed form (e.g. corresponding to “Open Release” of Use Case #1) that also provides guarantees of the origin of the Content.
GRS decides to offer a service (for free) allowing subscriber Sam to:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Sam |
Access |
Open Release authoring tool |
(this step is outside of DMP) |
Out of scope |
|
|
Sam |
Select |
license |
From a set of standard human-readable licenses for a range of jurisdictions |
Out of scope |
|
|
GRS |
Identify |
license |
|
Out of scope |
|
|
GRS |
Identify |
Licence |
|
Represent Licence Identifier |
2.5.2 |
|
Sam |
Binarise XML |
Licence |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
Sam |
Store |
Licence |
In GRS server |
None |
|
|
Sam |
Create |
Content Item |
Containing 1. Resources 2. Metadata 3. Human-readable license for the selected jurisdiction 4. Pointer to the binary License 5. Identifier of all the above |
Represent Content |
2.1 |
|
GRS |
Identify |
Content Item |
|
None |
|
|
Sam |
Represent |
Content Identifier |
In the Content Item |
Represent Content Identifier |
2.5.1 |
|
GRS |
Binarise XML |
Content Item |
|
Represent Binary XML |
2.19 |
|
Sam |
Store |
Content Item |
In GRS server |
None |
|
End User Pat of the GRS service can perform the following
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Pat |
Access |
Open Release browser |
|
Out of scope |
|
|
Pat |
Browse |
Content Data Base |
The database containing records created from the Content stored in-house and the Content searched on the WWW. Each record contains: 7. Content URL 8. Metadata 9. Licensing conditions |
Out of scope |
|
|
Pat |
Access |
Content Item |
|
Access Content as File |
3.5.1 |
|
Pat |
Access |
Licence |
|
Access Licence as File |
3.5.2 |
|
Pat |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Pat |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
This Use Case offers an example of how to mitigate the difficulties that some Rights Holders encounter in Releasing unencrypted digital media because of the possibility for a User to Copy Content on several Devices and Use it simultaneously, thereby reducing their revenues.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
GreatRedRecords (GRR) is a record label that is open to the adoption of new technology as a means to promote use of its repertoire by its loyal customer base and to extend use to new customers. GRR is concerned by the possibility of indiscriminate digital copies of its content, but feels that current DRM solutions for digital distribution do not allow enough flexibility. GRR is seeking a new way to offer its customers Use of its repertoire with the sole restriction that Use is made with one Device at a time.
The marketing department has come up with the following proposal:
· A family, identified by a Domain, is offered a large number of songs at appealing prices;
· all family members independently select songs for their own. The selection is called ContentGroup;
· Family members can play one song at a time taken from their ContentGroup any time they want on any of their Devices.
It is clear that a song that appears in more than one ContentGroup can be Used by more that one Device. In this case simultaneous Use of than song is obviously possible.
Let’s assume that a set of 8 songs has been selected by the Jones family and two family members Anne and Bob have made overlapping selections for their ContentGroups A and B, i.e. some songs have been selected for A, some for B and some for both A and B. Simultaneous Use of one song out of 1, 2, 3, 4, 5 and 6 is possible for ContentGroup A and of one song out of 4, 5, 6, 7 and 8 is possible for ContentGroup B. Therefore songs 4, 5 and 6 can be Used simultaneously. This is depicted in the figure below

Figure 198 – Songs in ContentGroups A and B
The following steps are needed to implement the proposal made by the GRR marketing department. Of course several variations are possible but only the one described below will be considered further:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
DMD Manufacturer |
Make |
DMD |
|
Out of scope |
|
|
Certification Agency |
Certify |
DMD |
|
Out of scope |
AD #5 2. |
|
Registration Agency |
Identify |
Device |
DMD Registered |
Register Domain |
2.5.5 3.1.1 |
|
The Jones |
Buy |
DMD |
|
Out of scope |
|
|
The Jones |
Install |
DMD |
On the family’s home media server |
Out of scope |
|
|
Domain Administrator |
Create |
Domain |
|
Create Domain Protocol |
3.3.2.1 |
|
Anne |
Add |
Device |
DMD adds Anne’s Devices to the Domain |
Add Device Protocol |
3.3.4.1 |
|
Anne |
Buy |
Licence |
Corresponding to set of songs belonging to ContentGroup A |
Out of scope |
|
|
Anne |
Access |
Content |
Containing Licence |
Access Content as File |
3. 5.1 |
|
Bob |
Add |
Device |
DMD adds Bob’s Devices to the Domain |
Add Device Protocol |
3.3.4.1 |
|
Bob |
Buy |
Licence |
Corresponding to set of songs belonging to ContentGroup B |
Out of scope |
|
|
Bob |
Access |
Content |
Containing Licence |
Access Content as File |
3. 5.1 |
|
Bob |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Bob |
Use |
Content Item |
Song #6 as per Licence terms |
Represent Content Elements |
2. |
|
Device |
Create |
Use Data |
Device used by Bob to play song #6 |
Create Use Data |
2.17 |
|
Anne |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Anne |
Use |
Content Item |
Song #1 as per Licence terms |
Represent Content Elements |
2. |
|
Device |
Create |
Use Data |
Device used by Anne to play song #1 |
Create Use Data |
2.17 |
|
Bob |
Use |
Content Item |
Song #2 against Licence terms at the same time as Anne plays song #1 |
Represent Content Elements |
2. |
|
Device |
Create |
Use Data |
Device used by Bob to play song #2 |
Create Use Data |
2.17 |
|
Device |
Connect |
DMD |
Device used by Anne to play song #1 |
Protocol to detect simultaneous Usage |
3.3.5 |
|
Device |
Connect |
DMD |
Device used by Bob to play song #2 |
Protocol to detect simultaneous Usage |
3.3.5 |
|
DMD |
Detect |
Simultaneous Use |
DMD detects un-Licences simultaneous Use of song #1 and song #2 |
Protocol to detect simultaneous Usage |
3.3.5 |
Procedure for subsequent steps, if simultaneous use did occur, follows whatever representations were set out in GRR marketing literature.
When using DRM systems based on copy protection, End Users are often confronted with inconveniences, if they want to transfer and/or copy content to various devices within their environment. One of the reasons for this is that DRM systems need to have the right key(s) “in the right place, at the right time” in order to encrypt and decrypt content as needed.
Alternatively, a traceability-based approach can be used. While not aiming at preventing End Users from Accessing Content “ex ante”, as conventional DRM does, such systems require that End-Users mark Content with a responsible User (e.g. the End-User), thus generating “Signed Content”. The User is traceable “ex post” in cases of unauthorized public dissemination. However, in return End-Users can Access and Copy Content within their personal environment as they wish, avoiding many complexities and possible inconveniences of conventional DRM solutions.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
This walkthrough has three Users:
1. GreatGreenMusic (GGM) is a Retailer that Releases Governed and protected Content (specifically music) with DRM Information that signals that a DRM Tool is required to Decrypt and mark Resources with the Identifier of the User of the Content Item.
2. GreatGreenTool (GGT) is a company that provides the DRM Tool.
3. Jim is a User who is willing to Use marked Resources from Governed Content acquired from GGM in his home environment in an unprotected form.
Jim performs the following steps:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Jim |
Buy |
Licence |
Allowing Export |
Out of scope |
|
|
Jim |
Access |
Content Item |
Content (title: INeedAKey) has 1. the above Licence Bundled within it 2. DRM Information signals the specific Resource marking DRM Tool |
Access Content as File |
3.5.1 |
|
Jim |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Jim |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
|
DRM Processor |
Access |
DRM Tool Body |
From GGT |
Access DRM Tool Body as File |
3.5.3 |
|
DRM Processor |
Export |
Resource |
Done on INeedAKey. The DRM Tool Parses and Decrypts the Resource in INeedAKey, marks it with Jim’s ID, and Stores it as an un-Encrypted mp3 file ICanBeCopied |
Out of scope |
|
|
Jim |
Play |
Resource |
On all mp3 players within his personal environment |
Out of scope |
|
Jim will not publicly disseminate the song because the ID of the marking software pointing to his software is within the mp3 file.
There is ample evidence that consumers are interested in accessing content via new, non-physical distribution mechanisms (e.g. the Internet) and to use that content on a variety of devices, e.g. portable devices. Rights holders have shown their availability to release governed content through such distribution mechanisms. However, so far this has been done using technologies that do not provide interoperability. The lack of interoperability is a serious obstacle to the widespread acceptance of governed content distribution mechanisms that compare favourably with existing services for their friendliness.
This Use Case is about how the technologies specified in Approved Document No. 3 can be used to implement Internet distribution of Governed Content for Use on Portable (PAV) and Stationary (SAV) Audio and Video Devices.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
GreatRedBand (GRB) has had considerable success in its native territory around Middleofnowheretown and its fame is spreading to the nearby Nexttonowhereville. The rest of the world is just next step. GRB produces Instances of original Works, original Adaptations of existing Works and non original Works.
Unfortunately contacts with distributors have not been successful, so GRB is considering the proposal of an IT solution vendor to try Internet-based distribution of their music as Governed Content. The proposal looks attractive because it promises to reach the growing number of DMP-compatible PAV Devices that can be used to Play Governed Content.
GRB decides to purchase an integrated IT solution to perform the following steps when producing each of its recordings of its original Works:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
GRB |
Make |
Resources |
MP3 file (possibly other Resources e.g. photos, videos etc. |
Out of scope |
|
|
GRB |
Make |
Metadata |
For all Works and Resources in each recording |
None |
|
|
GRB |
Make |
license |
Human-readable license for all the jurisdictions in which GRB intends to distribute its recording |
Out of scope |
|
|
GRB |
Make |
Licence |
Corresponding to the human-readable licence |
Represent Licence |
2.10 |
|
Registration Agency |
Identify |
Licence |
|
Represent Licence Identifier |
2.5.2 |
|
GRB |
Binarise XML |
Licence |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
GRB |
Store |
Binary Licence |
In own Licence Provider Device |
None |
|
|
GRB |
Encrypt |
Resources |
|
Represent Fixed DRM Tools |
2.8.3 |
|
GRB |
Make |
Content Item |
Containing Encrypted Resources, Metadata, human-readable Licence, pointer to Licence and Identifiers of all the above |
Represent Content |
2.1 |
|
Registration Agency |
Identify |
Content Item |
|
None |
|
|
GRB |
Represent |
Identifier |
In Content Item |
Represent Content Identifier |
2.5.1 |
|
GRB |
Binarise XML |
Content Item |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
GRB |
Package |
Content Item |
To make a file |
Package Content as File |
4.1.1 |
|
GRB |
Release |
Packaged Content Item |
On GRB’s web site (this step is outside of DMP) |
None |
|
Martin is a GRB fan. To Access their latest hit the following steps are performed:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Martin |
Select |
Song |
From www.GreatRedBand.com |
Out of scope |
|
|
PXD |
Access |
Content Item |
From www.GreatRedBand.com |
None |
|
|
PXD |
Access |
Licence |
From GRB Licence server |
Access Licence as File |
3.5.2 |
|
PXD |
Package |
Licence |
In DCF |
Package Content |
4.1.1.9 |
|
PXD |
Move |
DCF |
To Martin’s PAV |
None |
|
|
PAV |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
PAV |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
One of the Works that GRB wishes to Produce is called What Wonderful Music (WWM) by Magnificent B. Musico (MBM). WWM is registered with a Collective Management Society (CMS) that is also an Agency of the DMP Content Registration Authority.
The CMS offers an innovative web-based Work Licensing service that plugs into the GRB’s IT solution and that supports GRB performing the following:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
CMS |
Make |
Metadata |
Standard WWM Metadata |
None |
|
|
GRB |
Select |
license |
On the CMS web site for an appropriate (human-readable) distribution license for First Fixation and reproduction of GRB’s Instance of WWM by MBM |
Out of scope |
|
|
CMS |
Make |
Licence |
Corresponding to selected license |
|
|
|
CMS |
Identify |
Licence |
|
Represent Licence Identifier |
2.5.2 |
|
CMS |
Make |
Content Item |
|
Represent Content |
2.1 |
|
CMS |
Identify |
Content Item |
|
Represent Content Identifier |
2.5.1 |
|
GRB |
Access |
Content Item |
Content Item #1 |
Access Content as File |
3.5.1 |
|
GRB |
Make |
Resource |
The Resource is the MP3 file of the Production. Other Resource types may be added |
Out of scope |
|
|
GRB |
Make |
Metadata |
Of the MP3 file of the Production and possibly other Resource types |
None |
|
|
CMS |
Identify |
Resource |
|
Out of scope |
|
|
CMS |
Identify |
Metadata |
|
Out of scope |
|
|
GRB |
Make |
Content Item |
Content Item from Content Item #1 containing: Resources, Metadata and Identifiers of all the above |
Represent Content |
2.1 |
|
CMS |
Identify |
Content Item |
Content Item #2 |
None |
|
|
GRB |
Represent |
Identifier |
In Content Item #2 |
Represent Content |
2.1 |
|
GRB |
Package |
Content Item |
Content Item #2 as file |
Package Content |
4.1.1 |
|
GRB |
Release |
DCF |
Content Item #2 on GRB’s web site |
None |
|
To benefit from available world wide Work licensing services and Work Use Monitoring GRB Registers:
· All their original Works for worldwide identification;
· Instances (i.e. recordings) for world wide identification.
Soto Lesan from a far away land is a fan of Magnificent B. Musico and is looking for new productions of WWM by MBM. Soto Lesan does the following:
· Searches the web for all references of MBM and is directed to GRB’s websiste;
· Selects GRB’s production of WWM by MBM;
· Continues his use case as does Martin in walkthrough #1.
GreatGreenP2P (GGP) is a P2P network that has decided to “go legit”. The network hosts a vibrant community of music lovers whose members used to indulge in the traditional file sharing. With the change of times GGP has decided to retain its focus on music but to extend the offer to access music of two types of provenance:
· Self-produced by GGP members as Open Release Content where the Release mechanism is provided by GGP’s P2P network
· Produced by regular record companies that Release their assets on GGP’s P2P network as
o unEncrypted Resource in a Governed DCI for promotion
o Encrypted Resource in a Governed DCI for sale.
GGP provides its members with a “Create and Share” program to be used for making and sharing Content on the P2P network. The program is a Certified Application that acts as a Content Creation Device once installed.
A member wishing to share his own music in the community can make a DCI with
2 Resources
3 Metadata
4 Licence
The program supports the following Functions (same as for Open Release and Open Search):
· Registering the Resource with a Collective Management Society (CMS)
· Making a Licence using a small number of standard templates
· Registering the Licence
· Making the DCI
· Registering the DCI
· Making the DCF for distribution.
The program supports making DCIs with clear-text Resources only.
Once the “Create and Share” program has created a DCF it Stores it in the shared directory used by GGP’s P2P network in the Creator’s PC.
Further GGP makes a deal with GreatGreenRecords (GGR), an innovative record company. GGR wants to Release their repertoire on GGP’s P2P network. The Release is made in the form of a DCF. The DCI in the DCF contains
· Reference to one or more Resources
· Metadata
· Licence.
Only the most valuable of its Resources are Encrypted by GGR. The less known titles are Released in clear-text for promotion. All GGR Resources Released by GGR are watermarked.
GGP distributes to its members an “Access and Play” program to Access and Play songs Released on GGP P2P network. The same program can be employed to Access and Play Content Released by its grass root membership and by GGR. The program is a Certified Application that acts as a Content Consumption Device once installed.
A member of the GGP P2P network using the “Access and Play” program can scour the network to find Content Items of his interest. Once a Content Item is found, the program Parses the DCI and displays the Metadata in it. If the member is interested it can download the DCI to his PC where it will be Stored in the shared directory used by GGP’s P2P network.
There is no incentive for members of the GGP network to extract Unencrypted Resources from GGR’s Content Items as sharing on the network can only be done with Content Items and not with single Resources. There may well be an incentive to Export unEncrypted Resources from GGR outside of GGP network. However, the license explicitly forbids such an Export and the watermark allows GGR to monitor the importance of the phenomenon.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
Sara has created lyrics and scores of her new song. She has sung, played and recorded the song in the MP3 format.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Sara |
Make |
Resource |
MP3 file |
Out of scope |
|
|
Sara |
Request |
Identifier |
Of Resource from CMS |
None |
|
|
CMS |
Assign |
Identifier |
To Resource |
None |
|
|
Sara |
Make |
Metadata |
For all Works and Resources in the recording |
None |
|
|
Sara |
Select |
license |
Human-readable license for GGP distribution |
Out of scope |
|
|
Sara |
Make |
Licence |
Corresponding to the human-readable license |
Represent Licence |
2.10 |
|
Sara |
Request |
Identifier |
Of Licence to GGP |
None |
|
|
GPP |
Assign |
Identifier |
To Licence |
None |
|
|
Sara |
Binarise |
Licence |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
Sara |
Create |
DCI |
With Resources, Metadata, license, Licence and all Identifiers |
Represent Content |
2.1 |
|
Sara |
Request |
Identifier |
Of Content Item to GGP |
None |
|
|
GGP |
Assign |
Identifier |
To Content Item |
None |
|
|
Sara |
Add |
Identifier |
To Content Item |
Represent Content |
2.1 |
|
Sara |
Binarise |
DCI |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
Sara |
Package |
DCI |
To make DCF |
Package Content |
4.1.1 |
|
Sara |
Store |
DCF |
i.e. Release on GGP network |
None |
|
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Phil |
Browse |
GGP network |
Using GGP Metadata to look for interesting songs |
None |
|
|
Phil |
Select |
Song |
In GGP network (Sara’s Device) |
Out of scope |
|
|
Device |
Access |
Content Item |
From Sara’s Device |
Out of scope |
|
|
Device |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Device |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
GGP makes a deal with GGR whereby Content is Delivered to GGP as a DCI with unEncrypted Resources and prepared using a program similar to GGP’s “Create and Share” program.
For titles that require Encryption GGP makes the DCI for Release on the P2P network with the following steps:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
GGP |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
GGP |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
|
GGP |
Encrypt |
Resource |
With Resource Encryption Key |
Represent Fixed DRM Tool |
2.8.3 |
|
GGP |
Add |
URI of GGP LPD |
To Licence |
Represent Licence |
2.10 |
|
GGP |
Assign |
Identifier |
To Licence |
Represent Identifier |
2.5.2 |
|
GGP |
Assign |
Identifier |
To DCI |
Represent Identifier |
2.5.1 |
|
GGP |
Make |
DCI |
With Encrypted Resource, Licence and Identifiers |
Represent Content |
2.1 |
|
GGP |
Binarise |
DCI |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
GGP |
Package |
DCI |
To make DCF |
Package Content |
4.1.1 |
|
GGP |
Store |
DCF |
i.e. Release on GGP network |
None |
|
Phil is the first P2P user who has found Sara’s song in her PC and feels it looks interesting. He can do that because the P2P network gives direct access to Metadata in DCI. He performs the following.
Igor knows that Ivan has similar tastes as his and has found a song in Ivan’s PC that looks interesting. This comes from GGR’s repertoire and is Encrypted. Igor performs the following
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Igor |
Browse |
GGP network |
Using GGP Metadata to look for interesting songs |
None |
|
|
Igor |
Select |
Song |
In GGP network (Ivan’s Device) |
Out of scope |
|
|
Device |
Access |
DCF |
From Ivan’s Device |
Out of scope |
|
|
Device |
Un-Package |
DCF |
|
Package Content |
4.1.1 |
|
Device |
Parse |
DCI |
Notifies Igor that a Licence is required |
Represent Content Elements |
2. |
|
Igor |
Make |
Transaction |
With GGP server |
Out of scope |
|
|
Device |
Access |
Licence |
From GGP LPD |
Access Licence |
3.5.2 |
|
Device |
Parse |
Licence |
Encrypted Decryption Key is extracted and sent to the DRM Processor |
Represent Licence |
2.10 |
|
DRM Processor |
Decrypt |
Encrypted Resource Decryption Key |
Using Igor’s Public Key |
Out of scope |
|
|
DRM Processor |
Send |
Decrypted Resource Decryption Key |
To Fixed DRM Tool |
Represent DRM message |
2.12 |
|
Fixed DRM Tool |
Decrypt |
Resource |
Using Decrypted Resource Decryption Key |
Out of scope |
|
|
Igor |
Play |
Resource |
|
Out of scope |
|
Services that are respectful of the Rights of Rights Holders can be promoted by exploiting the flexibility of digital technologies to offer more than what is being provided by other types of services. One way is to offer Content subject to conditions that suit the needs of End-Users.
This Use Case describes how Retailer GreatRedOffers (GRO) is betting the future of the enterprise on its ability to offer Content with a broad variety of very flexible conditions. Therefore it only provides examples licenses without considering the other elements of the Value-Chain.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
GRO issues a Licence to Play a Content Item on a Device that can be Identified. Below is an example:
<?xml version="1.0" encoding="UTF-8"?>
<license
xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dmprr="urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS rel-mx-dmpREL.xsd urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS dmpREL.xsd">
<grant>
<keyHolder>
<info>
<dsig:KeyName>Device A's certificate or Identifier</dsig:KeyName>
</info>
</keyHolder>
<mx:play/>
<digitalResource>
<nonSecureIndirect URI="urn:games.breakout.class"/>
</digitalResource>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 199 – Example of Licence to Play a Content Item on a Device
GRO issues a Licence to Play once (i.e. to “preview”) a Content Item to any Device.
An example license is given below
<?xml version="1.0" encoding="UTF-8"?>
<license
xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dmprr="urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS rel-mx-dmpREL.xsd urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS dmpREL.xsd">
<grant>
<mx:play/>
<digitalResource>
<nonSecureIndirect URI="urn :songs.newsong.mp3"/>
</digitalResource>
<sx:exerciseLimit>
<sx:count>1</sx:count>
</sx:exerciseLimit>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 200 – Example Licence to preview a Content Item to any Device
GRO issues a Licence to Play a Content Item on a Device that can be Identified when the following conditions both hold:
4. The actual date/time is less than a specified date/time
5. The total duration the Content Item has been Played does not exceed a specified length of time.
An example Licence is given below
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dmprr="urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS rel-mx-dmpREL.xsd urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS dmpREL.xsd" licenseId="543210">
<grant>
<keyHolder>
<info>
<dsig:KeyName>Device A's certificate or Identifier</dsig:KeyName>
</info>
</keyHolder>
<mx:play/>
<digitalResource>
<nonSecureIndirect URI="urn :mysongs.aaa.mp3"/>
</digitalResource>
<allConditions>
<validityInterval>
<notAfter>2004-02-13T15:30:00</notAfter>
</validityInterval>
<sx:validityTimeMetered>
<sx:duration>P15D</sx:duration>
</sx:validityTimeMetered>
</allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer’s Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 201 – Example Licence to Play a Content Item on a Device with conditions
GRO issues a Licence (Super Distribution Licence) to Device A to Copy two times a Content Item C without a Bundled Licence to another Device B. When Device B needs to Play Content Item C it Accesses a Licence from GRO.
An example Licence is given below
<?xml version="1.0" encoding="UTF-8"?>
<r:license xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dmprr="urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS dmpREL.xsd" sx:profileCompliance="dmp-rel-1.0">
<r:grant>
<r:keyHolder>
<r:info>
<dsig:KeyName>Device A's certificate or identifier</dsig:KeyName>
</r:info>
</r:keyHolder>
<dmprr:copy/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:movies.wickedmovies.mymovie.mpeg"/>
</r:digitalResource>
<sx:exerciseLimit>
<sx:count>2</sx:count>
</sx:exerciseLimit>
</r:grant>
<r:issuer>
<r:keyHolder>
<r:info>
<dsig:KeyName>Issuer's signing key</dsig:KeyName>
</r:info>
</r:keyHolder>
</r:issuer>
</r:license>
Figure 202 – Example of Super Distribution Licence
GRO issues a Licence to Device A to Play a Content Item (http://acme.org/myVideo) which is Encrypted. The Licence conveys to Device A the Decryption key to Decrypt the Encrypted Content Data Element. The Decryption key, in turn, is Encrypted and can be Decrypted only by Device A’s private key.
An example Licence is given below
<?xml version="1.0" encoding="UTF-8"?>
<license
xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dmprr="urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS rel-mx-dmpREL.xsd urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS dmpREL.xsd">
<grant>
<keyHolder>
<info>
<dsig:KeyName>Device A's certificate or Identifier</dsig:KeyName>
</info>
</keyHolder>
<mx:play/>
<dmprr:protectedResource>
<digitalResource>
<nonSecureIndirect URI="http://acme.org/myVideo"/>
</digitalResource>
<enc:EncryptedKey>
<enc:EncryptionMethod Algorithm=" http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<dsig:KeyInfo>
<dsig:KeyName>Device A’s Public Key Name</dsig:KeyName>
</dsig:KeyInfo>
<enc:CipherData>
<enc:CipherValue>AQABAA==</enc:CipherValue>
</enc:CipherData>
<enc:CarriedKeyName>Content encryption key for mymovie clip</enc:CarriedKeyName>
</enc:EncryptedKey>
</dmprr:protectedResource>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer’s Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 203 – Example of Licence to Play an Encrypted Content Item on a Device
GRO issues two Licences to Device A that is part of Domain D:
1. The first Licence states that the device holding the named certificate or Identifier is a member of the Domain by virtue of possessing DomainResource property. This is in essence a Domain Certificate for the Device.
2. The second Licence (associated to a Content Item) states that any Device in the Domain (i.e. any Device that has the stated Domain certificate) can Play the specified Content Item.
These two Licences are enough to allow all Devices in the Domain to Play the stated Content Item. The benefit of this two Licence model is that individual Licences for each Content Item are not needed.
Two example Licences are given below. The first conveys Domain information to a Device, the second grants to a Device part of that Domain some rights on a Content Item.
<?xml version="1.0" encoding="UTF-8"?>
<r:license xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dmpmd="urn:dmp:Manage:Domain:2005:04-DMP-MD-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:dmp:Manage:Domain:2005:04-DMP-MD-NS dmpmd.xsd" sx:profileCompliance="dmp-rel-1.0">
<r:grant>
<r:keyHolder>
<r:info>
<dsig:KeyName>Device A's certificate or identifier</dsig:KeyName>
</r:info>
</r:keyHolder>
<r:possessProperty/>
<dmpmd:domainResource>
<dmpmd:DomainManager_ID>012345678</dmpmd:DomainManager_ID>
<dmpmd:Domain_ID>
<r:info>
<dsig:KeyName>Domain D's certificate or identifier</dsig:KeyName>
</r:info>
</dmpmd:Domain_ID>
<dmpmd:DomainKey>
<enc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
<enc:CipherData>
<enc:CipherValue>AQABAA==</enc:CipherValue>
</enc:CipherData>
<enc:CarriedKeyName>Domain D encyption key for Device A</enc:CarriedKeyName>
</dmpmd:DomainKey>
<dmpmd:Expiration>
<sx:duration>P1Y</sx:duration>
</dmpmd:Expiration>
</dmpmd:domainResource>
</r:grant>
</r:license>
Figure 204 – Example of Licence Granting a Device the membership to a Domain
<?xml version="1.0" encoding="UTF-8"?>
<license
xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dmprr="urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS" xmlns:dmpmd="urn:dmp:Manage:Domain:2005:04-DMP-MD-NS" xmlns:enc="http://www.w3.org/2001/04/xmlenc#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-REL-MX-NS rel-mx-dmpREL.xsd urn:mpeg:mpeg21:2005:04-REL-DMPRR-NS dmprr.xsd">
<grant>
<keyHolder>
<info>
<dsig:KeyName>Domain D's certificate or Identifier</dsig:KeyName>
</info>
</keyHolder>
<mx:play/>
<dmprr:protectedResource>
<digitalResource>
<nonSecureIndirect URI="http://acme.org/myVideo"/>
</digitalResource>
<enc:EncryptedKey>
<enc:EncryptionMethod Algorithm=" http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
<dsig:KeyInfo>
<dsig:KeyName>Domain D’s Public Key Name</dsig:KeyName>
</dsig:KeyInfo>
<enc:CipherData>
<enc:CipherValue>ACSWDQ==</enc:CipherValue>
</enc:CipherData>
<enc:CarriedKeyName>Content encryption key for mymovie clip</enc:CarriedKeyName>
</enc:EncryptedKey>
<dmpmd:DomainManager_ID>012345678</dmpmd:DomainManager_ID>
<dmpmd:SubDomain_ID>012ABCCDDEEE</dmpmd:SubDomain_ID>
<dmpmd:SubDomain_ID>3210ZSTTYY21</dmpmd:SubDomain_ID>
</dmprr:protectedResource>
</grant>
</license>
Figure 205 – Example of a Licence enabling Devices belonging to a Domain to Use a Content Item
Great Red Cameras (GRC) is a camera manufacturer who senses the growing demand on the part of its customers to retain control of their photos when they make “a copy” to their friends. Their latest model GRC-1 provides a new functionality that GRC hopes will encounter the favour of its customers.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
Shoji has bought a GRC camera and taken some pictures with it. Now he wants to send a selection of those pictures to Kenji. These are the steps he performs:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Shoji (camera) |
Encrypt |
Resources |
.jpg files |
Out of scope |
|
|
Shoji (camera) |
Move |
Resources |
To his PC using a Trusted Application provided by GRP |
None |
|
|
Shoji (SAV) |
Make |
Licence |
Licence terms are, e.g. 1. For one week 2. Unlimited number of times 3. Simultaneously on all the Devices of the friend’s Domain |
Represent Licence |
2.10 |
|
Registration Agency |
Identify |
Licence |
|
None |
|
|
Shoji (SAV) |
Store |
Licence |
To Shoji’s Licence Provider Device |
None |
|
|
Shoji (SAV) |
Make |
Content Item |
With the selected pictures (with whatever other Resources and Metadata (e.g. EXIF) the User will decide to add), pointer to Licence and Identifiers of Resources, Metadata and Licence |
Represent Content |
2.1 |
|
Registration Agency |
Identify |
Content Item |
|
None |
|
|
Shoji (SAV) |
Represent |
Identifier |
To Content Item |
Represent Content |
2.1 |
|
Shoji (SAV) |
Package |
Content Item |
For Delivery |
Package Content |
4.1.1 |
|
Shoji (SAV) |
Copy |
Content Item |
To Kenji (SAV) |
Out of scope |
|
Kenji, after receiving a notification that Shoji’s pictures have been Delivered, performs the following:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Kenji (SAV) |
Un-Package |
Content Item |
Using the Delivered DCF |
Package Content |
4.1.1 |
|
Kenji (SAV) |
Parse |
DCI |
|
Represent Content |
2. |
|
Kenji (SAV) |
Access |
Licence |
From Shoji’s Licence Provider Device |
Access Licence as File |
3.5.2 |
|
Kenji (SAV) |
Play |
Pictures |
|
None |
|
The 70-year old broadcast service is one of the most successful forms of distribution of audio-visual content. The use of digital technologies has helped carry the role of television to the digital space.
The greater ability of end-users to re-use digital content is of concern to Content Providers and Service Providers alike. That is why the world of television has been increasingly concerned with the problem of introducing some form of content governance, if not protection, with the condition that the traditional experience of television viewing is not negatively affected.
In this Use Case a light-weight form of content governance is applied that may satisfy some concerns of Content Providers, Service Providers while not affecting the End User experience negatively.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
This walkthrough has the following Users:
|
Type of User |
Name |
|
Service Provider |
GreenTVToday (GTT) |
|
Device Manufacturer |
GreenTVDevices (GTD) |
|
End User |
Tom |
The following steps are made
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
GTD |
Make |
Device |
SAV capable of: 1. Interpreting the Licence; 2. Displaying an appropriate message when the End-User performs a Function that does not comply with Permissions in the Licence |
Represent Content Represent Licence |
2.1 2.10 |
|
Certification Agency |
Certify |
Device |
Certification of REL interpreter conformance |
|
AD #5 |
|
GTD |
Sell |
Device |
To Retailer |
Out of scope |
|
|
GTT |
Make |
Licence |
· Play Content in the UK; · Store Content for later Use; · Move/Copy Content to another SAV or PAV within the UK |
Represent Licence |
2.10 |
|
GTT |
Make |
Content |
Clear-text Broadcasting of television programs with a Licence Bundled within the Content |
Represent Content |
2.1 |
|
GTT |
Deliver |
Content |
Streaming and Downloading of Governed Content |
Package Content as Strem |
4.1.2 |
|
Tom |
Buy |
Device |
From Retailer selecting a Manufacturer of his choice, e.g. GTD |
Out of scope |
|
|
Tom |
Access |
Service |
From different Service Providers (e.g. GTT) using the same SAV (e.g. the one bought from GTD) |
Out of scope |
|
|
Tom |
Access |
Content |
|
Access Content as Stream |
3.5.1 |
|
Tom |
Un-Package |
Content Item |
|
Package Content |
4.1.2 |
|
Tom |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
Currently some Service Providers adopt business models that employ technical protection measures (Conditional Access systems). Because of the absence of standards these business models require the creation of proprietary (portions of) value-chains that require in particular manufacturing, distribution and management of proprietary set top boxes.
Approved Documents no. 3 and 5 provide Tools to implement business models that do not require the establishment of proprietary (portions of) value-chains but rely in particular on an open market of Interoperable Devices. This is possible by giving the opportunity to
1. Service Providers to design their own DRM Tools that can be downloaded and executed in Interoperable Devices
2. Device Manufacturers to innovate their Devices for an open market.
In this walkthrough the following Users are assumed to exist:
|
User |
Perform |
|
A plurality of Broadcast Service Providers who |
· Offer a variety of Governed Content-based Services (e.g. subscription, pay per view, prepaid etc.) · Based on independently selected DRM Tools · Carried by a single service channel · Updated employing a single update mechanism; |
|
A plurality of Interoperable SAV Device Manufacturers |
Make Interoperable Devices |
|
A plurality of Devices Certification Agencies |
Certify Devices manufactured by Device Manufacturers |
|
A single smart card technology provider |
|
|
A plurality of End Users who |
1. Subscribe to and consume Services from Providers of their choice 2. Buy smart cards from smart card Providers 3. Buy Interoperable SAV Devices from Manufacturers of their choice 4. Use Governed Content as per Licence |
In this walkthrough the following specific Users play a role:
|
Type of User |
Name |
|
Device Manufacturer |
DM-A |
|
Device Certification Agency |
CA-B |
|
Content Service Provider |
SP-C |
|
Smart card Provider |
SP-D |
|
End User |
Keigo |
Note that the financial transactions enabling Keigo to Access and Use Content are outside of this walkthrough.
Preliminary steps required before Keigo can Access and Use Content:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
CA-B |
Certify |
Device |
DM-A’s SAVs, i.e. CA-B places a Certificate inside DM-A’s SAV |
|
AD #5 |
|
Keigo |
Buy |
Device |
DM-A’s SAV’s are Certified |
Out of scope |
|
|
Keigo |
Buy |
Smart card |
From SP-D |
Out of scope |
|
Note: In this and following walkthroughs the Licence is assumed to be unencrypted.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Keigo |
Select |
SP-C Service |
Out of all available Services |
Out of scope |
|
|
Keigo |
Access |
Content |
To obtain a subscription Licence from SP-C |
Access Content as Stream |
3.5.2 |
|
Keigo |
Select |
Content Item |
From SP-C’s Service |
Out of scope |
|
|
Keigo (SAV) |
Un-Package |
Content Item |
as Stream |
Package Content as Stream |
4.1.1 |
|
Keigo (SAV) |
Access |
Licence |
For every Governed Content Element |
Access Licence as Stream |
3.5.4 |
|
DRM Processor |
Instantiates |
DRM Tool |
By processing DRM Information |
Manage DRM Tool |
3.4.2 |
|
DRM Processor |
Access |
Key |
|
Access Key as Stream |
3.5.7 |
|
Keigo (SAV) |
Use |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
|
Keigo (SAV) |
Store |
DCF |
Stored as File with Licence Bundled within it |
Represent Content Identify Content Represent Licence Identify Licence Package Content |
2.1 2.5.1 2.10 2.5.2 4.1.1 |
In this walkthrough the steps made by two Users Keigo and Ken’ichi when Using Content received in walkthrough #1 (CI-E) are analysed. Ken’ichi uses a SAV Manufactured by Device Manufacturer DM-F Certified by Device Certification Agency CA-G.
The specific Users are:
|
Type of User |
Name |
|
Device Manufacturer |
DM-A |
|
Device Certification Agency |
CA-B |
|
Content Service Provider |
SP-C |
|
Smart card Provider |
SP-D |
|
Device Manufacturer |
DM-F |
|
Device Certification Agency |
CA-G |
|
End User |
Keigo |
|
End User |
Ken’ichi |
Preliminary steps required before Ken’ichi can Access and Use Content CI-E:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
CA-G |
Certify |
SAV |
DM-F’s SAVs, i.e. CA-G places a Certificate inside DM-F’s SAV |
|
AD #5 |
|
Ken’ichi |
Buy |
SAV |
DM-F’s SAV’s are Certified |
Out of scope |
|
|
Ken’ichi |
Buy |
smart card |
From SP-D |
Out of scope |
|
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Keigo |
Select |
Content Item |
Stored in Keigo’s SAV |
Out of scope |
|
|
Keigo (SAV) |
un-Package |
Content Item |
|
Package Content as File |
4.1.1 |
|
SAV |
Parse |
Licence |
|
Represent Licence |
2.10 |
|
Keigo (SAV) |
Use |
Content Item |
If Licence terms allow “Play Stored Content” 1. Then SAV Plays Stored Content Item 2. Else SAV displays message |
Represent Content Elements |
2. |
Keigo Copies/Moves Stored Content to Ken’ichi’s SAV.
As for “Keigo Plays Stored Content”. Ken’ichi’s SAV checks whether Licence terms allow “Play Stored Content in Ken’ichi’s SAV”.
Note: the PAV is an IDP-1 Device
Note: For reasons of simplicity SP-C performs the function of a Registration Agency
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Keigo (SAV) |
un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Keigo (SAV) |
Parse |
Licence |
If Licence does not permit creation of PAV-version of Stored Content Item then SAV displays message, else |
Represent Licence |
2.10 |
|
Keigo (SAV) |
Access |
Licence |
From SP-C Specifying PAV’s Certificate Containing Decryption Key K2 |
Access Licence as File |
3.5.3 |
|
DRM Processor |
Send |
Decrypted Resource Decryption Key |
To DRM Tool 1 |
Represent DRM message |
2.12 |
|
DRM Tool 1 |
Decrypt |
Resource |
Using Decrypted Resource Decryption Key |
Out of scope |
|
|
DRM Tool 2 |
Adapt |
Resources |
For the PAV |
Out of scope |
|
|
DRM Tool 3 |
Encrypt |
Adapted Resources |
DRM Tool 3 is the IDP-1 Encryption Tool with Key K2 |
Out of scope |
|
|
SAV |
Make |
Content Item |
With new Licence |
Represent Content |
2.1 |
|
SAV |
Move |
DCF |
To PAV |
None |
|
|
PAV |
Un-Package |
Content |
|
Package Content as File |
4.1.1 |
|
PAV |
Use |
DCI |
As per Licence terms |
Represent Content Item |
2. |
In the list below the differences with walkthrough #1 are marked in italic,
In this walkthrough the following Users are assumed to exist:
|
User |
Perform |
|
A plurality of Service Providers |
1) Offer a variety of Governed Content-based Services (e.g. subscription, pay per view, prepaid etc.) 2) Employ independently selected DRM Tools carried by a multiple service channel and DRM Tools updates implemented via multiple update mechanisms |
|
A plurality of Device Manufacturers |
Make Interoperable Devices |
|
A plurality of Device Certification Authorities |
Certify Devices manufactured by Device Manufacturers |
|
A plurality of smart card technology providers |
|
|
A plurality of End Users |
· Subscribe to Service Providers of their choice · Buy smart cards from trusted third parties · Buy Interoperable Devices from Manufacturers of their choice · Use Governed Content as per Licence · Access Content as files from other End Users via the network |
The specific Users are:
|
Type of User |
Name |
|
Device Manufacturer |
DM-A |
|
Device Certification Agency |
CA-B |
|
Content Service Provider |
SP-C |
|
Smart card Provider |
SP-D |
|
Tool Provider |
TP-E |
|
End User |
Choi |
Preliminary steps required before Choi can Access and Use Content:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
CA-B |
Certify |
SAV |
CA-B places a Certificate inside DM-A’s SAV |
|
AD #5 |
|
Choi |
Buy |
Device |
DM-A’s SAV’s are Certified |
Out of scope |
|
|
Choi |
Buy |
smart card |
From SP-D |
Out of scope |
|
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Choi |
Select |
SP-C Service |
Out of all available Services |
Out of scope |
|
|
Choi |
Access |
Content |
To obtain a subscription Licence from SP-C |
Access Content as Stream |
3.5.2 |
|
Choi |
Select |
Content Item |
From SP-C’s Service |
Out of scope |
|
|
Choi (SAV) |
Un-Package |
Content Item |
as Stream |
Package Content as Stream |
4.1.1 |
|
Choi (SAV) |
Access |
Licence |
For every Governed Content Element |
Access Licence as Stream |
3.5.4 |
|
Choi (SAV) |
Parse |
DRM Information |
To find the information regarding required DRM Tools in the DCI |
Represent Content |
2.1 |
|
Choi (SAV) |
Access |
DRM Tool |
Case 1: DRM Tool is in the DCI |
Access DRM Tool Body as Stream |
3.5.6 |
|
|
|
|
Case 2: DRM Tool is in the SAV |
Local DRM Tool Body Access |
3.5.9 |
|
|
|
|
Case 3: DRM Tool Body is Accessed from TP-A via the network |
Access DRM Tool Body as File |
3.5.5 |
|
DRM Processor |
Manage |
DRM Tool |
|
Manage DRM Tools |
3.4 |
|
DRM Processor |
Access |
Key |
|
Access Key as Stream |
3.5.7 |
|
Choi (SAV) |
Play |
Content Item |
As per Licence Terms |
Represent Content Elements |
2. |
|
SAV |
Store |
DCF |
Stores as a Content File with the Licence Bundled within it |
Package Content as File |
4.1.1 |
An example of Content Item describing an MPEG-2 program containing an audio and video stream governed by the Tool Pack technology is given below:
<?xml version="1.0" encoding="UTF-8"?>
<DIDL xmlns="urn:dmp:idp2:mpeg21:2002:02-DIDL-NS:2006:02" xmlns:dmp2rc="urn:dmp:idp2:Represent:Content:2006:02" xmlns:dmp2rl="urn:dmp:idp2:Represent:License:2006:02" xmlns:dmp1_dii="urn:dmp:idp1:mpeg21:2002:01-DII-NS:2005:04" xmlns:dmp2_ipmpdidl="urn:dmp:idp2:mpeg21:2004:01-IPMPDIDL-NS:2006:02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dmp2_ipmpinfo="urn:dmp:idp2:mpeg21:2004:01-IPMPINFO-NS:2006:02" xmlns:dmp2rdm="urn:dmp:idp2:Represent:DRMMessages:2006:02" xmlns:r="urn:dmp:idp1:mpeg21:2003:01-REL-R-NS:2005:04" xmlns:mx="urn:dmp:idp1:mpeg21:2003:01-REL-MX-NS:2005:04" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:mp7smp="urn:mpeg:mpeg7:smp:schema:2001" xmlns:dmp2rm="urn:dmp:idp2:Represent:Metadata:2006:02" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:dmp2_tva="urn:dmp:idp2:tva:metadata:2002:2006:02" xsi:schemaLocation="
urn:dmp:idp2:mpeg21:2002:02-DIDL-NS:2006:02 dmp2didl-2006-02.xsd">
<Container>
<Item id="Program1">
<Descriptor>
<Statement mimeType="text/plain">
<dmp1_dii:Identifier>Identifier of Program 1</dmp1_dii:Identifier>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2rc:DMPInformation>
<dmp2rc:Metadata>
<dmp2rc:StructuredData ref="urn:dmp:Represent:Metadata">
<dmp2rm:TVAMain>
<dmp2rm:ProgramDescription>
<dmp2rm:ProgramInformationTable>
<dmp2_tva:ProgramInformation programId="crid://foo.com/1234567">
<dmp2_tva:BasicDescription>
<dmp2_tva:Title><![CDATA[Around the World in 80 Treasures]]></dmp2_tva:Title>
<dmp2_tva:Synopsis length="short"><![CDATA[Dan Cruickshank visits India and Sri Lanka as he continues his search for the world's most beautiful and precious treasures. [S,SL]]]></dmp2_tva:Synopsis>
<dmp2_tva:Genre href="urn:dmp2_tva:metadata:cs:ContentCS:2002:3.1.5.3">
<dmp2_tva:Name><![CDATA[History]]></dmp2_tva:Name>
</dmp2_tva:Genre>
<dmp2_tva:Genre href="urn:dmp2_tva:metadata:cs:IntentionCS:2002:1.3">
<dmp2_tva:Name><![CDATA[EDUCATION]]></dmp2_tva:Name>
</dmp2_tva:Genre>
<dmp2_tva:Genre href="urn:dmp2_tva:metadata:cs:ContentCS:2002:3.1.4">
<dmp2_tva:Name><![CDATA[Arts & Media]]></dmp2_tva:Name>
</dmp2_tva:Genre>
<dmp2_tva:CaptionLanguage closed="true">EN-UK</dmp2_tva:CaptionLanguage>
<dmp2_tva:SignLanguage translation="true" type="BSL">EN-UK</dmp2_tva:SignLanguage>
</dmp2_tva:BasicDescription>
<dmp2_tva:AVAttributes>
<dmp2_tva:AudioAttributes>
<dmp2_tva:NumOfChannels>2</dmp2_tva:NumOfChannels>
</dmp2_tva:AudioAttributes>
<dmp2_tva:VideoAttributes>
<dmp2_tva:AspectRatio>16:9</dmp2_tva:AspectRatio>
</dmp2_tva:VideoAttributes>
</dmp2_tva:AVAttributes>
<dmp2_tva:MemberOf xsi:type="dmp2_tva:MemberOfType" crid="crid://foo.com/__SERAroundtheWorldin80Treasures"/>
</dmp2_tva:ProgramInformation>
</dmp2rm:ProgramInformationTable>
</dmp2rm:ProgramDescription>
</dmp2rm:TVAMain>
</dmp2rc:StructuredData>
</dmp2rc:Metadata>
</dmp2rc:DMPInformation>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2_ipmpinfo:IPMPGeneralInfoDescriptor>
<dmp2_ipmpinfo:ToolList>
<dmp2_ipmpinfo:ToolDescription localID="TPABCDEF9">
<dmp2_ipmpinfo:IPMPToolID>urn:ETRI:ToolPack:ToolID:ABCDEF9</dmp2_ipmpinfo:IPMPToolID>
</dmp2_ipmpinfo:ToolDescription>
</dmp2_ipmpinfo:ToolList>
</dmp2_ipmpinfo:IPMPGeneralInfoDescriptor>
</Statement>
</Descriptor>
<Component>
<Resource mimeType="application/mp21-ipmp">
<dmp2_ipmpdidl:ProtectedAsset mimeType="video/MP2P">
<dmp2_ipmpdidl:Identifier>urn:mpegRA:mpeg21:dmp1_dii:isan:006A-15FA-002B-C95F-B</dmp2_ipmpdidl:Identifier>
<dmp2_ipmpdidl:Info>
<dmp2_ipmpinfo:IPMPInfoDescriptor>
<dmp2_ipmpinfo:Tool>
<dmp2_ipmpinfo:ToolBaseDescription>
<dmp2_ipmpinfo:IPMPToolID>urn:ETRI:ToolPack:ToolID:ABCDEF9</dmp2_ipmpinfo:IPMPToolID>
<dmp2_ipmpinfo:Remote ref="http:\\www.ETRIToolPacks.com\ToolID:ABCDEF9"/>
<dmp2_ipmpinfo:ConfigurationSettings>
<dmp2_ipmpinfo:Update>
<dmp2_ipmpinfo:Location ref="http:\\www.ETRIToolPacks.com\ToolPackUpdate"/>
<dmp2_ipmpinfo:Condition>
<dmp2_ipmpinfo:ScheduledUpdateTime periodic="P1D">2005-03-07T00:00:00
</dmp2_ipmpinfo:ScheduledUpdateTime>
</dmp2_ipmpinfo:Condition>
</dmp2_ipmpinfo:Update>
</dmp2_ipmpinfo:ConfigurationSettings>
</dmp2_ipmpinfo:ToolBaseDescription>
<dmp2_ipmpinfo:InitializationSettings>
<dmp2_ipmpinfo:InitializationData>
<dmp2rdm:AddToolNotificationListener>
<dmp2rdm:dataID>98765</dmp2rdm:dataID>
<dmp2rdm:scope>00</dmp2rdm:scope>
<dmp2rdm:EventType>02</dmp2rdm:EventType>
</dmp2rdm:AddToolNotificationListener>
</dmp2_ipmpinfo:InitializationData>
</dmp2_ipmpinfo:InitializationSettings>
<dmp2_ipmpinfo:RightsDescriptor>
<dmp2_ipmpinfo:LicenseService>http://www.DRMTools.org/LicenseService.php</dmp2_ipmpinfo:LicenseService>
</dmp2_ipmpinfo:RightsDescriptor>
</dmp2_ipmpinfo:Tool>
<dmp2_ipmpinfo:RightsDescriptor>
<dmp2_ipmpinfo:License>
<dmp2rl:License>
<r:license licenseId="012345">
<r:grant>
<r:keyHolder>
<r:info>
<dsig:KeyName>Device A's certificate or Identifier</dsig:KeyName>
</r:info>
</r:keyHolder>
<mx:play/>
<r:digitalResource>
<r:nonSecureIndirect URI="Identifier of Program 1"/>
</r:digitalResource>
</r:grant>
<r:issuer>
<r:keyHolder>
<r:info>
<dsig:KeyName>The Public Key Name of Program 1's Owner</dsig:KeyName>
</r:info>
</r:keyHolder>
</r:issuer>
</r:license>
</dmp2rl:License>
</dmp2_ipmpinfo:License>
</dmp2_ipmpinfo:RightsDescriptor>
</dmp2_ipmpinfo:IPMPInfoDescriptor>
</dmp2_ipmpdidl:Info>
<dmp2_ipmpdidl:Contents ref="myserver.com/asset.mpgencoded"/>
</dmp2_ipmpdidl:ProtectedAsset>
</Resource>
</Component>
<Item id="AudioStream1">
<Descriptor>
<Statement mimeType="text/xml">
<dmp1_dii:Identifier>urn:mpegRA:mpeg21:dmp1_dii:isrc:US-ZO3-99-32476</dmp1_dii:Identifier>
<!-- ISRC identifying the sound recording -->
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp1_dii:RelatedIdentifier>urn:mpegRA:mpeg21:dmp1_dii:iswc:T-034.524.680-1</dmp1_dii:RelatedIdentifier>
<!-- ISWC identifying the underlying musical work -->
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2rc:DMPInformation>
<dmp2rc:Metadata>
<!-- Metadata related to this Content Item is Governed now -->
<dmp2_ipmpdidl:Info>
<dmp2_ipmpinfo:IPMPInfoDescriptor/>
</dmp2_ipmpdidl:Info>
<dmp2_ipmpdidl:Contents>01234567890ABCDEF</dmp2_ipmpdidl:Contents>
<!-- Insert the Governed - obfuscated metadata in element below -->
</dmp2rc:Metadata>
</dmp2rc:DMPInformation>
</Statement>
</Descriptor>
<Component>
<Resource ref="110xxxxx" mimeType="audio/mpeg"/>
<!-- Audio streams are identified by a stream ID like the one above -->
</Component>
</Item>
<Item id="VideoStream1">
<Descriptor>
<Statement mimeType="text/xml">
<dmp1_dii:Identifier>urn:mpegRA:mpeg21:dmp1_dii:isan:006A-15FA-002B-B012-A</dmp1_dii:Identifier>
</Statement>
</Descriptor>
<Descriptor>
<Statement mimeType="text/xml">
<dmp2rc:DMPInformation>
<dmp2rc:Metadata>
<dmp2rc:StructuredData ref="urn:mpeg:mpeg7:schema:2001">
<!-- MPEG-7 SMP metadata describing the movie-->
</dmp2rc:StructuredData>
</dmp2rc:Metadata>
</dmp2rc:DMPInformation>
</Statement>
</Descriptor>
<Component>
<Resource ref="1110xxxx" mimeType="video/mpeg"/>
<!-- Video streams are identified by a stream ID like the one above -->
</Component>
</Item>
</Item>
</Container>
</DIDL>
Figure 206 – An example Content Item
In this walkthrough the steps made by Users Choi and Joo when Using Content received in walkthrough #3 (CI-E) are analysed.
The specific Users are:
|
Type of User |
Name |
|
Device Manufacturer |
DM-A |
|
Device Certification Agency |
CA-B |
|
Content Service Provider |
SP-C |
|
Smart cards Provider |
SP-D |
|
Tool Provider |
TP-F |
|
Device Manufacturer |
DM-G |
|
Device Certification Agency |
CA-H |
|
Smart cards Provider |
SP-I |
|
Tool Provider |
TP-J |
|
End User |
Choi |
|
End User |
Joo |
Preliminary steps required before Joo can Access and Use Content:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
CA-H |
Certify |
SAV |
CA-H places a Certificate inside DM-G’s SAV |
|
AD #5 |
|
Joo |
Buy |
SAV |
DM-G’s SAV’s are Certified |
Out of scope |
|
|
Joo |
Buy |
smart card |
From SP-I |
Out of scope |
|
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Choi |
Select |
Content Item |
|
Out of scope |
|
|
Choi (SAV) |
Un- Package |
DCF |
|
Package Content as File |
4.1.1 |
|
Choi (SAV) |
Parse |
DCI |
|
Represent Content |
2.1 |
|
Choi (SAV) |
Parse |
Licence |
If Licence terms does not allow “Play Stored Content” display message |
Represent Licence |
2.10 |
|
SAV |
Play |
Content |
Else Play Stored Content in Choi’s SAV |
Represent Content Elements |
2. |
To Play Content Copied/Moved by Choi to his SAV Joo performs the following:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Joo |
Select |
Content Item |
|
Out of scope |
|
|
Joo (SAV) |
Un- Package |
DCF |
|
Package Content as File |
4.1.1 |
|
Joo (SAV) |
Parse |
DCI |
|
Represent Content |
2.1 |
|
Joo (SAV) |
Parse |
Licence |
If Licence terms do not allow “Play Stored Content in Joo’s Device” display message |
Process: Parse Licence |
|
|
Joo (SAV) |
Parse |
DRM Information |
To find the information regarding required DRM Tools in the DCI |
Represent Content |
2.1 |
|
Joo (SAV) |
Access |
DRM Tool |
Case 1: DRM Tool is in the DCI |
Access DRM Tool Body as Stream |
3.5.6 |
|
|
|
|
Case 2: DRM Tool is in the SAV |
Local DRM Tool Body Access |
3.5.9 |
|
|
|
|
Case 3: DRM Tool Body is Accessed from TP-A via the network |
Access DRM Tool Body as File |
3.5.5 |
|
DRM Processor |
Manage |
DRM Tool |
|
Manage DRM Tools |
3.4 |
|
Joo (SAV) |
Play |
Content Item |
As per Licence terms |
Represent Content Elements |
2. |
This Use Case describes how Broadcaster GreatGreenNetworks (GGN) is facing the new phase of broadcasting by offering a broad variety of programs with multiple Licences.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
This example shows a simple Licence instance using DMP REL with a grant described in the table below.
Table 28 – Licence example 1
|
Item |
Example of conditions |
|
Principal |
· Device A identified as DE0001 |
|
Right |
· Immediate Play only without buffering |
|
Resource |
7. urn:uci:ETRI-10357 with CEK |
|
Condition |
· 2 times play only |
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-1000:DO-0001</m1x:idSystem>
<m1x:idValue>DE0001</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<m1x:protectedResource>
<digitalResource>
<nonSecureIndirect URI="urn:uci:ETRI-10357"/>
</digitalResource>
<xenc:EncryptedKey>
<xenc:CipherData>
<xenc:CipherValue> ujnDATAPgvq5dPDvTGPPhJIpqnSieHWK2BEn2JYi2AgiTWtTqSsCIqg/76hHCmzSHAXrFaqTl/Zi3LtbXoCV MoDXgMFkUGIWVyLGDFmq5VxyOwzYM/WMWCEMF1qIUtKW62chDiPaEOfY6dPFyHxtUi4wXMpd3TcIYwV/QTQDMDg=
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
</m1x:protectedResource>
<allConditions>
<m2x:timeShiftDuration>
<m2x:duration>PT0S</m2x:duration>
</m2x:timeShiftDuration>
<sx:exerciseLimit>
<sx:count>2</sx:count>
</sx:exerciseLimit>
</allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Issuer's signing key</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 207 – Licence example 1
This example shows an elaborate Licence instance using DMP REL with a grant described in the table below.
Table 29 – Licence example 2
|
Item |
Example of conditions |
|
Principal |
· Device A identified as DE0001 |
|
Right |
· Play only with buffering and additional functions |
|
Resource |
1. urn:uci:ETRI-10357 with CEK |
|
Condition |
· Available for 10 days and 12 hours after receiving the Licence · Available only within KOREA · Allow to be displayed at other devices within the same domain where the device A is joined · Does not allow to be accessed by more than 3 SAV devices at the same time |
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-1000:DO-0001</m1x:idSystem>
<m1x:idValue>DE0001</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<m1x:protectedResource>
<digitalResource>
<nonSecureIndirect URI="urn:uci:ETRI-10357"/>
</digitalResource>
<xenc:EncryptedKey>
<xenc:CipherData>
<xenc:CipherValue> ujnDATAPgvq5dPDvTGPPhJIpqnSieHWK2BEn2JYi2AgiTWtTqSsCIqg/76hHCmzSHAXrFaqTl/Zi3LtbXoCV MoDXgMFkUGIWVyLGDFmq5VxyOwzYM/WMWCEMF1qIUtKW62chDiPaEOfY6dPFyHxtUi4wXMpd3TcIYwV/QTQDMDg=
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
</m1x:protectedResource>
<allConditions>
<sx:validityIntervalFloating>
<sx:duration>P10DT12H</sx:duration>
</sx:validityIntervalFloating>
<sx:territory>
<sx:location>
<sx:country>KR</sx:country>
</sx:location>
</sx:territory>
<m2x:destinationPrincipal>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-1000</m1x:idSystem>
<m1x:idValue>DO0001</m1x:idValue>
</m1x:identityHolder>
</m2x:destinationPrincipal>
<m2x:simultaneousAccess>
<m2x:count>3</m2x:count>
</m2x:simultaneousAccess>
</allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Issuer's signing key</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 208 – Licence example 2
This example shows you an ‘export’ Licence instance using DMP REL with a grant described in the table below.
Table 30 – Licence example 3
|
Item |
Example of conditions |
|
Principal |
· Domain A identified as DO0001 |
|
Right |
· Export except standard definition analog output |
|
Resource |
8. urn:uci:ETRI-10357 with CEK |
|
Condition |
· Available only 1 time · Target device should be device A identified as DE0001 |
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-1000</m1x:idSystem>
<m1x:idValue>DO0001</m1x:idValue>
</m1x:identityHolder>
<m2x:export/>
<m1x:protectedResource licensePartId="protectedResource1">
<digitalResource>
<nonSecureIndirect URI="urn:uci:ETRI-10357"/>
</digitalResource>
<xenc:EncryptedKey>
<xenc:CipherData>
<xenc:CipherValue> ujnDATAPgvq5dPDvTGPPhJIpqnSieHWK2BEn2JYi2AgiTWtTqSsCIqg/76hHCmzSHAXrFaqTl/Zi3LtbXoCV MoDXgMFkUGIWVyLGDFmq5VxyOwzYM/WMWCEMF1qIUtKW62chDiPaEOfY6dPFyHxtUi4wXMpd3TcIYwV/QTQDMDg=
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
</m1x:protectedResource>
<allConditions>
<m1x:outputRegulation licensePartId="outputRegulation1">
<m1x:regulation qualityOfSignal="analog" typeOfSignal="SD"/>
</m1x:outputRegulation>
<m2x:destinationPrincipal>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-1000:DO-0001</m1x:idSystem>
<m1x:idValue>DE0001</m1x:idValue>
</m1x:identityHolder>
</m2x:destinationPrincipal>
<sx:exerciseLimit>
<sx:count>1</sx:count>
</sx:exerciseLimit>
</allConditions>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="domainA"/>
<m2x:export/>
<m1x:protectedResource licensePartIdRef="protectedResource1"/>
<allConditions>
<m1x:outputRegulation licensePartIdRef="outputRegulation1"/>
<m2x:destinationPrincipal>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-1000:DO-0001</m1x:idSystem>
<m1x:idValue>DE0002</m1x:idValue>
</m1x:identityHolder>
</m2x:destinationPrincipal>
<sx:exerciseLimit>
<sx:count>1</sx:count>
</sx:exerciseLimit>
</allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Issuer's signing key</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 209 – Licence example 3
This example shows you a ‘write’ Licence instance using DMP REL with a grant described in the table below.
Table 31 – Licence example 4
|
Item |
Example of conditions |
|
Principal |
· Device A identified as DE0001 |
|
Right |
· Store |
|
Resource |
9. urn:uci:ETRI-10357 with CEK |
|
Condition |
1) Available only 2 times 2) Target storage should be within the same domain where device A is a member. · Device A has security level 3 in the DMP security system or above · Scrambling using AES encryption algorithm is needed while storing |
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-1000:DO0001</m1x:idSystem>
<m1x:idValue>DE0001</m1x:idValue>
</m1x:identityHolder>
<m1x:governedCopy/>
<m1x:protectedResource>
<digitalResource>
<nonSecureIndirect URI="urn:uci:ETRI-10357"/>
</digitalResource>
<xenc:EncryptedKey>
<xenc:CipherData>
<xenc:CipherValue> ujnDATAPgvq5dPDvTGPPhJIpqnSieHWK2BEn2JYi2AgiTWtTqSsCIqg/76hHCmzSHAXrFaqTl/Zi3LtbXoCV MoDXgMFkUGIWVyLGDFmq5VxyOwzYM/WMWCEMF1qIUtKW62chDiPaEOfY6dPFyHxtUi4wXMpd3TcIYwV/QTQDMDg=
</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedKey>
</m1x:protectedResource>
<allConditions>
<m2x:scrambling cipherType="AES"/>
<sx:exerciseLimit>
<sx:count>2</sx:count>
</sx:exerciseLimit>
<m2x:destinationPrincipal>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-1000</m1x:idSystem>
<m1x:idValue>DO0001</m1x:idValue>
</m1x:identityHolder>
</m2x:destinationPrincipal>
<m2x:securitySystem>
<m2x:identifier>DMP</m2x:identifier>
<m2x:level>3</m2x:level>
</m2x:securitySystem>
</allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Issuer's signing key</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 210 – Licence example 4
There is a need to describe what must be represented with the REL
· In the broadcast channel
· Use in Device and Domain
· Play Content
· Store Content
· Play Stored Content
· Use Stored Content at various levels of granularity, e.g. abstract/digest Content using appropriate Metadata
· Move or Copy Stored Content to another SAV.
· Adapt Content
· Move or Copy Adapted Content to a PAV
· Export Stored Content e.g. to a removable media
with a number of conditions
|
Items |
Example of conditions |
|
Validity period |
· Viewing period (start and end date) · Total viewing time |
|
Playback |
· Number of times · Allowed playback mode (e.g. Fast forward & rewind, Variable playback speed, Sequenced still image display) |
|
Domain management |
10. Domain identification 11. Number of users 12. Permission for transfer of Licence |
|
Output |
· Analogue and digital output · Allowed target devices |
In this example, Kim’s DTV is granted the right to play the stated broadcast news with right and conditions like below. Kim has a DTV with DVR which is a member of a digital home domain A and its identifier is BSI:2232111123.
· Play is only allowed within domain A.
· time-shift-operation
· required security level : at least 3 in DMP security system
· valid interval : from 2005/7/25 to 2005/7/29
· geographical limitation : only available within Seoul, Korea
· simultaneous access count : 5
· extendRights : when Licence becomes invalid, update or extend Licence through http://www.foo.org/extendLiceseService
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder licensePartId="domainA">
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>BSI:2232111123</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<digitalResource licensePartId="news">
<nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</digitalResource>
<allConditions>
<m2x:securitySystem>
<m2x:identifier>DMP</m2x:identifier>
<m2x:level>3</m2x:level>
</m2x:securitySystem>
<m2x:simultaneousAccess>
<m2x:count>5</m2x:count>
</m2x:simultaneousAccess>
<validityInterval>
<notBefore>2005-07-25T00:00:00</notBefore>
<notAfter>2005-07-29T00:00:00</notAfter>
</validityInterval>
<sx:territory>
<sx:location>
<sx:country>KR</sx:country>
<sx:region>SEOUL</sx:region>
</sx:location>
</sx:territory>
</allConditions>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="domainA"/>
<m2x:extendRights>
<m1x:serviceLocation>
<m1x:url>http://www.foo.org/extendLiceseService</m1x:url>
</m1x:serviceLocation>
</m2x:extendRights>
<digitalResource licensePartIdRef="news"/>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 211 – Licence example 5
The rights issuer sends Kim a Licence that allows him to store and export specified broadcast news while it is transferring under the following conditions:
1. Play is only allowed within domain A whose identifier is BSI:2232111123
2. Store into the storage with scrambling
3. Export through HD-analog output in the form of Constrained Image.
4. Export through all analog output in the form of Analog Protection according to Type 1 of APS
5. Export through the HD digital output in which DTCP protection method is used.
6. All export is only allowed when the target entity is device A or within domain D.
7. All export is only allowed when the security level in the DMP security system of target entity is at least 5
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder licensePartId="domainA">
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>BSI:2232111123</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<digitalResource licensePartId="news">
<r:nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</digitalResource>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="domainA"/>
<m1x:governedCopy/>
<digitalResource licensePartIdRef="news"/>
<m2x:scrambling/>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="domainA"/>
<m2x:export/>
<digitalResource licensePartIdRef="news"/>
<allConditions>
<m1x:outputRegulation licensePartId="outputRegulation1">
<m1x:regulation typeOfSignal="analog" qualityOfSignal="HD">ICT:1</m1x:regulation>
<m1x:regulation typeOfSignal="analog">APSTB:01</m1x:regulation>
<m1x:regulation typeOfSignal="digital" qualityOfSignal="HD">DTCP</m1x:regulation>
</m1x:outputRegulation>
<m2x:destinationPrincipal>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000:DO-00001</m1x:idSystem>
<m1x:idValue>DE_DeviceA</m1x:idValue>
</m1x:identityHolder>
</m2x:destinationPrincipal>
<m2x:destinationCondition licensePartId="destinationCondition1">
<m2x:securitySystem>
<m2x:identifier>DMP</m2x:identifier>
<m2x:level>5</m2x:level>
</m2x:securitySystem>
</m2x:destinationCondition>
</allConditions>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="domainA"/>
<m2x:export/>
<digitalResource licensePartIdRef="news"/>
<allConditions>
<m1x:outputRegulation licensePartIdRef="outputRegulation1"/>
<m2x:destinationPrincipal>
<m1x:identityHolder>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>DO_DomainD</m1x:idValue>
</m1x:identityHolder>
</m2x:destinationPrincipal>
<m2x:destinationCondition licensePartIdRef="destinationCondition1"/>
</allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 212 – Licence example 6
A rights issuer sends Kim a Licence that allows her copy the specified broadcast news after it is stored under the following conditions
Following example shows the Licence has copy-once rights. This broadcast program is allowed copy once with bpx:governedCopy condition.
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder licensePartId="domainA">
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>BSI:2232111123</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<digitalResource licensePartId="news">
<r:nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</digitalResource>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="domainA"/>
<m1x:governedCopy governanceRule="acme:CopyOnce"/>
<r:digitalResource licensePartIdRef="news"/>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 213 – Licence example 7
Once this broadcast program is copied to other device, new copied Licence may be shown like following.
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder licensePartId="domainA">
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>BSI:2232111123</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<digitalResource licensePartId="news">
<r:nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</digitalResource>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>Rights Issuer Public Key Name</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 214 – Licence example 8
The TV Anytime Forum has developed specifications with a native Rights Expression language called RMPI. In this Use Case it is assumed that broadcasting is effected using RMPI but that once Content is received by the SAV it is Imported as a file and Stored.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
The following example shows a possible combination of rights granted to a given piece of content broadcast free-to-air:
1. Content is not scrambled and will remain unscrambled after domain acquisition.
2. No possibility is granted to acquire new rights.
3. In the receiving domain, Play, Analogue Export, Digital Export (both HD and SD) are granted. Proximity Control is the only restriction that applies. Required security level in the TVA security system is the lowest.
4. Only Play, Analogue Export are granted in any other domain. No Proximity Control applies but Geographic Control (only Germany) does. A medium security level in the TVA security system is required to enforce that restriction.
<?xml version="1.0" encoding="UTF-8"?>
<TVAMain xmlns="urn:tva:metadata:2005"
xmlns:tva2="urn:tva:metadata:extended:2005"
xmlns:tva="urn:tva:metadata:2005"
xmlns:rmpi="urn:tva:rmpi:2005"
xmlns:mpeg21="urn:tva:mpeg21:2005" xmlns:mpeg7="urn:tva:mpeg7:2005"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:tva:metadata:extended:2005 tva2_metadata_3-3_v111.xsd"
xsi:type="tva2:ExtendedTVAMainType">
<tva2:RMPITable xml:lang="en-us">
<tva2:RMPIDescription RMPIDescriptionId="String">
<rmpi:AncillaryRMPI>
<rmpi:RMPITypeFlag>RMPI-MB</rmpi:RMPITypeFlag>
<rmpi:VersionOfRMPI>0</rmpi:VersionOfRMPI>
<rmpi:OriginOfRMPI>FTABroadcasterDE</rmpi:OriginOfRMPI>
<rmpi:Cipher>no cipher</rmpi:Cipher>
<rmpi:MBScramblingControl>maintain</rmpi:MBScramblingControl>
</rmpi:AncillaryRMPI>
<rmpi:ExtendRights>
<rmpi:ExtendRightsFlagNotGranted/>
</rmpi:ExtendRights>
<rmpi:ReceivingDomainRights>
<rmpi:PlayRightFlag>granted</rmpi:PlayRightFlag>
<rmpi:AnalogueExportRight>
<rmpi:AnalogueExportRightFlagGranted/>
</rmpi:AnalogueExportRight>
<rmpi:DigitalExportSDRight>
<rmpi:DigitalExportRightFlagGranted/>
</rmpi:DigitalExportSDRight>
<rmpi:DigitalExportHDRight>
<rmpi:DigitalExportRightFlagGranted/>
</rmpi:DigitalExportHDRight>
<rmpi:SecurityLevel>level 0</rmpi:SecurityLevel>
<rmpi:GeographicalControl>Any</rmpi:GeographicalControl>
<rmpi:PhysicalProximityFlag/>
</rmpi:ReceivingDomainRights>
<rmpi:AnyDomainRights>
<rmpi:PlayRightFlag/>
<rmpi:AnalogueExportRight>
<rmpi:AnalogueExportRightFlagGranted/>
</rmpi:AnalogueExportRight>
<rmpi:SecurityLevel>level 1</rmpi:SecurityLevel>
<rmpi:GeographicalControl>Germany</rmpi:GeographicalControl>
</rmpi:AnyDomainRights>
</tva2:RMPIDescription>
</tva2:RMPITable>
</TVAMain>
Figure 215 –
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder licensePartId="domainID">
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>DO12345</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<digitalResource licensePartId="news">
<nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</digitalResource>
<allConditions licensePartId="ReceivingDomainCondition">
<m2x:destinationPrincipal>
<m1x:identityHolder licensePartIdRef="domainID"/>
</m2x:destinationPrincipal>
<m2x:securitySystem>
<m2x:identifier>RMPI</m2x:identifier>
<m2x:level>0</m2x:level>
</m2x:securitySystem>
<m2x:proximity/>
</allConditions>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="domainID"/>
<m2x:export/>
<digitalResource licensePartIdRef="news"/>
<allConditions licensePartIdRef="ReceivingDomainCondition"/>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="domainID"/>
<m1x:governedCopy/>
<digitalResource licensePartIdRef="news"/>
<allConditions licensePartIdRef="ReceivingDomainCondition"/>
</grant>
<grant>
<mx:play/>
<digitalResource licensePartId="news">
<nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</digitalResource>
<allConditions licensePartId="AnyDomainCondition">
<m2x:securitySystem licensePartId="AnyDomainSecuritySystemCondition">
<m2x:identifier>RMPI</m2x:identifier>
<m2x:level>1</m2x:level>
</m2x:securitySystem>
<sx:territory licensePartId="AnyDomainTerritoryCondition">
<sx:location>
<sx:country>Germany</sx:country>
</sx:location>
</sx:territory>
</allConditions>
</grant>
<grant>
<m2x:export/>
<digitalResource licensePartIdRef="news"/>
<allConditions>
<m2x:securitySystem licensePartIdRef="AnyDomainSecuritySystemCondition"/>
<sx:territory licensePartId="AnyDomainTerritoryCondition"/>
<m1x:outputRegulation>
<m1x:regulation typeOfSignal="digital"/>
</m1x:outputRegulation>
</allConditions>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>FTABroadcasterDE</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 216 –
The following example shows a possible combination of rights granted to a given piece of content broadcast e.g. by a Pay-TV operator, where:
· Content has to be re-scrambled using AES when acquired in the domain
· Possibility to acquire new rights is granted. The Pay-TV operator will grant these rights.
· In the receiving domain, Play Right is granted with ability to trick play the content. Content can be exported to analogue or digital (both HD and SD) outputs but only for immediate viewing. A high security level in the TVA security system is required.
· No rights is granted to other domains
<?xml version="1.0" encoding="UTF-8"?>
<TVAMain xmlns="urn:tva:metadata:2005"
xmlns:tva2="urn:tva:metadata:extended:2005"
xmlns:tva="urn:tva:metadata:2005"
xmlns:rmpi="urn:tva:rmpi:2005"
xmlns:mpeg21="urn:tva:mpeg21:2005" xmlns:mpeg7="urn:tva:mpeg7:2005"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:tva:metadata:extended:2005 tva2_metadata_3-3_v111.xsd"
xsi:type="tva2:ExtendedTVAMainType">
<tva2:RMPITable xml:lang="en-us">
<tva2:RMPIDescription RMPIDescriptionId="String">
<rmpi:AncillaryRMPI>
<rmpi:RMPITypeFlag>RMPI-MB</rmpi:RMPITypeFlag>
<rmpi:VersionOfRMPI>5</rmpi:VersionOfRMPI>
<rmpi:OriginOfRMPI>FTABroadcasterDE</rmpi:OriginOfRMPI>
<rmpi:Cipher>AES</rmpi:Cipher>
<rmpi:MBScramblingControl>change</rmpi:MBScramblingControl>
</rmpi:AncillaryRMPI>
<rmpi:ExtendRights>
<rmpi:ExtendRightsFlagGranted/>
</rmpi:ExtendRights>
<rmpi:ReceivingDomainRights>
<rmpi:PlayRightFlag/>
<rmpi:AnalogueExportRight>
<rmpi:AnalogueExportRightFlagGranted/>
</rmpi:AnalogueExportRight>
<rmpi:DigitalExportSDRight>
<rmpi:DigitalExportRightFlagGranted/>
</rmpi:DigitalExportSDRight>
<rmpi:DigitalExportHDRight>
<rmpi:DigitalExportRightFlagGranted/>
</rmpi:DigitalExportHDRight>
<rmpi:SecurityLevel>level 3</rmpi:SecurityLevel>
<rmpi:GeographicalControl>Any</rmpi:GeographicalControl>
<rmpi:PhysicalProximityFlag>controlled</rmpi:PhysicalProximityFlag>
<rmpi:BufferDuration>buffered</rmpi: BufferDuration>
</rmpi:ReceivingDomainRights>
<rmpi:AnyDomainRights>
<rmpi:PlayRightNotFlag>not granted</rmpi:PlayRightFlag>
<rmpi:AnalogueExportRight>
<rmpi:AnalogueExportRightFlagNotGranted/>
</rmpi:AnalogueExportRight>
<rmpi:DigitalExportSDRight>
<rmpi:DigitalExportRightFlagNotGranted/>
</rmpi:DigitalExportSDRight>
<rmpi:DigitalExportHDRight>
<rmpi:DigitalExportRightFlagNotGranted/>
</rmpi:DigitalExportHDRight>
<rmpi:SecurityLevel>N/A</rmpi:SecurityLevel>
<rmpi:GeographicalControl>N/A</rmpi:GeographicalControl>
</rmpi:AnyDomainRights>
</tva2:RMPIDescription>
</tva2:RMPITable>
</TVAMain>
Figure 217 –
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder licensePartId="ReceivingDomain">
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>DO12345</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<m1x:protectedResource licensePartId="news">
<digitalResource>
<nonSecureIndirect URI="urn:uci:ETRI-10357"/>
</digitalResource>
<xenc:EncryptedData>
<xenc:EncryptionMethod Algorithm="AES"/>
<xenc:CipherData>
<xenc:CipherReference URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</xenc:CipherData>
</xenc:EncryptedData>
</m1x:protectedResource>
<allConditions licensePartId="ReceivingDomainCondition">
<m2x:timeShiftDuration>
<m2x:duration>PT0S</m2x:duration>
</m2x:timeShiftDuration>
<m2x:securitySystem licensePartIdRef="ReceivingDomainSecuritySystemCondition">
<m2x:identifier>TVA</m2x:identifier>
<m2x:level>3</m2x:level>
</m2x:securitySystem>
</allConditions>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="ReceivingDomain"/>
<m2x:export/>
<digitalResource licensePartIdRef="news"/>
<allConditions licensePartIdRef="ReceivingDomainCondition"/>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="ReceivingDomain"/>
<m2x:extendRights>
<m1x:serviceLocation>
<m1x:url>http://www.paytv.com/extendLiceseService</m1x:url>
</m1x:serviceLocation>
</m2x:extendRights>
<digitalResource licensePartIdRef="news"/>
<m2x:securitySystem licensePartIdRef="ReceivingDomainSecuritySystemCondition"/>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>FTABroadcasterDE</dsig:KeyName>
</info>
</keyHolder>
</issuer>
</license>
Figure 218 –
The following example shows a possible combination of rights granted to a given piece of content provided by a content provider using DRM technology, where:
· Content is scrambled using Camellia and needs not to be re-scrambled when acquired in the domain
· Possibility to acquire new rights is granted. An URL is given for that purpose.
· In the receiving domain, Play Right is granted for two days. Only one copy of the content can be made within these two days and this copy is usable by one single device. Content can be exported only to HD digital output and only for immediate viewing. Content can only be redistributed in the proximity of the receiving domain and within Japan. The highest security level is required.
· No rights is granted to other domains
<?xml version="1.0" encoding="UTF-8"?>
<TVAMain xmlns="urn:tva:metadata:2005"
xmlns:tva2="urn:tva:metadata:extended:2005"
xmlns:tva="urn:tva:metadata:2005"
xmlns:rmpi="urn:tva:rmpi:2005"
xmlns:mpeg21="urn:tva:mpeg21:2005" xmlns:mpeg7="urn:tva:mpeg7:2005"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:tva:metadata:extended:2005 tva2_metadata_3-3_v111.xsd"
xsi:type="tva2:ExtendedTVAMainType">
<tva2:RMPITable xml:lang="en-us">
<tva2:RMPIDescription RMPIDescriptionId="String">
<rmpi:AncillaryRMPI>
<rmpi:RMPITypeFlag>RMPI-MB</rmpi:RMPITypeFlag>
<rmpi:VersionOfRMPI>0</rmpi:VersionOfRMPI>
<rmpi:OriginOfRMPI>FTABroadcasterDE</rmpi:OriginOfRMPI>
<rmpi:Cipher>Camellia</rmpi:Cipher>
<rmpi:MBScramblingControl>maintain</rmpi:MBScramblingControl>
</rmpi:AncillaryRMPI>
<rmpi:ExtendRights>
<rmpi:ExtendRightsFlagGranted>http://www.vod.com/extendLiceseService</rmpi: ExtendRightsFlagGranted>
</rmpi:ExtendRights>
<rmpi:ReceivingDomainRights>
<rmpi:PlayRightFlag/>
<rmpi:AnalogueExportRight>
<rmpi:AnalogueExportRightFlagNotGranted/>
</rmpi:AnalogueExportRight>
<rmpi:DigitalExportSDRight>
<rmpi:DigitalExportRightFlagNotGranted/>
</rmpi:DigitalExportSDRight>
<rmpi:DigitalExportHDRight>
<rmpi:DigitalExportRightFlagNotGranted/>
</rmpi:DigitalExportHDRight>
<rmpi:SecurityLevel>level 3</rmpi:SecurityLevel>
<rmpi:TimeWindow>
<rmpi:StartDate>
<rmpi:TimePoint>2005-10-05T12:00:00</rmpi:TimePoint>
</rmpi:StartDate>
<rmpi:EndDate>
<rmpi:TimePoint>2005-10-07T12:00:00</rmpi:TimePoint>
</rmpi:EndDate>
</rmpi:TimeWindow>
<rmpi:GeographicalControl>Japan</rmpi:GeographicalControl>
<rmpi:PhysicalProximityFlag/>
<rmpi:BufferDuration>immediate</rmpi:BufferDuration>
</rmpi:ReceivingDomainRights>
<rmpi:AnyDomainRights>
<rmpi:PlayRightFlag>not granted</rmpi:PlayRightFlag>
<rmpi:AnalogueExportRight>
<rmpi:AnalogueExportRightFlagNotGranted/>
</rmpi:AnalogueExportRight>
<rmpi:DigitalExportSDRight>
<rmpi:DigitalExportRightFlagNotGranted/>
</rmpi:DigitalExportSDRight>
<rmpi:DigitalExportHDRight>
<rmpi:DigitalExportRightFlagNotGranted/>
</rmpi:DigitalExportHDRight>
<rmpi:SecurityLevel>N/A</rmpi:SecurityLevel>
<rmpi:GeographicalControl>N/A</rmpi:GeographicalControl>
</rmpi:AnyDomainRights>
</tva2:RMPIDescription>
</tva2:RMPITable>
</TVAMain>
Figure 219 –
<?xml version="1.0" encoding="UTF-8"?>
<license xmlns="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:mx="urn:mpeg:mpeg21:2003:01-REL-MX-NS" xmlns:m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS" xmlns:m1x="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sx:profileCompliance="dmp-IDP2-rel-1.0" xsi:schemaLocation="urn:mpeg:mpeg21:2006:01-REL-M2X-NS ..\idp-2\rel-m2x-dac-v1.xsd">
<grant>
<m1x:identityHolder licensePartId="ReceivingDomain">
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>DO12345</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<m1x:protectedResource licensePartId="news">
<digitalResource>
<nonSecureIndirect URI="urn:uci:ETRI-10357"/>
</digitalResource>
<xenc:EncryptedData>
<xenc:EncryptionMethod Algorithm="Camellia"/>
<xenc:CipherData>
<xenc:CipherReference URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</xenc:CipherData>
</xenc:EncryptedData>
</m1x:protectedResource>
<allConditions licensePartId="ReceivingDomainCondition">
<m2x:timeShiftDuration>
<m2x:duration>PT0S</m2x:duration>
</m2x:timeShiftDuration>
<m2x:securitySystem>
<m2x:identifier>TVA</m2x:identifier>
<m2x:level>3</m2x:level>
</m2x:securitySystem>
<validityInterval>
<notBefore>2005-10-04T12:00:00</notBefore>
<notAfter>2005-10-06T12:00:00</notAfter>
</validityInterval>
<sx:territory>
<sx:location>
<sx:country>Japan</sx:country>
</sx:location>
</sx:territory>
<m2x:proximity/>
<m1x:outputRegulation>
<m1x:regulation typeOfSignal="analog"/>
<m1x:regulation typeOfSignal="digital" qualityOfSignal="SD"/>
<m1x:regulation typeOfSignal="digital" qualityOfSignal="HD">DTCP</m1x:regulation>
</m1x:outputRegulation>
</allConditions>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="ReceivingDomain"/>
<m2x:export/>
<digitalResource licensePartIdRef="news"/>
<allConditions licensePartIdRef="ReceivingDomainCondition"/>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="ReceivingDomain"/>
<m1x:governedCopy/>
<digitalResource licensePartIdRef="news"/>
<allConditions licensePartIdRef="ReceivingDomainCondition"/>
</grant>
<grant>
<m1x:identityHolder licensePartIdRef="ReceivingDomain"/>
<m2x:extendRights>
<m1x:serviceLocation>
<m1x:url>http://www.paytv.com/extendLiceseService</m1x:url>
</m1x:serviceLocation>
</m2x:extendRights>
<digitalResource licensePartIdRef="news"/>
</grant>
<issuer>
<keyHolder>
<info>
<dsig:KeyName>FTABroadcasterDE</dsig:KeyName>
</info>
</keyHolder>
</issuer>
Figure 220 –
The advancing deployment of Internet Protocol (IP)-based network gear with increasingly higher bitrate is making it possible to distribute video and television content on a demand basis.
In this Use Case we consider the distribution of video content carried by RTP/UDP/IP.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
In this walkthrough the following Users are assumed to exist:
|
User |
Perform |
|
A plurality of Devices Manufacturers |
Manufacture Interoperable Devices |
|
A plurality of Device Certification Authorities |
Certify Interoperable Devices |
|
A plurality of Service Providers |
4. Offer a variety of Governed Content-based Services, in particular on-demand Services 5. Employ independently selected DRM Tools |
|
A plurality of smart cards providers |
|
|
A plurality of Licence Providers |
|
|
A plurality of End Users |
1. Buy Interoperable Devices from Manufacturers of their choice 2. Buy smart cards from Trusted Third Parties 3. Access Services from Providers of their choice 4. Access Licences from Providers of their choice 5. Use Governed Content as per Licence |
The specific Users are:
|
Type of User |
Name |
|
Device Manufacturer |
DM-A |
|
Device Certification Agency |
CA-B |
|
Content Service Provider |
SP-C |
|
Smart card Provider |
SP-D |
|
Tool Provider |
TP-E |
|
Licence Provider |
LP-F |
|
Payment Service Provider |
PP-G |
|
End User |
Rufus |
Before Rufus can Access and Use Content the following has to happen
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
CA-B |
Certify |
SAV |
CA-B places a Certificate inside DM-A’s SAV |
|
AD #5 |
|
Rufus |
Buy |
SAV |
DM-A’s SAV’s are Certified |
Out of scope |
|
|
Rufus |
Buy |
smart card |
From SP-D |
Out of scope |
|
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Rufus |
Select |
SP-B’s Service |
Out of all available Services |
Out of scope |
|
|
Rufus |
Select |
Content Item |
e.g. a movie |
Out of scope |
|
|
Rufus |
Select |
Licence |
e.g. for 24 hours |
Out of scope |
|
|
Rufus |
Select |
Payment method |
Pays PP-G |
Out of scope |
|
|
Rufus (SAV) |
Un-Package |
Content Item |
|
Package Content as Stream |
4.1.2 |
|
Rufus (SAV) |
Access |
Licence |
|
Access Licence as File |
3.5.3 |
|
SAV |
Parse |
Licence |
|
Represent Licence |
2.10 |
|
Rufus (SAV) |
Parse |
DRM Information |
To find the information regarding required DRM Tools |
Represent Content |
2.1 |
|
Rufus (SAV) |
Access |
DRM Tool |
Case 1: DRM Tool is in the DCI |
Access DRM Tool Body as Stream |
3.5.6 |
|
|
|
|
Case 2: DRM Tool Body is Accessed from TP-A via the network |
Access DRM Tool Body as File |
3.5.5 |
|
DRM Processor |
Manage |
DRM Tool |
|
Manage DRM Tools |
3.4 |
|
DRM Processor |
Access |
Key |
|
Access Key as Stream |
3.5.7 |
|
Rufus (SAV) |
Play |
Content Item |
As per Licence Terms |
Represent Content Elements |
2. |
|
Rufus (SAV) |
Store |
DCF |
Stores as a Content File with the Licence Bundled within it |
Package Content as File |
4.1.1 |
It may happen that even after IDP is broadly deployed not all devices used for using digital content conform to it and other devices/content would remain conforming to other DRM standards or systems. It might be impossible to use content governed according to one DRM System in a device conforming to another DRM systems even within one user’s domain. For seamless content service, it is required to have a procedure for conversion between different DRM standards or systems.
This Use Case is about the conversion of DRM content between various DRM standards or systems to make possible the use of DRM content governed by one DRM system on different DRM system by using DMP Content Format as an intermediate format.
This Use Case is considered for illustration purposes. Therefore it is not specifically recommended for implementation.
Tom downloads a movie governed by A-DRM System into his A-DRM compliant STB through a VOD service site. Tom wants to send the movie to his B-DRM compliant PMP device and play this movie content on the PMP as well as the original STB.
This walkthrough has the following Users:
|
Type of User |
Name |
|
Service Provider |
A-DRM compliant VOD Service (ADV) |
|
Device Manufacturer |
A-DRM compliant STB Devices (ADD) |
|
Device Manufacturer |
B-DRM compliant PMP Devices (BDD) |
|
End User |
Tom |
The following steps are made
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Tom |
Buy |
content item |
Buy Movie file (possibly other Resources e.g. photos, mp3s etc. from ADV) |
Out of scope |
|
|
Tom |
Use |
content item |
Play the movie governed by A-DRM system at ADD |
Out of scope |
|
|
Tom |
Request |
content item |
Make a request to ADD for “copying content item governed by A-DRM to BDD”
|
Out of scope |
|
|
ADD |
Parse |
Licence |
If Licence terms allow “Export Content” 1. Then ADD starts to convert content item 2. Else ADD displays message |
Out of scope |
|
|
ADD |
Authenticate |
BDD |
ADD and BDD mutually authenticate |
Authenticate Device |
3.2.1 |
|
ADD |
Unpackage |
Licence |
ADD unpackages Licence associated with the movie content. |
Out of scope |
|
|
ADD |
Convert |
Licence |
ADD converts the unpacked Licence into Licence with CEK encrypted with BDD’s public key |
Represent Licence |
2.10 |
|
ADD |
Unpackage |
content item |
ADD unpackages the movie content item |
Out of scope |
|
|
ADD |
Convert |
content item |
ADD converts the unpacked movie content item into Content Item and inserts the Licence into the Content Item |
Represent Content |
2.1 |
|
ADD |
Package |
Content Item |
For Delivery |
Package Content |
4.1.1 |
|
ADD |
Send |
Content Item |
As file |
Access Content as File |
3.7.1 |
|
BDD |
Unpackage |
Content Item |
BDD unpackages the Content Item |
Package Content |
4.1.1 |
|
BDD |
Unpackage |
Licence |
BDD unpackages the Licence |
Package Content |
4.1.1 |
|
BDD |
Convert |
Licence |
BDD converts the unpacked Licence into its own Licence |
Out of scope |
|
|
BDD |
Convert |
Content Item |
BDD converts the unpacked Content Item into its own content item |
Out of scope |
|
|
BDD |
Package |
content item |
As file |
Out of scope |
|
|
Tom |
Use |
content item |
Play the movie governed by B-DRM system at BDD |
Out of scope |
|
Tom downloads a movie into his A-DRM compliant STB through a VOD service site. This movie content is governed by A-DRM System. Tom wants to receive the movie from the STB at his B-DRM compliant PMP device and play this movie content on the PMP as well as the original STB.
This walkthrough has the following Users:
|
Type of User |
Name |
|
Service Provider |
A-DRM-compliant VOD Service (ADV) |
|
Device Manufacturer |
A-DRM-compliant STB Devices (ADD) |
|
Device Manufacturer |
B-DRM-compliant PMP Devices (BDD) |
|
End User |
Tom |
The following steps are made
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Tom |
Buy |
content item |
Buy Movie file (possibly other Resources e.g. photos, mp3s etc. from ADV) |
Out of scope |
|
|
Tom |
Use |
content item |
Play the movie governed by A-DRM system at ADD |
Out of scope |
|
|
Tom |
Request |
content item |
Make a request to BDD for “copying content item governed by A-DRM at ADD into BDD” |
Out of scope |
|
|
BDD |
Authenticate |
ADD |
BDD and ADD mutually authenticate |
Authenticate Device |
3.2.1 |
|
ADD |
Parse |
license |
If license terms allow “Export Content” 1. Then ADD starts to convert content item 2. Else ADD send message to BDD, BDD displays message |
Out of scope |
|
|
ADD |
Unpackage |
license |
ADD unpackages license associated with the movie content. |
Out of scope |
|
|
ADD |
Convert |
license |
ADD converts the unpacked license into Licence with CEK encrypted with BDD’s public key. |
Represent Licence |
2.10 |
|
ADD |
Unpackage |
content item |
ADD unpackages the movie content item |
Out of scope |
|
|
ADD |
Convert |
content item |
ADD converts the unpacked movie content item into Content Item and inserts the Licence into the Content Item |
Represent Content |
2.1 |
|
ADD |
Package |
Content Item |
For Delivery |
Package Content |
4.1.1 |
|
BDD |
Receive |
Content Item |
As file |
Access Content as File |
3.7.1 |
|
BDD |
Unpackage |
Content Item |
BDD unpackages Content Item |
Package Content |
4.1.1 |
|
BDD |
Unpackage |
Licence |
BDD unpackages Licence |
Package Content |
4.1.1 |
|
BDD |
Convert |
Licence |
BDD converts the unpacked Licence into its own license |
Out of scope |
|
|
BDD |
Convert |
Content Item |
BDD converts the unpacked Content Item into its own content item |
Out of scope |
|
|
BDD |
Package |
content item |
As file |
Out of scope |
|
|
Tom |
Use |
content item |
Play the movie governed by B-DRM system at BDD |
Out of scope |
|
A Content Registration Agency may decide to offer multiple Content Identification Services.
GreenRegistrations offers Content Creators the ability to
· Select a standard Licence
· Fill in all specific Data in the Licence
· Register the Licence, i.e. obtain a Licence Identifier
· Create a DCI adding the Resource Licence to the Content
· Register the DCI and obtain a DCI Identifier.
In this Use Case the Protocol can be implemented using a variant of AD #3 Protocols as follows:
1. CCD makes a DCI
2. Content Creator contacts GreenRegistrations
3. CID and CCD mutually Authenticate
4. Content Creator selects a Licence applicable to his intended Use of the Resources from CID GUI
5. Content Creator fills in the Resource Identifiers to be added to the Licence (eg, click and send)
6. CID sends Licence and Licence Identifier to CCD
7. CCD adds Licence and Identifier to the DCI
8. CID
a. Assigns Content Identifier to the DCI
b. Sends the requested Identifier to Creator
9. CCD
a. Adds Identifier to DCI
b. Computes the hash of the new DCI with Identifier
c. Content Creator signs Hash
d. Sends the hash of DCI to GreenRegistrations
10. CID Stores the hash for future reference
Groups of individuals sporadically and often spontaneously, work together to create Content that may become distributed on the internet. They do this by exchanging preliminary computer files (text, audio, audio visual, image) known as Resources which serve to represent the different related IP Entities each are responsible for. Eventually, these Resources can become part of Products that are used and traded on the internet. These individuals are also recognized between each other by virtue of sets of specific actions they perform on or with specific IP Entities, different sets of these actions constitute Roles for example, a “Creator” authors, a “Performer” interprets and so on with the Roles of arranger, producer publisher and distributor. These Roles are thus associated with specific IP Entities that in turn qualify the digital objects that represent them. Also, IP Entity to IP Entity and Role to Role relationships are direct corollaries of one another.
However and presently, the process of formalising and recording interactions between Users that assume Roles is performed through disparate means that are sometimes only partially mechanised and certainly not interoperable. Therefore, there is a clear need for a common machine readable method for representing the relationships between:
1. IP Entities
2. IP Entities and Roles
3. Roles
A way to achieve the above is by implementing formal (machine readable) Ontologies that allow capturing definitions and their relationships in a constant and consistent fashion. One such ontology based on the DMP Creation Model is the RRD.
This Use Case illustrates how the RRD as specified in Approved Document No. 3 of IDP 3.1 can be used by several different Users to mutually declare complementary roles vis à vis a common Content Item.
This Use Case is considered for illustrative purposes. Therefore it is not specifically recommended for implementation.
George has an MP3 file on his computer that he wishes to be used exclusively as a Manifestation of his Work in lieu of a written score and not as a performance for distribution to the general public.
George is a registered user of RRD Ontology Access (ROA), an on line service where he can access an Ontology Application that runs an API that interfaces the latest version of the DMP RRD Ontology maintained as a standard OWL file format. The RRD Ontology supports the Roles: Creator, Adaptor, Instantiator, Producer and Distributor. Thus, George can Register his DCI as representing his Manifestation of his Work. The following table includes a step by step description of how George would achieve this.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
George |
Make/ Register/ Identify |
DCI |
User Creates, Registers and Identifies a DCI to Represent his Resource |
Represent Content |
2.5.1 |
|
George |
Enter |
User Login |
User accesses ROA |
none |
|
|
George/ROA |
Mutually Authenticate |
User |
The ROA uses a SAC |
Out of scope |
|
|
George |
Access |
ROA RRD Application |
The RRD application consists of a user interface that accesses the RRD OWL |
RRD Ontology/API |
2.10 |
|
ROA |
Request |
DCI |
The ROA requires the Content Item for its Authentication |
Access Content |
3.6.1 |
|
George |
Upload |
Content Item |
|
|
|
|
ROA |
Authenticate |
Content Item |
The ROA needs to Authenticate the DCI and its ID |
Authenticate Content |
3.2.3 |
|
ROA |
Request |
Role |
A Role must be associated to identified User with respect to Content Item’s ID. |
RRD Ontology/API |
2.10 |
|
George |
Enter |
Creator |
With the User’s declaration of Role, the RRD Application + RRD OWL knows what IP Entities can apply. |
RRD Ontology/API |
2.10 |
|
ROA |
Request |
IP-Entity |
The RRD Application offers the User the relevant IP-Entity options corresponding to the Role in this case: Work in Work-Manifestation-Copy. |
RRD Ontology/API |
2.10 |
|
George |
Enter |
Work-Manifestation-Copy |
RRD requires that all parent class individuals be entered also before entering child class individuals |
RRD Ontology/API |
2.10 |
|
ROA |
Request |
Work and Work-Manifestation Titles |
The Parents of Work-Manifestation-Copy |
RRD Ontology/API |
2.10 |
|
George |
Enter |
Work ID |
This may be either of a string, a code such as ISWC or both |
none |
|
Following the above steps, the ROA has added to its RRD OWL file the corresponding concrete individuals for the following RRD classes: Creator, Work and Work- Manifestation and Work-Manifestation-Copy. These class individuals are now related to one another thanks to the standard RRD OWL file logic. When in the future another user wishes to use Georges Work-Manifestation-Copy, George can require that before being granted access and through his Work-Manifestation-Copy DCI License Users must be referred back to the ROA to be associated with a valid available Role vis à vis George’s DCI i.e. Instantiator or Producer. This way, George will have a record in the ROA of all Users that have accessed his DCI and the Role those users have declared vis à vis that same DCI.
There are many cases where Users (companies or individuals) who have Rights want to Release Content in such a way that only a group of Users can Access it. Domains are sets of Devices sharing common attributes, such as personal or group ownership. Domain Management includes setting up Domains, managing Device and User membership of a Domain (i.e. joining, renewing and leaving Domains) and controlling the Use of Content within the Domain.
The following Use Cases are considered for illustration purposes and are not specifically recommended for implementation.
The Device manufacturer Great Blue Devices (GBD) intends to use interoperable DRM to bind Users to the Environment of his well designed GBD Devices and DotBlue Services. For this purpose GBD creates a Domain of GBD Devices. A Domain Authority assigns a Domain Manager ID to the Domain Manager Device (DMD) and Domain Manager Device (DMD) requests Domain Identification Device (DoID) to assign a Local Domain ID to the newly created Domain operated by GBD. Before shipping new Devices GBD adds the Device Identifiers to the GBD DMD so that all GBD Devices are automatically members of the Domain of GBD Devices.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
DMD, Domain Administrator(GBD) |
Create |
Domain |
Domain of GBD Devices |
Create Domain Protocol |
3.3.2.1 |
|
Domain Authority, DoID, DMD |
Identify |
Domain |
Domain of GBD Devices |
Request Local Domain ID Protocol |
|
|
DMD, Domain Administrator(GBD) |
Add |
Device IDs |
Domain of GBD Devices |
Add Device Protocol |
3.3.4.1 |
A Service Provider can set up and manage a Domain of Users and Devices. The Service Provider can add Users and/or Devices to this Domain. All members of the Domain can receive his Services.
Great Blue Cable network (GBC) is a Provider of internet television Services. Historically the GBC network infrastructure was owned by the people of the Democratic Republic of Blue Island. Blue Island's citizens could only watch two channels (BTV1 and BTV2). Watching foreign television channels was considered to be a disgrace to the honoured leaders of Blue Island. Then, after the silent revolution of 2007, the network infrastructure was privatized and upgraded.
The new owners of GBC installed a GBC television Service Provider Device on the head end side of Blue Island's network infrastructure. All citizens of Blue Island were supplied with Devices for receiving digital television Services. With these Devices they can receive 40 television channels for free. These Devices were preconfigured to be part of a GBC Domain managed by a GBC Domain management Device (DMD).. Together with their Devices all citizens of Blue Island received a GBC Pay-TV smart card. The smart card contains a certificate that Identifies the User. Only identified Users can receive GBC Services and it is not possible to receive GBC Services (like e.g. the GBC Electronic Program Guide) on Devices that are not members of the GBC Domain.
GBC also operates 80 Pay-TV channels and rental and retail Services for films (e.g. near-video-on-demand). When a User inserts the smart card into the Device, it exchanges the certificate with the GBC television Service Provider Device. The Domain Management Device then adds the User ID to the Domain of GBC Pay-TV Users and the Device with the smart card inserted can Access Pay-TV and other Services.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
DMD (GBC Domain Administrator) |
Create |
Domain |
Domain of GBC Devices |
Create Domain Protocol |
3.3..2.1 |
|
DMD (GBC Domain Administrator) |
Create |
Domain |
Domain of GBC Users |
Create Domain Protocol |
|
|
DMD (Domain Authority) |
Identify |
Domain |
Domain of GBC Devices |
Request Local Domain ID Protocol |
|
|
DMD (Domain Authority) |
Identify |
Domain |
Domain of GBC Users |
Request Local Domain ID Protocol |
|
|
DMD (GBC Domain Administrator) |
Add |
Device IDs |
Domain of GBC Device |
Add Device Protocol |
3.3.4.1 |
|
DMD (GBC Domain Administrator) |
Add |
User IDs |
Domain of GBC Users |
Add Device Protocol |
3.3.4.2 |
Clark is a salesman working on a trade fair. Since Clark has subscribed to GBC's Pay-TV Service he can watch his favourite TV programmes in the hotel room on his mobile Device. On the third day of the fair a thief steals Clark's bag containing the mobile Device with Clark's smart card. Fortunately Clark has stored his music archive on his home Device, so no Content is lost. Before he calls the police Clark calls the GBC Domain Administrator and identifies himself with a secret pass phrase.
The GBC Domain Administrator revokes Clark's User identity and the stolen mobile Device from the Domain of GBC so that it is not possible any more to Use Clark's stolen smart card nor mobile Device for accessing GBC communication Services. Then the GBC Domain Administrator creates a new User identity for Clark, adds it to the GBC Domain and sends a new set of devices (e.g. SIM cards, smart cards) to Clark via express mail. In an electronic store nearby Clark buys a new mobile Device. If the express mail service does a good job Clark will be able to access his usual GBC Service a few hours later.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
DMD, Domain Administrator (Clark) |
Identify |
User/Device |
Exchanging Credential information with Domain Administrator |
Request Local Domain ID Protocol |
|
|
DMD Domain Administrator (GBC) |
Revoke |
User/Device |
Domain of GBC's Users |
Leave Device Protocol, Leave User Protocol |
3.3.4.5
3.3.4.6 |
David is an End-user. He owns several GBD Devices belonging to the GBD Domain (the Domain operated by the Device Manufacturer GreatBlue Devices – see above). David can establish a local Domain by requesting a new Domain from his local Domain Manager Device (DMD) which is operated by David. Then David can add/remove Devices of his choice to/from his local Domain, including non-GBD Devices. Content Licensed to David's Domain can be Used on all Devices in his local Domain, but only GBD Devices in David's local Domain can receive GBD Services.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
DMD Domain Administrator (David),
|
Create |
Domain |
Domain of David's Devices |
Create Domain Protocol |
3.3.2.1 |
|
DMD Domain Authority, (David) |
Identify |
Domain |
Domain of David's Devices |
Request Local Domain ID Protocol |
|
|
DMD Domain Administrator (David) |
Add |
Device IDs |
Domain of David's Devices |
Add Device Protocol |
3.3.4.1 |
|
DMD Domain Administrator (David) |
leave |
Device IDs |
Domain of David's Devices |
Leave Device Protocol |
3.3.4.2 |
Content can be Licensed to Users, Devices or Domains. Though sharing Content between Users is legal in some situations and jurisdictions (e.g. between friends and family members), strange situations can happen when Users decide to connect their Devices and try to Play Content on a Device that was Licensed for an other Device.
David and Eliza are two students of the University of Blue Island. David has a large collection of Kung Fu films Licensed to his local Domain (the License allows David to download the films and Play them on all Devices in his local Domain). Eliza collects Blue Island horror films from the 1970s. All of Eliza's films are Licensed to her User identity (the License allows her to download the films and Play them on all Devices controlled by her). One day David and Eliza fall in love and David moves into Eliza's flat. Of course they want to Play David's films on Eliza's Devices (and vice versa)
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
DMD (Domain Administrator - David) |
Create |
Domain |
Domain of David's Users |
Create Domain Protocol |
3.3.2.1 |
|
DoID |
Identify |
Domain |
Domain of David's Users |
Request Local Domain ID Protocol |
|
|
DMD (Domain Administrator - David) |
Add |
User ID |
Add Eliza's User ID to Domain of David's Users |
Add User Protocol |
3.3.4.2 |
|
DMD (Domain Administrator - Eliza) |
Create |
Domain |
Domain of Eliza's Devices |
Create Domain Protocol |
3.3.2.1 |
|
DoID, |
Identify |
Domain |
Domain of Eliza's Devices |
Request Local Domain ID Protocol |
|
|
DMD (Domain Administrator – Eliza) |
Add |
Device IDs |
Add David's Devices to Domain of Eliza's Devices |
Add Device Protocol |
3.3.4.1 |
To perform the tasks for which they are designed, Value-Chains built to operate according to DMP Technical Specifications and References need to rely on the guaranteed Integrity of Entities such as Device and DRM Tools and the Identity of Entities such as Content, Device, Domain, DRM Tools and User.
This Approved Document No. 5 collects roles, qualification requirements, appointment procedures and operation rules of DMP-appointed Certification and Registration Authorities.
Prerequisites for proper understanding of this Approved Document are: reading of this Foreword, Approved Document No. 2 – Architecture and Approved Document No. 6 – Terminology.
When designing, implementing and operating Value-Chains handling Governed Content there are several cases where Entities such as Devices (e.g. Creation Devices, Consumption Devices and Domain Management Devices) and DRM Tool Bodies have to be Certified before operation on the IDP. As an example, Certification constitutes a key assurance for a Rights Holder to entrust his Content to a Device.
Certification is carried out by a plurality of organisations dedicated to the task of Certifying Entities. To perform this task these organisations must be properly accredited by a root authority called Certification Authority.
In this regard, the only role of DMP is to select and appoint the Certification Authority. Said Authority is responsible for Certification policy of types of Entity for which Certification is required. A Certification Agency is responsible for performing tests to guarantee – within an acceptable level of confidence – that a given Entity may operate in the IDP. Once Certified, the Entity can be Identified. The Certification Authority will appoint Certification Agencies on the basis of the general rules as specified in this Approved Document.
For each Certification Authority the following process shall be followed:
1. When the need for a Certification Authority is identified as part of the development of one or more Approved Documents, the General Assembly will document the need in a Call for Participation;
2. The General Assembly will request the Board of Directors to issue the Call for Participation within the time set by the General Assembly;
3. Applications shall be received by the Board of Directors and reviewed on the basis of compliance with the terms contained in the Call for Participation and adequacy of the Certification Policy proposed by the applicant;
4. The Board of Directors shall select and propose the appointment of one candidate Certification Authority to the General Assembly within 180 days of the deadline indicated in the Call for Participation for submitting Applications;
5. The General Assembly shall appoint the Certification Authority based on the proposal made by the Board of Directors;
6. Once appointed, the Certification Authority may receive applications from applicants wishing to become Certification Agencies;
7. The Certification Authority shall review the application for compliance with the Certification Policy;
8. In case an application is rejected, the applicant may appeal to the Board of Directors;
9. The Board of Directors will issue a final judgement on the appeal;
10. The Board of Directors will inform the Certification Authority and the appealing Certification Agency of its decision within 90 days of the date of appeal;
11. If a Certification Authority, resigns the matter will be brought to the attention of the General Assembly for action.
To qualify for appointment as a Certification Authority an organization shall demonstrate that:
1. It is a legal entity;
2. It has been in existence for no less than five years;
3. It enjoys a sound financial structure;
4. It is familiar with the field in which it applies to operate as an Authority;
5. It has employees who are technically competent in Certification of the relevant Entity and are in number deemed to be sufficient to handle the expected workload;
6. It does not have a direct economic stake in the related business;
7. It commits to function in its capacity as a Certification Authority for a minimum of ten years;
8. It has sufficient equipment resources (e.g., hardware, software) and communication facilities (e.g., postal street address, telephone, facsimile, e-mail, ftp and web site);
9. The fee structure, if one is envisaged, shall be for the purpose of cost recovery, and shall be approved as part of the appointment;
10. It shall require no financial contribution from DMP and its members;
11. It shall not become a Certification Agency.
The following procedure shall be invoked whenever DMP identifies the need for a Certification Authority:
1. The General Assembly shall draft a Call for Participation;
2. The Board of Directors shall issue the Call for Participation by the time indicated by the General Assembly;
3. Prospective Certification Authorities shall submit an application indicating
a. How the requirements of the Call for Participation are fulfilled;
b. The time the Certification Authority will start accepting applications from candidate Certification Agencies;
c. The criteria for accepting or rejecting applications for Certification Agencies to be applied in a strictly non-discriminatory fashion;
d. The level of administrative fees and the underlying cost structure which must be based on cost recovery principles;
4. The DMP Board shall
a. Assess the applications;
b. Select one;
c. Draft the text of the agreement between DMP and the selected applicant;
d. Achieve agreement with the selected applicant on the text of the agreement;
e. Submit its conclusions to the General Assembly, including the text of the agreement between DMP and the selected applicant;
5. The General Assembly shall vote on the proposal of the Board of Directors;
6. The DMP Board will inform the successful applicant of the result within 180 days of the deadline indicated in the Call for Participation for submitting Applications.
Once appointed the Certification Authority shall:
1. Handle all business in English;
2. Publish all relevant material on the Certification Authority’s web site. This will include:
a. How to apply for a Certification Agency
b. The level of fees
c. The application approval criteria
d. Documents describing practices and tutorials
e. Etc.;
3. Receive applications from prospective Certification Agencies;
4. Evaluate applications in accordance with the application approval criteria, including technical capabilities of the applicant;
5. Inform the applicant within 180 days of receipt of the application of the outcome of the evaluation;
6. Deal with resubmissions of a previously rejected application as a new application;
7. Adhere to the procedure for appeals;
8. Process requests to extend the field of Entity Certification of a previously appointed Certification Agency as a new application;
9. Publish the register of appointed Certification Agencies on the Certification Authority’s web site;
10. Keep a record of all request forms, granted and denied;
11. Safeguard any confidential information;
12. Handle all aspects of the Certification process in accordance with good business practices;
13. Collect complaints about performance of Certification Agencies and act accordingly, including revoking the status of Certification Agency;
14. Inform the relevant Registration Agencies that Certification of an Entity has been revoked in case the Certification Agency responsible fails to act;
15. Report periodically to the DMP Board of Directors.
1. Not to be engaged in the business for which it seeks to become a Certification Agency, as this would create a conflict of interest;
2. Apply to the Certification Authority following the procedures and including a description of:
a. The field of Entity Certification;
b. The technical qualifications;
c. The procedures and test suites to be employed for Certification;
3. Provide contact information;
4. Agree to set up an operational Certification Agency within 180 days from the day of receipt of acceptance of the application;
5. Be aware that the appointment may be revoked if the Certification Agency fails to be operational within the prescribed time;
6. Maintain a permanent record of the application form and the notification received from the Certification Authority;
7. Keep a record of all request forms – granted and denied – from companies applying for Certification in accordance with good business practices;
8. Revoke Certification of Entities that are found after receiving Certification that they do not fulfil the requirements and inform the relevant Registration Agencies
9. Make periodic reports to the Certification Authority.
When designing, implementing and operating Value-Chains handling Governed Content there are several cases where Entities such as Content, Licenses, DRM Tool Bodies, Devices, Users and Domains need to be reliably and unambiguously Identified. This task requires specific capabilities, as Identification constitutes a key element of Trust establishment, e.g. in the case of Devices. The task of Identification needs to be carried out by several organisations that are properly accredited by a root authority.
In this regard DMP has to make sure that for each Entity there is one and only one root authority – called Registration Authority each of which may have responsibility for more than one Entity. However, the only role of the DMP is to select and appoint Registration Authorities. A Registration Authority is responsible for allocating namespaces to Registration Agencies in accordance with Approved Document No. 3 [3]. The Registration Authority will appoint Registration Agencies on the basis of the general rules as specified in this Approved Document.
For each Registration Authority the following process shall be followed:
1. When the need for a Registration Authority is identified as part of the development of one or more Approved Documents, the General Assembly will document the need in a Call for Participation;
2. The General Assembly will request the Board of Directors to issue the Call for Participation within the time set by the General Assembly;
3. Applications shall be received by the Board of Directors and reviewed on the basis of compliance with
a. The terms contained in the Call for Participation;
b. Adequacy of the policy to appoint and supervise Agencies;
c. Level of detail of the proposal;
4. The Board of Directors shall
a. Provide a list of all responses to the Call for Participation to the General Assembly
b. Select and propose appointment of one candidate Registration Authority to the General Assembly within 180 days of the deadline indicated in the Call for Participation for submitting Applications;
c. Propose a contract between the DMP and the Registration Authority proposed for appointment;
5. The General Assembly shall
a. Approve the contract between the DMP and the Registration Authority proposed for appointment;
b. Appoint the Registration Authority
6. The Registration Authority shall receive applications from candidate Registration Agencies and appoint them;
7. In case an application of a candidate Registration Agency is rejected the applicant may appeal to the Board of Directors;
8. The Board of Directors will issue a final judgement on the appeal;
9. The Board of Directors will inform the Registration Authority and the appealing candidate Registration Agency of its decision within 90 days of the date of appeal;
10. The Registration Authority shall make a yearly report which will be reviewed by the General Assembly;
11. If a Registration Authority resigns the matter will be brought to the attention of the General Assembly for action
12. If a Registration Authority resigns it must ensure continuity of its function until a new Registration Authority is appointed.
To qualify for designation as a Registration Authority an organization shall demonstrate that:
1. It is a legal entity;
2. It has been in existence for no less than five years;
3. It enjoys a sound financial structure;
4. It is familiar with the field in order to operate as an Authority;
5. It has employees who are technically competent in digital identification;
6. It does not have a direct stake in the related business that would create a conflict of interest;
7. It commits to function in its capacity as a Registration Authority for a minimum of nine years, however, the appointment will be renewed every 3 years;
8. It has sufficient equipment resources (e.g., hardware, software) and communication facilities (e.g., postal street address, telephone, facsimile, e-mail, ftp and web site);
9. If it operates with a fee structure, this structure shall be for the purpose of cost recovery, and shall be approved as part of the appointment;
10. It shall require no financial contribution from DMP and its members;
11. It shall not become a Registration Agency.
The following procedure shall be invoked whenever DMP identifies the need for a Registration Authority:
1. The General Assembly will draft a Call for Participation;
2. The Board of Directors shall issue the Call for Participation by the time indicated by the General Assembly;
3. Prospective Registration Authorities shall submit an application indicating:
a. The time the Registration Authority will start assigning subordinate namespaces to Registration Agencies;
b. The criteria for accepting or rejecting applications for Registration Agencies to be applied in a strictly non-discriminatory fashion;
c. The level of administrative fees, if any, which must be based on cost recovery principles;
d. The policy to be applied in appointing and supervising Agencies;
4. The DMP Board shall
a. Assess the applications;
b. Select one;
c. Draft the text of the contract between DMP and the selected applicant;
d. Achieve agreement with the selected applicant;
e. Submit its conclusions to the General Assembly;
5. The General Assembly will vote on the proposal of the Board of Directors;
6. The DMP Board shall inform the selected applicant of the result within 180 days of the deadline indicated in the Call for Participation
7. The selected applicant and the DMP will sign the contract in the form approved by the General Assembly.
Once appointed the Registration Authority shall:
1. Obtain, where required, a namespace and use the namespace as a prefix for identifiers in accordance with the relevant part of Approved Document No. 3 [3];
2. Handle all business in English;
3. Publish all relevant material on the Registration Authority’s web site whose domain name is provided by the DMP. This will include:
a. How to apply for a Registration Agency,
b. The level of fees charged by the Registration Authority;
c. The application approval criteria;
d. Documents describing practices and tutorials;
e. Etc.;
4. Receive applications from prospective Registration Agencies;
5. Review applications in accordance with the application approval criteria;
6. If the criteria are met, communicate to the applicant within 30 days of receipt of the application the assigned subordinate name spaces;
7. If criteria are not met, inform the applicant within 30 days of receipt of the application;
8. Deal with resubmissions of a previously rejected application as a new application;
9. Adhere to the procedure for appeals;
10. Process updates of a previously registered subordinate namespace as a new application;
11. Act on Registration Agencies failing to be operational within the prescribed time, including revocation of the authorization;
12. Maintain an accurate register of the assigned subordinate name spaces;
13. Keep a record of all request forms, granted and denied;
14. Safeguard any confidential information;
15. Handle all aspects of the registration process in accordance with good business practice;
16. Collect complaints about performance of Registration Agencies and act accordingly, including revoking the status of Registration Agencies;
17. A revoked Registration Agency can appeal to the Board of Directors;
18. Report annually to the DMP Board of Directors.
1. A Registration Authority shall provide access to the list of appointed Registration Agencies on a 24x7 level so that Devices may Access the Registration Agency that has issued a given Identifier (See Approved Document No. 3 for details)
2. A Registration Authority shall perform the functions of a Registration Agency that has been revoked or ceased to operate, with the exclusion of Registration of new Content, at the same level of service, until such time as the Identifier data base will be reassigned.
1. Apply using the forms supplied and following the procedures adopted by the Registration Authority;
e. Include a description of the purpose of the subordinate name space, and the required technical details as specified in the application form;
f. Provide a precise statement of the policy the candidate Registration Agency will pursue when providing Identifiers;
g. Provide contact information;
2. Agree to set up an operational Registration Agency within 180 days from the day of receipt of acceptance of the request;
3. Publish on their web site the policy the Registration Agency pursues when providing Identifiers;
4. Assign Identifiers using exclusively one or more of the DMP Identification Protocols;
5. Maintain a permanent record of the application forms and the notifications received from the Registration Authority;
6. Keep a record of all request forms, granted and denied;
7. Provide Content Authentication services using the appropriate DMP Authentication Protocol;
8. Make the identifier data base available to the Registration Authority for reassignment in case the Registration Agency is revoked or ceases to operate.
DRM Tool Body Registration Agencies shall Assign Identifiers for the following:
|
DRM Tool Bodies |
Identifiers that uniquely Identify executable computer code that implements a DRM Tool |
|
Control Point |
Identifiers that uniquely Identify a point in a Device under the control of a DRM Tool |
|
DRM Tool Instantiation_API_ID |
Identifiers that uniquely Identify the API for instantiation of the DRM Tool. |
|
DRM Tool Messaging_API_ID |
Identifiers that uniquely Identify the API to pass messages to/from a DRM Tool |
See Approved Document No. 3 for details.
The responsibilities of the DMP Board of Directors regarding Certification and Registration Authorities shall be:
1. Publish Calls for Participation;
2. Receive applications of organizations seeking to become Certification or Registration Authorities;
3. Select and propose Certification and Registration Authorities to the General Assembly;
4. Communicate decision of appointment or otherwise to candidate Certification or Registration Authorities;
5. Review and dispose of all appeals by organizations seeking to become Certification or Registration Agencies within 120 days of receipt of the appeal by the DMP secretariat;
6. Inform, in writing, the appealing organization and the Certification or Registration Authority of the disposition of the appeal;
7. Review the annual reports of the Certification and Registration Authorities’ summary of activities;
8. Report to the DMP General Assembly any information concerning the status of operation of the Certification and Registration Authority and the general status of Certification and Registration Agencies.
This document collects the definitions of key terms used throughout DMP Approved Documents. When terms are used with upper case in other DMP Approved Documents they have the meaning defined here, unless another meaning is explicitly declared. When the terms are used in lower case they do not necessarily imply that the meaning is included in the upper case definitions provided here. For example, "copy" does not necessarily include "Copy", and "use" does not have to include "Use".
|
Access (Content) |
The Function executed by a Device when making Content available so that the Device can execute Functions on it |
|
|
|
|
Adapt (Content) |
The Function of restricting the attributes of a Content Item, e.g. by reducing the Permissions in a License |
|
Adapt (Resource) |
The Function of modifying the attributes of a Resource, such as converting 5-channel music to 2-channel music, or sub-sampling a high-definition video to a standard-definition video, etc. |
|
Adaptation |
A Work that is derived from another Work |
|
AdaptationInstance |
An object or event which is an example of an Identified Adaptation Manifestation (e.g. a File) |
|
AdaptationInstanceCopy |
A copy of an Adaptation Instance |
|
AdaptationManifestation |
An object or event which is an expression of an Adaptation |
|
AdaptationManifestationCopy |
A copy of an Adaptation-Manifestation |
|
Adaptor |
A User who produces an Adaptation |
|
Annotate (Resource) |
The Function of a User who 1. References a specific Fragment of a Resource and 2. Links the reference to another Fragment Created by the User |
|
Approved Document |
Any of the following types of DMP documents 1. Recommended Action 2. Recommended Practice 3. Technical Reference 4. Technical Specification |
|
Assign (Identifier) |
The Function of allotting an Identifier to an Entity |
|
Authenticate |
The Function of confirming the identity of an Entity to a Device or User |
|
Backup |
The Function that supports 1. Duplication of Content 2. Duplication of Rights Expression in case this is a Stateless Rights Expression, and 3. Moving of the duplicate(s) to another location that is not a Device |
|
Binarised XML |
XML data converted to binary form in a lossless fashion |
|
Broadcast |
The Function that Delivers Content to a Device in a point-to-multipoint modality |
|
Bundle |
The Function of binding two sets of Data |
|
Certificate |
A token attesting that an Entity has passed the tests of a Certification Agency |
|
Certification |
The process whereby a Certification Agency issues a Certificate |
|
Certification Agency |
A User appointed by a Certification Authority to Certify Entities |
|
Certification Authority |
A User appointing and overseeing Certification Agencies |
|
Clear-text |
Data that can be Processed as is by a Device |
|
Condition |
The terms and obligations under which Permissions in a License can be exercised |
|
Conformance |
The status of a Content or Device Entity that has been judged to positively meet the requirements of a Technical Specification |
|
Content |
A DMP-defined structure of Content Elements |
|
Content Element |
Any of the following Data types: Resource, Metadata, Content, License, DRM Information, DRM Tool, DRM Tool Pack and Use Data |
|
Content Entity |
Any of the following Entities: Content and Content Elements |
|
ContentGroup |
A group of Content Items for Management within Domains |
|
Content Interoperability |
The capability of a Content Item to be Used by a Device in the way expected by the Device(s) from which the Content has originated. DMP Governed Content is Interoperable with DMP Devices |
|
Content Item |
A particular instance of Content |
|
Content Provider |
A User who Delivers Content to another User |
|
Control Point |
A point in a Device under the control of a DRM Tool, e.g. in a Resource decoding pipeline |
|
Copy |
The Function by which Device A Stores Content in Device B, preserving the original Content in Device A |
| Create | The action of creating a Work without any previous IP Entity |
|
Creator |
A User who generates a Work and makes its first Manifestation, also referred to as author |
|
Credentials |
Information describing the security attributes of an Entity |
|
Data |
Information converted to digital form |
|
Decrypt |
The Function of bringing previously unprocessable Data to a processable form using a Key |
|
Delete |
The Function of erasing a Content Item Stored on a Device |
|
Deliver |
The Function of transferring Content between any two or more Devices using a transport mechanism (file download, broadcast transport protocol or network streaming protocol) |
|
Delivery System |
A system designed to enable Delivery of Content between Devices |
|
Depend |
The un-severable relation between two IP Entities whether physically perceivable or not |
|
Descriptor |
Data that describe the properties of a Resource |
|
Device |
A combination of hardware and software or just an instance of software that allows a User to execute Functions |
|
Device Entity |
Any of the following Entities: Device, User and Domain |
|
Device Information |
Data characterising a Device, e.g. CPU, OS etc. |
|
Device Interoperability |
The capability of a device to exchange data with other devices across standard interfaces, using standard protocols, and to be processed by the devices exchanging the data in a predictable fashion. DMP Devices are Interoperable |
|
Distribution |
The Function of selling, renting and lending |
|
Distributor |
A User who distributes a Product |
|
DMP Content Broadcast (DCB) |
DMP Content Information Packaged for Delivery as Broadcast |
|
DMP Content Broadcast (DCS) |
DMP Content Information Packaged for Delivery as Streaming |
|
DMP Content File (DCF) |
DMP Content Information Packaged for Delivery as File |
|
DMP Content Information (DCI) |
The digital Representation of Content |
|
DMP DRM System |
A DRM System that realizes Interoperability. A DMP DRM system implementation allows Devices to Use Content from another DMP DRM System implementation even though the latter may use different technologies |
|
DMP Information |
Data used to describe Content and Content Elements not related to Governance |
|
Domain |
A set of Devices sharing some common attributes, such as personal or group ownership that is appropriate for various business models |
|
Domain Context Information |
Data characterising a Domain that is Stored in a Device for the purpose of Managing and Licensing Use of Content in Domains |
|
Domain Information |
Data characterising a Domain that is Stored in a Domain Management Device, e.g. the list of Devices, Users, Domain Key etc. |
|
Domain Management |
The set of Functions that relate to the 1. creation, renewal and deletion of Domains 2. joining, renewing and leaving a Domain by Devices and Users 3. Licensing of Content to Domains |
|
DRM Function |
|
|
DRM Information |
Data that describe Governance of Content |
|
DRM Message |
A message exchanged between DRM Tool Bodies, DRM Processor and Devices |
|
DRM Processor |
A module within a Device Certified as being Trusted for executing DRM Functions |
|
DRM system |
A system of Information Technology components and services which strives to distribute and control content and its rights. This operates in an environment driven by law, policies and business models. |
|
DRM Tool |
An algorithm which implements one or more DRM Functions |
|
DRM Tool Agent |
Executable code that instantiates, initialises, Authenticates, and supervises any operation performed between DRM Tools within a DRM Tool Group |
|
DRM Tool Body |
An executable computer code that implements a DRM Tool |
|
DRM Tool Group |
A combination of DRM Tools |
|
DRM Tool Pack |
Executable code that comprises a DRM Tool Group and its DRM Tool Agent |
|
Edit |
The Function of Modifying a Content Item, such as by adding, deleting, or altering pieces of Content in a Content Item |
|
Encrypt |
The Function of making Data unprocessable unless a Key is available to bring the Data to a processable form |
|
End-User |
A User in a Value-Chain who ultimately consumes Content |
|
Entity |
Any of the following: Intellectual Property Entities, Content Entities and Device Entities |
|
Environment |
A Device or set of interconnected Devices. An Environment can interact with other Environments using Protocols and can also interact with the outside of the Environment through appropriate interfaces using protocols |
|
Event |
The execution of a (set of) Function(s) by a Device. It is synonymous with Use |
|
Event Reporting |
The Creation of a DCI containing information of and about an Event and communication of the DCI to appropriate Users |
|
Experience |
The End-User’s emotional and economic result of Using Content |
|
Export |
The Function of making available a Content Item to a non-DMP DRM system |
|
File |
Content Entity which is Stored on a Device |
|
First Fixation |
The Function of making an Instance |
|
Fixate |
The Function of Storing a Manifestation of a Work |
|
Footprint |
The geographic area, typically delimited by political boundaries, intended to be covered by a broadcast signal |
|
Fragment |
A time-marked portion within a Resource |
|
Function |
Any action implemented with DMP-specified technologies |
|
Governed Content |
A Content Item that is at least Identified |
|
Grant |
The Function of a User asserting to another User the Permission to Use a Content Item under specified Conditions |
|
Identifier |
The unique signifier Assigned by Identification |
|
Identify |
The Function of Assigning a unique signifier that establishes the identity of Entities |
|
Import |
The Function of Accessing a governed content item from a non-DMP DRM system |
|
Instance |
An object or event which is an example of an Identified Manifestation (e.g. a File) |
|
Instantiator |
A User who produces an Instance |
|
Integrity |
The state of a Content Item or a Device when the information contained has not been altered or corrupted |
|
Intellectual Property (IP) |
Any identifiable product of the mind attributable to any person(s) or legal entitie(s) that can be represented or communicated physically and protectable by copyright or similar laws. |
|
Interface |
The Data interchange point between 1. Devices 2. Devices and devices 3. Devices and Users 4. Devices and Delivery Systems |
|
Intermediary |
Any Value-Chain User with the exclusion of Creator and End-User |
|
Interoperability |
The ability of a User to technically execute Functions through Interfaces and Protocols, based on open specifications, with predictable results |
|
IP Class |
An ordered set of IP Entities |
|
IP Entities |
Types of IP Represented as Content: Work, Adaptation, Manifestation, Instance |
|
Jurisdiction |
The geographic area over which a given set of laws is enforced |
|
Key |
Data used by a cryptographic method to make Clear-text Data Encrypted or, conversely, Encrypted Data Clear-text |
|
Key Management |
The set of processes employed to create, authenticate, issue, distribute, store, recover, and revoke Keys |
|
Lend |
The Function of Moving a Content Item Stored in one Environment for temporary Use into another Environment |
|
Licence |
Data Representing the Permissions to a Content Entity under given Conditions expressed by Rights Expressions that are Granted by one User to another User |
|
License |
The Function by which a User Grants Permissions to Use a Content Entity |
|
Licensee |
The User to whom another User Grants Rights |
|
Licensor |
The User who Grants Rights to another User |
|
Link |
The establishment of a relationship between two Fragments |
| MakeAdaptation | The action of making an Adaptation |
| MakeAdaptationManifestationCopy | The action of making a ManifestationCopy |
| MakeAdaptationInstanceCopy | The action of making an Adaptation InstanceCopy |
| MakeAdaptationInstance | The action of making an Instance from an Adaptation |
|
MakeAdaptationManifestation |
The action of making an Adaptation Manifestation. |
| MakeCopy | See Copy |
| MakeInstance | The action of making an Instance from a Manifestation |
| MakeManifestation | The action of making a Manifestation. |
| MakeWorkInstanceCopy | The action of making a Work InstanceCopy |
| MakeWorkManifestationCopy | The action of making a Work ManifestationCopy |
| MakeWorkInstance | The action of making an Instance from a Work Manifestation. |
| MakeWorkManifestation | The action of making a Manifestation from Work. |
|
Manifestation |
An object or event which is an expression of a Work |
|
Mechanical Reproduction |
The Function of making physical copies of a Product |
|
Metadata |
Data that describe Content and Content Elements |
|
Move |
The Function by which Device A Stores Content in Device B deleting the original Content in Device A |
|
Package (Content) |
The Function of Processing Content for the purpose of Delivering it between Devices |
|
Parse |
The Function of looking for useful Data in Data |
|
Pause |
The Function of suspending the Rendering of a Resource by a User |
|
Performer |
A type of Instantiator |
|
Permission |
The ability to execute Functions on a Content Item |
|
Platform |
The technology infrastructure that enables Users to Use Content |
|
Play |
The Function of Rendering a Resource |
|
Policy |
A principle accepted by a group of Users |
|
Primitive Function |
A Function typically embedded in a Function or more than one Function |
|
Principal |
The User to whom Permissions are Granted |
|
Private Copy |
The Function of Storing Content and hold it private for non commercial purposes |
|
Private Key |
A Key used to Encrypt Data that only the corresponding Public Key can Decrypt or Decrypt data Encrypted by the corresponding Public Key |
|
Process |
The Function of transforming Data executed by a Device |
|
Produce |
The Function of making Products |
|
Producer |
A User that makes Products |
|
Product |
A Content Item that adds value to IP Entities by including them with an appropriate Licence for the purpose of Publishing |
|
Protocol |
Data formats and rules Devices must follow to exchange information with each other |
|
Public Communication |
The Function of publicly displaying/performing, e.g. live performance, radio, television, internet streaming, multicast of Instances and Manifestations, and download |
|
Public Key |
A Key used to Encrypt Data that only the corresponding Private Key can Decrypt or Decrypt data Encrypted by the corresponding Private Key |
|
Publish |
The Function of making available a Product to other Users |
|
Publisher |
A User who selects a Product and makes it available to other Users |
|
Quote |
The Function of referencing or extracting a Content Item from another Content Item |
|
Rate (Content) |
The Function of measuring the Use of a Content Item by a set of Users |
|
Register |
The Function of Assigning an Identifier to an Entity and keeping a record of it |
|
Registered Content |
Content to which an Identifier has been Assigned by a Registration Agency |
|
Registration Agency |
A User appointed by a Registration Authority to Assign Identifiers |
|
Registration Authority |
A User managing Identifier name spaces, and appointing and overseeing Registration Agencies |
|
Release |
The Function of making a Content Item available to other Users, e.g. at commercial terms |
|
Render |
The Function of converting a Resource to a human-perceivable form |
|
Rent |
The Function of Moving a Content Item that was Used in one Environment for Use in another Environment in an exchange based on a Value-Expression for a given period of time |
|
Represent |
The Function of expressing information in a form that can be processed by a Device |
|
Resource |
Data, whose Representation is not specified by DMP (e.g. an MP3 file or an executable code), that can be Processed by a Device |
|
Resource Processor |
A module within a Device capable of processing Resources |
|
Resource Type |
A Resource such as video, audio, audio-visual, text, synthetic audio, 2D/3D graphics etc. |
|
Restore |
The Function of Moving Content and the associated Stateless Rights Expression, if any, to the Device from which Backup had been performed |
|
Retailer |
A User who sells or Licenses Content to an End-User |
|
Revoke |
The Function of recalling a Content Item or removing the ability of a Device to Use Content |
|
Rewind |
The Function of restarting the Rendering of a Resource |
|
Right |
A consequence of ownership of Intellectual Property yielding the ability of performing one or more Functions |
|
Rights Data |
Data that describes the semantics of actions that can be taken on or with IP Entities |
|
Rights Expression |
Data that can be Processed to obtain the list of Functions Permitted on a Content Item and the Conditions under which they can be performed |
|
Rights Holder |
A User who has Rights to License Content |
|
Role |
A defined set of actions and corresponding Conditions attributed to and required of a User |
|
Schema |
A description of the structure and rules an XML document must satisfy |
|
Secure Authenticated Channel (SAC) |
A Delivery System that is secure and Encrypted |
|
Service |
A set of Functions executed by a User on Content that is valuable for another User or Users |
|
Signature |
Data Encrypted with a Private Key and appended to other Data typically for the purpose of guaranteeing the Integrity of the Data |
|
Stateless Rights Expression |
A Rights Expression that does not include any Use counts or overall Use duration etc. |
|
Store |
The Function by which Device A Delivers Content to Device B for the purpose of retaining it in Device B for Use at a different point in time |
|
Stream |
The Function of Delivering Content to a Device where the transferred Content is Processed for Rendering only and not Stored |
|
Super Distribution |
A mechanism that 1. Allows an End-User to Distribute Content to recipient End-Users or Devices and 2. Enables the End-Users of the recipient Devices to obtain a Licence for the said Content |
|
Synchronise |
The Function of concurrently performing/displaying two distinct IP Entities each for a different human sense e.g. text and audio or video and song |
|
Syndicate |
The Function of Licensing Works or Content for Publication or Distribution by more than one Publisher or Distributor, typically simultaneously |
|
Technical Specification |
A type of Approved Document containing normative clauses. Its use in Devices, Contents and Services may require business agreements between relevant Users. Such business agreements are outside of DMP |
|
Territory |
The geographical area under a Jurisdiction |
|
Tool |
A technology capable of implementing a Function |
|
Traditional Right and Usage |
A Right or exception or custom to use content in a given manner within Jurisdiction |
|
Trick Modes |
Any of the following Functions, or Functions of a similar type, performed on a Content Item during Rendering by a User: 1. Fast forward 2. Slow motion 3. Freeze frame 4. Fast reverse 5. Slow reverse |
|
Trust |
A state where Device Entities enable Users to execute Functions on Governed Content |
|
Trust Management |
The set of mechanisms by which Trust can be established, preserved and severed |
|
Use |
The execution of a Function on a Content Item by a Device |
|
Use Case |
A description of a specific case involving the establishment and operation of a Value-Chain that can be implemented using the Tools specified in Approved Documents |
|
Use Context |
The association of a Content Item with other Content Items and the circumstances of Use |
|
Use Data |
Data documenting the Functions performed by a Device on a Content Item and the associated context |
|
User |
Any person or legal entity in a Value-Chain connecting (and including) Creator and End-User. For the purpose of the current phase of Approved Documents a User is represented by a device or by a User Identity on the Device (e.g. username/password). |
|
User Data |
Data related to a User |
|
User Identity |
Data that establish the distinct personality of a person or a legal entity |
|
Utilize |
The Function of employing a Manifestation or Instance for the purpose of making a new IP Entity |
|
Value-Chain |
A group of interacting Users, connecting (and including) Creators to End-Users |
|
Value-Expression |
The equating of any two groupings of Content Items and/or Services |
|
Verify |
The Function of assessing 1. The Integrity of a Content Item 2. The Integrity of a Device 3. The Role adopted by a User with respect to the IP Entity represented by a Content Item |
|
Withdraw |
The Function of a Creator that discontinues any and all Licenses to Use one or more of his Works |
|
Work |
A creation that retains intellectual or artistic attributes independently of its Manifestations |
|
WorkInstance |
An object or event which is an example of an Identified Manifestation of a Work (e.g. a File) |
|
WorkInstanceCopy |
A copy of a WorkInstance |
|
WorkManifestation |
An object or event which is an expression of a Manifestation of a Work |
|
WorkManifestationCopy |
A copy of a WorkManifestation |
This Approved Document No. 7 – Reference Software provides a normative reference software implementation of the DMP specification. The Reference Software for the DMP specification is available in source code under the terms of the Mozilla Public License Version 1.1 [48] and is currently under development by the Chillout project [47]. As the software is constantly improving and new functionalities are added over time, it is recommended to get the latest news about the code on the Chillout web site [50].
Chillout offers a set of Java libraries implementing the basic DRM functionalities (Core library), support functionalities (Auxiliary library), and Applications for the different Devices that are based on these. Chillout can also be used to test conformance of independent implementations and therefore to enable the building of Value Chains whose individual Devices interoperate in spite of them coming from independent implementers.
Chillout Devices currently run on Windows, Mac and Linux Operative Systems.
Proper understanding of this Approved Document is facilitated by a careful reading of the Foreword and of Approved Document No. 2 – Architecture [1], Approved Document No. 3 – Interoperable DRM Platform [2], Approved Document No. 4 – Use Cases and Value-Chains [3] and Approved Document No. 6 – Terminology [5].
The DMP Reference software is organised in the following structure:
1. Core library: library of classes implementing the Primitive functions defined in the Technical Specification. This software is normative as much as the Technical Specification and provides the functionalities needed to:
• Represent: a set of classes to generate and parse the XML structures defined by the DMP Technical Specifications;
• Package: a set of classes to generate and parse the DCF and DCS;
• (perform the) Protocols: a set of classes to generate and parse the messages exchanged by two Devices performing the Protocols, and providing the functionality to send and receive such messages
2. Auxiliary library: library of classes encapsulating the functionalities of a number of modules which a Device may have as a hardware or software implementation. This library is not normative, in real Devices, these modules are supposed to be replaced by proprietary ones. However the interfaces made available by some or by all the components of this library may become part of the DMP Technical Specification. A preliminary list of the modules part of the Auxiliary library is given below;
• Security manager: module incorporating all those functionalities such as secure storage of digital Certificates and Licenses, performing signature operations, etc...
• DRM Processor: module parsing the DRM Information in a DCI, instantiating and managing the required DRM Tools, etc...
3. Applications: a set of sample applications with the purpose of showing how to use the classes part of the Core and Auxiliary library and to provide a number of demonstrators of the DMP functionalities. This category includes a number of Devices: SAV, CCD, LPD, CPD, CID, TPD, DID, DMD. This library also includes testing applications such as those for testing Protocols, well-formedness of DCI, License, etc. The figure below shows the list of all available Devices and a possible way of inter-connecting them.

Figure 221 – A network of Devices
The figure below shows the relationship between the software libraries described above. For simplicity, the Utility library is not shown in the figure, as its functionalities are available to all other classes.


Figure 222 – DMP Reference software layers
The DMP Reference Software is available from the Chillout Subversion ([50]) repository [49]. The code can be downloaded by any computer using a Subversion client, and it can be automatically built by Apache Maven 2 [52] project management tool.
The figure below shows the Chillout Subversion repository when explored by employing a Subversion client:

Figure 223 – Overview of the Chillout software repository
The following modules are currently available in the trunk remote folder:
· chillout_auxiliary: library of classes encapsulating the functionalities that every device must have when operating in a real environment. This library is not normative, as these modules may be replaced by those a developer needs.
· chillout_ccd: The Content Creation Device is an application allowing a User (e.g. an author) to create Content: the DCI and the DCF.
· chillout_cid: The Content Identification Device is a server application issuing identifiers to new content items created by a SAV or a CCD
· chillout_core: library providing the functionalities needed to Represent (a set of classes to generate and parse the XML structures defined by IDP), to Package (a set of classes to generate and parse the DMP Content File and Streaming formats) and to perform the Protocols (a set of classes to generate and parse the messages exchanged by two devices performing the Protocols)
· chillout_cpd: The Content Provider Device is a server application allowing Content creators/distributors/publishers to make available their Content via a streaming protocol or downloaded as a file.
· chillout_did: The Device Identification Device is a server application providing Digital Certificates to other Devices upon request.
· chillout_dmd: The Domain Management Device is a server application allowing, among the other functionalities, Domain Administrators to create Domains where Governed and un-Governed Content can be Accessed by any Device or User part of them, and Devices and Users to subscribe to them
· chillout_lpd: The License Provider Device is a server application issuing Licences to Devices or Users, Granting them the Right to use Content.
· chillout_sav: The Stationary Audio and Video Device is an application capable of playing audio-visual Governed and un-Governed Content either stored in files or streamed over network Protocols. By means of a browser integrated in the application, users can browse a Content Provider Devices' portal to select content for real time streaming or file download.
· chillout_tpd: The DRM Tool Provider Device is a server application providing DRM Tool Bodies (modules performing DRM functions such as Decryption, watermarking, etc.) to a SAV or a CCD upon request.
· maven-plugins: A folder containing source code not developed by Chillout which is needed for the correct installation of the Chillout software
· mpegtools: A folder containing MPEG reference software which is used by Chillout code, among which the Digital Item Streaming [29] reference software.
In addition to the Project Object Model (POM) [52] describing the whole software, each individual module has its own POM containing the instructions needed by Maven to build it.
The Chillout software needs a number of software tools in order to be compiled on a computer. These are:
· JDK 5.0 or above [53]
· A Subversion client [49]
· Apache Maven 2 [51]
Each individual module also requires a number of libraries in order to be compiled; these are downloaded automatically by Maven when it is executed. In addition to these, each module may require additional external software in order to run, such as the Apache Tomcat servlet Container [55], Apache Ant [56], etc. Further details on the software dependencies for each module will be given in the sections describing all modules individually.
The Chillout Core Library provides the functionalities needed to:
· Represent: a set of classes to generate and parse the XML structures defined by IDP.
· Package: a set of classes to generate and parse the DMP Content File (DCF) and Streaming (DCS) formats.
· (perform the) Protocols: a set of classes to generate and parse the messages exchanged by two devices performing the Protocols, and providing the functionality to send and receive such messages
The figure below shows the Core module on the Chillout Subversion repository when explored by employing a Subversion client:

Figure 224 – Overview of the chillout_core module
Chillout Core, by following the standard Maven structure, is divided in two branches: the main and the test branch. The main branch contains the classes implementing the functionalities of this module, while the test branch contains a number of JUnit [58] classes for testing some of the main classes. The pom.xml file describes how the chillout_core project shall be built by Maven 2.
Note: As Java does not allow naming a package with the name "package", the classes part of the Package section are contained in a package named "_package".
The DCI, i.e. the information related to content, such as its structure, Metadata, Identifiers, Licences, protection etc. as well as the payload of any message exchanged between two devices is expressed in XML. The Chillout Core library provides a set of classes that allow an application to easily generate any XML structure defined in IDP, and conversely to extract any information contained within.
As shown in the figure below, the Represent classes are divided in two main modules: level0 and level1. A few classes: DCIMaker, DCIParser, ItemParser and Mpeg7SMPParser are external to both modules, as they provide the functionalities to manipulate some of the main XML structures such as the DCI, its Content Elements and any related Metadata (when Expressed according to the MPEG-7 Simple Metadata Profile).

Figure 225 – Overview of the Represent classes
The level0 classes have been generated by employing an Open Source software tool called Java Architecture for XML Binding (JAXB) [57]. By taking the IDP schemas as input, JAXB can generate a set of Java classes for manipulating XML structures conformant to the schemas. The figure below shows how JAXB is employed to generate the level0 classes.

Figure 226 – JAXB Architecture as employed by the Represent classes
For each XML complex type defined in the IDP schemas, JAXB has generated a class with the same name of the complex type. Each of these classes provides the basic methods to read and write the corresponding XML complex type.
In order to facilitate the Applications to use the functionalities provided by the level0 classes, a set of classes have been developed as part of the Represent section. For enabling access to those XML elements used more frequently by Applications, a corresponding level1 class has been developed as a wrapper around the level0 one.

Figure 227 – The level1 and level0 classes
Users in Media Value Chains sometime require transferring media resources, DCIs and licenses bundled together. IDP-2 specifies the DCF and DCS when the bundle is stored in a file or sent over a stream (e.g. MPEG-2 TS) respectively.
The DMP specifies to Package Content as a Stream using the ISO/IEC CD 21000-18 Digital Item Streaming (DIS) [29] technology.
This section specifies how to Package Content into the DMP Content File (DCF). The Core library provides a set of functions to bundle media resources with the DCI and other information in a DCF, and conversely to extract this information from a DCF.
The logic structure of DCF is shown in the figure below.

Figure 228 – Logical Structure of DCF
And a DMP Box static view is also shown here:

Figure 229 – DMP Box static view
The purpose for Package is to create and parse DMP Content in a standard way, which is done here by DCF Maker and DCF Parser. For DCF Maker to work properly, we need to provide DCF Maker with information including Content Resource, Resource ID, License, License ID and DCI. The DCF Parser will extract information such as Resource ID, Content Resource,License ID, License, DCI, etc. A model for Package is shown below:


Figure 230 – Input/Output Model of Package Protocol
A static view of DCF Maker is shown below:

Figure 231 – DCF Maker static view
DCF Maker is to make a DCF object by generating all kinds of boxes according to AD #3 from input information such as license data,license ID,resource location,resource ID, and storing them in the DCF object. Then DCF Maker converts all the boxes into bytestream and write this bytestream into a file. DCF Maker provides users with data input interfaces and output .dcf file, hiding all the details for boxes processing. As described here, the DCF Maker activities view is given below.

Figure 232 – DCF Maker Activities View
DCF Parser is to extract out all the requested information from the received DMP Content File (.dcf file) according to AD #3.

Figure 233 –DCF Parser Static View
Conversely, DCF Maker reconstructs all the boxes from the bytestream read out from a DCF file. Then DCF Maker parses all the boxes according to the DCF format specified by IDP-3 and extracts out all the information needed by users. Its activities view is shown below.

Figure 234 –DCF Parser Activities View
The chillout_core library does not require any additional software in addition to those mentioned in 7.1.3. The software libraries on which chillout_core is based on are automatically downloaded by Maven from the remote locations where these are available.
Unlike the Core library, the Auxiliary library has no normative value. It comprises those classes encapsulating the functionalities of a number of modules required for devices to operate according to the IDP specification. However, commercial application may well decide to implement those key DRM components in a proprietary way, even in hardware, therefore Chillout decided to group them in the Auxiliary library.
On the other hand, in order to provide interoperability at a deeper level, some of the interfaces made available by the Auxiliary components may become part of the IDP-3 Technical Specification.
The figure below shows the Auxiliary module on the Chillout Subversion repository when explored by employing a Subversion client:

Figure 235 – Overview of the Auxiliary classes
The IDP does not specify any specific algorithm to govern media resources: this choice is left to the user implementing the specification. However, IDP does specify how to signal that one or more media resources part of a content item are governed, and which DRM Tools shall be employed to access it.
The DRM Processor is the SAV module in charge of instantiating and managing the DRM Tools protecting a media resource. After receiving the list of all the DRM Tools required for each governed media resource, the DRM Processor locates them either locally on the SAV or remotely, and instantiates them. Usually, before any governed resource is processed, the DRM Tools are required to mutually authenticate with the platform on which they operate. This operation, too, is made possible by the DRM Processor. If this operation succeeds, the DRM Processor initialises any DRM Tool requiring it, and acts as a message dispatcher between any DRM Tool and the SAV during the lifetime of the Tool.
The message payload exchanged by means of the DRM processor is defined in IDP-2. This allows a standard communication protocol between DRM Tools and the hosting SAV not just for authentication purposes, but also for exchanging various types of information, such as decryption keys extracted from the DCI.
The DRM Processor provided in the Chillout Auxiliary library provides a reference implementation of the functionalities described above. It is expected that this module could be replaced by a tamper-resistant component in commercial implementations.
All the DRMProcessing functionalities are depicted in a common interface, org.dmp.chillout.auxiliary.drmprocessor.DRMProcessorInterface. The main methods defined in this interface are described below:
boolean consumeResource(URL location,
List<DRMToolInfo> tools,
JAXBElement<? extends Right> useType) throws
UnsupportedFeatureException,
JAXBException,
MalformedContentElementException,
SecurityException,
IllegalArgumentException,
IOException,
ClassNotFoundException,
NoSuchMethodException,
InstantiationException,
IllegalAccessException,
InvocationTargetException;
This method is used to create a player to render the resource specified in the location parameter, using the DRM tools information specified in the tools parameter. The useType parameter is used to check if the requested operation is available (Play, GovernedCopy, ...). This method returns true if the resource was correctly rendered, false otherwise.
boolean manageResource( List<DRMToolInformation> tools,
URL oldResourceFileName,
URL newResourceFileName) throws UnsupportedFeatureException,
MalformedURLException,
IOException,
JAXBException,
MalformedContentElementException,
ClassNotFoundException,
SecurityException,
NoSuchMethodException,
IllegalArgumentException,
InstantiationException,
IllegalAccessException,
InvocationTargetException;
The method above is used to encrypt a resource specified in oldResourceFileName in a new file specified in newResourceFileName, using the DRM tools information specified in tools. This method returns true if the resource was encrypted correctly, false otherwise.
This interface also provides a number of methods as described in the two figures below.
boolean createPlayer(URL location) throws UnsupportedFeatureException, JAXBException, MalformedContentElementException, SecurityException, IllegalArgumentException, IOException, ClassNotFoundException, NoSuchMethodException, InstantiationException, IllegalAccessException, InvocationTargetException;
This method, called by the above method consumeResource, needs to be implemented by a general PlayerManagerEngine. It has to create and prepare a media chain to consume the passed resource
boolean encryptResource(URL oldResourceFileName, URL newResourceFileName) throws UnsupportedFeatureException, MalformedURLException,IOException, JAXBException, MalformedContentElementException, ClassNotFoundException, SecurityException,
NoSuchMethodException, IllegalArgumentException, InstantiationException, IllegalAccessException, InvocationTargetException;
This method, called by the above method manageResource, needs to be implemented by a general PlayerManagerEngine. It has to create and start a media chain to manage the passed resource. The result managed resource is saved in the newResourceFileName
boolean realize();
This method, called usually by SAV, needs to be implemented by a general PlayerManagerEngine. It has to inform the media player chain to play
boolean mute();
Mute the player. Return true if no exception are reached, false otherwise.
boolean unMute(float volume);
Set the volume of the player to volume. Return true if no exception are reached, false otherwise.
boolean setVolume(float volume);
Set the volume of the player to volume. Return true if no exception are reached, false otherwise.
double getDuration();
Return the duration of the resource.
double getMediaTime();
Return the current media time of the played resource.
boolean setMediaTime(double time);
Set the current media time of the played resource. Return true if no exception are reached, false otherwise.
boolean isStarted();
Check if the media Player is playing
boolean isPrefetched();
Check if the media Player is ready to play
boolean isRealized();
Check if the media Player is starting to be ready to play
boolean start();
Start the media chain
boolean stop();
Stop the media chain
boolean destroy();
Destroy the media chain
//boolean createPlayer(RTPConnectionInfo rtpci, ArrayList al) throws Exception;
create a player for RTPConnection (todo)
//boolean startRecording(String inputUrl, String destlocation) throws Exception;
start recording (todo)
//boolean autoPlay();
autiorun the resource (todo)
boolean addDRMProcessorListener(DRMProcessorListener listner);
boolean removeDRMProcessorListener(DRMProcessorListener listener);
adding and removing listener that has to be notified from this interface
The DRMProcessorImplementation class, an abstract implementation of the DRMProcessorInterface was developed. Nowadays this class is employed to manage DRM Tools in controlPoint=1 and to forward to the player implementation all the requests received. This class will be extended to manage the authentication and the downloading of missing DRM Tools from a TPD.

Figure 236 – DRM Processor
When a CCD or a SAV needs to access the functionalities of the DRM Processor, they simply need to instantiate the target EngineImplementation (JMFEngineImplementation in the case JMF is specified as the DRMProcessor's mediaplayer, GstreamerEngineImplementation in the case of Gstremaer. This can be specified by testing the CCDContext or SAVContext static classes (In the case of a CCD or a SAV respectively). For example:
|
DRMProcessorInterface mediaPlayer;
mediaPlayer=MediaPlayerFactory.getFactory(SAVContext.getMediaPlayerFactory()). createMediaPlayer();
|
The SAVContext class finds the MediaPlayer property in the SAVConfig.properties file.
|
MediaPlayerFactory=org.dmp.chillout.auxiliary.mediaplayer.jmf.JMFFactory # MediaPlayerFactory=org.dmp.chillout.auxiliary.mediaplayer.gstreamer. GstreamerFactory |
After instantiation, CCD/SAV simply require the consumeResource/realize functionalities to consume the media or manageResource to manage the media:
|
//in the SAV scenario mediaPlayer.consumeResource(location, tools, useType); mediaPlayer.realize(); |
|
//in the CCD scenario mediaPlayer.manageResource(tools, oldlocation, newlocation); |
The SAV/ CCD has also to listen about event thrown by the DRM Processor, to be notified when the media player emits an EOS signal, or to simply check which is the current media time. The list of events thrown by the DRMProcessorInterface are:
|
EndOfMediaDRMProcessorEvent: throwed when the media is totally consumed
SetRenderingComponentDRMProcessorEvent (Component renderingComponet): throwed when the component to realize the media can be used
ReachedErrorDRMProcessorEvent (String msg, Exception ex): throwed when a generic error is reached
SendMessageDRMProcessorEvent (String msg): throws an generic message to the player
ControllerClosedDRMProcessorEvent: throwed when controller is closed (JMF semantics)
StartEventDRMProcessorEvent: throwed when the media is started
StopEventDRMProcessorEvent: throwed when the media is stopped |
Description of the DRMProcessingPackage:
package org.dmp.chillout.auxiliary.drmprocessor:
· DRMProcessorInterface: interface that summarize all the DRMProcessor functionalities;
· DRMProcessorImplementation: abstract class that implement (some of) the DRMProcessorInterface's methods. It adds support for DRM Tool Control Point 1;
· DRMProcessorListener / DRMProcessorEvent: classes that support dispatching message between DRMProcessor and CCD/SAV;
· DRMProcessor: class that manage DRMProcessing functionalities (for instantiation purpose)
· DRMTool_CCD / DRMTool_SAV / DRMTool: class that support DRMTool's description
package org.dmp.chillout.auxiliary.drmprocessor.event:
· List of events that can be dispatched between DRMProcessor and CCD/SAV
package org.dmp.chillout.auxiliary.mediaplayer.gstreamer:
· Class that supports all the needed steps to instantiate, render and copy a resource using Gstreamer platform as media player.
package org.dmp.chillout.auxiliary.mediaplayer.jmf:
· Class that supports all the needed steps to instantiate, render and copy a resource using JMF platform as media player.
DRM Tools are certainly among those DRM components that a user wishing to make a commercial implementation of Chillout would provide on his own, either in software or in hardware, as these may contain the "secrets" of his business. However, the Chillout project has provided as part of the Auxiliary library a DRM Tool performing DES decryption, which can be used either in real applications or as a reference to build new DRM Tools.
All the DRMTool functionalities are depicted in a common interface, org.dmp.chillout.auxiliary.drmtool.ToolInterface. The methods defined in this interface are described below:
public void setCPIDs(int[] CPIDs);
public int[] getCPIDs();
These two methods permit to get and set the Control Point Ids related to the current drmtool
public void setEncryption(boolean encType);
public boolean isEncryption();
These two methods permit to get and to set the encryption type of the current tool (true means encryption, false means decryption)
public void setKey(byte[] keyData);
public byte[] getKey();
These two methods permit to get and to set the encryption key of the current tool
public String getToolID();
public void setToolID(String toolID);
These two methods permit to get and to set the name of the current tool
public int getDefaultControlPointID();
These methods has to return the default control point ID
Depending on which media player is used to manage/consume the resource, a different implementation of the above interface has to be realized. This implementation has to be regard with all the drmtool functionalities the media chain needs for processing a media. For Example, the JMF consider the interface Codec as a envelope where we can insert our drmtool. So, the implementation of a drmtool for JMF (called JMFToolInterface) has to extend ToolInterface, but also javax.media.Codec. A sketch of the scenario is depicted below

Figure 237 – DRM Tool usage
The ToolInterface's functionalities are so on used only by DRMProcessor when, at start up, instantiate all the specified tools in the right CPIDs and for the right Action. This instantiation phase is absolutely transparent to the media player user, so it can be concentrate on the really use of this tool and not how are they managed/instantiated.
The License Authorisation Engine is a software module that has the following:
· Input:
o An REL license file
o A Query file consisting of a principal, right, resource, and context information
· Output:
o Authorization result:
§ YES – Authorized
§ NO – Not authorized and why.
§ MAYBE - Some Conditions could not be verified
The figure below shows a high level overview of the License Authorisation Engine architecture:

Figure 238 – Overview of the License Authorisation module
· Using the License Authorisation module as a stand-alone application
By following the example in chillout_auxiliary\src\test\...\licenseauthorisation.test.AuthorisationEngineTest, it is possible to specify a License file name and a Query file name to give in input to the AuthorisationEngine class. The result of the process is both printed on the screen and wrote to a log file.
One example of License and three examples of Query are provided in chillout_auxiliary\src\test\resources: one which will succeed, one which contains unverifiable Conditions (and therefore the Authorisation Engine will return "maybe" and one which will fail.
· How the License Authorisation module is used in the SAV
Every time the SAV is attempting to perform an operation on a Content Item, the SAV Manager first verifies if this is Governed. If yes, the SAV Manager delegates the License Manager to verify whether there are any Licenses Granting the SAV the needed Right. If there is a License in the associated DCI, this is given in input to the License Manager. The License Manager generates a Query corresponding to the SAV intentions over the Content Item. The Principal in the Query is the SAV itself; this information is obtained from the Security Manager.
The License Manager performs the Authorisation process first by using the generated Query file and the License given in input from the SAV Manager (if this was available). If this is not sufficient to satisfy the request, any further License for the same Content Item contained in the Security Manager is also checked against the Query. The process stops as soon as a License satisfying the Query is found, and in this case the License Manager returns to the SAV Manager a positive result.
In the case no License was able to satisfy the request in the Query, a negative result is returned instead. At this point, the SAV Manager may prompt the User if he wants to perform the Access License Protocol to obtain one.
The media player package manages all the media player functionalities needed to manage/consume a media resource. Depending on the chosen media player framework, a subpackage is considered: for JMF purpose the mediaplayer.jmf is deployed, for Gstreamer the mediaplayer.gstreamer.
Mediaplayer.MediaPlayerFactory is the main class (that acts as a Factory) that has to be called to instantiate the chosen media player framework.
|
DRMProcessorInterface mediaPlayer;
mediaPlayer=MediaPlayerFactory.getFactory(SAVContext.getMediaPlayerFactory()) |
As already described in previous chapter, the MediaPlayer factory is used to instantiate a new DRMProcessor interface, usually checking in the SAV/CCD properties file (where the Media Player Framework chosen is specified).
Mediaplayer.gstreamer.GStreamerFactory simply extends Mediaplayer.MediaPlayerFactory, creating a GstreamerEngineImplementation for a DRMProcessorInterface.
GstreamerEngineImplementation is the main class than implements all the DRMProcessor functionalities to manage/consume the media resource using the Gstreamer Media Framework.
Currently this code is experimental, but already permits to manage audio (on mp3) and audiovideo (h263 and raw audio on mov) resources. It interfaces with Gstreamer's dll (on W32 system) using the Gstreamer-java bridge and create an ad hoc pipeline that permit to:
· -render a resource with a decrypt drmtool (in control point 2 and 4)
· -protect a resource with encrypt drmtool (in control point 2 and 4).
To render an audio resources the pipeline is composed by: a filesource element, a drmtool plugin (if requested), a mad decoder, an audioconverter, an audioresample and a directsoundsink (on W32 system). For audiovideo resources: a filesource element, a ffdemux_mov_mp4_m4a_3gp_3g2_mj2 demultiplexer, a queue for both audio and video elementary streams, two drmtools (if requested), a ffdec_h263 decoder, a ffmpegcolorspace and videoscale converter, an audioconverter, an audioresample, a directsoundsink (on W32 system) and the Gstreamer-Java Component where the video can be renderer (using sun.java2d.opengl property).
To protect the audio resources the pipeline are simply composed by a filesource element, a drm tool (if needed) and a filesink element. For audiovideo resources: a filesource element, a ffdemux_mov_mp4_m4a_3gp_3g2_mj2 demultiplexer, a queue for both audio and video elementary stream, two drmtools (if needed), a ffmux_mov multiplexer and a filesink element.
Important to note: the protection of the resources is made directly after that the pipeline is created, meanwhile, to render a resource the realize functionalities has to be called after the pipeline is instantiated.
Mediaplayer.gstreamer.JMFFactory simply extends Mediaplayer.MediaPlayerFactory, creating a JMFEngineImplementation for a DRMProcessorInterface.
JMFEngineImplementation is the main class than implements all the DRMProcessor functionalities to manage/consume the media resource using the JMF Media Framework. It simply create a Process with JMF semantics and adding (if needed) a drmtool filter (as effect in JMF semantics) in the media chain. It permits to:
· -render a resource and eventually insert a decrypt drmtool (in control point 2 and 4)
· -protect a resource with encrypt drmtool (in control point 2 and 4).
Due some limitation on the multiplexer JMF element, the supported filetype is just audiovideo (h263 and raw audio on mov). The code has also implemented as a first attempt to support also recording and RTP functionalities. Nowadays this code is off-to-date and is not tested yet.
The Security package contains the Security Manager, a module incorporating all those functionalities such as securely storing digital certificates and Licences, performing operations involving Digital Signatures, X.509 Certificates generation and verification, etc... The security functions provided by the Security Manager are mainly based on the java.security and javax.crypto libraries part of the JDK.
The Security Manager operates on three security repositories: the first containing License information (LicenseInfostore), the second containing Domain Information (DomainInfoStore) and the third containing Keys (KeyStore). The command line tool keytool provided by JAVA 2 SDK is recommended for generating and managing the KeyStore.
Security Manager provides general interfaces (methods) which will meet the common security services required. Those interfaces can be roughly classified into 4 types as follows:
· Secure information storage and retrieval
o
License storage and retrieval
Retrieving from and storing into the License infostore secure License
information using an alias; deleting License information with the given alias
from the License infostore.
The methods for these purposes are:
§ public void addSecureLicenseInfo(String secureInfoAlias, String secureInfo)
§ public String[] getSecureLicenseInfo(String secureInfoAlias)
§ public void deleteSecureLicenseInfo(String secureInfoAlias, String secureInfo)
o
Domain information storage and retrieval
Retrieving from and storing into the Domain infostore secure Domain information
using an alias; deleting Domain information with the given alias from the
Domain infostore.
The methods for these purposes are:
§ public void addSecureDomainInfo(String secureInfoAlias, String secureInfo)
§ public String[] getSecureDomainInfo(String secureInfoAlias)
§ public void deleteSecureDomainInfo(String secureInfoAlias, String secureInfo)
·
X.509 Certificates
Generating X.509 Certificates; retrieving from and storing into the keystore a
Certificate; exporting and importing a Certificate.
The methods for these purposes are:
o public void createUserEntry (String userName, String password, UserInfo userInfo, PrivateKeyEntry privateKeyEntry)public String[] getSecureLicenseInfo(String secureInfoAlias)
o This method is used to add a new user entry in the KeyStore. If the privateKeyEntry parameter is null, a new public/private key pair and a self-signed certificate will be created.
o public void setCertificateEntry(String username, String password, X509Certificate certificate)
o public X509Certificate getCertificate(String alias, String password)
o public X509Certificate getMyCertificate(String username, String password)
o It is used to obtain the X.509 Certificate for the CCD User identified by username and password.
o public void exportMyCertificate(String keyAlias, String password, FileOutputStream fos)
o public String importCertificate(String keyAlias, String password, FileInputStream fis)
o public DeviceID getDeviceID(String username, String password)
· Cryptographic services
General cryptographic services such as key generation, encryption/decryption, generation and verification for both hash and digital signature
The methods for these purposes are:
o public void addSecretKey(String keyAlias, String algorithm, int keysize, String pwdKeyStore, String pwdKeyEntry)
o public KeyPair generateTestKeyPair(String algorithm)
o public byte[] generateRandomKey(String algorithm)
o public byte[] generateHash(byte[] data, String algorithm)
o public boolean verifyHash(byte[] data, byte[] hashValue, String algorithm)
o public byte[] encrypt(byte[] data, String algorithm, String keyAlias, char[] password, boolean symCipher)
o public byte[] decrypt(byte[] data, String algorithm, String keyAlias, char[] password, boolean symCipher)
o public byte[] generateSignature(byte[] data, String algorithm, String keyAlias, char[] password)
o public boolean verifySignature(byte[] data, byte[] signature, String algorithm, String keyAlias, char[] password)
Every Device should have a Security Manager inside for security consideration. To use Security Manager, you need an instance of class SecurityManager and certain engines. SecurityManager provides you convenient interfaces for calling security services, while those engines perform proper operations to fulfill the security services. Currently, you need to build all the codes in folders security_manager and engines under the package of org.dmp.chillout.auxiliary.security. Then the steps are as follows:
1) Instantiate a SecurityManager object:
You must specify the securityInfo object for the SecurityManager to work properly.
PrincipalInfo principalInfo = new PrincipalInfo();
//initialise the principalInfo object with some data (such as country, region domainURI, etc.) //otherwise use the default ones
SecurityInfo securityInfo = new SecurityInfo(licenseInfoStorePathName, domainInfoStorePathName, keyStorePathName, principalInfo);
SecurityManager securityManager = SecurityManager.getInstance(securityInfo);
2) Storing a License in the SecurityManager
securityManager.addSecureLicenseInfo(resourceID, license.generateString())
3) Retrieving all Licenses for a Resource from the SecurityManager
String[] txtLicenses = securityManager.getSecureLicenseInfo(resourceID);
4) Encrypting a String with a specific key
Suppose that you want to encrypt “abc” with a key from your keystore, the steps are like this:
byte[] data = "abc".getBytes();
String algorithm = "AES";
String keyAlias = "mykey";
char[] password = "testkey".toCharArray();
byte[] cipherData = securityManager.encrypt(data, algorithm, keyAlias, password, false);
byte[] plainData = securityManager.decrypt(cipherData, algorithm, keyAlias, password, false);
if(plainData == "abc".getBytes()){
/* test for methods encrypt and decrypt passed */
}
You can call the method getAlgorithms to see whether AES is supported:
String[] cipherAlgorithms = securityManager.getAlgorithms(“Cipher”);
The mutual Authentication package contains a basic Authentication function which is to process the message transferred between two devices when they want to communicate with each other. For example, initializing the Authentication and checking the Certificates
The Mutual Authentication is used between two devices who want to communicate with each other. The general process is below:

Figure 239 – Overview – Mutual Authentication between two devices
When users want to use Mutual Authentication, the important thing is to ascertain that each device has two certificates: one is a certificate for himself and the other one is a CA certificate(CA’s self-signed certificate) which signs the first one. Because the devices in Chillout System use the same CA, all these two devices have the same CA certificate.
Checking messages between two devices
· There is two basic messages: InitAuthenticationType and MutualAuthenticationType
o InitAuthenticationType is a message to initiate the Mutual Authentication process.
o MutualAuthenticationType is a message containing every message which a device should response after the MutualAuthentication is initiated.
·
There is a manage class which manages all the messages between
two devices: basicAuthentication
After device A initiates the Authentication, device B will send the manage
class name to device A and say “we should follow this protocol to process
Mutual Authentication”. If A agree with it and then two devices all will use
this manage class to check all the message communicating between two devices
and response with a result message.
·
Check certificates
After device A sends his certificate to device B, device B will check device
A’s certificate using A’s CA certificate. This will check device A’s validation
and decide whether they will continue the mutual Authentication or end the
mutual Authentication successfully. The check process is like this:
certificated.checkValidity(nowDate);//certificated
is device A’s certificate
PublicKey pubkey=certificating.getPublicKey();//certificating is device A’s
CA certificate
certificated.verify(pubkey);//check certificate
The Mutual Authentication package can be found at the test package: org.dmp.chillout.auxiliary.mutualauthentication.test.
The chillout_auxiliary library depends on the chillout_core library. Additionally, in order to use the Auxiliary library the Java Media Framework [54] is required.
Chillout does not only to provide the source code of core and auxiliary components, but also a set of devices that are easy to configure and run. This helps promoting adoption of Chillout and the DMP specification by enabling those users not experienced in the DRM field, not enough skilled in programming or working for small companies, to experiment with a technology that so far could only be used by those experts in the field.
The Devices contains source and executable Java code built on top of the Core classes, and integrated with Auxiliary classes.
A Stationary Audio and Video Device (SAV) is a software application capable of playing audio-visual resources stored in files or streamed over the IP protocol. By means of a browser integrated in the application, users can browse a Content Provider's portal to select content for real time streaming or file download. The SAV supports playing both clear-text and encrypted resources.
The SAV architecture diagram is shown in the figure below

Figure 240 – Chillout SAV high level architecture
The following walkthrough shows the behaviour of a Stationary Audio and Video Device when a User employs it to play a Content Item.
1 Content Item is of any un-Governed media content types (e.g. mp4)
1.1 Player Manager checks that it is not DCI/DCF
1.2 Player Manager creates an instance of Processor Bridge (PB) communicating the Resource to play
1.3 PB creates an instance of/communicates to the Processor, passing the Resource to play
1.3.1 Processor sets up the media processing chain and play the Resource:
1.3.1.1 A demux is instantiated, based on the file extension
1.3.1.2 The demux reads the container headers and finds information on the ESs
1.3.1.3 Appropriate decoders are instantiated and connected to the demux output
1.3.1.4 Appropriate renderers are instantiated and connected to the decoders output
1.3.1.5 The media processing chain starts to consume the Resource
1.3.2 An ERROR_CODE is sent back if any Errors are reached by Processor / PB
2 Content Item is a DCF/DCI
2.1 Player Manager checks that it is DCI/DCF
2.2 Player Manager creates an instance of DRM Manager
2.3 Player Manager asks the DRM Manager to parse the DCF and the DCI
2.4 DRM Manager returns
2.4.1 a failure value (all possible error codes TBD ) if something went wrong
2.4.2 a handler to a DCIParser class
2.5 Player Manager can use DCIParser class to shows the contents of the DCI to the User
2.6 User chooses a Resource to play.
2.6.1 Player Manager asks DRM Manager to checks if the Resource is:
2.6.2 non-Governed and non-Protected
2.6.2.1 DRM Manager returns a dmp2didl:Resource for the Resource
2.6.2.2 Player Manager parses the passed information to extract Resource information (mime type, etc...)
2.6.2.3 goto a
2.6.3 Governed but non-Protected
2.6.3.1 Player Manager asks the DRM Manager to checks whether the User has a License (either in the DCI or in the Security Manager) granting the Right to play the Governed Resource.
2.6.3.2 DRM Manager returns:
2.6.3.2.1 False (No, User has no Licence):
2.6.3.2.1.1 Player Manager prompts the User to request a License from the LPD specified in the Content or to join a Domain
2.6.3.2.1.2 if successful:
2.6.3.2.1.2.1 Player Manager shows the User that now he can play the content
2.6.3.2.1.3 if not successful:
2.6.3.2.1.3.1 Player Manager shows the User some problems occurs
2.6.3.2.2 dmp2didl:Resource (Yes, the User has a Licence and can play straight away)
2.6.3.2.2.1.1 DRM Manager returns a dmp2didl:Resource for the Resource
2.6.3.2.2.1.2 Player Manager parse the passed information to extract Resource information (mimetype, etc...)
2.6.3.2.2.1.3 goto a
2.6.3.2.3 A User Query Message: User must agree to a text or to some actions (e.g. CC license or generate an ER) before play can occur:
2.6.3.2.3.1.1 Player Manager prompts text to the User and wait for agreement
2.6.3.2.3.2 DRM Manager returns a dmp2didl:Resource for the Resource
2.6.3.2.3.3 Player Manager parses the passed information to extract Resource information (mime type, etc...)
2.6.3.2.3.4 goto a
2.6.4 Governed and Protected
2.6.4.1 Repeat from 3 above, except that, rather then performing "goto a":
2.6.4.1.1 DRM Manager extracts the Master Key from the valid License for the Protected Resource and decrypts it by employing the SAV Private Key in the Security Manager
2.6.4.1.2 DRM Manager decrypts the keys in any KeyData message (in a dmp2rk:Key element) for each DRM Tool specified in the Protected Asset by using the Master key
2.6.4.1.3 DRM Manager returns to Player Manager a dmp2rdm:InitialiseDRMProcessor message, including all the information reached above (i – iv)
2.6.4.1.4 Player Manager creates an instance of DRM Processor Bridge (DRM PB), communicating the Resource to play and the dmp2rdm:InitialiseDRMProcessor
2.6.4.1.5 The DRM PB creates an instance of/communicates to the DRM Processor
2.6.4.1.6 The DRM PB establishes a SAC with the DRM Processor
2.6.4.1.6.1 DRM Manager Encrypts the dmp2rdm:InitialiseDRMProcessor message
2.6.4.1.6.2 sends the dmp2rdm:InitialiseDRMProcessor message to DRM Processor
2.6.4.1.7 DRM Processor decrypts the dmp2rdm:InitialiseDRMProcessor message
2.6.4.1.8 DRM Processor parses the dmp2rdm:InitialiseDRMProcessor and get all essential DRM Tools
2.6.4.1.9 DRM Processor establishes a SAC with the DRM Tools
2.6.4.1.10 DRM Processor initializes DRM Tools
2.6.4.1.11 DRM Processor sends KeyData message (in a dmp2rk:Key element) to appropriate DRM Tool
2.6.4.1.12 DRM Processor configure the media processing chain
2.6.4.1.12.1 A demux is instantiated, based on the file extension
2.6.4.1.12.2 The demux reads the container header and finds information on the Ess
2.6.4.1.12.3 Appropriate decoders are instantiated and connected to the demux output
2.6.4.1.12.4 Appropriate renderers are instantiated and connected to the decoders output
2.6.4.1.13 DRM Processor setup link between DRM Tools and control points in media processing chain
2.6.4.1.14 DRM Processor play the protected Resource:
2.6.4.1.14.1 Protected Resource entering a control point is passed to appropriate DRM Tool to be processed
2.6.4.1.14.2 Resource in clear text is sent back to control point and then be forwarded to next node in the media chain
2.6.4.1.14.3 After the Resource passed through all control points, it is rendered
2.6.4.1.15 A NotifyToolEvent or NotifyDRMProcessorEvent is sent back if any Errors are reached by Processor / PB
The figure below shows the packages part of the chillout_sav module.

Figure 241 – Chillout SAV package overview
Each talker sits in a separate folder. They function as the client side of the Web Services. They are implemented following the Java event model. When talker gets a response from the other party, it wraps up the request result object in an event object and dispatches it to listeners to notify them of the result.Relationship with other Devices
As shown the figure below, DMD manages Domain in co-operation with DoID, LPD, SAV and DomainAdministrator. First of all, DomainAdministrator initiates the CreateDomain protocol to DMD. DMD creates DomainID and DomainaManageInfo for the newly created Domain with DoID.
After the creation of Domain, the protocols between SAV and DMD are used to deliver the Domain membership to SAV.

Figure 242 – Domain set up
The chillout_sav library depends on the chillout_core and the chillout_auxiliary library. Additionally, in order to use the chillout_sav library the Apache Ant [56Error! Reference source not found.] software is required.
The SAV can be used to play DCFs (DMP Content Files), DCIs where Content Items are packaged as DCS (DMP Content Stream) as well as un-Governed Media Resources encoded in a number of formats. Some pre-encoded DCFs are available on the Chillout ftp repository at the following URL: http://wiki.dmpf.org/files/download/DCFs/.
If a valid License is not included in the DCI, but a License Reference is signaled in the DCI, the SAV will perform the Access License Protocol with the LPD specified in that field.
The Chillout Media Player has an integrated browser window that allows the SAV to browse web pages, and can be used in particular to browse the pages displayed by a Content Provider Device.
The Chillout Media Player has a control panel to execute some Domain Administrative operations. As it’s seen in Domain Administrator tab in Domain Administrator tab, three kinds of operations are provided which are CreateDomain, RenewDomain and DeleteDomain. And the necessary parameters for each operation can be inserted in the dialog box below the radio buttons. After selecting desired operation and providing appropriate parameters, the operation is initiated by pressing the Execute Button on the bottom. After successful execution of CreateDomain operation, DomainID of the newly created Domain is shown in the DomainID List box on the right. By selecting one of each DomainID, corresponding parameters are shown in dialog boxes below the DomainID List box.
After successful execution of DeleteDomain operation, the corresponding DomainID disappeares from the DomainID List box.

Figure 243 – Domain Administration GUI in the SAV (1)
The Chillout Media Player has a control panel to execute some Domain operations for this SAV. As it’s seen in Join a Domain tab in Domain Administrator tab, six kinds of operations are provided which are AddDevice, RenewDevice, LeaveDevice, AddUser, RenewUser and LeaveUser. And the necessary parameters for each operation can be inserted in the dialog box below the radio buttons. After selecting desired operation and providing appropriate parameters, the operation is initiated by pressing the Execute Button on the bottom. After successful execution of AddDevice operation, DomainID of the newly added to this SAV is shown in the DomainID List box on the right. By selecting one of each DomainID, corresponding parameters are shown in dialog boxes below the DomainID List box.
After successful execution of LeaveDevice operation, the corresponding DomainID disappeares from the DomainID List box.
AddUser, RenewUser and LeaveUser are not completed yet since SAV doesn’t have the interface to get UserID from user device e.g. smart card.

Figure 244 – Domain Administration GUI in the SAV (2)
The Content Creation Device is a Device capable of creating Content Items with the following characteristics:
1. They may contain audio/visual resources encoded with the most common encoding formats such as MP4, MP3, Quicktime, etc
2. The audio/video resources may be published
2.1. un-Governed
2.2. Governed by means of a License (Creative Commons-like approach)
2.3. Governed by means of a License and protected by means of DRM Tools. The User may choose among a list of DRM Tools the ones to employ to protect each Resource, and may specify the encryption key to be employed by each DRM Tool
3. A license may be added to the Governed/Protected Resources, or a License Provider Device my be specified in the Content, or both
4. A minimum set of metadata (according to the MPEG-7 Simple Metadata Profile) may be added for each Resource and for the whole Content Item
The CCD architecture diagram is shown in the figure below:

Figure 245 – CCD architecture package overview
The following walkthrough shows the behaviour of a Content Creation Device when a User employs it to Create a Content Item.
Add new Resource walkthrough
· User inserts a new record in the CCD database for each Resource (local/remote) he wants to publish. This information includes the location where the Resource resides, Resource metadata (like title, etc...) and Resource ID (alternatively, this can be obtained from a CID). See Figure 246 – Import a Resource in the CCD.
Add new SAV certificate walkthrough
· User adds a new record in the CCD database and CCD Security Manager containing a SAV X.509 certificate DER-encoded. This may be employed to create Content Items containing Protected Resources accessible by that SAV only. See Figure 247 – Import a SAV certificate.
Create a new content item walkthrough
· The User selects to create a new DCI. See Figure 248 – Create a new Content item
· The CCD GUI show the list of all available Resources and the User checks a checkbox next to the Resources he wishes to include in the DCI
· The CCD GUI asks the User, for each checked Resources, how shall be made available (See Figure 249 – Configure Resource DRM settings). The following options are available:
· Non-governed: goto 5)
· Governed only by means of a License (Open Release-like approach) goto 4)
· Governed by License and protected by DRM Tools:
· CCD GUI shows the list of DRM Tools available on the CCD file system (characterised by e.g. Tool ID and Tool description)
· If the User chooses:
· a Single DRM Tool: he also needs to specify the Control Point in which such Tool shall operate
· a ToolPack: he does not need to specify any Control Points
· The User specifies further information needed by the chosen DRM Tool(s) to process the Resource (e.g. encryption key(s), watermark payload, initialisation data, etc. See Figure 250 – Configure DRM Tool settings)
· The User specifies the SAV(s) to whom are Granted the Right to access the Protected Resource (See Figure 251 – Configure a Resource custom License).
· For each Governed Resource:
· CCD GUI creates an instance of DRM Processor Bridge (DRM PB), communicating the Resource to crypt and the information related to the DRM Tools to be employed, including decryption keys etc.
· DRM Processor instantiates and initialize the DRM Tools
· DRM Processor configure the media processing chain
· A demux is instantiated, based on the mimetype specified in the ProtectedAsset
· The demux reads the container header and finds information on the ESs
· Appropriate decoders are instantiated (if needed)
· DRM Processor setup link between DRM Tools and control points in media processing chain
· DRM Processor create the protected Resource:
· Resource entering a control point is passed to appropriate DRM Tool to be processed
· Processed Resource is sent back to control point and then be forwarded to next node in the media chain
· After the Resource passed through all control points, it is written to file system
· If any Errors are reached by Processor / PB a NotifyToolEvent or NotifyDRMProcessorEvent is sent back, otherwise CCD GUI asks DMPContent Builer to request a new resource ID to CID
· For each Governed Resource:
· CCD GUI asks the User to specify (either or both) (See Figure 249 – Configure Resource DRM settings):
· License Reference (LPD url) from where the License for the Governed Resource can be obtained (and eventually give instructions to the LPD on how to issue licences when requests by SAVs will be made)
· Licence
· By performing CCD – LPD protocol specifying some conditions
· Selection a well-known licence
· The CCD GUI ask DMPContent Builder to includes the License and/or the License Reference into the DCI that will be created
· For each Resource:
· CCD asks the User to specify whether the Resource shall be made available in the DCF, Streaming from a Content Provider Device or available in P2P network
· File: CCD asks the DMPContentBuilder to include the Resource in the DCF
· Streaming: CCD asks the User to specify further information such as the CPD URL and additional Streaming instructions for the Resource
· CCD asks the DMPContent Builder to generate the DCI and get a Content ID
· The CCD – CID protocol is performed to request a new Content ID to the CID
· If at least one resource was specified to be available in File the DCF is created
· DMPContent Builder performing the CCD – CPD protocol
Acquire new DRM Tools walkthrough
· User may specify a DRM Tool Provider Device from which the CCD may obtain more DRM Tools than those available on the file system. In this case the CCD will perform the CCD – TPD protocol and download the selected DRM Tools (See Figure 253 – Add a new DRM Tool)
The Content Creation Device stores a number of information in a database which is based on Derby [60]. This information relates to:
· the available Resources, including the metadata describing them
· the available DRM Tools, including a textual description
· the SAV certificates, including a textual description
· the Content Items generated, including the metadata describing them.
|
|
|
|
Figure 246 – Import a Resource in the CCD |
Figure 247 – Import a SAV certificate |
|
|
|
|
Figure 248 – Create a new Content item |
Figure 249 – Configure Resource DRM settings |
|
|
|
|
Figure 250 – Configure DRM Tool settings |
Figure 251 – Configure a Resource custom License |
|
|
|
|
Figure 252 – Publish the Content Item |
Figure 253 – Add a new DRM Tool |
The figure below shows the packages part of the chillout_ccd module.

Figure 254 – Chillout SAV package overview
The contentbuilders package contains the classes needed to create a Content Item, i.e. the DCI, the DCF and the DCS.
The following classes are defined in this package:
l DMPContentBuilder
o As represented in Figure 245 – CCD architecture package overview, and in the walkthrough in 7.4.2.2. This is the class which applications wishing to create a Content item have to call.
l DCIBuilder
o Class for creating a DCI
l MetaBuilder
o Class for creating metadata descriptions for a Content Item or its Content Elements
l MPEG7SMPBuilder
o Class for creating metadata descriptions conforming to the MPEG-7 Simple Metadata profile
l ORCLicenseBuilder
o Class for creating Licenses conforming to the MPEG-21 Rights Expression Language (REL) Open Release Content (ORC) profile
l ProtectedAssetBuilder
o Class for creating a ProtectedAsset element describing a Protected Resource
l ToolListBuilder
o Class for generating the DRM Tool List for a Content Item
The db package contains the classes needed to create, connect to and access the Content Creation Device database.
The following classes are defined in this package:
· CCD_DAO
o Class creating the CCD database (if it does not exist yet in the folder <user_home>/chillout/CCD/db) and providing connection to it
· DBAccess
o Class providing a number of methods for reading from and writing information to the CCD database
· PlayerManager
o This is an interface declaring the below two behaviors which needs to be implemented by the implementation classes.
§ AskUserConfirmation
AskUserConfirmation is to show the user confirmation info.
§ UseResource
The implementation is to implement UseResource to finish the Resource right parsing and validation.
· PlayerManagerImplementation
o This is an implementation of the PlayerManager is an assembler to complete parsing the messages, executing the rights, playing the Content and interact with the end user.
· WebPanel
o WebPanel rends the web browser from the Operation system and interacts with the browser. For more, it also implements WebListener to handle the web exceptions.
· WebListener
o WebListener is an interface to define the handleWebException method.
· WebExceptionEvent
o WebExceptionEvent defines a web event to carry the web exception info from the notifier to the listener.
· ImagePanel
o ImagePanel is to show the image.
· DCIPanel
o DCIPanel is a panel to show the DCI info.
· DomainAdminPanel
o DomainAdminPanel is a gate including the DomainAdminSubPanel1 and DomainAdminSubPanel2 to access the domain management info.
· ContentItemInfo
o ContentItemInfo represents the Content item.
· AboutDialog
o AboutDialog shows the basic info of the SAV device.
The guiprocessors package contains two classes needed to process the information inserted by the user in the CCD GUI. In particular:
· AddResourceProcessor
o Class needed to read the information inserted by the User in the GUI when adding a new Resource, and writing in the GUI the information related to a Resource extracted from the CCD database
· NewContentItemProcessor
o Class needed to read the information inserted by the User in the GUI when creating a new Content Item, and writing in the GUI the information related to a Content Item extracted from the CCD database
The classes defined in this package are basically containers of information exchanged between the GUI components (or any applications wishing to create a Content Item) and the DMPContentBuilder class.
This package contains a few utility classes useful for several purposes
The test package contains a test class, DMPContentBuilderTest, which can be employed to test the DMPContentBuilder class by showing how to employ the main methods of this class to generate DCIs and DCFs.
This feature is currently under development.
This feature is currently under development.
This feature is currently under development.
This feature is currently under development.
In order to run the Content Creation Device, any additional software to those needed to compile the whole Chillout project is needed.
The Content Creation Device depends on chillout_core and chillout_auxiliary modules
The Content Creation Device supports the following functionalities:
1. Add new Resource
o User may insert a new record in the CCD database for each Resource (local/remote) he wants to publish. The location where the Resource resides, the Resource title and Resource ID are the only mandatory fields, although additional metadata can be specified. See Figure 246 – Import a Resource in the CCD.
2. Add new SAV certificate
o User may add a new record in the CCD database and CCD Security Manager containing a SAV X.509 certificate DER-encoded. This may be employed to create Content Items containing Protected Resources accessible by that SAV only. See Figure 247 – Import a SAV certificate.
3. Create a new content item
o The User selects to create a new DCI. See Figure 248 – Create a new Content item
o The CCD GUI show the list of all available Resources and the User checks a checkbox next to the Resources he wishes to include in the DCI
o The User, for each checked Resources, may specify how shall be made available (See Figure 249 – Configure Resource DRM settings). Refer to 4 - Configure Resource DRM Settings.
o The User, for each checked Resources, may specify how shall be made available (See Figure 252 – Publish the Content Item):
§ in the DCF
§ Streaming from a Content Provider Device
§ available in P2P network
o The CCD generate the DCI and gets a Content ID from the specified CID
o If at least one resource was specified to be available in File the DCF is created, otherwise the CCD – CPD protocol is performed
4. Configure Resource DRM Settings
o The following options are available:
§ Non-governed
§ Governed only by means of a License (Open Release-like approach):
· The user may choose among a finite set of license templates.
§ Governed by License and protected by DRM Tools:
· The User may choose among a number of DRM Tools the ones to employ to protect (encrypt) the Resource
· CCD GUI shows the list of DRM Tools available on the CCD file system
· The User specifies further information needed by the chosen DRM Tool(s) to process the Resource (e.g. encryption key(s), watermark payload, initialisation data, etc. See Figure 250 – Configure DRM Tool settings)
· The User specifies the SAV(s) to whom are Granted the Right to access the Protected Resource (See Figure 251 – Configure a Resource custom License) or the License Reference (LPD url) from where the License for the Governed Resource can be obtained (and eventually give instructions to the LPD on how to issue licences when requests by SAVs will be made)
5. Acquire a new DRM Tool:
5.1. User may specify a DRM Tool Provider Device from which the CCD may obtain one or more DRM Tools (See Figure 253 – Add a new DRM Tool)
Content Identification Device is used to assign an identifier for content or content element and authenticate content item.
The following walkthrough shows the behaviour of a Content Identification Device when CCD employs it to identify content or content element.
Identify Content with transfer of DCI walkthrough
1. CCD and CID mutually Authenticate.
2. The CCD sends to the CID an dmp2rcip:IdentifyContentRequest;
3. The CID
a. Assigns a new Content Identifier to the received DCI
b. Adds the Identifier to received DCI
c. Digitally Signs or otherwise Hashes the received DCI
d. Stores the Content ID and the generated Hash value in the CID database
e. Returns the modified DCI to requesting party by including it in an dmp2rcip:IdentifyContentResponse.
Identify Content with transfer of Signature/Hash walkthrough
1. CID and CCD mutually Authenticate.
2. CCD request a Content Identifier from the CID by sending a dmp2rcip:RequestContentIdentifier.
3. CID sends the requested Identifier to CCD by employing the dmp2rcip:RequestIdentifierResponse message.
4. CCD
a. Adds the received Identifier to the DCI to be Identified
b. Computes the hash of the DCI with Identifier included
c. Sends a dmp2rcip:RegisterIdentifier message to the CID .
5. The CID
a. Stores the Identifier together with the Hash in the CID database for future reference.
b. Replies with an dmp2rcip:Ack message to the CCD.
Identify Content Elements walkthrough
1. The CCD:
a. generates the Hash value or the digital Signature of the Content Element to be Identified and inserts it in a dmp2rcip:RequestContentElementIdentifier message
b. sends the message to the CID
2. The CID
a. Generates an Identifier
b. Stores the Identifier together with the Hash value/digital Signature in the CID database
c. returns an dmp2rcip:RequestIdentifierResponse message to the CCD.
The following walkthrough shows the behaviour of a Content Identification Device when any User wishes to verify the authenticity of a Content Item.
Authenticate a Content Item walkthrough
1. The requesting Device (e.g. the SAV):
a. Generate an dmp2rcip:AuthenticateContentRequest message (See Figure 170: The dmprcip:AuthenticateContentRequest element) containing
i. either:
1. the Content ID of the Content Item to be Authenticated
2. (optionally) the DCISignature element containing the hash value of the DCI
ii. or
1. the full DCI Representing the Content Item to be Authenticated
b. Mutually Authenticate with CID
c. Sends the dmp2rcip:AuthenticateContentRequest to the CID
2. The CID:
a. Parses the received dmp2rcip:AuthenticateContentRequest message and generates an AuthenticateContentResponse message containing:
i. either:
1. the DCISignature for the Content Item (if this exists in the CID database), if the dmp2rcip:AuthenticateContentRequest contained the ContentID field. The DCISignature may contain either the digital Signature of the DCI, or its Hash value only, and the Signature/Hash calculation an verification is left to the requesting Device.
ii. or:
1. the AuthenticationResult boolean value, if the dmp2rcip:AuthenticateContentRequest contained the whole DCI in the dmp2_didl:DIDL field. In this case the Signature/Hash calculation and verification is done on the CID
iii. or:
1. An error code specifying that the requested service could not be performed.
Table CONTENTID
Table CONTENTID is used to store the path of file id and signature. Hash value is stored in the signature.
|
Column name |
Column type |
Column instruction |
|
Id |
Bigint |
Primary key |
|
Contentid |
Varchar(100) |
Content identifier |
|
Filepath |
Varchar(100) |
Store the pathe of file signature |
Table CIDCONFIG
Table CIDCONFIG is used to store the configuration items which CID needs.
|
Column name |
Column type |
Column instruction |
|
Id |
Bigint |
Primary key |
|
Name |
Varchar(50) |
Configuration item name |
|
Idvalue |
Varchar(100) |
Configuration item value |
The figure below shows the packages part of the chillout_cid module.

The classes in the package action are used to call business logic object(bo) and control the pages jump according to the processing result by Struts components.
The classes in the package bo are used to process business logic and call the database object dao to implement the database operation according to processing logic.
The classes in the package dao are used to operate the persistent object(po) and finish the database operations according to the Hibernate components operation.
The classes in the package are related to the table data of the web pages and read or store element values in the table according to the Struts components
The classes in the package po are related to the table of the database and implement the operations of the database persistence operation according to the Hibernate components.
The classes in the package service are used to process web service request according to the Axis components and call business logic object(bo) to finish the business logic processing.
The classes in the package vo are used to implement the functionalities which can transfer the element values in the table into persistent objects. The functionalities contain filtering and cleaning up the element value in the table.
The classes in the package Test are used to test the services which CID support in every case.
CCD requests id from CID.
SAV requests content authentication from CID.
In order to run the Content Identification Device, any additional software to those needed to compile the whole Chillout project is needed.
The Content Identification Device depends on chillout_core and chillout_auxiliary modules
The Content Identification Device supports the following functionalities:
1. Identify Content or Content element
2. Authenticate Content Item
Content provider device (CPD) acting as a content-distributor role in DMP content-value-chain, releases legal registered contents to end users. Customers can order the contents through the end-user devices, i.e. SAV (Stationary Audio and Video Device). Usually CCD (Content creation device) creates contents and delivers them to CPD; CPD co-works with LPD (License provider device) sell end users final digital media goods.
When initializing the service to outside, CPD negotiates with LPDs to retrieve concrete license locations and relevant information for every published content. When the service is ready, end users can surf the CPD website to browse the digital goods with corresponding licenses. When user orders the satisfied one, the CPD will assemble the final media content file as DCF format and deliver it to customer through http or web-service path.
The CPD is a web application running on Tomcat server. CPD is composed of four layers:
· Web GUI layer based on Webwork framework
· Business logical layer based on Spring framework
· Data persistence layer based on Hibernate
· Web service layer based on Axis

Figure 255 – The CPD architecture
The CPD is designed following the MVC pattern to arranges the functions into the six packages which are the accesscontentprocessor, the bizlogic, the database, the management, the webservice and the webwork as the below figure. The following would introduce the each package in detailed.

Figure 256 – The CPD layers
· Accesscontentprocessor
This package is responsible for handling the BBL streaming request.
· Bizlogic
The Bizlogic is responsible for processing the content as file request.
· Database
The database package persists the CPD data into the database. It adopts the Hibernate framework and is designed by the DAO pattern. The package composes of the four parts which are the interface part defined in the iface package, the base part defined in the base package, the DAO part in the dao package and the part of the table representatives like Tcontentinfo.

· The interface(iface) part
The iface part defines the contract of the operations of the table object like the table of the content. Currently there are three classes of the IcontentinfoDAO, the IlicenseinfoDAO, and the IuserinfoDAO under the iface packages.
· The base part
The base package contains the_BootRootDAO class implementing all the database access management, the base table representative class mapping to the each table like the BaseTcontentinfo.java and the base operation representative class like the BaseTcontentinfoDAO.java. The base operation class implements all methods from the iface class.
· The dao part
The dao package contains the _RootDAO extending from the _BootRootDAO and the other DAO classes extending from the base operation representative classes. The developer can customize the specific methods to access the database in the DAO classes.
· The table representative part
The table representative classes in the hibernate package which are extended from the base table representative classes can be customized by the developer.
· Management
The management packages works at the biz layer to implement all the business logic like operating the content, the license and the user.

· The bo package
The bo package contains all the classes representing the business objects. The aim of designing the bo is to map the visual objects in the front layer to the persistent objects at the backend layer.
· The content package
The content package contains the ContentAgency and the ContentUtility. The ContentAgency is a facade to access the content info within the ContentUtility’s help.
· The license package
The license package contains the LicenseAgency and the LicenseUtility. The LicenseAgency is a facade to access the license info within the LicenseUtility’s help.
· The user package
The user package contains the UserRegisterAgency and the UserUtility. The ContentAgency is a facade to access the user info within the UserUtility’s help.
· Webservice
The webservice implements the wsdl communication protocol between the CPD and another device. For example, the access content as file protocol.

· Webwork
The webwork package defines the actions needed in the Webwork framework and the visual objects(VO) classes representing the business objects in the front layer. Via the classes defined in the vo packages, the data input from the webpage would be transferred to the middle business layer through the action classes.

CCD can store the created contents to the CPD following the remote content store protocol. The feature is under the development.
CPD can navigate the user to the corresponding LPD when the user wants to buy the content.
CPD get the device identifier from the DID.
SAV download the content from the CPD.


3. User Management (Add User)

4. SAV access CPD through Access Content As File Protocol (Web Service)

The LPD device is the License management device in the DMP system. It should be capable of the following:
· Store a License at the request of CCD when the License is not bundled within the Content.
· Issue a Signed License to SAV on request. The license should satisfy the terms that are enforced or agreed upon by all parties in the value chain, and it should contain the resource master key encrypted by SAV’s private key.
· Talk to Domain Management Device when it receives a request that a License should be issued to a Domain.
LPD is a web application running on Tomcat server. It implements protocols with other devices as Web Services. The Web Services include LPD-CCD protocol (License storage), LPD-SAV protocol (License issuing) and LPD-DMD protocol.
LPD provides a central storage for Licenses that are not bundles within Content, and keeps record of issued Licenses for statistics purposes. Also, it provides a GUI for Administrators and normal users. Administrators can maintain the License DB, modified stored Licenses, and generate reports on License issuing history. Normal users can login to review their own license purchase records.
LPD is composed of the following parts:
· Business logical layer based on Spring framework
· Data persistence layer based on Hibernate
· Web service layer based on Axis
LPD walkthrough
Store License walkthrough
· CCD raises a request to LPD, including in the message the ID of the governed content and the license to be stored. LPD retrieves information from the message and store it into persistent storage. (still under development.)
Issue License walkthrough
1 SAV sends request to LPD, asking for a License for the content it wants to consume. SAV can tell LPD what License it wants in 2 ways:
1.1 SAV can include in the message the License ID. In this case, LPD will retrieve the License from its DB and validate the terms.
1.1.1 If all terms are satisfied, LPD will encrypt the content master key with SAV’s public key, put the key in the License, sign the License and send it back to SAV.
1.1.2 If any conflict is found during validation, LPD will deny the request.
1.2 SAV can include in the message the ID of the content that it wants to consume and the License it wants to have (Intended License). In this case, LPD will validate the Intended License against all Licenses it finds in its DB for that specific content.
1.2.1 If the Intended License agrees with any of the Licenses in DB, the validation is regarded as successful. Then LPD will encrypt the content master key with SAV’s public key, put the key in the Intended License, sign it and send it back to SAV.
1.2.2 If the Intended License agrees with none of the Licenses in DB, LPD will deny the request.
Get DomainInfo walkthrough
This function is based on the LPD-DMD protocol and is currently under development.
LPD Administration walkthrough
This function is based on Webworks GUI and is currently under development.
LPD User walkthrough
This function is based on Webworks GUI and is currently under development.
LPD database
There are 3 tables in the LPD database:
· LicenseTemplate table: used to store the Licenses sent through from CCD devices.
· LicencingRecord table: used to keep record of Licenses that have been issued to different SAV devices.
· Resourceinfo table: stores information for content resource encryption.

Figure 257 – Overview of the LPD package
· In the Java source folder, there are the following packages:
1. Database package – It’s implemented based on Hibernate technology.
a) base folder – Base classes generated by Hibernate that map onto database tables.
b) dao folder – DAO objects that can be used by Business Logic layer. Users can extend them to add their own data access operations.
iface – interface classes
other files – utility classes that implement the iface interfaces
c) Other files in the Database package – Java classes that extend the Base DB-mapping classes. User can customize these classes to add their own properties and logics.
2. Management package
This package includes the classes that connect Hibernate-based DAO layer with the Spring-based Business Logic layer
3. Services package
This package includes the classes that implement the Web services of LPD. It is the core package of the LPD device.
· In the Resources folder, there are configuration files for DB, logging and internationalization.
· The webapp folder contains supporting files for web interfaces of LPD.
The Test folder contains client applications that can be used to test and debug the LPD Web Services.
When CCD wants to store a license in LPD, it should start the license storage process as described above in the Store License walkthrough.
When SAV want to use a content that is governed by a License that is not bundled with the content, it should talk to LPD to ask for a License. The process should be carried out as described in the Issue License walkthrough.
This feature is currently under development.
This feature is currently under development.
This feature is currently under development.
In order to run the Content Creation Device, any additional software to those needed to compile the whole Chillout project is needed.
The Content Creation Device depends on chillout_core and chillout_auxiliary modules
For those devices that need to access a certain Web Service of LPD, a LPD talker class should be implemented. They should populate a message as defined in the protocol, and send it to LPD by invoking the Web Service. You can see the LPDTalker class in the savmessenger package of the SAV device as an example.
The usage of GUI will be documented later when the development is done.
In DMP Device Identification Device is a service that provides device id for other deviced (e.g. SAV, CCD, CPD, LPD, TPD, CID, DMD). When device obtains a device id from DID, it becomes part of the DMP system and can establish a security communication channel with other DMP devices.
The DID architecture diagram is shown in the figure below:

Figure 258 – DID walkthrough
The following walkthrough shows the behaviour of a Device Identification Device when device obtain a device id.
1) Other device marshal request message.
i. Device put its device information into request message.
ii. If device wants to obtain “Certificate-based identification”, it must generate a private key/public key pair, and put public key into request message. But if it only wants to obtain “Device info-based identification”, it will elide this step.
iii. Device send request message to DID.
2) DID build device id for the application device
i. DID parse request message.
ii. If request message not content device serial number, DID will generate a device serial number for it.
iii. DID query device id from database, if DID has issued a device id for this application device, DID only return it.
iv. If request message not content public key, DID will generate “Device info-based identification”.
1. DID marshal dmp2mdi:DeviceID message.
v. If request message content public key, DID will generate “Certificate-based identification”.
1. DID access with EJBCA
2. Add a new end entity for this device.
3. Create user X.509 certificate for this end entity.
4. Turn user X.509 certificate DER-encoded format into xml format.
5. DID marshal dmp2mdi:DeviceID message.
vi. DID return dmp2mdi:DeviceID message to application device.
The Device Identification Device stores device id information in a database which is based on MYSQL.Table name is tbl_didemap.

Figure 259 – Overview of the DID package
The core package contains the all core classes needed to create a X.509 certificate.
The following classes are defined in this package:
· Base64
This class implements a BASE64 Character encoder/decoder as specified in RFC1521.
· CreateSerialNumber
This class is use for generate a serial number.
· DIDXmlProc
o Parse request message.
o marshal dmp2mdi:DeviceID message
· EJBCAProc
This class is use for operation EJBCA
The dao package contains the all classes needed to operate database.
The following classes are defined in this package:
· HibernateSessionFactory
This class Configures and provides access to Hibernate sessions, tied to the current thread of execution.
· DideDao
This class define all functions need to operate database.
· DideMap
This class is a map layer from database table to java class.
The webservice package contains webservice interface and its implement classes.
The following are defined in this package:
· IdentifyDeviceProtocolService
Webservice interface .
· IdentifyDeviceProtocolServiceImpl
Webservice interface implement.
This feature is currently under development.
This feature is currently under development.
This feature is currently under development.
This feature is currently under development.
This feature is currently under development.
This feature is currently under development.
This feature is currently under development.
The chillout_did library depends on the chillout_core and the chillout_auxiliary library.
Additionally, in order to use the chillout_did library the EJBCA and MYSQL software is required.
The Device Identification Device supports the following functionalities:
The Domain Management Device enables the creation of groups of Devices of Users.
As shown the figure below, DMD manages Domain in co-operation with DoID, LPD, SAV and DomainAdministrator. First of all, DomainAdministrator initiates the CreateDomain protocol to DMD. DMD creates DomainID and DomainaManageInfo for the newly created Domain with DoID. In this process, LocalDomainID created by DoID is sent to DMD by using LocalDomainIDRequest and LocalDomainIDResponse messages,. Then it’s combined with DomainManagerID and becomes DomainID.
After the creation of Domain, the protocols between SAV and DMD are used to deliver the Domain membership to SAV. When a Domain bound content is requested, LPD is informed DomainID by application dependant means, then the LPD issues RequestKey protocol to DMD to get the corresponding DomainKey.
Finally the domain bound license can be created by encrypting the content key with the DomainKey.

Figure 260 – Components of Domain Management
A Tool Provider Device (TPD) is a Device capable of releasing Tools to End-user Device such as SAV. The TPD packages the Tools and enables a user or a Broadcast client to download it. End-User Device can download them through the message protocol defined in IDP. Followings are the roles of TPD in IDP.
TPD consists of Tool DB, Storage Manager, Tool Packager, Protocol Manager as shown if the below figure.

Figure 261 – The TPD architecture
Followings are the roles of each module:
|
1 |
Tool DB
|
Stores the Tool information such as Tool ID, Tool meta information, Tool binary data |
|
2 |
Storage manager |
Manages Tool DB and makes a role of middleware between Tool Packager and Tool DB |
|
3 |
Tool Packager |
Creates Tool Packages using the Tool information stored in Tool DB |
|
4 |
Protocol Manager |
Parses and analyzes the request messages from the Tool Provider or the SAV, and sends the responses or Tool packages |
TPD Walkthrough
The following walkthrough shows the behaviour of a Tool Provider Device.
Downloading the Tools (by SAV)
The protocol between the TPD and the SAV for downloading Tools.
SAV:
· Mutually Authenticates with TPD.
· sends a dmp2rap:RequestDRMToolBody message to the TPD, containing:
o The requested Tool ID
o Device Information
o Message signature
DRM Protection Tool Server:
· Receives the message;
· Verifies the signature;
· Creates the required Tool packages
· Delivers dmp2rap:RequestToolBodyResponse message to the SAV
SAV:
· Receives dmp2rap:RequestToolBodyResponse message and stores the Tools into its local Tool storage.
The figure below shows the packages of the chillout_tpd.

Figure 262 – Overview of the TPD package
This package includes auxiliary classes, such as Base64.
This package supports database to TPD. It stores DRM Tool(s). It stores such messages about DRM Tool: Tool ID, Tool Body ID, Device Type, Tool Package Type and Tool code(byte). Recently, it supports storing simple tool, but not tool group.
The following classes are defined in this package:
· MediatoolDAO:
This class includes a few operations about database: get tool(s) by tool ID, insert tool(s),update tool(s),delete tool(s).
· Mediatool and HibernateSessionFactory:
These are two auxiliary classes about the database operations
This package provides TPD Service Interface. Other devices can access TPD to request DRM Tool(s) through this interface. It has only one class: TPDService. In particular, it needs to receive users’ message including basic information such as Tool ID, Device information, license signature. It can retrieve DRM Tool(s) from the Database by Tool ID, package the result and then return the request result to users.
This package contains a few utility classes useful for several purposes.
This package provides a test class: ClientCall for users to test the TPD service for getting DRM Tool(s) through network.
DMD Provides various Tools to SAV when SAV request them. When User try to play the governed Content on SAV, SAV parses and analyses the DRM information of the content, and extracts the list of the necessary Tools for the Content. If SAV succeed to find the necessary Tools on their local Tool storage, SAV loads the Tools and start to play the Content. If SAV fails to find the necessary Tools on their local Tool storage, SAV accesses the TPD and requests the necessary Tools.
According to the request, TPD searches the Tools in their Tool repository, and creates the Tool packages for transmission. This Tool package is sent to SAV as a response. Once the SAV receives the Tool package, SAV stores the tools in their Tool storage. The SAV sends dmp2rap:RequestToolBody messages for requesting the Tools and TPD sends dmp2rap:RequestToolBodyResponse messages as a response, which is includes Tool binaries and the Tool information.
CCD creates Contents according the many options. According to this options, CCD creates various Contents - Governed, Ungoverned, or in clear text. If Contents is Governed, CCD can create the protected Contents or the unprotected Contents. To create Protected Contents, CCD should apply the necessary Tools on the Resource for protection. For this, CCD should provide to the Content Providers the functionality of choosing the protection Tools to apply. However, CCD does not maintain all kinds of tool information, but it only can apply protection Tools on the Resource. Therefore, CCD communicates with TPD to acquire the Tool information.
There’re two types of information that is sent to CCD from TPD. One is Tool list information. When the Content Provider chooses the protection tool on the CCD, they might want to use the Tool that is not stored in the CCD itself. In this case, CCD should receive the Tool list information from TPD.
The other one is protection Tool itself. If the Content Provider, for protecting the resource, chooses a Tool that is not stored in CCD, CCD should request the necessary Tools to TPD, and TPD sends Tool package to CCD as a response, which is very similar with the relationship between SAV and TPD.
This is under development
This is under development
In order to run Tool Provider Device, Compiling the whole Chillout project is needed.
The Tool Provider Device depends on Chillout_Core module. And a database is needed.
The Tool Provider Device supports the following functionalities:
· Add a new Tool:
o User device(SAV) registers a tool through the GUI interface and gives detailed information about the registered tool
o Tool Provider Device confirms them and forms a Tool Body and then stores it in the Database.
· Provide Tool(s):
o User sends a request including Tool ID to Tool Provider Device. Tool Provider Device retrieves the requested tool(s) from the database by the Tool ID. If the tool exists, the package it and return it to user
Disclaimer: This code is part of Chillout but its functionalities are currently not integrated with the rest of the Chillout code.
The OWL language is based on RDFS, ultimately an XML file, making it technologically neutral. Therefore, any program that reads an OWL file will extract the same logic. Furthermore, any OWL file may be validated against another via an appropriate reasoner such as Pellet. In order to facilitate a swifter development of applications, a basic Java API is required. This section provides the definition for the minimum and necessary Java routines to handle the RRROnto OWL file meaningfully and build applications that make use of the RRD logic.
This library provides the basic functionality to:
This document only provides the definition of Java methods without any specific implementation and although code is not provided it can be easily generated accessing the appropriate Java libraries for parsing and reasoning over OWL files. Examples of such libraries are Jena V 2.4 for parsing OWL files and Pellet V 1.3 provides methods for reasoning over OWL files.
The main functionalities of the RRDOnto API have been defined in a public “interface” class called RRDOnto. This abstract class may be adopted by several implementations e.g. its generic method “store” is defined to enable storage in any destination such as a file, a database, or a remote host etc.
Constructor initialises the ontology parser and reasoner.
Parameters:
owlurl Reference OWL should point to RRDOnto.owl found on the web or on the local machine. Example: “http://.../dmp3.owl”, or "file:dmp3.owl".
· Boolean Load (String url)
This method loads RRD individuals from a data repository. The data repository may be local or remote, an OWL file or a database, or any other storage type. The load operation is additive, i.e., if individuals have already been loaded the new individuals will be added to the former.
Parameters:
url Address of the data repository.
Returns:
True on success, false on error.
· Boolean Store (String url)
This method stores individuals in a data repository. This data repository may be local or remote, an OWL file or a database, or any other storage form.
Parameters:
url Address of the data repository.
Returns:
True: upon success
False: upon error.
· Boolean Unload ()
This unloads individuals from the data model.
Returns:
True: upon success
False: upon error.
· Boolean CreateUser(Vector<String> roles, String name, String refid)
This registers a new user with given roles. Note that all operations are done in the memory data model, and persistency is not achieved until a Store operation is performed.
Parameters:
name Name of the user
roles Set of roles that the user plays
refid Reference id to link this user with other user databases
Returns:
True: upon success
False: upon error.
· Boolean EraseUser(String name)
Deletes an user from the data model.
Parameters:
name Name of the user
Returns:
True: upon success
False: upon error.
· Boolean ExecuteAction (String user, String action, Vector<String> objects, String newipentity)
Permits a User to execute an action over one or more objects.
Parameters:
agent Name of the user
action Name of the action
objects Names of the objects
newipentity Name of the new IP Entity (if any)
Returns:
True: upon success
False: upon error.
· Vector<String> SearchPermit(String user, String action, String ipentity)
Searches for a permit where user can execute the action over an ipentity, and returns the ids of the permits (if existing)
Parameters:
user Name of the user
action Name of the action
ipenity Name of the object
Returns:
Null if no permit exists, or a vector with permits ids that permits the action to be executed on ipentity by user.
· Boolean CreatePermit(String fromagent, String toagent, String entity, Vector<String> actions, String permitid)
A user gives permission to other user to execute certain actions over a particular IP entity.
Parameters:
fromagent Agent donor of the permission, and owner of the rights.
toagent. Agent that gets the permission
entity. Entity over which the actions can be exercised.
actions. One or more actions whose execution permission is given.
permitid: ID of the Permit.
Returns:
True: upon success
False: upon error.
· Boolean RevokePermit(String permitid)
Revokes a given permit.
Parameters:
permitid: ID of the Permit.
Returns:
True: upon success
False: upon error.
· Boolean GiveConsent(String userfrom, String userto, String object)
The Creator userfrom gives special consent to userto over object. This consent is special in certain cases, in the sense that it breaks the value chain of authorisations. For example, in order to make a PublicCommunication it is needed the special consent of the author. This function gives that consent.
Parameters:
userform Author that gives the consent
userto Author that receives the consent
object IPEntity over which the action is to be executed.
Returns:
True: upon success
False: upon error.
· String getRightsOwner(String ipentity)
Returns the rights owner of a given ipentity.
Parameters:
ipentity Name of the IP Eentity
Returns:
Name of the User who owns the rights.
· String getOrigin(String ipentity)
Returns the source of a given ipentity.
Parameters:
ipentity Name of the IP entity
Returns:
Name of the source upon which ipentity is based.
DMP Technical Specifications and References provide Tools and guidance to Users on how to employ the DMP-specified Tools to set up Value-Chains. However, DMP Approved Documents #1 to #7 are in general not sufficient to respond to the following basic questions:
1. Question 1: Has a given Content or Device Entity been made correctly according to the Technical Specifications?
2. Question 2: Can the Device Entity that has passed the test of Question 1. be safely admitted to a Value-Chain, i.e. it does not compromise its integrity?
Being able to respond to the first question is a pre-requisite for building Interoperable Value-Chains based on Devices that are independently manufactured and Use independently Created Content. This is the first purpose of this Approved Document No. 8 – End-to-End Conformance. The goal is achieved through the use of methodologies, test suites and software to test Entities for Conformance to the Technical Specifications.
By using the material made available by this Approved Document, Users will be in a position to:
1. Take a content item, feed it to a reference Consumption Device, i.e. a Consumption Device whose Conformance has been positively assessed, observe the performance of the Device and judge whether the content item is a Content Item;
2. Take a protocol, install it on a device, observe the performance of the Protocol running on a reference Device that sends reference Content, i.e. Content whose Conformance has been positively assessed and judge whether the implementation of the protocol is a Protocol;
3. Take a device, e.g. a content consumption device, connect it to a number of reference Devices, e.g. Content Provider Device, Domain Management Device etc., and judge whether the implementation of the content consumption device conforms to the Technical Specifications by observing its performance when subjected to a number of test suites;
4. Etc.
In order to build Value-Chains that Users can entrust their assets to, with an expectation that they will be Used as expected, Users require means to obtain responses to the second question. This is a primary function of the Certification Authority and Agencies whose general role is described in Approved Document No. 5 – Certification and Registration Authorities. Therefore this Approved Document No. 8 – End-to-End Conformance only provides general elements that help provide responses to Question 2, with the understanding that complete answers to this question with a level of satisfaction suitable for business practices in a specific environment can only be obtained from Certification Agencies.
Prerequisites for proper understanding of this Approved Document are: reading of this Foreword, Approved Document No. 2 – Architecture, Approved Document No. 3 – Interoperable DRM Platform, Approved Document No. 6 – Terminology and Approved Document No. 7 – Reference Software.
The notion of conformance of an implementation (e.g. a video decoder) to a standard, e.g. MPEG-2 Video, is well established. There is a set bitstreams, designed to test different features of the decoding process, which can be fed to the video decoder under test. If the decoder correctly decodes the bitstreams one can infer that the decoder implementation is conformant. If the video decoder is to be tested for conformance to the MPEG-4 Visual standard, things are slightly more complicated because of the different profiles and levels that are practically used (this is true of MPEG-2 as well, however, only Main Profile is practically used). In practice, however, the same conformance testing process described for MPEG-2 Video applies to each individual MPEG-4 Visual profile.
The notion of conformance of an implementation to the DMP specification (IDP) cannot be derived in an immediate fashion from the preceding case for the simple reason that the IDP is a toolkit standard with a number of dimensions that is much larger than the number of dimensions of, say, MPEG-4 Visual.
A second aspect of the toolkit nature of the IDP concerns the fact that, even though DMP, in its search for an interoperable specification, has specified only one Tool to support a given Function, to the extent possible the IDP has been designed to allow the use of alternative technologies. Indeed future versions of the IDP could be extended to support a further level of abstraction by allowing the use of more that one technology to implement a given Function. As it is the policy of the DMP not to encourage the use of technologies other than those specified in the current version of the IDP, this Approved Document No. 8 – End-to-End Conformance will in general provide no support to assess the conformance of implementations in which native IDP Tools have been replaced by other tools of similar functionalities.
The table below lists some of the technology types that are employed by the IDP, the corresponding native DMP Tools and other tools that could possibly be used, not necessarily with exactly the same functionalities, by an implementer to replace native DMP Tools:
Table 1 – Some technologies potentially replaceable by non-DMP specified technologies
|
Technology type |
Native DMP Tools |
Other tools |
|
Rights Expression Language |
DMP REL |
ODRL, RMPI |
|
Represent Rights Data |
DMP RRD |
ODRL Ontology |
|
Metadata |
TV-Anytime profile |
MPEG-7, Dublin Core, ... |
The general problem of testing exhaustively an Entity for Conformance requires examining a large number of aspects for which it may be impractical to provide all material to test it. Therefore this document will only concentrate on the means to test the most critical aspects. Future versions of this Approved Document No. 8 – End-to-End Conformance may provide additional material in response to precise user needs.
Conformance testing material is provided for the following broad areas:
1. Content and Content Elements
2. Protocols and Package Tools
3. Devices.
For Content and Content Elements
A content item or content element under test shall be used as an input to a reference Parser. The Parser shall provide as output
1. An indication of whether the syntax of the content item or a content element under test is correct or not (always)
2. Indications of what in the content item or content element under test is incorrect and, if possible, why (in the latter case).
This Approved Document No. 8 – End-to-End Conformance points to reference implementations of the Parsers of Approved Document No. 7 – Reference Software that shall be used to test content items and a range of content elements for Conformance.
Protocols and Package Tools
An implementation of a protocol or a package tool to be tested for Conformance shall be provided either as an implementation of one side of the protocol or package tool, e.g. for a Content Identification Device and for a Content Creation Device, or as clearly separated parts of the two sides of the protocol or package tool. The side to be tested for Conformance shall be installed on a device with the appropriate interfaces and the behaviour of the device shall be assessed when it communicates with a reference Device implementing the other half of the Protocol or Package Tool.
This Approved Document No. 8 – End-to-End Conformance points to reference implementations of the two sides of all Protocols and a range of test suites (reference Content Items and Content Elements) required to test Protocols for Conformance.
Devices
A device to be tested for Conformance shall be provided with direct access to the individual component protocols or package tools and to the relevant parts of the device. The device shall be connected to the set of Devices required for the type of operation required by the Value Chain for which the device under test is expected to operate and the performance of each protocol or package tool or groups of protocols and package tools implemented on the device shall be assessed.
This Approved Document No. 8 – End-to-End Conformance only provides limited and demonstration level support for this type of device Conformance testing. Devices can be tested for Conformance by making them interact with the Reference Devices of Approved Document No. 7 – Reference Software and observing the behaviour of the reference Devices.
The Reference Parser will provide information on the correctness of
1. The Structure of the DCI
2. The location of
a. Identifiers
Identifier for Content Item
i. Identifiers for Content Elements
b. Metadata
i. Metadata for a Content Item
ii. Metadata for a Content Element
c. DCI signatures
d. DCI hash
e. Resources in the DCI
f. Governed Content Elements
g. DRM Information including DRM Tools
h. General DRM Information including DRM ToolList
i. Licenses
i. Granting the Right to Use Content
ii. Governing the Use of DRM Tools
j. Key Information
i. Time-independent Keys
ii. Time-dependent Keys
k. DRM Tool Body
l. Device Information
The Parser will provide information on the correctness of
· Governed Elements
· Local DRM Information
· General DRM Information
The Parser will provide information on the correctness of
· dmp2_ipmpinfo:ToolList
· dmp2_ipmpinfo:Tool element
· Fixed DRM Tools
The Parser will provide information on the correctness of
· Single DRM Tool Body
· DRM Tool Pack Body
The Parser will provide information on the correctness of
· License element
· DomainResource element
· digitalResource element
· protectedResource element
The Parser will provide information on the correctness of
· Containers for DRM Messages
· DRM Messages
The Parser will provide information on the correctness of
· InitAuthentication
· MutualAuthentication
The Parser will check that the implementation supports Access to namespaces that are specifically identified by DMP.
Testing an implementation of a Protocol for Conformance means to be able to verify that a Device on which the implemented Protocol under test is running responds correctly to another Device that is known to implement correctly the other half of the Protocol.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Device Identification Protocol for
· Device Identification Device.
This Approved Document No. 8 – End-to-End Conformance does not provide a reference Protocol implementation for the User Identification Device as this is out of scope.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Content Identification Protocol for
· Device Identification Device
· Content Creation Device.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Device Authentication Protocol.
This Approved Document No. 8 – End-to-End Conformance does not provide a reference Protocol implementation for User Identification as this is out of scope.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Content Authentication Protocol for
· Device Identification Device
· Any other Device invoking the Content Authentication Protocol.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Manage Domain Protocol for the Domain Management Device side of:
· Create Domain Protocol
· Renew Domain Protocol
· Delete Domain Protocol
· Add Device Protocol
· Add User Protocol
· Renew Device Protocol
· Renew User Protocol
· Leave Device Protocol
· Leave User Protocol
· Un-Licensed Simultaneous Use
· Notification to Domain Management Device
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Manage Domain Protocol for the Domain Administrator side of:
· Create Domain Protocol
· Renew Domain Protocol
· Delete Domain Protocol
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Manage Domain Protocol for the LPD side.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Manage Domain Protocol for the End-User Device side of:
· Add Device Protocol
· Renew Device Protocol
· Leave Device Protocol
· Merging Use Data between Devices
· Notification to Domain Management Device
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Manage DRM Tool Protocol for:
· Instantiation of a DRM Tool
o Instantiation of a single DRM Tool
o Instantiation of a DRM Tool Pack
· Initialisation of a DRM Tool
o Initialisation of a single DRM Tool
o Initialisation of a DRM Tool Pack
· Authentication of DRM Tools and DRM Processor
· General DRM Tool Management
o Obtaining a reference to the DRM Tool Group
o Obtaining a reference to a DRM Tool
No support is provided as these Protocols are not yet part of Approved Document No. 3 – Interoperable DRM Platform.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Access Content Protocol for
· Content Provider Device
· Any other Device.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Access License Protocol for
· License Provider Device
· Any other Device.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Access DRM Tool Body Protocol for
· DRM Tool Body Provider Device
· Any other Device.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the Access Key Protocol for
· Key Provider Device
· Any other Device.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of Package as File Tool for
· Content Creation Device
· Any other Device unPackaging a DCI in a file.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of Package as Stream Tool for
· Content Provider Device
· Any other Device unPackaging a DCI in a stream.
A Value-Chain is typically made of a number of Devices managed by Users. Devices interact with other Devices using Protocols to exchange Data that are Represented as specified in AD #3.
Therefore testing a Device for conformance makes only sense in the context of a particular Value-Chain, even though it should be possible to isolate and test a set of Primitive Functions in a Device for conformance.
A Content Creation Device can be tested for conformance in its ability to successfully
· Authenticate with another Device
· Register a Content Item with a Content Registration Agency
· Make a Content Item that is syntactically correct
· Etc.
A Content Consumption Device (SAV) can be tested for conformance in its ability to successfully
· Authenticate with another Device
· Join a Domain Management Device
· Authenticate a Content Item with a Content Registration Agency
· Use a Content Item, after
o Accessing a License from a License Provider Device
o Accessing a DRM Tool from a DRM Tool Provider Device
· Etc.
This Approved Document No. 8 – End-to-End Conformance points to the reference implementation of the following reference Devices:
· Device Identification Device
· Content Creation Device
· Content Identification Device
· Content Provider Device
· License Provider Device
· DRM Tool Provider Device
· Domain Management Device
· Content Consumption Device (SAV)
These can be used as a basis for extending the functionality of reference Devices needed for setting up Conformance testing environments for specific Value-Chains.
A Device shall have been designed and manufactured so that the cost for an attacker to
1. Extract cryptographic secrets
2. Alter embedded identities
3. Defeat Authentication, DCI decoding and Rights Expression interpretations
4. Defeat Encryption/Decryption functionalities
is made sufficiently high. The definition of “sufficiently high” is specific of a business area and will be defined by a Device Certification Agency in the framework set by the Device Certification Authority.
Techniques useful to achieve the above goals are:
1. No easily accessible interfaces or busses from which clear-text data can be extracted
2. Use of signed code to self-check integrity of software component
3. Use of secure hardware in case software relies on hardware for robustness
DMP specifications provide interoperable technologies that help Use Governed Content (i.e. Content that is at least Identified). Some of these technologies (i.e. Identification) do not require Rights Holders’ Permissions, others (i.e. Licenses) provide a more complete set of possibilities to manage Content throughout the Value-Chain requiring Rights Holders’ Permissions.
Traditionally Users have had many ways of enjoying content they purchase or access some of which do not require rights holders’ permission. Some of these media usages are backed by law in some jurisdictions, some others are dealt with as exceptions to the law and some others are practices currently exercised simply because the state of technology enables them.
DMP feels that solutions that are based on the Interoperable DRM Platform (IDP) could be seen as a poor proposition, in spite of being superior to other DRM solutions thanks to the Interoperability they provide, because the experience gained from them may be perceived by Users as inferior to the current digital or even to the analogue experience.
DMP calls Traditional Rights and Usages (TRU) the ensemble of usages made possible by laws and exceptions or simply practiced by the general public. The DMP community has gone to a great pain collecting as many TRUs as possible and Annex A provides a list of the 88 TRUs that have been identified. The reader is directed to http://www.dmpf.org/open/dmp0270.zip for a detailed analysis of those TRUs.
The objective of this Approved Document No. 9 – Mapping of TRUs to the Digital Space is to provide illustrative examples of:
1. Support of uses similar to those that users were accustomed to in the analogue age but using the technologies in the IDP and without compromising the integrity of a Value Chain that is based on it
2. New innovative ways of offering and consuming digital media largely inspired by TRUs that DMP calls Digital Media Business Models (DMBM).
For each TRU/DMBM supported the following is provided:
1. A rationale for the TRU/DMBM
2. One or more than one solution enabling support of the selected TRU/DMBM, each with
a. A walkthrough complemented with the list of IDP Tools required
b. Additional actions that may be required to enable TRU/DMBM support.
Note that
1. The DMP has no intention to debate, define or promote the legal status of any of the specific examples of TRU support;
2. The ways to support a TRU can be manifold. The fact that one has been selected does not imply that DMP has a preference for that particular TRU support and anybody is encouraged to provide alternative solution cases following the template used in this Approved Document. These will be discussed by DMP in an open forum and, if considered technically sound, added to the next version;
3. The DMP intends to add more TRUs/DMBMs or just more solution cases in future releases of this Approved Document;
4. Full support of some TRUs may require technologies that are not yet in the IDP Tool kit (indicated in italics) but whose addition may already be under investigation;
5. In most cases a practical implementation of the solutions presented might require a third party action, e.g. legislation, in order to determine the conditions under which a User is entitled to get a License as opposed to ask for a License;
6. By identifying a third party action, the DMP does not intend to suggest that such an action necessarily be undertaken.
Reading of the following documents is a prerequisite for proper understanding of this Approved Document:
1. The Foreword of this Approved Document No. 9
2. Approved Document No. 4 – Use Cases and Value-Chain Functions and Requirements
3. Approved Document No. 6 – Terminology.
An important feature of digital vs. analogue media is the low threshold of entry to creation because virtually anybody is in a position to create Content of high (technical) quality using inexpensive devices and software. With more and more Content that is being posted it becomes important for persons in their capacity of Creators to be able to make Quotes from Content that has been Released, possibly in a format that employs technical protection measures.
Below a number of walkthroughs are described in which IDP Users can Quote Content.
Tim wants to show 10 seconds from time code 1h 15m 25s of “My best quote of the year”, a movie that is only available as protected Content.
Tim performs the following sequence of steps:
|
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
|
Tim |
Obtain |
License |
To quote 10 seconds of “My best quote of the year” |
Negotiate License |
|
|
Tim |
Make |
DCI |
Using a Content Creation Device (CCD). The DCI includes · Tim’s Content · The 10 seconds of the movie · The License obtained for Quoting the movie |
Represent Content |
2.1 |
|
Tim |
Register |
DCI |
|
Protocol to Identify Content |
3.1.2 |
|
Tim |
Upload |
DCI |
To Content Provider Device |
CCD-CPD Protocol |
3.7 |
|
CPD |
Make |
DCF |
|
Package Content as File |
4.1.2 |
There are several ways in which this TRU can be actually implemented. Here follows a non-exhaustive list
1. In a given Jurisdiction the law may oblige Rights Holders to allow a User to make a limited number of Quotes of a given Content Item each with a maximum duration
2. In a given Jurisdiction a subscriber to a movie service may be entitled to make a limited number of Quotes of a given maximum duration
3. The Rights Holder of “My best quote of the year” may wish to promote his movie using the technology analysed in the walkthrough giving away a limited number of Quote Licences
4. A User may offer to send Quotes of the movie to a number of friends and be paid for the effort
5. ....
Users who buy Content Items would like to make sure that they can continue to play the Content even when the medium on which the Content is Stored breaks down or is lost. Below a number of walkthroughs are described in which Users can expect to be able to continue Playing the Content they have bought, in the said feared adverse circumstances.
Pete buys a Content Item with a License to Use it on only one Device of his Domain at a time.
This is supported by the walkthrough of AD #4 Use Case No. 3 – Home Distribution #1.
Legislation may be required to ensure that a User can get a License that supports this Use Case.
In a world where human mobility is on the increase, the ability to enjoy a Content Item independently from the physical location, assuming that the law of a particular location allows the Use of such a Content Item, is an important requirement. Below a number of walkthroughs are described in which Users can expect to be able to Use Content at different locations.
Abe, a UK national living in the UK, obtains a License from GreatBlueMulti (GBM) to Use a Content Item in multiple territories.
The following steps are performed.
|
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
|
Abe |
Selects |
Content |
|
Out of scope |
|
|
Abe |
Selects |
License terms |
|
Out of scope |
|
|
Abe |
Make |
Transaction |
|
Out of scope |
|
|
GBM |
Make |
License |
License Permits Use of Content in listed multiple Territories |
Represent License |
2.10 |
|
GBM |
Make |
DCI |
The DCI references the License |
Represent Content |
2.1 |
|
GBM |
Make |
DCF |
|
Package Content as File |
4.1.2 |
|
Abe |
Access |
License |
|
Access License |
3.6.2 |
|
Abe |
Un-Package |
DCF |
|
Package Content as File |
4.1.2 |
|
Abe |
Use |
DCI |
In multiple Territories |
Represent Content Elements |
2. |
Legislation may be required to ensure that a User can get a License that supports this Use Case.
Abe is now attending a conference in Germany, a country not covered by the License he has previously obtained for the Content Item of his current interest.
Abe obtains a new License to extend temporary coverage to Germany.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Abe |
Selects |
License |
|
Out of scope |
|
|
Abe |
Make |
Transaction |
|
Out of scope |
|
|
GBM |
Make |
License |
Content may be Used in Germany |
Represent License |
2.10 |
|
Abe |
Access |
License |
|
Access License |
3.6.2 |
|
Abe (PXD) |
Make |
DCF |
New License is in the License Container Box |
Package Content as File |
4.1.2 |
|
Abe (PXD) |
Move |
DCF |
To PAV |
None |
|
|
Abe (PAV) |
Un-Package |
DCF |
|
Package Content as File |
4.1.2 |
|
Abe (PAV) |
Use |
DCI |
In Germany |
Represent Content Elements |
2. |
Legislation may be required to ensure that a User can get a License that supports this Use Case.
In some delivery systems, like broadcast, Content must be Used the moment it is received, unless the User’s Device has the ability to Store the Content for later Use. Below a number of walkthroughs are described in which Users can expect to be able to Use the Content at a different time than it was delivered to the User, as it used to be the case with Audio and Video Cassette Recorders.
Daphnis is a Greek citizen living in Greece. In 2010 the Greek Broadcaster BlueRadioTV (BRT) has implemented a form of DTT whereby BRT broadcasts Clear-text digital television and subscribers use a Certified Device to watch BRT programs. As long as Daphnis watches BRT programs the Device behaves as a regular DTT set top box. However, when Daphnis wants to Store Content, the Device requests a License for a DCI of the Stored Content from BRT. In this way Daphnis can Use Content at the time of his choice.
The following happens when Daphnis wants to Store a Content Item:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
BRT |
Make |
Content |
Clear-text Broadcasting of television programs |
None |
|
|
BRT |
Deliver |
Content |
Streaming of Governed Content |
None |
|
|
Daphnis |
Select |
Content |
To be Stored |
Out of scope |
|
|
Daphnis (SAV) |
Request |
Identifier |
Of DCI to be Stored to ERT (acting as Registration Agency) |
Identify Content |
|
|
BRT |
Make |
License |
1. Store Content for 1 week; 2. Play Content in Greece; 3. Move/Copy Content to another SAV within Greece |
Represent License |
2.10 |
|
Daphnis (SAV) |
Access |
License |
From ERT License Provider Device |
Access License as File |
|
|
Daphnis (SAV) |
Encrypt |
Resource |
|
Out of scope |
|
|
Daphnis (SAV) |
Make |
DCI |
With License Bundled within it |
Represent Content |
2.1 |
|
Daphnis (SAV) |
Make |
DCF |
|
Package Content as File |
4.1.2 |
|
Daphnis (SAV) |
Un-Package |
Content Item |
|
Package Content as File |
4.1.2 |
|
Daphnis (SAV) |
Use |
Content Item |
As per License terms |
Represent Content Elements |
2. |
Legislation may be required to ensure that a User can get a License that supports this Use Case.
Chloe has subscribed to a Broadcast Service Provider and has a License to Use Content at the time of her choice.
This is supported by the walkthrough of AD #4 Use Case No. 10 – Open Governed Broadcast.
Legislation may be required to ensure that a User can get a License that supports this Use Case.
VHS2.0 is a start up that is offering personalised services to store TV programs. User George instructs VHS2.0 to store certain programs so that he can watch them at the time of his convenience.
The following happens when the service operates:
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
George |
Request |
Program storage |
This can be done by selecting which programs George wants to have stored |
Out of scope |
|
|
VHS2.0 |
Receive |
Program |
One of the programs selected by George |
Out of scope |
|
|
VHS2.0 |
Encrypt |
Program |
|
Protocols to Manage DRM Tools |
3.5 |
|
VHS2.0 |
Register |
Resource |
Resource is the program selected by George |
Protocol to Identify Content Elements |
3.1.3 |
|
VHS2.0 |
Make |
Licence |
With terms that make use of the program eligible as “personal use” |
Represent Licence |
2.11 |
|
VHS2.0 |
Register |
Licence |
|
Protocol to Identify Content Elements |
3.1.3 |
|
VHS2.0 |
Make |
DCI |
Adding Metadata |
Represent Content |
2.1 |
|
VHS2.0 |
Register |
DCI |
|
Protocol to Identify Content |
3.1.2 |
|
VHS2.0 |
Make |
DCF |
|
Package Content as File |
4.1.2 |
|
VHS2.0 |
Store |
DCF |
For later use by George |
Out of scope |
|
The following happens when George want to watch a selected program
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
George |
Access |
Content |
|
Protocol to Access Content |
3.6.1 |
|
George |
Parse |
DCF |
George begins to Play the program |
Package Content as File |
4.1.2 |
|
George |
Parse |
Content |
|
Represent Content |
2.1 |
|
George |
Parse |
License |
|
Represent Licence |
2.11 |
|
George |
Decrypt |
Program |
|
Protocols to Manage DRM Tools |
3.5 |
Note that the TRU support can be achieved either by Storing Content both on the VHS2.0 server or on George’s SAV.
Legislation may be required to ensure that a VHS2.0 can actually offer this service.
Many complain about end users being forced to spoil their digital media experience because of the need to deal with complicated and unfriendly Technical Protection Measures (TPM) and point to the immediacy of the “MP3 experience” in accessing, using and sharing music. Some have imagined distribution systems, generally called as Alternative Compensation Systems (ACS), deployed in a given (say) juridiction in which the payment of a “content access tax” by all citizens allows them to have access to all content distributed on (say) all digital platforms and rights holders would be compensated in proportion of the actual use of their content.
Some ACS proponents and supporters claim the system is simple. This is not entirely true because an ACS requires the deployment of a legal, technology and administrative infrastructure of a significant complexity. They also claim ACSs are alternative to the use of DRM. While it is true that ACSs do not require enforcement using TPMs they do require quite sophisticated DRM (management) technologies. On the other hand it is true that ACSs do provide probably the best user experience but it is also true that the borderless nature of the Internet would make a country deploying an ACS a potential source of “free” content for other countries.
The country of Oceanland has decided to deploy an ACS for its citizens and to use the IDP as the technology to implement it. Therefore Oceanland mandates that
7. All consumption devices used in Oceanland are Certified Devices implementing the Event Reporting Tool
8. All citizens shall pay a yearly amount of 100 oceaners to the Content Usage Monitoring Agency (CUMA)
9. CUMA shall
a. Collect the Event Reports generated by Oceanlanders when they Use Content
b. Redistribute the proceeds to the Rights Holders in proportion to the Use of their Content
10. Rights holders who want to benefit from a share of CUMA’s revenues Release their Content as a DCI. The DCI includes the Event Reporting Tool that instructs the Device send an Event Report to CUMA every time the Content is Used
Rights Holder Joe performs a song and wants to distribute it to the national community
Rights Holder
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Joe |
Make |
DCI |
With a Licence permitting use of the Content within Oceanland |
Represent Content |
2.1 |
|
CUMA |
Add |
ER-R |
See A.5 of AD #3 for a general explanation of the technology |
|
2.23 |
|
Joe |
Register |
DCI |
|
Protocol to Identify Content |
3.1.2 |
|
Joe |
Make |
DCF |
|
Package Content |
4.1 |
|
Joe |
Distribute |
DCF |
|
Out of scope |
|
End User
End User Kate is made aware of a new song. Kate is equipped with a Certified Device that is capable of interpreting the Event Report Request and sending the correct Event Report whenever a song is Played.
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Kate |
Access |
DCF |
|
Out of scope |
|
|
Kate |
Play |
DCF |
|
Represent Content |
2.1 |
|
Device |
Send |
Event Report |
Sent to CUMA |
|
2.23 |
There are several aspects of legislation that may be required to implement this DMBM.
There is a contradiction between digital content sharing within a community, and the potential economic exploitation of that same content within that community.
The IDP can be configured to set up communities that can still rely on the positive side of the multiplicative factor but where the potential economic exploitation is not entirely lost.
“Active Book Club” (ABC) is the name of a community of individuals who share common features regarding the type of content they enjoy. The ABC community operates according to the following rules:
1. ABC acquires the rights to let its members Use a given number of Content Items delivered in an Encrypted format for free or at a price
2. If available, each member has the right to check out a Content Item for a given duration (e.g. 24 hours)
3. For the duration of 24 hours that Content Item cannot be checked out by any other member
4. When a member checks in a Content Item, it becomes available to other members to check out
5. If all “free” Content Items are checked out and a member badly wants one he can get it from ABC at a price
Simon finds that the novel he was looking for is now available from ABC. The following is performed
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Simon |
Become ABC member |
|
|
Out of scope |
|
|
Simon |
Check out |
DCF |
Simon’s preferred novel |
Out of scope |
|
|
Simon |
Read |
DCF |
For 24 hours |
Represent Content |
2.1 |
|
Simon |
Check in |
DCF |
Simon’s preferred novel |
Out of scope |
|
This is likely to be implementable as a pure business relation between ABC and Rights Holders.
Electronic music can be generated by a process called “sampling”. Sampling involves extracting arbitrary fragments from pre-existing recorded music and producing a Work that can be entirely new or a derivative depending on the nature of fragments.
Many DRM systems prevent users from copying, editing or storing digital resources, even if the user intends to do so for private purposes. This fact makes sampling almost impossible in the digital space without circumventing measures applied by DRM systems.
Below a number of walkthroughs are described in which Users can expect to be able to sample Protected Content even if the Licence does not explicitly Grant this Permission.
Jah is a DJ who creates and produces music. For the creation and production of his music Jah uses a Content Creation Device (CCD) enabling him to
l get Governed Content of his choice
l edit (e.g. cut, paste, mix, modify) this Content (sources) using the Tools of his choice
l create, produce and publish new Content (target) using the Tools of his choice
Jah wants to excerpt and modify samples from three different pieces of music (sources) that are only available as Governed Content Items. Jah performs the following sequence of steps
|
Who |
Perform |
What |
Notes |
IDP Tool |
Ref. |
|
Jah |
Selects |
Content |
Jah selects several different pieces of music as sources |
Out of scope |
|
|
Jah |
Selects |
License terms |
|
Out of scope |
|
|
Jah |
Access |
License |
Jah reads the License |
Access License as File |
|
|
Jah |
Un-Package |
Content Item |
|
Package Content |
4.1.1 |
|
Jah |
Decrypt |
Resource |
|
Out of scope |
|
|
Jah |
Create |
Audio and video |
Jah knows that he can sample if the Licenses of the sources allows the creation of Derivative Works (e.g. Adaptations) |
Out of scope |
|
|
Jah |
Create |
Resource |
Audio-visual Resource file |
Out of scope |
|
|
Jah |
Create |
Metadata |
Of audio-visual Resource file. |
None |
|
|
Registration Agency |
Identify |
Resources and Metadata |
audio-visual file |
None |
|
|
Jah |
Represent |
Identifier |
In Resources and Metadata |
Represent Content |
2.5.1 |
|
Jah |
Create |
Human-readable License |
Jah includes information about the original Authors in the Metadata of his Content if the License of the source requires attribution |
Out of scope |
|
|
Registration Agency |
Assign: Identifier to |
Human readable license |
Lower case "L" because this is not a License |
Out of scope |
|
|
Jah |
Create |
Machine-readable License |
Corresponding to the human-readable license (expressed in verbose XML) |
Represent License |
2.10 |
|
Registration Agency |
Identify |
License |
|
None |
2.5.2 |
|
Jah |
Create |
Content Item |
Containing · Resources · Metadata · Human-readable license for the selected jurisdiction · License |
Represent Content |
2.1 |
|
Registration Agency |
Identify |
Content Item |
|
None |
|
|
Jah |
Represent |
Content Identifier |
In the Content Item |
Represent Content |
2.5.1 |
|
Jah |
Binarise XML |
Content Item |
To reduce memory, transmission and processing requirements |
Represent Binary XML |
2.19 |
|
Jah |
Package |
Content |
As file |
Package Content |
4.1.1 |
|
Jah |
Release |
Content file |
|
None |
|
Whether or not Jah's quotes breach the author rights of other's can only be determined by a court of law. However, if Jah wants to avoid possible problems he can ask the author's first to see if they consider Jah's use of the music samples a legitimate use or if they consider that they constitute a breach of some kind.
For the prevention of abuse there is a possibility to introduce the following restrictions
5 The allowed length and the number of samples is Governed by the License of the sources;
6 The License of the sources prevents recombination of samples to form whole works.
1. Digital Media Project; Approved Document No. 1 – Technical Reference: Use Cases; 2005/04
2. Digital Media Project; Approved Document No. 2 – Technical Reference: Architecture; 2005/04
4. Digital Media Project; Approved Document No. 4 – Technical Specification: Value-Chains; 2005/04
5. Digital Media Project; Approved Document No. 5 – Technical Reference: Registration Authorities; 2005/04
6. Digital Media Project; Approved Document No. 6 – Technical Reference: Terminology; 2005/04
10. The Digital Media Manifesto, http://www.dmpf.org/manifesto/, 2003/09/30
11. The Digital Media Project, Procedures of Work, http://www.dmpf.org/project/procedures_of_work.htm
14. ISO/IEC 14496-13, Information technology — Coding of audio-visual objects — Part 13: Intellectual Property Management and Protection (IPMP) extensions
16. ISO/IEC 15938-2, Information technology – Multimedia content description interface (MPEG-7) – Part 2: Description Definition Language
17. ISO/IEC 15938-5, Information technology – Multimedia content description interface (MPEG-7) – Part 5: Multimedia Description Schemes
25. ISO/IEC 21000-5 Amd 2, Information technology – Multimedia framework (MPEG-21) – Part 5: Rights Expression Language, Amendment 2, Dissemination & Capture Extension (DACX) Profile
28. ISO/IEC 21000-9, Information technology – Multimedia framework (MPEG-21) – Part 9: File format
29. ISO/IEC 21000-15, Information technology – Multimedia framework (MPEG-21) – Part 15: Event Reporting
32. ISO/IEC 23000-7, Information technology – Multimedia Application Format (MPEG-A), Open Access Application Format
33. ISO/IEC 23001-1, Information technology – MPEG Systems Technologies (MPEG-B) – Part 1: Binary MPEG format for XML
35. ETSI TS 102 822-3-2 V1.3.1 (2006-01); Broadcast and On-line Services: Search, select, and rightful use of content on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 2: System aspects in a uni-directional environment
37. IETF RFC 1737, K. Sollins and L. Masinter, Functional Requirements for Uniform Resource Names, December 1994.
39. IETF RFC 2141 R. Moats, URN Syntax, May 1997.
40. IETF RFC 2616 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee "Hypertext Transfer Protocol – HTTP/1.1"
42. “XML-Encryption Syntax and Processing” - W3C Recommendation 10 December 2002. http://www.w3.org/TR/xmlenc-core/.
43. “XML-Signature Syntax and Processing” - W3C Recommendation 12 February 2002. http://www.w3.org/TR/xmldsig-core/.
45. W3C Candidate Recommendation, “XML Path Language (XPath) 2.0”, 3 November 2005, http://www.w3.org/TR/xpath20/
46. OWL Web Ontology Language (http://www.w3.org/TR/owl-features/)
47. The Chillout project, http://chillout.dmpf.org
48. The Mozilla Public License Version 1.1, http://www.mozilla.org/MPL/MPL-1.1.html
49. The Subversion project, http://subversion.tigris.org/
50. The Chillout software repository, http://dmp.jdl.ac.cn/svn/chillout
51. The Apache Maven project, http://maven.apache.org/
52. The Maven Project Object Model, http://maven.apache.org/pom.html
53. The Java SE Development Kit (JDK), http://java.sun.com/javase/downloads/index.jsp
54. Java Media Framework API (JMF), http://java.sun.com/products/java-media/jmf/
55. The Apache Tomcat project, http://tomcat.apache.org/index.html
56. The Apache Ant project, http://ant.apache.org/
57. Java Architecture for XML Binding, http://java.sun.com/webservices/jaxb/
58. The JUnit testing framework, http://www.junit.org/index.htm
59. The Apache Ant project, http://ant.apache.org/
60. Apache Derby, http://db.apache.org/derby/
|
Acronym |
Meaning |
|
AD |
Approved Document |
|
BBL |
Bitstream Binding Language |
|
CCD |
Content Creation Device |
|
CID |
Content Identification Device |
|
CPD |
Content Provider Device |
|
DCB |
DMP Content Broadcast |
|
DCF |
DMP Content File |
|
DCI |
DMP Content Information |
|
DCS |
DMP Content Streaming |
|
DID |
Device Identification Device |
|
DIS |
Digital Item Streaming |
|
DoID |
Domain Identification Device |
|
DMD |
Domain Management Device |
|
DPD |
DRM Tool Provider Device |
|
DRM |
Digital Rights Management |
|
IDP |
Interoperable DRM Platform |
|
GUI |
Graphical User Interface |
|
IP |
Intellectual Property |
|
IP |
Internet Protocol |
|
LID |
License Identification Device |
|
LLAP |
Local License Access Protocol |
|
LPD |
License Provider Device |
|
OWL |
Ontology Web Language |
|
PAV |
Portable Audio and Video (Device) |
|
PKI |
Public Key Infrastructure |
|
PXD |
PAV eXternal Device |
|
RCAP |
Remote Content Access Protocol |
|
REL |
Rights Expression Language |
|
RLAP |
Remote License Access Protocol |
|
RMPI |
Rights Management and Protection Information |
|
RTP |
Real Time Protocol |
|
SAC |
Secure Authenticated Channel |
|
SAV |
Stationary Audio and Video (Device) |
|
TCG |
Trusted Computing Group |
|
TCP |
Trusted Computing Platform |
|
TPD |
DRM Tool Provider Device |
|
TPM |
Technical Protection Measure |
|
TPM |
Trusted Platform Module |
|
TRU |
Traditional Right and Usage |
|
TS |
(MPEG-2) Transport Stream |
|
TSS |
Trusted Software Stack |
|
UDP |
User Datagram Protocol |
|
URI |
Universal Resource Identifier |
|
XML |
eXtensible Markup Language |
Annex A – Introduction to some referenced standards
A.1MPEG-21 Digital Item Declaration
The MPEG-21 Digital Item Declaration (DID) describes a set of abstract terms and concepts to form a useful model for defining Digital Items.
The semantic meanings of the principal elements of the Digital Item Declaration Model are:
A container is a structure that allows items and/or containers to be grouped. These groupings of items and/or containers can be used to form logical packages (for transport or exchange) or logical shelves (for organization). Descriptors allow for the “labeling” of containers with information that is appropriate for the purpose of the grouping (e.g. delivery instructions for a package, or category information for a shelf).
An item is a grouping of sub-items and/or components that are bound to relevant descriptors. Descriptors contain information about the item, as a representation of a work. Items may contain choices, which allow them to be customized or configured. Items may be conditional (on predicates asserted by selections defined in the choices). An item that contains no sub-items can be considered an entity -- a logically indivisible work. An item that does contain sub-items can be considered a compilation -- a work composed of potentially independent sub-parts. Items may also contain annotations to their sub-parts.
A component is the binding of a resource to all of its relevant descriptors. These descriptors are information related to all or part of the specific resource instance. Such descriptors will typically contain control or structural information about the resource (such as bit rate, character set, start points or encryption information) but not information describing the “content” within.
An anchor binds descriptors to a fragment, which corresponds to a specific location or range within a resource.
A descriptor associates information with the enclosing element. This information may be a component (such as a thumbnail of an image, or a text component), or a textual statement.
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. All resources must be locatable via an unambiguous address.
A statement is a literal textual value that contains information, but not an asset. Examples of likely statements include descriptive, control, revision tracking or identifying information.
A.2MPEG-21 Digital Item Identification
ISO/IEC 21000-3, Digital Item Identification (DII) [22] provides a method to use existing identification schemes to identify Digital Items. It relies on existing schemes (such as ISRC) and provides a uniform mechanism to transport industry identifiers within context of MPEG-21. Therefore the specification satisfies two requirements:
· The specification needs to be compatible with existing and future identification schemes; and
· The specification needs to enable use of such identifiers in the context of MPEG-21 applications.
The rationale behind this approach is that (most) identification schemes are content domain specific. It is the stakeholders in these domains that define important issues with respect with “their” identifiers, including:
· Level of Granularity;
· Scope of uniqueness;
· Persistence;
· Reference metadata;
· Resolution;
· Governance.
Identification systems themselves have to be identified because it may be so that different identifiers are included within one Digital Item. For instance, to know that a Digital Item has an identifier “5-010356-663694” is meaningless unless it is known that this is an EAN bar code. Thus ISO/IEC 21000-3 uses namespaces for this and two methods of providing such identifier namespaces.
· Some identifications have their own “native: namespace (e.g. the Digital Object Identifier DOI);
· A Registration Authority has been established to provide a namespace for other identifier systems.
MPEG-21 IPMP Components [23] defines:
· A language named IPMP Digital Item Declaration Language (IPMP DIDL), which provides for a protected Representation of the DID Model, allowing DID hierarchy which is encrypted, digitally signed or otherwise Governed to be included in a DID document in a schematically valid manner.
· The IPMPInfoDescriptor schema, defining structures for expressing Governance information related to a single resource within the Content Item, including all required tools, mechanisms and Licenses.
· The IPMPGeneralInfoDescriptor schema, defining structures for expressing general Governance information related to the whole Content Item, including all required tools, mechanisms and Licenses.
According to IPMP DIDL, for each entity in the DID Model, an IPMP DIDL element is provided as a protected Representation of that entity. didl-msaf and IPMP DIDL element are equally interchangeable within a Digital Item; an IPMP DIDL element replaces a didl-msaf element whenever that element requires protection. For instance, as ISO/IEC 21000-2 DID defines the element <didl:Item>, ISO/IEC 21000-4 defines the equivalent <ipmpdidl:Item> and so on for every element in DIDL.
Each of the IPMP DIDL elements contains identical structure.
1 a maximum of one ipmpdidl:Identifier element, into which an appropriate identifier for the protected Representation may be placed
2 one ipmpdidl:Info element, into which information about the governance is placed
3 one ipmpdidl:Contents element, into which the Governed Content is placed
Below is an example of a Resource (an mp3 file) whose Governance is expressed according to the IPMP DIDL model.
<did:Component>
<!--Asset protected, referenced externally-->
<did:Resource mimeType="application/ipmp">
<ipmpdidl:ProtectedAsset mimeType="video/mpeg">
<ipmpdidl:Identifier>...</ipmpdidl:Identifier>
<ipmpdidl:Info>...</ipmpdidl:Info>
<ipmpdidl:Contents ref="funky1.mp3" mimeType="audio/mpeg"/>
</ipmpdidl:ProtectedAsset>
</did:Resource>
</did:Component>
Figure 263: IPMP information for a governed resource
In this case, the Resource conveyed in element <ipmpdidl:Contents> (although a reference to it is given rather that its inclusion inline) is supposed to be obfuscated or protected in some form, and the necessary information for gaining access to it in clear form is specified in the <ipmp:IPMPInfoDescriptor> element which is child of <ipmpdidl:Info>.
The root element for IPMP Information Descriptor schema is “IPMPInfoDescriptor”, which may contain information related to the algorithms that protect the associated Content, to the licenses that govern them, and an associated digital signature, which is specified in the three elements below:
· ipmp:Tool - The algorithms performing (one or more) IPMP functions such as Authentication, Decryption, watermarking, etc. IPMP Tools can be single modules or even a complete DRM system. This element specifies the information required to gain access to the protected Resource part of the Content Item by conveying algorithm description and configuration settings.
· ipmp:RightsDescriptor – This element contains information about the License that Governs the Resource part of the DMP Content. The License can be contained within this element, or a reference to it (or to a License service) is provided instead. If the License is encrypted, an IPMPInfoDescriptor containing information about how to access it is provided as a direct child of ipmp:RightsDescriptor.
· dsig:Signature - The dsig:Signature element contains the signature for the IPMPInfoDescriptor element.
Annex C.3 provides the schema for the DMP profile of IPMPInfoDescriptor.
A.3.3 The IPMPGeneralInfoDescriptor
The IPMPGeneralInfoDescriptor element is used to convey general Governance information relating to the complete Content Item, and its use is mandatory whenever one or more IPMPInfoDescriptor elements are present in the DCI. In other words, a DCI containing one or more Governed Resources shall use one and only one IPMPGeneralInfoDescriptor to convey general Governance information. This element contains the following elements:
· The ipmp:ToolList element, the list of all the IPMP Tools required to access all the Governed objects part of the DMP Content.
· The ipmp:LicenseCollection element, which contains a collection of references to Licenses for all Governed parts of theDMP Content. This element is used with the purpose of giving the “big picture” on the governed parts of the file in one point.
· The (optional) dsig:Signature element, which contains the signature for the present ipmp:IPMPGeneralInfoDescriptor.
A.4MPEG-21 Rights Expression Language
The MPEG-21 REL comprises of the base and DAC (Dissemination And Capture) profile extensions to represent rights expressions in a plurality of domains: mobile, downloadable, physical media or broadcast of digital content.
These permissions to Use Content are represented in a ‘License’, which is composed of two main parts: the ‘Issuer’, the User granting a Right to another User, and the ‘Grant’, as shown in the Figure below.

Figure 264: Overview of an REL License
The Grant specifies a ‘Resource’, the target content to be controlled by the License, a ‘Principal’, the identifier or certificate of the entity which can be a device, a domain or user, a ‘Right’ to describe what kind of Use is permitted on the Resource, and lastly a set of ‘Condition’ to confine the usage of the resource. The following diagram illustrates the seven basic MPEG REL elements used to encapsulate these information and their inter-relationships.
MPEG-4 is a standard providing the technological elements allowing production, distribution and access to digital content in a wide range of scenarios and applications: from digital cinema to the wireless environment, from the WWW world to the graphical applications, enabling a high level interaction between users and content, subject to the rules specified by its rights holder.
The MPEG-2 and MPEG-4 IPMP eXtension (IPMP-X) specification [12[ and [14] defines the IPMP Tools as modules that perform (one or more) IPMP functions such as authentication, decryption, watermarking, etc. An MPEG-4 stream may be protected by one or more IPMP Tools, which control the access to it: in case of an audio/visual stream, for example, being rendered only by authorized users. A User, during the authoring phase, can decide the level of access the content should have prior the distribution phase take place, i.e. the type and location of IPMP Tools which will govern the content access.
An Identifier long 128-bits is assigned by a Registration Authority identifies each IPMP Tool.
Instantiation of IPMP Tools is performed by a conceptual entity within the Terminal: the Tool Manager. When this action is performed, to each instance of IPMP Tool is assigned a unique identifier, which will be used to distinguish such instance among the other Tools. In order to support multi-platform implementation, a Registration Authority is assigned to record the instantiation API and the Messaging API adopted by every specific platform.
An IPMP Tool may be instantiated in a specific point of the decoding chain of an Elementary stream. Such points named Control Points which are normatively defined in [12[ and [14] with hexadecimal values. For example, in case on an Audio/Visual Stream, the possible Control Points are defined:
To facilitate the cooperation of multiple Tools in the protection and governance of content, a message-based architecture is provided. Once instantiated, an IPMP Tool may communicate with the Terminal or other Tools by means of the Message Router, another conceptual entity within the Terminal, which allows the physical routing of information among two entities (any pair of IPMP Tools or between a Tool and the Terminal). The Standard defines a set of messages, which every IPMP Tool and the Terminal must be able to generate, and interpreter in order to be interoperable with the other components of the framework.
By means of normative messages, every IPMP Tool at any point may require to mutually authenticate with other components. This functionality grants IPMP Tools to operate in a secure environment, enabling the detection of malicious components. After mutual authentication has taken place, encrypted messages may be exchanged among two parties upon agreement on encryption/decryption key
The information included in this overview, including informative example fragments, is taken from, or based closely upon the text in the published TV-Anytime documents SP002V13 ‘System Description’ and SP003v13 Part A ‘Metadata’ also available as ETSI documents TS02 822- 2 Systems and TS 02 822-3-1 Part 3: Metadata. The text here is meant as an informative introductory overview and the reader is referred to these specification documents for the fuller authoritative text.
The TV-Anytime metadata system allows the consumer to find, navigate and manage content from a variety of internal and external sources including, for example, enhanced broadcast, interactive TV, Internet and local storage.
There is a need to associate metadata with content to facilitate human and automated searching for content of interest. Such metadata includes descriptive elements and attractors to aid the search process as well as elements essential to the acquisition, capture and presentation processes; formats, duration, etc. Many of these descriptive elements can be found in electronic programme guides and Web pages.
The TV-Anytime Phase 1 content description metadata is general information about an audio video resource that does not change regardless of how the content is published or broadcast. It includes information such as the Resource title, textual description, and genre. Typically, the audio video Resource creator assigns content description metadata before publication.
A.6.1 TV-Anytime Content Description Metadata
The DMP Metadata used to describe the Audio–Video Resources is taken from the TV-Anytime Content Description and includes:
1) Descriptions of audio –visual resources e.g., television programmes. These descriptions are held in the ProgramInformationTable. They include things like the title of the programme, a synopsis, the genres it falls under and a list of keywords that can be used to match a search. The following example is a ProgramInformationTable containing a single ProgramInformation element and is taken from SP002 [35]
<ProgramInformationTable>
<ProgramInformation programId="crid://hbc.com/foxes/episode11">
<BasicDescription>
<Title type="main">
The one where Fox jumps in the Potomac
</Title>
<Synopsis>
Fox goes to Washington and jumps in the Potomac
</Synopsis>
<Keyword>Fox</Keyword>
<Keyword>Washington</Keyword>
<Keyword>Potomac</Keyword>
<Genre href="urn:tva:metadata:cs:FormatCS:3.5.7.3" type="main"/>
</BasicDescription>
<OtherIdentifier>guid://e41a-b456-a876-3e49</OtherIdentifier>
<OtherIdentifier>urn:mpeg:mpeg21:diid:v-isan:29ef-94ba-53c4-3e7a-4ce8-e-5a45-98ec-f</OtherIdentifier>
<MemberOf crid = "crid://hbc.com/foxes/all" index = "11" xsi:type = "EpisodeOfType"/>
</ProgramInformation>
</ProgramInformationTable>
Figure 265: The tva-msaf:ProgramInformationTable element
2) Descriptions of groups of related items of content e.g., all episodes of "Foxes in the Wild". These descriptions are held in the GroupInformationTable. The following example is a GroupInformationTable containing a single ProgramInformation element. The example is not exhaustive. Again from SP002 [35]
<ProgramDescription>
<GroupInformationTable>
<GroupInformation groupId="crid://hbc.com/foxes/all">
<GroupType xsi:type="ProgramGroupTypeType" value="series"/>
<BasicDescription>
<Title type="main">All episodes of Foxes ever</Title>
<Synopsis>More Foxes than you can handle</Synopsis>
<Keyword>Foxes</Keyword>
<Keyword>all</Keyword>
<Genre href="urn:tva:metadata:cs:FormatCS:3.5.7" type="main"/>
</BasicDescription>
<MemberOf xsi:type="MemberOfType" crid="crid://hbc.com/comedy/all"/>
</GroupInformation>
</GroupInformationTable>
</ProgramDescription>
Figure 266: The tva-msaf:ProgramDescription element
3) A mapping of cast members to unique identifiers. The identifiers can be used in other metadata instances making searching easier. This mapping is held in the CreditsInformationTable, which provides this brief reference that can be used to key into the more comprehensive role mappings provided in the CreditsList that forms a part of the BasicDescription Schema. An illustrative example is given below.
<CreditsInformationTable>
<PersonName personNameId="id1">
<mpeg7:GivenName><![CDATA[Ron]]></mpeg7:GivenName>
<mpeg7:FamilyName><![CDATA[O'Neal]]></mpeg7:FamilyName>
</PersonName>
</CreditsInformationTable>
Figure 267: The tva-msaf:CreditsInformationTable element
A.6.2 Documents related through the CRID
Parts of a TV-Anytime document are related through the CRID. Metadata may be distributed across many TV-Anytime documents, but it is always possible to relate appropriate pieces through CRIDs. Note that the TV-Anytime CRID is an aid for relating the provision of Content by Service Providers with data aggregators, commentators or critics through listings or Electronic Programme Guides (EPGs) using TV-Anytime programme metadata. The Crid is not an authoritative registered Identifier for binding Content to its Content Creator, Rights owner or End User. For this functionality the DMP Content ID is specified in Section 3.1 ‘Identify Content’ and associated Registration Authorities described in the accompanying DMP Specification Approved Document No. 5 [5].
Content Identifiers other than the CRID can be placed in the TV-Anytime metadata under the <OtherIdentifier> tag of the ProgramDescription as shown in the example above.
Programmes can belong to groups, and groups can belong to other groups. Linking programme descriptions with group descriptions using CRIDs reflects this relationship in the metadata. The following explanation is from SP002 [35].
ProgramInformation elements are related to GroupInformation elements through the memberOf or episodeOf elements within the ProgramInformationTable or GroupInformationTable. I.e., the memberOf element contains a group CRID e.g., Foxes Episode 11 is a member of the Foxes group, which is a group that aggregates all episodes of Foxes. This supports the feature where a viewer or End User can say "I like this. What is it? Are there more programmes like this?" By navigating up to the group the viewer may discover that the group is a member of another group and so forth. The higher one goes in the tree the more general the concepts become, i.e., moving from a specific episode of Foxes, to all episodes of Foxes, to all comedy shows, to all shows.
Although out of scope of the DMP, the TV-Anytime specification specifies a protocol for using the CRID to resolve to the locations of the associated DCI, whether these be Internet server or broadcast schedule based. This is a powerful feature of TV-Anytime which may prove useful to service providers serving DMP DCI structured Content over the Internet.
A metadata schema is the formal definition of the structure and type of metadata. TV‑Anytime uses the MPEG-7 Description Definition Language (DDL) [16] to describe metadata structure as well as the XML encoding of metadata. DDL is based on XML schema as recommended by W3C in [44]. TV‑Anytime uses several MPEG-7 datatypes and MPEG-7 Classification Schemes.
A.7MPEG-21 Digital Item Adaptation
MPEG-21 Digital Item Adaptation (DIA) specifies a comprehensive set of description tools that can be exchanged and used to enable the optimised adaptation of multimedia content. DIA descriptions are specified in XML to facilitate the development of applications creating, aggregating, exchanging and consuming the descriptions. Whenever bandwidth is constrained, an efficient XML encoding technique is provided by the MPEG-B part 1 standard [33].
Describing the usage context is required for determining what version of the content optimally fits this context. For this purpose, DIA provides a set of metadata describing the context in terms of networks and devices characteristics, user preferences as well as natural environment characteristics. These metadata are gathered under the term Usage Environment Descriptions.
DIA specifies the syntax and semantics of tools that assist in the adaptation of Digital Items.
DIA is used to satisfy transmission, storage and consumption constraints as well as Quality of Service management.


Figure 268 – The Reference diagram for MPEG-21 DIA
Additionally, DIA specifies content centric metadata facilitating the content adaptation process itself. Firstly, DIA provides a way to express the correspondence between usage context and content characteristics, resulting in possible adaptation operations required for obtaining the optimized version. Secondly, it provides the means to perform content adaptation in an efficient and coding format independent way. In particular, MPEG-21 DIA leverages the use of scalable content such as MPEG-4 Scalable Video Coding (SVC) [6] by specifying a generic tool for describing the high level bitstream syntax and using this description in order to obtain a new adapted version.
Within the ISO/IEC 14496 MPEG-4 standard there are several parts that define file formats for the storage of time-based media (such as audio, video etc.). They are all based and derived from the ISO Base Media File Format [12], which is a structural, media-independent definition. It has a basic box-structuring part, and a definition for timed sequences of multi-media (audio, video etc.) in such a box structured file.
ISO/IEC 21000-9 – File Format [28] defines the storage of an MPEG-21 digital item, with some or all of its ancillary data (such as images, movies, or other non-XML data) within the same file using the structural definition of a box-structured file as defined in the ISO Base Media File Format. The family of the storage file formats is based in the concept of box-structured files. These are used in a number of applications, and it is possible to form ‘multi-purpose’ files which contain the boxes required by more than one specification
The general meta-box can be used at the file level for MPEG-21 files to to hold an MPEG-21 Digital Item Declaration. The meta-box also contains a list of attached resources; which may have local names, and may be located within the same file or in another file.
The full structural power of the meta-box can be used to give significant flexibility in the structure of the MPEG-21 file:
1 Items (other files) required by the digital item may be included in the same file, or in another (possibly combined together in another file), that could be another MPEG-21 file, another file from the family, or of another format entirely;
2 Items (files) included in this or other files may be fragmented, and those fragments interleaved.
3 Items (files) may be protected and the signaling of that protection given.
4 Items (files) may be named, to make access of them easier.
There are URL forms defined for the items (files) defined in a meta-box, and these forms allow access to the items from within or outside the file. The general concept is that the MPEG-21 file is a ‘package’ of files that are ‘pre-cached’ at the client, and this cache obviates the need to fetch many individual files when accessing an MPEG-21 digital item.
The brand defined for MPEG-21 files is ‘mp21’, and if used as a major-brand, the matching file extension would be “.m21”. The IANA registry (http://www.iana.org/) should be consulted for the appropriate MIME type.
There is a registration authority which registers and documents the four-character-code code-points used in this file-format family, as well as some other code-points related to MPEG-4 systems. The database is publicly viewable and registration is free (http://www.mp4ra.org/).
ISO/IEC 21000-15 – Event Reporting [29] is a standard designed to provide rights-holders the means to monitor the usage of copyrighted content in a commercial environment, namely to specify, detect and act upon “reportable events”. These may relate either to the usage of a Digital Item (DI) by a Peer, or to the occurrence of Events related to the device itself. For example, an Event that is related to the usage of a DI could be the rendering (or PLAYing) of resources associated with a DI. Alternatively, an example of an Event that is device-related is when a device discovers (or connects to) another device, an action has no relation to the usage and/or manipulation of DI’s.
In order to allow DI creators to specify reportable events, Event Reporting introduces the concepts of an Event Report Request (ER-R) and an Event Report (ER). An ER-R is used to specify:
· Conditions that must be fulfilled in order for the reportable Event to “occur”;
· The syntax/format of the information contained within an Event Report (ER) that is to be reported when the reportable Event occurs;
· The intended recipient(s) of the Event Report (devices that need to be notified when the reportable Event occurs),
· Parameters related to delivery of the Event Report (e.g. transport mechanism and protocol, delivery timing constraints, priority, etc.).
A general (non-normative) model which reflects the functional aspects of ER-R handling and the subsequent creation of ER’s is shown in the figure below where a set of functional blocks is shown that together can provide the overall Event Reporting functionality. The general model of Event Reporting is as follows:
· An Event Report Request (ER-R) is delivered to an MPEG-21 device;
· The ER-R is parsed and the device waits for Events to “occur”. They are “trapped” by the Event Watchdog which then checks to see if the Events need to be reported on, according to the ER-R’s that the device has received;
· When all of the Event conditions associated with an ER-R have been fulfilled, the device proceeds to construct an ER which includes the data fields specified in the ER-R;
· The device then dispatches the resulting ER towards the ER-R’s specified recipient device(s).

Figure 269: General model of ER-R processing and ER generation
A.10MPEG-21 Digital Item Streaming
Digital Item Streaming (DIS) is part 18 of the MPEG-21 Standard [30]. DIS defines the Bitstream Binding Language, designed to enable the streaming of XML documents in general and Digital Items in particular. The Bitstream Binding Langauge also allows the streaming of binary resources part of a Digital Item, by employing elements from part 7 of ISO/IEC 21000 which specifies the structure of the binary resources which are to be streamed along with their declaration. Fragments of a binary resource are specified using W3C XPATH references.
The Bitstream Binding Language (BBL) enables the description of how a Digital Item and possibly binary content part of it can be fragmented and inserted (bound) into one of several transport streams, being the language agnostic to the format of the data it is able to process, as well as the type of transport streams to be output. Moreover, BBL provides an abstraction layer between a stored Digital Item and its representation in a specific channel. This enables different bitstreams to be created from a single DI to provide different views/subsets of the DI, different renderings of the content and different bitstream formats.
As a result, different parts of a DI can be sent over separate channels.
In BBL, each channel to be used is associated with a Handler. A BBL processor will provide in a handler the functionality required for operating the transport channel with which it is associated. BBL is designed for maximum reusability, so that the binding of resources of type Y to output streams of type O can be specified once, and referenced by all DIs using Y and O. In the same way, when metadata is presented in a standard format for a group of Digital Items, a single BBL binding can be written for that metadata format and applied to all of the DIs.
The Binary MPEG format for XML, or BiM, part of the MPEG-21 suite of Standards, provides a set of generic technologies for encoding XML documents, addressing a broad spectrum of applications and requirements by standardising the methods for transmitting and compressing XML documents.
BiM specifies rules for the preparation of XML documents for efficient transport and storage, both at the encoding and the decoding side of their transmission; at the receiving end, compressed XML documents are decoded, assembled and possibly partitioned.
The coding possibilities (and therefore the encoding size) of every component of a document is achieved by a contextual decoding combined with the use of the schema information. The BiM structure encoding is based on the XML Schema notion of "content model" from which the encoding format takes most of its source of optimization.
The advantages provided by BiM, such as high compression efficiency and flexibility in fragmentating and processing XML documents is achieved by the sharing knowledge of a schema between encoder and decoder. The specification also defines means to compile and transmit schema knowledge information to enable the decoding of compressed XML documents without a priori schema knowledge at the receiving terminal. This because a schema may change over time, or a decoder may not have a priori knowledge of all schema information. By means of this functionality, additional schema information is sent in such a way that it requires minimal CPU of the decoder to be able to process it: schemas are binary encoded and carried in a Schema Update Unit (SUU).
The transmission of a BiM document is progressive, i.e., is done through a set of elementary updates called Fragment Update Units (FUU). These FUUs are themselves packed into access units (AU), which is the minimal transport packet to which timing information is associated. Each FUU is composed of a path (FU Context Path) pointing at the node to be added, updated or deleted to the decoder's current representation of the document, and a payload (FU Payload) containing the portion of the carried document.
On the other hand, during the decoding of a FU Context Path, the element names and types are progressively decoded from the root element down to the context node, in a depth first manner. In this case, at each step of the tree, traversal codes are assigned to each possible element of the path. In addition to this information, its position among its sibling elements is decoded. Other information related to element substitution and type-casting are also decoded. In the case of payload decoding, the element names and types are progressively decoded from the first element to the last one in a breadth first manner.
Annex B – DMP Schemas
B.1 The Media Streaming Access Protocol Extensions schema
The Media Streaming Access Protocol Extensions schema characterised by the following URI: urn:dmp:idp:mediastreaming:accessprotocol:extensions:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:dmp:idp:mediastreaming:accessprotocol:extensions:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dmp-msapx="urn:dmp:idp:mediastreaming:accessprotocol:extensions:2007"
xmlns:msap="urn:mpeg:maf:schema:mediastreaming:accessprotocol:2007"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:msbp="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
xmlns:ipmpinfo-msx="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007"
xmlns:ipmpinfo-msaf="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS"
xmlns:ipmpmsg="urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msaf.xsd"/>
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-DIA-NS" schemaLocation="http://www.dmpf.org/schemas/ued.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007" schemaLocation="http://www.dmpf.org/schemas/msbp.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:accessprotocol:2007" schemaLocation="http://www.dmpf.org/schemas/msap.xsd"/>
<import namespace="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msx.xsd"/>
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msaf.xsd"/>
<import namespace="urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007" schemaLocation="http://www.dmpf.org/schemas/ipmpmsg.xsd"/>
<element name="RequestDRMToolInfoList" type="dmp-msapx:RequestDRMToolInfoListType"/>
<complexType name="RequestDRMToolInfoListType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element ref="ipmpinfo-msx:DeviceInformation" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestDRMToolInfoListResponse" type="dmp-msapx:RequestDRMToolInfoListResponseType"/>
<complexType name="RequestDRMToolInfoListResponseType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element ref="dmp-msapx:DRMToolInfo" minOccurs="0" maxOccurs="unbounded"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="DRMToolInfo" type="dmp-msapx:DRMToolInfoType"/>
<complexType name="DRMToolInfoType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID" />
<element ref="ipmpmsg:ParametricDescription" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Figure 270: The dmp-msafx schema
B.2 The Represent Content Identifier Protocol schema
The Represent Content Identifier Protocol schema characterised by the following URI: urn:dmp:idp:Represent:ContentIdentifierProtocol:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:dmp:idp:Represent:ContentIdentifierProtocol:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dmprcip="urn:dmp:idp:Represent:ContentIdentifierProtocol:2007"
xmlns:msbp="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
xmlns:didl-msaf="urn:mpeg:mpeg21:2006:07-DIDL-NS"
xmlns:didl-msx="urn:mpeg:maf:schema:mediastreaming:DIDLextensions"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:dii-msaf="urn:mpeg:mpeg21:2002:01-DII-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:mpeg21:2006:07-DIDL-NS" schemaLocation="http://www.dmpf.org/schemas/didl-msaf.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007" schemaLocation="http://www.dmpf.org/schemas/msbp.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:DIDLextensions" schemaLocation="http://www.dmpf.org/schemas/didl-msx.xsd"/>
<import namespace="urn:mpeg:mpeg21:2002:01-DII-NS" schemaLocation="http://www.dmpf.org/schemas/dii-msaf.xsd"/>
<complexType name="ContentIdentifierProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
<element name="Ack" type="dmprcip:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<!-- ******************** -->
<!-- Identify Content (1) -->
<!-- ******************** -->
<element name="IdentifyContentRequest" type="dmprcip:IdentifyContentRequestType"/>
<complexType name="IdentifyContentRequestType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element name="DCI" type="didl-msaf:DIDLType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="IdentifyContentResponse" type="dmprcip:IdentifyContentResponseType"/>
<complexType name="IdentifyContentResponseType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element name="DCI" type="didl-msaf:DIDLType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- **************************************** -->
<!-- Identify Content (2) and Content Element -->
<!-- **************************************** -->
<element name="RequestContentIdentifier" type="dmprcip:RequestContentIdentifierType"/>
<complexType name="RequestContentIdentifierType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType"/>
</complexContent>
</complexType>
<element name="RequestContentElementIdentifier" type="dmprcip:RequestContentElementIdentifierType"/>
<complexType name="RequestContentElementIdentifierType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element name="ContentElementSignature" type="dsig:SignatureType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestIdentifierResponse" type="dmprcip:RequestIdentifierResponseType"/>
<complexType name="RequestIdentifierResponseType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element ref="dii-msaf:Identifier"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RegisterIdentifier" type="dmprcip:RegisterIdentifierType"/>
<complexType name="RegisterIdentifierType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element ref="dii-msaf:Identifier"/>
<element name="DCISignature" type="dsig:SignatureType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- **************************************** -->
<!-- Authenticate Content and Content Element -->
<!-- **************************************** -->
<element name="AuthenticateContentRequest" type="dmprcip:AuthenticateContentRequestType"/>
<complexType name="AuthenticateContentRequestType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<choice>
<element name="DCIInfo" type="dmprcip:InfoType"/>
<element name="DCI" type="didl-msaf:DIDLType"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="InfoType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ID" type="anyURI"/>
<element name="Signature" type="dsig:SignatureType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="AuthenticateContentElementRequest" type="dmprcip:AuthenticateContentElementRequestType"/>
<complexType name="AuthenticateContentElementRequestType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<element name="ContentElementInfo" type="dmprcip:InfoType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="AuthenticateResponse" type="dmprcip:AuthenticateResponseType"/>
<complexType name="AuthenticateResponseType">
<complexContent>
<extension base="dmprcip:ContentIdentifierProtocolType">
<sequence>
<choice>
<element name="Signature" type="dsig:SignatureType"/>
<element name="AuthenticationResult" type="boolean"/>
<element name="ErrorCode" type="dmprcip:ErrorCodeType"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="ErrorCodeType">
<restriction base="string">
<enumeration value="HASH_MISSING"/>
<enumeration value="HASH_CORRUPTED"/>
</restriction>
</simpleType>
</schema>
Figure 271: The dmprcip schema
B.3 The Represent Device Identifier Protocol schema
The Represent Device Identifier Protocol schema characterised by the following URI: urn:dmp:idp:Represent:DeviceIdentifierProtocol:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:dmp:idp:Represent:DeviceIdentifierProtocol:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dmprdip="urn:dmp:idp:Represent:DeviceIdentifierProtocol:2007"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:msbp="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007" schemaLocation="http://www.dmpf.org/schemas/msbp.xsd"/>
<complexType name="DeviceIdentifierProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
<element name="Ack" type="dmprdip:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="dmprdip:DeviceIdentifierProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="DeviceIDRequest" type="dmprdip:DeviceIDRequestType"/>
<complexType name="DeviceIDRequestType">
<complexContent>
<extension base="dmprdip:DeviceIdentifierProtocolType">
<sequence>
<element name="VendorID" type="dmprdip:IDType"/>
<element name="ModelID" type="anyURI"/>
<element name="SerialNumber" type="anyURI" minOccurs="0"/>
<element name="DeviceKey" type="dsig:KeyInfoType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="IDType">
<complexContent>
<extension base="dmprdip:DeviceIdentifierProtocolType">
<sequence>
<choice>
<element name="id" type="anyURI"/>
<element ref="dsig:X509Data"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="DeviceIDResponse" type="dmprdip:DeviceIDResponseType"/>
<complexType name="DeviceIDResponseType">
<complexContent>
<extension base="dmprdip:DeviceIdentifierProtocolType">
<sequence>
<element name="DeviceID" type="dsig:KeyInfoType"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Figure 272: The dmprdip schema
B.4 The Represent License Schema
The Represent License schema characterised by the following URI: urn:dmp:idp:Represent:License:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:dmp:idp:Represent:License:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dmprl="urn:dmp:idp:Represent:License:2007"
xmlns:msd="urn:mpeg:maf:schema:mediastreaming:domain:2007"
xmlns:r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:domain:2007" schemaLocation="http://www.dmpf.org/schemas/msd.xsd"/>
<element name="DomainResource" type="dmprl:DomainResourceType" substitutionGroup="r-msaf:resource"/>
<complexType name="DomainResourceType">
<complexContent>
<extension base="r-msaf:Resource">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:DomainKey"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Figure 273: The dmprl schema
B.5 The Represent Store Content Protocol schema
The Represent Store Content Protocol schema characterised by the following URI: urn:dmp:idp:Represent:StoreContentProtocol:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:dmp:idp:Represent:StoreContentProtocol:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dmprscp="urn:dmp:idp:Represent:StoreContentProtocol:2007"
xmlns:didl-msaf="urn:mpeg:mpeg21:2006:07-DIDL-NS"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:msbp="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
xmlns:dii-msaf="urn:mpeg:mpeg21:2002:01-DII-NS"
xmlns:bbl="urn:mpeg:mpeg21:2007:01-BBL-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="urn:mpeg:mpeg21:2006:07-DIDL-NS" schemaLocation="http://www.dmpf.org/schemas/didl-msaf.xsd"/>
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007" schemaLocation="http://www.dmpf.org/schemas/msbp.xsd"/>
<import namespace="urn:mpeg:mpeg21:2002:01-DII-NS" schemaLocation="http://www.dmpf.org/schemas/dii-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg21:2007:01-BBL-NS" schemaLocation="http://www.dmpf.org/schemas/bbl.xsd"/>
<complexType name="StoreContentProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
<element name="Ack" type="dmprscp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="TransferProtocolRequest" type="dmprscp:TransferProtocolRequestType"/>
<complexType name="TransferProtocolRequestType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence maxOccurs="unbounded">
<element name="TransferPrtocol" type="dmprscp:TransferProtocolType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="TransferProtocolType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element name="StandardProtocol" type="dmprscp:StandardProtocolType"/>
<element name="CustomProtocol" type="dmprscp:CustomProtocolType"/>
</choice>
</sequence>
<attribute name="priority" type="int" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="StandardProtocolType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="Option" type="dmprscp:ProtocolOptionType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute type="dmprscp:ProtocolCodeType" name="ProtocolCode" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="CustomProtocolType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="Option" type="dmprscp:ProtocolOptionType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute type="string" name="ProtocolCode" use="required"/>
</extension>
</complexContent>
</complexType>
<simpleType name="ProtocolCodeType">
<restriction base="string">
<enumeration value="TCP"/>
<enumeration value="FTP"/>
<enumeration value="SFTP"/>
<enumeration value="HTTPS"/>
<enumeration value="HTTP"/>
<enumeration value="SOAP"/>
<enumeration value="SMB"/>
</restriction>
</simpleType>
<complexType name="ProtocolOptionType">
<simpleContent>
<extension base="string">
<attribute name="Key" type="string"/>
</extension>
</simpleContent>
</complexType>
<element name="TransferProtocolResponse" type="dmprscp:TransferProtocolResponseType"/>
<complexType name="TransferProtocolResponseType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<choice>
<element name="ProtocolResult" type="msbp:ProtocolResultType"/>
<element name="ProtocolOptions" type="dmprscp:TransferProtocolType" minOccurs="0"/>
</choice>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="ContentUploadRequest" type="dmprscp:ContentUploadRequestType"/>
<complexType name="ContentUploadRequestType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<element name="ContentInfo" type="dmprscp:ContentInfoType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ContentInfoType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element name="DCF" type="dmprscp:DCFType"/>
<element name="DCS" type="dmprscp:DCSType"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DCFType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ContentID" type="anyURI"/>
<element name="Size" type="long"/>
<element name="ContentSignature" type="dsig:SignatureType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DCSType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element ref="didl-msaf:DIDL"/>
<element name="ContentID" type="anyURI"/>
</choice>
<element ref="bbl:BBL" minOccurs="0"/>
<element name="Resource" type="dmprscp:ResourceType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ResourceType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ResourceID" type="anyURI"/>
<element name="Size" type="long"/>
<element name="ResourceSignature" type="dsig:SignatureType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="ContentUploadResponse" type="dmprscp:ContentUploadResponseType"/>
<complexType name="ContentUploadResponseType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<choice>
<element name="StorePath" type="dmprscp:StorePathType" maxOccurs="unbounded"/>
<element name="StoreFailure" type="dmprscp:StoreFailureType" maxOccurs="unbounded"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="StorePathType">
<simpleContent>
<extension base="anyURI">
<attribute name="EntityID" type="anyURI"/>
</extension>
</simpleContent>
</complexType>
<complexType name="StoreFailureType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ResultCode" type="msbp:ProtocolResultType"/>
</sequence>
<attribute name="EntityID" type="anyURI"/>
</extension>
</complexContent>
</complexType>
<element name="UploadStatusRequest" type="dmprscp:UploadStatusRequestType"/>
<complexType name="UploadStatusRequestType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<element ref="dii-msaf:Identifier"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="UploadStatusResponse" type="dmprscp:UploadStatusResponseType"/>
<complexType name="UploadStatusResponseType">
<complexContent>
<extension base="dmprscp:StoreContentProtocolType">
<sequence>
<element ref="msbp:ProtocolResult"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Figure 274: The dmprscp schema
B.6 The Represent Store License Protocol schema
The Represent Store License Protocol schema characterised by the following URI: urn:dmp:idp:Represent:StoreLicenseProtocol:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:dmp:idp:Represent:StoreLicenseProtocol:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dmprslp="urn:dmp:idp:Represent:StoreLicenseProtocol:2007"
xmlns:didl-msaf="urn:mpeg:mpeg21:2006:07-DIDL-NS"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:msbp="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
xmlns:r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="urn:mpeg:mpeg21:2006:07-DIDL-NS" schemaLocation="http://www.dmpf.org/schemas/didl-msaf.xsd"/>
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007" schemaLocation="http://www.dmpf.org/schemas/msbp.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<complexType name="StoreLicenseProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
<element name="Ack" type="dmprslp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="dmprslp:StoreLicenseProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="StoreLicenseRequest" type="dmprslp:StoreLicenseRequestType"/>
<complexType name="StoreLicenseRequestType">
<complexContent>
<extension base="dmprslp:StoreLicenseProtocolType">
<sequence>
<element name="ContentItem" type="dmprslp:ItemType"/>
<element name="ContentElement" type="dmprslp:ItemType" minOccurs="0" maxOccurs="unbounded"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ItemType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ID" type="anyURI"/>
<element name="LicenseTemplate" type="r-msaf:License" minOccurs="0"/>
<element ref="dmprslp:LicensingDirectives" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="LicensingDirectives" type="dmprslp:LicensingDirectivesType"/>
<complexType name="LicensingDirectivesType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="DenyDirective" type="r-msaf:License" minOccurs="0" maxOccurs="unbounded"/>
<element name="ExclusiveGrantDirective" type="r-msaf:License" minOccurs="0" maxOccurs="unbounded"/>
<element name="MandatoryGrantDirective" type="r-msaf:License" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Figure 275: The dmprslp schema`
Annex C – DMP Profiles of Schemas defined by other Bodies
C.1 The MPEG-21 Digital Item Streaming schema
The schema characterised by the following URI: urn:mpeg:mpeg21:2007:01-BBL-NS is given below.
<?xml version="1.0"?>
<!-- ***************************************************************************
This XML document was originally developed in the course of development of
the ISO/IEC 21000 standard (MPEG-21). This XML document contains either a
part of the MPEG-21 schema implementation for one or more MPEG-21 tools as
specified by the MPEG-21 Requirements or MPEG-21 examples conformant to the
MPEG-21 schemas.
ISO/IEC gives users of MPEG-21 free license to this XML document or
modifications thereof for use in hardware or software products claiming
conformance to MPEG-21.
Those intending to use this XML document in hardware or software products are
advised that its use may infringe existing patents. The original developers
of this XML document and his/her company, the subsequent editors and their
companies, and ISO/IEC have no liability for use of this XML document or
modifications thereof in an implementation.
Copyright is not released for non MPEG-21 conforming products. The
organizations who contributed to this XML document retain the full right to
use the code for their own purpose, assign or donate their contribution to a
third party and inhibit third parties from using their contribution for non
MPEG-21 conforming products.
Copyright (c) 2007 ISO/IEC.
This XML document is provided for informative purposes only. If any parts of
this XML document contradict the normative part of the corresponding standard
document then the normative part should be used as the definitive
specification.
This notice must be included in all copies or derivative works.
**************************************************************************** -->
<!--=======================================
####################################################################
# ISO/IEC 21000-18/AMD 1 #
# Information technology #
# - Multimedia framework (MPEG-21) #
# - Part 18: Digital Item Streaming #
# #
# Schema for Bitstream Binding Language (BBL) #
# #
####################################################################
=======================================-->
<xs:schema
xmlns:bbl="urn:mpeg:mpeg21:2007:01-BBL-NS"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:mpeg:mpeg21:2007:01-BBL-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="1.0.0">
<!-- ********************************************************************* -->
<!-- Abstract Type Declarations ** -->
<!-- ********************************************************************* -->
<xs:attribute name="name" type="xs:QName"/>
<!-- *********************************************************************** -->
<xs:attribute name="value" type="xs:string"/>
<!-- *********************************************************************** -->
<xs:attribute name="match" type="xs:string" default="."/>
<!-- *********************************************************************** -->
<xs:attribute name="handler" type="xs:IDREF"/>
<!-- *********************************************************************** -->
<xs:attribute name="encoding" type="xs:IDREF"/>
<!-- *********************************************************************** -->
<xs:attributeGroup name="timeScheme">
<xs:attribute name="timeScheme">
<xs:simpleType>
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NCName">
<xs:enumeration value="npt"/>
<xs:enumeration value="smpte-24"/>
<xs:enumeration value="smpte-24-drop"/>
<xs:enumeration value="smpte-25"/>
<xs:enumeration value="smpte-30"/>
<xs:enumeration value="smpte-30-drop"/>
<xs:enumeration value="smpte-50"/>
<xs:enumeration value="smpte-60"/>
<xs:enumeration value="smpte-60-drop"/>
<xs:enumeration value="mp7t"/>
<xs:enumeration value="clock"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="frac\(\d+\)"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:attribute>
</xs:attributeGroup>
<!-- *********************************************************************** -->
<xs:complexType name="SourceElementType" abstract="true">
<xs:attribute name="xmlSource" type="xs:string" use="optional"/>
<xs:attribute name="binarySource" type="xs:string" use="optional"/>
<xs:attribute name="bSrcNamespace" type="xs:string" use="optional"/>
<xs:attributeGroup ref="bbl:timeScheme"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="IdentifiableElementType">
<xs:complexContent>
<xs:extension base="bbl:SourceElementType">
<xs:attribute name="id" type="xs:ID" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="BBLDocType">
<xs:complexContent>
<xs:extension base="bbl:IdentifiableElementType">
<xs:sequence>
<xs:element name="Declarations" minOccurs="0"
type="bbl:DeclarationsType"/>
<xs:element name="Variables" minOccurs="0" type="bbl:VariablesType"/>
<xs:element name="Register" type="bbl:RegisterType"/>
<xs:choice maxOccurs="unbounded">
<xs:element name="Packet" type="bbl:PacketType"/>
<xs:element name="PacketStream" type="bbl:PacketStreamType"/>
</xs:choice>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="AbstractVarType">
<xs:complexContent>
<xs:extension base="bbl:SourceElementType">
<xs:attribute ref="bbl:name" use="required"/>
<xs:attribute ref="bbl:value" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="ParametricElementType">
<xs:complexContent>
<xs:extension base="bbl:IdentifiableElementType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:any namespace="##other"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="AbstractPacketType" abstract="true">
<xs:complexContent>
<xs:extension base="bbl:IdentifiableElementType">
<xs:sequence>
<xs:element name="HandlerParams" type="bbl:ParametricElementType" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="bbl:handler" use="optional"/>
<xs:attribute name="deliveryCondition" type="xs:string" use="optional"/>
<xs:attribute name="deliveryTime" type="xs:string" use="optional"/>
<xs:attribute name="repeat" type="xs:float" use="optional" default="0.0"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="AbstractContentType">
<xs:complexContent>
<xs:extension base="bbl:IdentifiableElementType">
<xs:sequence maxOccurs="unbounded">
<xs:any namespace="##any" processContents="skip"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="TimingElementType">
<xs:attribute ref="bbl:match" use="optional"/>
<xs:attribute ref="bbl:value" use="required"/>
</xs:complexType>
<!-- *********************************************************************** -->
<!-- ** BBL concrete types ** -->
<!-- *********************************************************************** -->
<xs:element name="BBL">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="Instance" type="bbl:InstanceType"/>
<xs:element name="Binding" type="bbl:BindingType"/>
</xs:choice>
</xs:complexType>
</xs:element>
<!-- *********************************************************************** -->
<xs:complexType name="InstanceType">
<xs:complexContent>
<xs:extension base="bbl:BBLDocType"/>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="BindingType">
<xs:complexContent>
<xs:extension base="bbl:BBLDocType"/>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="DeclarationsType">
<xs:sequence maxOccurs="unbounded">
<xs:any namespace="##any" processContents="skip"/>
</xs:sequence>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="VariablesType">
<xs:complexContent>
<xs:extension base="bbl:SourceElementType">
<xs:choice maxOccurs="unbounded">
<xs:element name="Define" type="bbl:DefineType"/>
<xs:element name="Assign" type="bbl:AbstractVarType"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="RegisterType">
<xs:complexContent>
<xs:extension base="bbl:SourceElementType">
<xs:sequence>
<xs:element name="Handler" type="bbl:HandlerType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Encoder" type="bbl:EncoderType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Multiplexer" type="bbl:MultiplexerType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="BSD" type="bbl:BSDType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="Function" type="bbl:FunctionType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="DefineType">
<xs:complexContent>
<xs:extension base="bbl:AbstractVarType">
<xs:attribute name="type" type="bbl:VarType" use="optional" default="xs:int"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="VarType">
<xs:restriction base="xs:QName">
<xs:enumeration value="xs:integer"/>
<xs:enumeration value="xs:int"/>
<xs:enumeration value="xs:long"/>
<xs:enumeration value="xs:short"/>
<xs:enumeration value="xs:decimal"/>
<xs:enumeration value="xs:float"/>
<xs:enumeration value="xs:double"/>
<xs:enumeration value="xs:boolean"/>
<xs:enumeration value="xs:byte"/>
<xs:enumeration value="xs:QName"/>
<xs:enumeration value="xs:dateTime"/>
<xs:enumeration value="xs:base64Binary"/>
<xs:enumeration value="xs:hexBinary"/>
<xs:enumeration value="xs:unsignedInt"/>
<xs:enumeration value="xs:unsignedShort"/>
<xs:enumeration value="xs:unsignedByte"/>
<xs:enumeration value="xs:time"/>
<xs:enumeration value="xs:date"/>
<xs:enumeration value="xs:anySimpleType"/>
</xs:restriction>
</xs:simpleType>
<!-- *********************************************************************** -->
<xs:complexType name="HandlerType">
<xs:complexContent>
<xs:extension base="bbl:ParametricElementType">
<xs:attribute name="handlerURI" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="EncoderType">
<xs:complexContent>
<xs:extension base="bbl:ParametricElementType">
<xs:attribute name="encoderURI" type="xs:anyURI"
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="MultiplexerType">
<xs:choice maxOccurs="unbounded">
<xs:element name="Channel" type="bbl:ChannelType"/>
<xs:element name="Multiplexer" type="bbl:MultiplexerType"/>
</xs:choice>
<xs:attribute ref="bbl:handler" use="optional"/>
<xs:attribute name="mode" use="required">
<xs:simpleType>
<xs:restriction base="xs:NCName">
<xs:enumeration value="packetCount"/>
<xs:enumeration value="bandwidth"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="weight" type="xs:int" use="optional" default="1"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="ChannelType">
<xs:attribute name="id" type="xs:ID" use="required"/>
<xs:attribute name="weight" type="xs:int" use="optional" default="1"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="BSDType">
<xs:attribute name="namespace" type="xs:anyURI" use="required"/>
<xs:attribute name="bsSchemaLocation" type="xs:anyURI" use="required"/>
<xs:attribute name="fromBinarySource" type="xs:boolean" use="optional"
default="true"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="FunctionType">
<xs:annotation>
<xs:documentation>Defines an ECMAScript based XPath function</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="bbl:name" use="required"/>
<xs:attribute name="args" type="xs:nonNegativeInteger" use="optional" default="0"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="PacketType">
<xs:complexContent>
<xs:extension base="bbl:AbstractPacketType">
<xs:sequence>
<xs:element name="Content" type="bbl:AbstractContentType"/>
<xs:element name="Variables" type="bbl:VariablesType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="PacketStreamType">
<xs:complexContent>
<xs:extension base="bbl:AbstractPacketType">
<xs:sequence>
<xs:choice>
<xs:element name="ContentTemplate" type="bbl:AbstractContentType"/>
<xs:element name="Bind" type="bbl:BindType"/>
</xs:choice>
<xs:element name="Variables" type="bbl:VariablesType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="IncludeType">
<xs:complexContent>
<xs:extension base="bbl:SourceElementType">
<xs:sequence>
<xs:element name="Timing" type="bbl:TimingType" minOccurs="0"/>
<xs:element name="Fragmentation" type="bbl:FragmentationType"
minOccurs="0"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="bbl:Attribute"/>
<xs:element name="Include" type="bbl:IncludeType"/>
<xs:element name="Encode" type="bbl:EncodeType"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="ref" type="xs:string" use="required"/>
<xs:attribute name="depth" use="optional" default="0">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="-1"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="height" use="optional" default="0">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="-1"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref="bbl:match" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="TimingType">
<xs:choice maxOccurs="unbounded">
<xs:element name="DeliveryTimes" type="bbl:TimingElementType">
</xs:element>
<xs:element name="Durations" type="bbl:TimingElementType">
</xs:element>
</xs:choice>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="FragmentationType">
<xs:sequence>
<xs:element name="FragmentAt" type="bbl:FragmentAtType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="Size" type="bbl:SizeType" minOccurs="0"/>
<xs:element name="Duration" type="bbl:DurationType" minOccurs="0"/>
<xs:element name="Count" type="bbl:CountType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="Constraint" type="bbl:ConstraintType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="attributes" use="optional" default="none">
<xs:simpleType>
<xs:restriction base="xs:NCName">
<xs:enumeration value="none"/>
<xs:enumeration value="id"/>
<xs:enumeration value="context"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="FragmentAtType">
<xs:attribute ref="bbl:match" use="required"/>
<xs:attribute name="deliveryTime" type="xs:string" use="optional"/>
<xs:attribute name="repeat" type="xs:string" use="optional" default="0"/>
<xs:attribute name="id" type="xs:ID" use="optional"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="SizeType">
<xs:attribute name="value" type="xs:positiveInteger" use="required"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="DurationType">
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="CountType">
<xs:attribute name="value" type="xs:positiveInteger" use="required"/>
<xs:attribute ref="bbl:match" use="optional"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="ConstraintType">
<xs:attribute name="type" use="required">
<xs:simpleType>
<xs:restriction base="xs:NCName">
<xs:enumeration value="first"/>
<xs:enumeration value="last"/>
<xs:enumeration value="unbroken"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref="bbl:match" use="optional"/>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="EncodeType">
<xs:complexContent>
<xs:extension base="bbl:ParametricElementType">
<xs:attribute ref="bbl:encoding" use="required"/>
<xs:attribute ref="bbl:match" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<xs:complexType name="BindType">
<xs:complexContent>
<xs:extension base="bbl:SourceElementType">
<xs:sequence minOccurs="0">
<xs:element name="Binding" type="bbl:BindingType"/>
</xs:sequence>
<xs:attribute name="binding" type="xs:string" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- *********************************************************************** -->
<!-- ** Elts & Attrs used in BBL documents attached to non-bbl elements ** -->
<!-- *********************************************************************** -->
<xs:element name="value-of">
<xs:complexType>
<xs:complexContent>
<xs:extension base="bbl:SourceElementType">
<xs:attribute name="select" type="xs:string" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- *********************************************************************** -->
<xs:element name="Attribute">
<xs:complexType>
<xs:complexContent>
<xs:extension base="bbl:IdentifiableElementType">
<xs:sequence>
<xs:element ref="bbl:value-of" minOccurs="0"/>
</xs:sequence>
<xs:attribute ref="bbl:name" use="required"/>
<xs:attribute ref="bbl:match" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- *********************************************************************** -->
<!-- ** BBL attributes which are transmitted as part of xml fragments ** -->
<!-- *********************************************************************** -->
<!-- *********************************************************************** -->
<xs:attribute name="context" type="xs:string" fixed="$addr"/>
<!-- *********************************************************************** -->
<xs:attribute name="rap" type="xs:boolean" fixed="true"/>
<!-- *********************************************************************** -->
<xs:attribute name="seqNo" type="xs:integer"/>
<!-- *********************************************************************** -->
<xs:attribute name="processable" type="xs:boolean" default="true"/>
</xs:schema>
Figure 276: The bbl schema
C.2 The MPEG-21 Digital Item Adaptation schema
The schema characterised by the following URI: urn:mpeg:mpeg21:2003:01-DIA-NS is given below.
<?xml version="1.0"?>
<!-- Digital Item Adaptation ISO/IEC 21000-7 -->
<!-- Schema for basic schema tools -->
<schema
version="ISO/IEC 21000-7"
id="DIA.xsd"
targetNamespace="urn:mpeg:mpeg21:2003:01-DIA-NS"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:dia="urn:mpeg:mpeg21:2003:01-DIA-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- ################################################ -->
<!-- Definition of DIA Base Types -->
<!-- ################################################ -->
<complexType name="DIABaseType" abstract="true">
<complexContent>
<restriction base="anyType">
<attribute name="id" type="ID" use="optional"/>
</restriction>
</complexContent>
</complexType>
<complexType name="DIADescriptionType" abstract="true">
<complexContent>
<extension base="dia:DIABaseType"/>
</complexContent>
</complexType>
<!-- ################################################ -->
<!-- Definition of Description Metadata Type -->
<!-- ################################################ -->
<complexType name="DescriptionMetadataType">
<complexContent>
<extension base="dia:DIABaseType">
<sequence>
<element name="ClassificationSchemeAlias" maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base="dia:DIABaseType">
<attribute name="alias" type="NMTOKEN" use="required"/>
<attribute name="href" type="anyURI" use="required"/>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- ################################################ -->
<!-- Definition of DIA Root Element -->
<!-- ################################################ -->
<element name="DIA">
<complexType>
<sequence>
<element name="DescriptionMetadata" type="dia:DescriptionMetadataType"
minOccurs="0"/>
<choice maxOccurs="unbounded">
<element name="Description" type="dia:DIADescriptionType"/>
<element name="Reference" type="dia:ReferenceType"/>
</choice>
</sequence>
</complexType>
</element>
<element name="DIADescriptionUnit" type="dia:DIABaseType"/>
<!-- ################################################ -->
<!-- Definition of Reference -->
<!-- ################################################ -->
<complexType name="ReferenceType">
<attribute name="uri" type="anyURI" use="required"/>
</complexType>
</schema>
Figure 277: The dia schema
C.3 The Media Streaming Application Format DIDL Profile schema
The schema characterised by the following URI: urn:mpeg:mpeg21:2006:07-DIDL-NS is given below.
<?xml version="1.0"?>
<schema targetNamespace="urn:mpeg:mpeg21:2006:07-DIDL-NS"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:didl-msaf="urn:mpeg:mpeg21:2006:07-DIDL-NS"
xmlns:didl-msx="urn:mpeg:maf:schema:mediastreaming:DIDLextensions"
xmlns:ipmpinfo-msaf="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS"
xmlns:ipmpdidl-msaf="urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS"
xmlns:didmodel="urn:mpeg:mpeg21:2002:02-DIDMODEL-NS"
xmlns:dii-msaf="urn:mpeg:mpeg21:2002:01-DII-NS"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.1">
<import namespace="urn:mpeg:mpeg21:2002:02-DIDMODEL-NS" schemaLocation="http://www.dmpf.org/schemas/didmodel.xsd"/>
<import namespace="urn:mpeg:mpeg21:2002:01-DII-NS" schemaLocation="http://www.dmpf.org/schemas/dii-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpdidl-msaf.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:DIDLextensions" schemaLocation="http://www.dmpf.org/schemas/didl-msx.xsd"/>
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<!--=========================================================-->
<attributeGroup name="ID_ATTRS">
<attribute name="id" type="ID" use="optional"/>
</attributeGroup>
<element name="DIDL" type="didl-msaf:DIDLType"/>
<complexType name="DIDLType">
<sequence>
<element ref="didl-msaf:DIDLInfo" minOccurs="0" maxOccurs="unbounded"/>
<element ref="didmodel:Item"/>
</sequence>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
<element name="DIDLInfo" type="didl-msaf:DIDLInfoType"/>
<complexType name="DIDLInfoType">
<sequence>
<element name="DCISignature" type="dsig:SignatureType"/>
</sequence>
</complexType>
<element name="Item" type="didl-msaf:ItemType" substitutionGroup="didmodel:Item"/>
<complexType name="ItemType">
<complexContent>
<extension base="didmodel:ItemType">
<sequence>
<element ref="didmodel:Descriptor" maxOccurs="unbounded"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="didmodel:Item"/>
<element ref="didmodel:Component"/>
</choice>
</sequence>
<attributeGroup ref="didl-msaf:ID_ATTRS"/>
</extension>
</complexContent>
</complexType>
<element name="Descriptor" type="didl-msaf:DescriptorType" substitutionGroup="didmodel:Descriptor"/>
<complexType name="DescriptorType">
<complexContent>
<extension base="didmodel:DescriptorType">
<sequence>
<element ref="didmodel:Statement"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Statement" type="didl-msaf:StatementType" substitutionGroup="didmodel:Statement"/>
<complexType name="StatementType" mixed="true">
<complexContent mixed="true">
<extension base="didmodel:StatementType">
<sequence>
<choice>
<element ref="dii-msaf:Identifier"/>
<element ref="dii-msaf:RelatedIdentifier"/>
<element ref="didl-msx:Metadata"/>
<element ref="ipmpinfo-msaf:IPMPGeneralInfoDescriptor"/>
<element name="ContentElementSignature" type="dsig:SignatureType"/>
</choice>
</sequence>
<attribute name="mimeType" type="string"/>
<attribute name="ref" type="anyURI"/>
</extension>
</complexContent>
</complexType>
<element name="Component" type="didl-msaf:ComponentType" substitutionGroup="didmodel:Component"/>
<complexType name="ComponentType">
<complexContent>
<extension base="didmodel:ComponentType">
<sequence>
<element ref="didmodel:Resource" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Resource" type="didl-msaf:ResourceType" substitutionGroup="didmodel:Resource"/>
<complexType name="ResourceType" mixed="true">
<complexContent mixed="true">
<extension base="didmodel:ResourceType">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"/>
</sequence>
<attribute name="mimeType" type="string" use="required"/>
<attribute name="ref" type="anyURI"/>
<attribute name="encoding" type="string"/>
<attribute name="contentEncoding" type="NMTOKENS"/>
</extension>
</complexContent>
</complexType>
<element name="Choice" type="didl-msaf:ChoiceType" substitutionGroup="didmodel:Choice"/>
<complexType name="ChoiceType">
<complexContent>
<extension base="didmodel:ChoiceType">
<sequence>
<element ref="didmodel:Condition" minOccurs="0" maxOccurs="unbounded"/>
<element ref="didmodel:Descriptor" minOccurs="0" maxOccurs="unbounded"/>
<element ref="didmodel:Selection" maxOccurs="unbounded"/>
</sequence>
<attribute name="minSelections" type="nonNegativeInteger"/>
<attribute name="maxSelections" type="positiveInteger"/>
<attribute name="default" type="IDREFS"/>
<attribute name="choice_id" type="ID"/>
<anyAttribute namespace="##other" processContents="lax"/>
</extension>
</complexContent>
</complexType>
<element name="Selection" type="didl-msaf:SelectionType" substitutionGroup="didmodel:Selection"/>
<complexType name="SelectionType">
<complexContent>
<extension base="didmodel:SelectionType">
<sequence>
<element ref="didmodel:Condition" minOccurs="0" maxOccurs="unbounded"/>
<element ref="didmodel:Descriptor" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="select_id" type="ID" use="required"/>
<anyAttribute namespace="##other" processContents="lax"/>
</extension>
</complexContent>
</complexType>
<element name="Condition" type="didl-msaf:ConditionType" substitutionGroup="didmodel:Condition"/>
<complexType name="ConditionType">
<complexContent>
<extension base="didmodel:ConditionType">
<attribute name="require" type="IDREFS"/>
<attribute name="except" type="IDREFS"/>
</extension>
</complexContent>
</complexType>
</schema>
Figure 278: The didl-msaf schema
C.4 The Media Streaming DIDL Extensions Schema
The schema characterised by the following URI: urn:mpeg:maf:schema:mediastreaming:DIDLextensions is given below.
<?xml version="1.0"?>
<schema targetNamespace="urn:mpeg:maf:schema:mediastreaming:DIDLextensions"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:didl-msx="urn:mpeg:maf:schema:mediastreaming:DIDLextensions"
xmlns:ipmpdidl-msaf="urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.1">
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpdidl-msaf.xsd"/>
<element name="Metadata" type="didl-msx:MetadataType"/>
<complexType name="MetadataType">
<sequence>
<choice>
<group ref="ipmpdidl-msaf:IPMPDIDLChildGroup" minOccurs="0"/>
<element ref="didl-msx:StructuredData" maxOccurs="unbounded"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="id" type="anyURI" use="optional"/>
</complexType>
<element name="StructuredData" type="didl-msx:StructuredDataType"/>
<complexType name="StructuredDataType">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"/>
</sequence>
<attribute name="ref" type="anyURI" default="urn:mpeg:ms-maf:tva:2006:07"/>
</complexType>
</schema>
Figure 279: The didl-msx schema
The schema characterised by the following URI: urn:mpeg:mpeg21:2002:02-DIDMODEL-NS is given below.
<?xml version="1.0"?>
<!-- *******************************************************************************
This XML document was originally developed in the course of development of the ISO/IEC
21000 standard (MPEG-21). This XML document contains either a part of the MPEG-21 schema
implementation for one or more MPEG-21 tools as specified by the MPEG-21 Requirements or
MPEG-21 examples conformant to the MPEG-21 schemas.
ISO/IEC gives users of MPEG-21 free license to this XML document or modifications thereof
for use in hardware or software products claiming conformance to MPEG-21.
Those intending to use this XML document in hardware or software products are advised that
its use may infringe existing patents. The original developers of this XML document and his/her
company, the subsequent editors and their companies, and ISO/IEC have no liability for use of
this XML document or modifications thereof in an implementation.
Copyright is not released for non MPEG-21 conforming products. The organizations who
contributed to this XML document retain the full right to use the code for their own purpose,
assign or donate their contribution to a third party and inhibit third parties from using their
contribution for non MPEG-21 conforming products.
Copyright (c) 2001-2005 ISO/IEC.
This XML document is provided for informative purposes only. If any parts of this XML
document contradict the normative part of the corresponding standard document then the
normative part should be used as the definitive specification.
This notice must be included in all copies or derivative works.
****************************************************************************-->
<!--=======================================
####################################################################
# ISO/IEC 21000-2:2005 #
# Information technology #
# Multimedia framework (MPEG-21) #
# Part 2: Digital Item Declaration #
# #
# Schema for DID Model abstract Types #
# #
####################################################################
=======================================-->
<schema targetNamespace="urn:mpeg:mpeg21:2002:02-DIDMODEL-NS" xmlns:didmodel="urn:mpeg:mpeg21:2002:02-DIDMODEL-NS" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.01">
<complexType name="DIDBaseType" abstract="true"/>
<element name="Container" type="didmodel:ContainerType" abstract="true"/>
<complexType name="ContainerType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Item" type="didmodel:ItemType" abstract="true"/>
<complexType name="ItemType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Descriptor" type="didmodel:DescriptorType" abstract="true"/>
<complexType name="DescriptorType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Statement" type="didmodel:StatementType" abstract="true"/>
<complexType name="StatementType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Component" type="didmodel:ComponentType" abstract="true"/>
<complexType name="ComponentType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Anchor" type="didmodel:AnchorType" abstract="true"/>
<complexType name="AnchorType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Fragment" type="didmodel:FragmentType" abstract="true"/>
<complexType name="FragmentType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Condition" type="didmodel:ConditionType" abstract="true"/>
<complexType name="ConditionType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Choice" type="didmodel:ChoiceType" abstract="true"/>
<complexType name="ChoiceType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Selection" type="didmodel:SelectionType" abstract="true"/>
<complexType name="SelectionType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Resource" type="didmodel:ResourceType" abstract="true"/>
<complexType name="ResourceType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Annotation" type="didmodel:AnnotationType" abstract="true"/>
<complexType name="AnnotationType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
<element name="Assertion" type="didmodel:AssertionType" abstract="true"/>
<complexType name="AssertionType" abstract="true">
<complexContent>
<extension base="didmodel:DIDBaseType"/>
</complexContent>
</complexType>
</schema>
Figure 280: The didmodel schema
C.6 The Digital Item Identification schema
The schema characterised by the following URI: urn:mpeg:mpeg21:2002:01-DII-NS is given below.
<?xml version="1.0" encoding="UTF-8"?>
<!--############################################################-->
<!-- -->
<!-- XML Schema for ISO/IEC 21000-3 -->
<!-- -->
<!--############################################################-->
<xsd:schema targetNamespace="urn:mpeg:mpeg21:2002:01-DII-NS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:mpeg:mpeg21:2002:01-DII-NS"
version="0.02">
<!--#########################################
ISO/IEC 21000-3 Identifier Element
#########################################-->
<xsd:element name="Identifier" type="xsd:anyURI"/>
<!--#############################################
ISO/IEC 21000-3 Related Identifier Element
#############################################-->
<xsd:element name="RelatedIdentifier">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:anyURI">
<xsd:attribute name="relationshipType" type="xsd:anyURI"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<!--#############################################
ISO/IEC 21000-3 Type Element
#############################################-->
<xsd:element name="Type" type="xsd:anyURI"/>
</xsd:schema>
Figure 281: The dii-msaf schema
C.7 The Event Reporting schema
The schema characterised by the following URI: urn:mpeg:mpeg21:2002:01-DII-NS is given below.
<?xml version="1.0"?>
<!--============================================================-->
<!--============================================================-->
<!-- -->
<!-- Schema for ERL XML Document Type -->
<!-- -->
<!--============================================================-->
<!--============================================================-->
<xsd:schema targetNamespace="urn:mpeg:mpeg21:2005:01-ERL-NS"
xmlns:erl="urn:mpeg:mpeg21:2005:01-ERL-NS"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:dii="urn:mpeg:mpeg21:2002:01-DII-NS"
xmlns:dia="urn:mpeg:mpeg21:2003:01-DIA-NS"
xmlns:sx="urn:mpeg:mpeg21:2003:01-REL-SX-NS"
xmlns:mpeg7="urn:mpeg:mpeg7:schema:2004"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-DIA-NS" schemaLocation="http://www.dmpf.org/schemas/dia.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2002:01-DII-NS" schemaLocation="http://www.dmpf.org/schemas/dii-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-SX-NS" schemaLocation="http://www.dmpf.org/schemas/rel-sx-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg7:schema:2004" schemaLocation="http://www.dmpf.org/schemas/mpeg7.xsd"/>
<!-- ############################################ -->
<!-- 7.1 Definition of an Event Report Request -->
<!-- ############################################ -->
<xsd:element name="ERR">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="erl:ERRDescriptor"/>
<xsd:element ref="erl:ERSpecification"/>
<xsd:element ref="erl:EventConditionDescriptor"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- ######################################## -->
<!-- 7.2 Definition of ERRDescriptor -->
<!-- ######################################## -->
<xsd:element name="ERRDescriptor">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="LifeTime" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="StartTime" type="xsd:dateTime"/>
<xsd:element name="EndTime" type="xsd:dateTime"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Modification" type="erl:ModificationType" maxOccurs="unbounded"/>
<xsd:element name="Priority" default="2" minOccurs="0">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="0"/>
<xsd:enumeration value="1"/>
<xsd:enumeration value="2"/>
<xsd:enumeration value="3"/>
<xsd:enumeration value="4"/>
<xsd:enumeration value="5"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="ModificationType">
<xsd:sequence>
<xsd:element ref="erl:PeerId"/>
<xsd:element ref="erl:UserId"/>
<xsd:element name="Time" type="xsd:dateTime"/>
<xsd:element name="Description" type="erl:DescriptionType" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<!-- ############################################### -->
<!-- 7.3 Definition of ER Descriptor within an ER-R -->
<!-- ############################################### -->
<xsd:element name="ERSpecification">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="dii:Identifier" minOccurs="0"/>
<xsd:element name="ERDescription" type="erl:DescriptionType" minOccurs="0"/>
<xsd:element name="AccessControl" type="xsd:anyType" minOccurs="0"/>
<xsd:element name="ERPayloadSpecification">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ERIdentifier" minOccurs="0">
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:anyURI">
<xsd:attribute name="baseId" type="xsd:boolean"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="PeerId" minOccurs="0"/>
<xsd:element name="UserId" minOccurs="0"/>
<xsd:element name="Time" minOccurs="0"/>
<xsd:element name="Location" minOccurs="0"/>
<xsd:element name="DIOperation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="DomainData" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="reportTag" type="xsd:string" use="optional"/>
<xsd:attribute name="semantics" type="xsd:anyURI" use="required"/>
<xsd:attribute name="syntax" type="xsd:anyURI" use="required"/>
<xsd:attribute name="value" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="DIMetadata" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="DISelection" minOccurs="0">
<xsd:complexType>
<xsd:choice>
<xsd:element name="DISelectionViaDII" minOccurs="0"/>
<xsd:element name="DISelectionViaRelatedDII" minOccurs="0"/>
<xsd:element name="DISelectionViaXPath" minOccurs="0"/>
<xsd:element name="DISelectionViaMetadataElements" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="nameSpace"/>
<xsd:attribute name="itemType"/>
<xsd:attribute name="itemName"/>
<xsd:attribute name="internalOperator"/>
<xsd:attribute name="itemValue"/>
<xsd:attribute name="externalOperator"/>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="DIMetadataElement" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="nameSpace"/>
<xsd:attribute name="tagName"/>
</xsd:complexType>
</xsd:element>
<!-- Selection of the DI from which the metadata will be reported -->
<!-- Selection of the metadata to be reported -->
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ERFormatSpecification">
<xsd:complexType>
<xsd:choice>
<xsd:element name="Ref" type="xsd:anyURI"/>
<xsd:element name="XMLschema" type="xsd:anyURI"/>
<xsd:element name="MimeType" type="xsd:string"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="ERDeliverySpecification" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Recipient" minOccurs="0" maxOccurs="unbounded" type="erl:RecipientType"/>
<xsd:element name="DeliveryTime" type="erl:TimeType"/>
<xsd:element name="DITransportService">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="r:serviceReference"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element ref="erl:EmbeddedERR" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- ############################################ -->
<!-- 7.4 Definition of Event Condition Descriptor -->
<!-- ############################################ -->
<xsd:element name="EventConditionDescriptor">
<xsd:complexType>
<xsd:group ref="erl:EventConditionGroup" maxOccurs="unbounded"/>
</xsd:complexType>
</xsd:element>
<xsd:group name="EventConditionGroup">
<xsd:sequence>
<xsd:element name="Operator" type="erl:ExternalOperator" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="TimeCondition" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:group ref="erl:TimeConditionGroup" maxOccurs="unbounded"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Operator" type="erl:ExternalOperator" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="DIOperationCondition" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:group ref="erl:DIOperationConditionGroup" maxOccurs="unbounded"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Operator" type="erl:ExternalOperator" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="PeerCondition" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:group ref="erl:PeerConditionGroup" maxOccurs="unbounded"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Operator" type="erl:ExternalOperator" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="TimeConditionGroup">
<xsd:sequence>
<xsd:element name="TimeEvent" type="erl:TimeType" />
<xsd:element name="Operator" type="erl:ExternalOperator" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="DIOperationConditionGroup">
<xsd:sequence>
<xsd:element name="DIOperationEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="erl:UserId" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="erl:PeerId" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="Operation" type="xsd:anyURI"/>
<xsd:element name="DII" type="xsd:anyURI" maxOccurs="unbounded"/>
<xsd:element name="RelatedDII" type="xsd:anyURI" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Operator" type="erl:ExternalOperator" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:group>
<xsd:group name="PeerConditionGroup">
<xsd:sequence>
<xsd:element name="PeerEvent">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attributeGroup ref="erl:InternalOperator"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Operator" type="erl:ExternalOperator" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:group>
<!-- ############################################ -->
<!-- 8.1 Definition of ER -->
<!-- ############################################ -->
<xsd:element name="ER">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="erl:ERDescriptor"/>
<xsd:element ref="erl:ERData"/>
<xsd:element ref="erl:EmbeddedERR" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- ########################################## -->
<!-- 8.2 Definition of Event Report Descriptor -->
<!-- ########################################## -->
<xsd:element name="ERDescriptor">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Description" type="erl:DescriptionType" minOccurs="0"/>
<xsd:element name="Recipient" type="erl:RecipientType"/>
<xsd:element name="Status">
<xsd:complexType>
<xsd:attribute name="value" type="xsd:boolean" default="false"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="Modification" type="erl:ModificationType" maxOccurs="unbounded"/>
<xsd:element name="ERSource">
<xsd:complexType>
<xsd:choice>
<xsd:element ref="erl:ERR" minOccurs="0"/>
<xsd:element name="ERRReference" type="xsd:anyURI" minOccurs="0"/>
<xsd:element name="OtherSource" type="xsd:anyURI" minOccurs="0"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- ############################################ -->
<!-- 8.3 Definition of ERData -->
<!-- ############################################ -->
<xsd:element name="ERData">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="erl:PeerId" minOccurs="0"/>
<xsd:element ref="erl:UserId" minOccurs="0"/>
<xsd:element name="Time" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="Location" type="mpeg7:PlaceType" minOccurs="0"/>
<xsd:element name="DII" type="xsd:anyURI" minOccurs="0"/>
<xsd:element name="RelatedDII" type="xsd:anyURI" minOccurs="0"/>
<xsd:element name="DIOperation" type="xsd:anyURI" minOccurs="0"/>
<xsd:element name="ReportedDomainData" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReportedDIMetadata" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="##any" processContents="lax" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<!-- ############################################### -->
<!-- 8.4 Definition of Embedded Event Report Request -->
<!-- ############################################### -->
<xsd:element name="EmbeddedERR">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="erl:ERR"/>
<xsd:element name="ERRReference" type="xsd:anyURI"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<!-- ############################################ -->
<!-- 9.1 Definition of Time types -->
<!-- ############################################ -->
<xsd:complexType name="TimeType">
<xsd:choice minOccurs="0">
<xsd:element name="SpecificTime" type="erl:SpecificTime"/>
<xsd:element name="ElapsedTime" type="erl:ElapsedTime"/>
<xsd:element name="PeriodicTime" type="erl:PeriodicTime"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="SpecificTime">
<xsd:choice>
<xsd:element name="OnTime" type="xsd:dateTime"/>
<xsd:sequence>
<xsd:element name="AfterOn" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="BeforeOn" type="xsd:dateTime" minOccurs="0"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="ElapsedTime">
<xsd:sequence>
<xsd:element name="StartElapse" type="erl:StartElapse" minOccurs="0"/>
<xsd:element name="EndElapse" type="erl:EndElapse" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="StartElapse">
<xsd:choice>
<xsd:element name="sTime" type="xsd:time"/>
<xsd:element name="sDuration" type="xsd:duration"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="EndElapse">
<xsd:choice>
<xsd:element name="eTime" type="xsd:time"/>
<xsd:element name="eDuration" type="xsd:duration"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="PeriodicTime">
<xsd:sequence>
<xsd:element name="Start" type="xsd:dateTime"/>
<xsd:element name="DayofWeek" type="erl:DayofWeekType" minOccurs="0"/>
<xsd:element name="Period" type="xsd:duration"/>
<xsd:element name="Duration" type="xsd:duration"/>
<xsd:element name="End" type="xsd:dateTime"/>
</xsd:sequence>
</xsd:complexType>
<!-- Definition of DayofWeekType datatype -->
<xsd:simpleType name="DayofWeekType">
<xsd:restriction base="xsd:string">
<xsd:pattern value="\-?[1-5]{1}W[1-7]{1}D"/>
</xsd:restriction>
</xsd:simpleType>
<!-- ############################################ -->
<!-- 9.2 Definition of PeerId -->
<!-- ############################################ -->
<xsd:element name="PeerId" type="xsd:anyURI"/>
<!-- ############################################ -->
<!-- 9.3 Definition of UserId -->
<!-- ############################################ -->
<xsd:element name="UserId" type="xsd:anyURI"/>
<!-- ############################################ -->
<!-- 9.4 Definition of External operator -->
<!-- ############################################ -->
<xsd:complexType name="ExternalOperator">
<xsd:attribute name="name" type="erl:ExternalOprType"/>
</xsd:complexType>
<xsd:simpleType name="ExternalOprType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="AND"/>
<xsd:enumeration value="OR"/>
<xsd:enumeration value="XOR"/>
<xsd:enumeration value="NOT"/>
<xsd:enumeration value="("/>
<xsd:enumeration value=")"/>
</xsd:restriction>
</xsd:simpleType>
<!-- ############################################ -->
<!-- 9.5 Definition of Internal operator -->
<!-- ############################################ -->
<xsd:attributeGroup name="InternalOperator">
<xsd:attribute name="name" type="erl:InternalOprType"/>
<xsd:attribute name="location" type="erl:InternalOprLocationType"/>
</xsd:attributeGroup>
<xsd:simpleType name="InternalOprType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value=">"/>
<xsd:enumeration value="<"/>
<xsd:enumeration value=">="/>
<xsd:enumeration value="<="/>
<xsd:enumeration value="><"/>
<xsd:enumeration value="="/>
<xsd:enumeration value="+"/>
<xsd:enumeration value="-"/>
<xsd:enumeration value="*"/>
<xsd:enumeration value="/"/>
<xsd:enumeration value="%"/>
<xsd:enumeration value="("/>
<xsd:enumeration value=")"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="InternalOprLocationType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="prefix"/>
<xsd:enumeration value="infix"/>
<xsd:enumeration value="postfix"/>
</xsd:restriction>
</xsd:simpleType>
<!-- ############################################ -->
<!-- 9.6 Definition of DescriptionType -->
<!-- ############################################ -->
<xsd:simpleType name="DescriptionType">
<xsd:restriction base="xsd:string"/>
</xsd:simpleType>
<!-- ############################################ -->
<!-- 9.8 Definition of RecipientType -->
<!-- ############################################ -->
<xsd:complexType name="RecipientType">
<xsd:sequence>
<xsd:element ref="erl:PeerId"/>
<xsd:element ref="erl:UserId" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
Figure 282: The erl schema
C.8 The Media Streaming IPMPDIDL schema
The schema characterised by the following URI: urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS is given below.
<?xml version="1.0"?>
<schema targetNamespace="urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ipmpdidl-msaf="urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS"
xmlns:ipmpinfo-msaf="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS"
xmlns:didmodel="urn:mpeg:mpeg21:2002:02-DIDMODEL-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.01">
<import namespace="urn:mpeg:mpeg21:2002:02-DIDMODEL-NS" schemaLocation="http://www.dmpf.org/schemas/didmodel.xsd"/>
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msaf.xsd"/>
<element name="Item" type="ipmpdidl-msaf:ItemType" substitutionGroup="didmodel:Item"/>
<complexType name="ItemType">
<complexContent>
<extension base="didmodel:ItemType">
<sequence>
<group ref="ipmpdidl-msaf:IPMPDIDLChildGroup"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Statement" type="ipmpdidl-msaf:StatementType" substitutionGroup="didmodel:Statement"/>
<complexType name="StatementType" mixed="true">
<complexContent mixed="true">
<extension base="didmodel:StatementType">
<sequence>
<group ref="ipmpdidl-msaf:IPMPDIDLChildGroup"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Resource" type="ipmpdidl-msaf:ResourceType" substitutionGroup="didmodel:Resource"/>
<complexType name="ResourceType" mixed="true">
<complexContent mixed="true">
<extension base="didmodel:ResourceType">
<sequence>
<group ref="ipmpdidl-msaf:IPMPDIDLChildGroup"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- elements from here onward are unique to the IPMP DIDL Representation-->
<group name="IPMPDIDLChildGroup">
<sequence>
<element ref="ipmpdidl-msaf:Identifier" minOccurs="0"/>
<element ref="ipmpdidl-msaf:Info"/>
<element ref="ipmpdidl-msaf:Contents"/>
</sequence>
</group>
<element name="Contents">
<complexType mixed="true">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"/>
</sequence>
<attribute name="ref" type="anyURI"/>
</complexType>
</element>
<element name="Info">
<complexType mixed="true">
<sequence>
<element ref="ipmpinfo-msaf:IPMPInfoDescriptor" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<element name="Identifier">
<complexType mixed="true">
<sequence>
<any namespace="##any" processContents="lax" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="ProtectedAsset" type="ipmpdidl-msaf:ProtectedAssetType"/>
<complexType name="ProtectedAssetType">
<sequence>
<group ref="ipmpdidl-msaf:IPMPDIDLChildGroup"/>
</sequence>
<attribute name="mimeType" type="string" use="required"/>
<attribute name="contentEncoding" type="string"/>
</complexType>
</schema>
Figure 283: The ipmpdidl-msaf schema
C.9 The Media Streaming IPMPINFO schema
The schema characterised by the following URI: urn:mpeg:mpeg21:2004:01-IPMPINFO-NS is given below.
<?xml version="1.0"?>
<schema targetNamespace="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ipmpinfo-msaf="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:ipmpmsg="urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007"
xmlns:mpeg4ipmp="urn:mpeg:mpeg4:IPMPSchema:2002"
xmlns:ipmpinfo-msx="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007"
elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.01">
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<import namespace="urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007" schemaLocation="http://www.dmpf.org/schemas/ipmpmsg.xsd"/>
<import namespace="urn:mpeg:mpeg4:IPMPSchema:2002" schemaLocation="http://www.dmpf.org/schemas/mpeg4ipmp.xsd"/>
<import namespace="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msx.xsd"/>
<!-- elements-->
<element name="IPMPInfoDescriptor" type="ipmpinfo-msaf:IPMPInfoDescriptorType"/>
<complexType name="IPMPInfoDescriptorType">
<sequence>
<element ref="ipmpinfo-msaf:Tool" minOccurs="0" maxOccurs="unbounded"/>
<element ref="ipmpinfo-msaf:RightsDescriptor" minOccurs="0" maxOccurs="unbounded"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="Tool" type="ipmpinfo-msaf:ToolType"/>
<complexType name="ToolType">
<sequence>
<choice>
<element ref="ipmpinfo-msaf:ToolBaseDescription"/>
<element ref="ipmpinfo-msaf:ToolRef"/>
</choice>
<element ref="ipmpinfo-msaf:InitializationSettings" minOccurs="0"/>
<element ref="ipmpinfo-msaf:RightsDescriptor" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="order" type="positiveInteger"/>
</complexType>
<element name="ToolBaseDescription" type="ipmpinfo-msaf:ToolBaseDescriptionType"/>
<complexType name="ToolBaseDescriptionType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID"/>
<choice minOccurs="0">
<element ref="ipmpinfo-msaf:Inline"/>
<element ref="ipmpinfo-msaf:Remote"/>
</choice>
<element ref="ipmpinfo-msaf:ConfigurationSettings" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="ToolRef" type="ipmpinfo-msaf:ToolRef"/>
<complexType name="ToolRef">
<attribute name="localidref" type="IDREF" use="required"/>
</complexType>
<element name="IPMPToolID" type="anyURI"/>
<element name="Inline" type="ipmpinfo-msaf:InlineType"/>
<complexType name="InlineType">
<sequence>
<element ref="ipmpinfo-msaf:Binary"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="Binary" type="base64Binary"/>
<element name="Remote" type="ipmpinfo-msaf:RemoteType"/>
<complexType name="RemoteType">
<sequence>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="ref" type="anyURI"/>
</complexType>
<element name="ConfigurationSettings" type="ipmpinfo-msaf:ConfigurationSettingsType"/>
<complexType name="ConfigurationSettingsType" mixed="true">
<sequence>
<element ref="ipmpinfo-msaf:Configuration"/>
<element ref="ipmpinfo-msaf:Update" minOccurs="0"/>
</sequence>
</complexType>
<element name="Configuration" type="ipmpinfo-msaf:ConfigurationType"/>
<complexType name="ConfigurationType" mixed="true">
<sequence>
<element ref="ipmpinfo-msx:ToolBody"/>
</sequence>
</complexType>
<element name="Update" type="ipmpinfo-msaf:UpdateType"/>
<complexType name="UpdateType">
<sequence>
<element ref="ipmpinfo-msaf:Location" maxOccurs="unbounded"/>
<element ref="ipmpinfo-msaf:ScheduledUpdateTime" minOccurs="0"/>
<element ref="ipmpinfo-msaf:SupportedPlatform" minOccurs="0" maxOccurs="unbounded"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="Location" type="ipmpinfo-msaf:RemoteType"/>
<element name="Condition" type="ipmpinfo-msaf:ConditionType"/>
<complexType name="ConditionType">
<sequence>
<element ref="ipmpinfo-msaf:ScheduledUpdateTime" minOccurs="0"/>
<element ref="ipmpinfo-msaf:SupportedPlatform" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="ScheduledUpdateTime" type="ipmpinfo-msaf:ScheduledUpdateTimeType"/>
<complexType name="ScheduledUpdateTimeType">
<simpleContent>
<extension base="dateTime">
<attribute name="periodic" type="duration" use="optional"/>
</extension>
</simpleContent>
</complexType>
<element name="SupportedPlatform" type="ipmpinfo-msaf:SupportedPlatformType"/>
<complexType name="SupportedPlatformType">
<sequence>
<element ref="ipmpinfo-msx:DeviceInformation"/>
</sequence>
</complexType>
<element name="InitializationSettings" type="ipmpinfo-msaf:InitializationSettingsType"/>
<complexType name="InitializationSettingsType" mixed="true">
<sequence>
<element ref="ipmpinfo-msaf:InitializationData"/>
</sequence>
</complexType>
<element name="InitializationData" type="ipmpinfo-msaf:InitializationDataType"/>
<complexType name="InitializationDataType" mixed="true">
<sequence>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="ipmpmsg:ControlPointID" minOccurs="0"/>
<element ref="ipmpmsg:ControlPointAddress" minOccurs="0"/>
</sequence>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="RightsDescriptor" type="ipmpinfo-msaf:RightsDescriptorType"/>
<complexType name="RightsDescriptorType">
<sequence>
<choice minOccurs="0">
<element ref="ipmpinfo-msaf:License"/>
<element ref="ipmpinfo-msaf:LicenseReference"/>
</choice>
</sequence>
</complexType>
<element name="License" type="ipmpinfo-msaf:LicenseType"/>
<complexType name="LicenseType" mixed="true">
<sequence>
<element ref="r-msaf:license" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="LicenseReference" type="ipmpinfo-msaf:LicenseReferenceType"/>
<complexType name="LicenseReferenceType">
<simpleContent>
<extension base="anyURI"/>
</simpleContent>
</complexType>
<!--********************************* -->
<!-- IPMPGeneralInfoDescriptor -->
<!--********************************* -->
<element name="IPMPGeneralInfoDescriptor" type="ipmpinfo-msaf:IPMPGeneralInfoDescriptorType"/>
<complexType name="IPMPGeneralInfoDescriptorType">
<sequence>
<element ref="ipmpinfo-msaf:ToolList" minOccurs="0"/>
<element ref="ipmpinfo-msaf:LicenseCollection" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
<!--Signature for the IPMPGeneralInfoDescriptor element and children -->
</sequence>
</complexType>
<element name="ToolList" type="ipmpinfo-msaf:ToolListType"/>
<complexType name="ToolListType">
<sequence>
<element ref="ipmpinfo-msaf:ToolDescription" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="ToolDescription" type="ipmpinfo-msaf:ToolDescriptionType"/>
<complexType name="ToolDescriptionType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID"/>
<element ref="ipmpinfo-msaf:MemberOf" minOccurs="0"/>
<choice minOccurs="0">
<element ref="ipmpinfo-msaf:Inline"/>
<element ref="ipmpinfo-msaf:Remote"/>
</choice>
<element ref="ipmpinfo-msaf:RightsDescriptor" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
<attribute name="localID" type="ID" use="required"/>
</complexType>
<element name="MemberOf" type="ipmpinfo-msaf:MemberOfType"/>
<complexType name="MemberOfType">
<sequence maxOccurs="unbounded">
<element ref="ipmpinfo-msaf:AlternateGroup"/>
</sequence>
</complexType>
<element name="AlternateGroup" type="ipmpinfo-msaf:AlternateGroupType"/>
<complexType name="AlternateGroupType">
<attribute name="groupID" type="positiveInteger" use="required"/>
</complexType>
<element name="LicenseCollection" type="ipmpinfo-msaf:LicenseCollectionType"/>
<complexType name="LicenseCollectionType" mixed="true">
<sequence>
<element ref="ipmpinfo-msaf:RightsDescriptor" maxOccurs="unbounded"/>
</sequence>
</complexType>
</schema>
Figure 284: The ipmpinfo-msaf schema
C.10 The Media Streaming IPMPINFO extensions schema
The schema characterised by the following URI: urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007 is given below.
<?xml version="1.0"?>
<schema targetNamespace="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ipmpinfo-msx="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:rmsaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:ipmpinfo-msaf="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS"
xmlns:mpeg4ipmp="urn:mpeg:mpeg4:IPMPSchema:2002"
elementFormDefault="qualified" attributeFormDefault="unqualified" version="0.01">
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg4:IPMPSchema:2002" schemaLocation="http://www.dmpf.org/schemas/mpeg4ipmp.xsd"/>
<!-- elements-->
<!--********************************* -->
<!-- ToolBody -->
<!--********************************* -->
<element name="ToolBody" type="ipmpinfo-msx:ToolBodyType"/>
<complexType name="ToolBodyType">
<sequence>
<choice maxOccurs="unbounded">
<element ref="ipmpinfo-msx:SingleTool"/>
<element ref="ipmpinfo-msx:ToolPack"/>
</choice>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="ToolPack" type="ipmpinfo-msx:ToolPackType"/>
<complexType name="ToolPackType">
<sequence>
<element ref="ipmpinfo-msx:ToolBodyID"/>
<element ref="ipmpinfo-msx:DeviceInformation" minOccurs="0"/>
<element name="ToolPackageType" type="string" minOccurs="0"/>
<element name="ToolAgent" type="ipmpinfo-msx:ToolAgentType"/>
<element name="ToolGroup" type="ipmpinfo-msx:ToolGroupType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="ToolAgent" type="ipmpinfo-msx:ToolAgentType"/>
<complexType name="ToolAgentType">
<sequence>
<element name="ToolAgentID" type="anyURI"/>
<element name="ToolAgentCode" type="base64Binary"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="ToolGroup" type="ipmpinfo-msx:ToolGroupType"/>
<complexType name="ToolGroupType">
<sequence>
<element name="ToolGroupID" type="anyURI"/>
<element name="ToolGroupCode" type="base64Binary"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<element name="SingleTool" type="ipmpinfo-msx:DRMToolType"/>
<complexType name="DRMToolType">
<sequence>
<element ref="ipmpinfo-msx:ToolBodyID"/>
<element ref="ipmpinfo-msx:DeviceInformation" minOccurs="0"/>
<element name="ToolPackageType" type="string" minOccurs="0"/>
<element name="ToolCode" type="base64Binary"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="ToolUpdateType"/>
<element name="ToolBodyID" type="anyURI"/>
<!--********************************* -->
<!-- DeviceInformation -->
<!--********************************* -->
<element name="DeviceInformation" type="ipmpinfo-msx:DeviceType"/>
<complexType name="DeviceType">
<complexContent>
<extension base="mpeg4ipmp:TerminalIDType">
<sequence>
<element ref="ipmpinfo-msx:ToolAPI_Config" minOccurs="0" maxOccurs="unbounded"/>
<element ref="ipmpinfo-msx:Others" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Others" type="ipmpinfo-msx:OtherTypes"/>
<complexType name="OtherTypes">
<sequence>
<any namespace="##any" processContents="lax"/>
</sequence>
<attribute name="ref" type="anyURI" use="required"/>
</complexType>
<element name="ToolAPI_Config" type="ipmpinfo-msx:ToolAPI_ConfigType"/>
<complexType name="ToolAPI_ConfigType">
<sequence>
<element name="Instantiation_API_ID" type="anyURI" minOccurs="0"/>
<element name="Messaging_API_ID" type="anyURI" minOccurs="0"/>
<element name="OpaqueData" type="hexBinary" minOccurs="0"/>
</sequence>
</complexType>
</schema>
Figure 285: The ipmpinfo-msx schema
C.11 The IPMP XML Messages schema
The schema characterised by the following URI: urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ipmpmsg="urn:mpeg:mpegB:schema:IPMP-XML-MESSAGES:2007"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:ipmpinfo-msaf="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS"
xmlns:r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:dii-msaf="urn:mpeg:mpeg21:2002:01-DII-NS"
xmlns:ipmpdidl-msaf="urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPDIDL-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpdidl-msaf.xsd"/>
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="rel-r-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg21:2002:01-DII-NS" schemaLocation="dii-msaf.xsd"/>
<!-- Abstract Base Type from which both DRM Message Containers and DRM Messages inherit -->
<complexType name="IPMPBaseType" abstract="true"/>
<!--ToolMessageBase-->
<element name="ToolMessageBase" type="ipmpmsg:ToolMessageBaseType" abstract="true"/>
<complexType name="ToolMessageBaseType" abstract="true">
<complexContent>
<extension base="ipmpmsg:IPMPBaseType">
<sequence>
<element name="Sender" type="anyURI"/>
<element name="Recipient" type="anyURI"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--Data_BaseClass-->
<element name="Data_BaseClass" type="ipmpmsg:Data_BaseClassType" abstract="true"/>
<complexType name="Data_BaseClassType" abstract="true">
<complexContent>
<extension base="ipmpmsg:IPMPBaseType">
<sequence>
<element name="dataID" type="unsignedInt"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- **************************************************************** -->
<!-- DRM Message Containers -->
<!-- **************************************************************** -->
<!-- MessageFromDI-->
<element name="MessageFromDI" type="ipmpmsg:MessageFromDIType" substitutionGroup="ipmpmsg:ToolMessageBase"/>
<complexType name="MessageFromDIType">
<complexContent>
<extension base="ipmpmsg:ToolMessageBaseType">
<sequence>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--MessageFromTool-->
<element name="MessageFromTool" type="ipmpmsg:MessageFromToolType" substitutionGroup="ipmpmsg:ToolMessageBase"/>
<complexType name="MessageFromToolType">
<complexContent>
<extension base="ipmpmsg:ToolMessageBaseType">
<sequence>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- **************************************************************** -->
<!-- DRM Messages -->
<!-- **************************************************************** -->
<!-- AUTHENTICATION MESSAGES -->
<!--InitAuthentication-->
<element name="InitAuthentication" type="ipmpmsg:InitAuthenticationType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="InitAuthenticationType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="ContextID" type="anyURI" minOccurs="0"/>
<element name="AuthType" type="ipmpmsg:AUTType"/>
<!--Context ID of the logical instance of the Tool with which mutual authentication is to be performed-->
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="AUTType">
<annotation>
<documentation>
"01" - No Authentication Required
"02" - No ID verify, Do secure channel
"03" - Do ID verify, No secure channel
"04" - Do ID verify, Do secure channel
</documentation>
</annotation>
<restriction base="integer">
<enumeration value="01"/>
<enumeration value="02"/>
<enumeration value="03"/>
<enumeration value="04"/>
</restriction>
</simpleType>
<!--MutualAuthentication-->
<element name="MutualAuthentication" type="ipmpmsg:MutualAuthenticationType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="MutualAuthenticationType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<choice minOccurs="0">
<element name="requestNegotiation" type="ipmpmsg:requestNegotiationType"/>
<element name="successNegotiation" type="ipmpmsg:successNegotiationType"/>
<element name="failedNegotiation" type="boolean" fixed="true"/>
</choice>
<element name="authenticationData" type="hexBinary" minOccurs="0"/>
<element name="authCodes" type="ipmpmsg:AuthCodesType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="requestNegotiationType">
<sequence>
<element name="candidateAlgorithms" type="ipmpmsg:AlgorithmDescriptorType"/>
</sequence>
</complexType>
<complexType name="AlgorithmDescriptorType">
<sequence>
<element name="algoID" type="anyURI" maxOccurs="unbounded"/>
<element name="opaqueData" type="base64Binary" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="successNegotiationType">
<sequence>
<element name="agreedAlgorithms" type="ipmpmsg:AlgorithmDescriptorType" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="AuthCodesType">
<sequence>
<element name="certificates" type="dsig:KeyInfoType" maxOccurs="unbounded"/>
<element name="trustData" type="hexBinary" minOccurs="0"/>
</sequence>
</complexType>
<!--SecureContainer-->
<element name="SecureContainer" type="ipmpmsg:SecureContainerType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<annotation>
<documentation>
To fill the protectedMsgTag field below, use values from
Table 1 in doc ISO/IEC 14496-13:2004
</documentation>
</annotation>
<complexType name="SecureContainerType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<choice>
<sequence>
<element name="encryptedData" type="hexBinary"/>
<element name="MAC" type="hexBinary" minOccurs="0"/>
</sequence>
<sequence>
<element name="protectedMsgTag" type="short"/>
<element name="protectedMsg" type="hexBinary"/>
<element name="MAC" type="hexBinary" minOccurs="0"/>
</sequence>
</choice>
</extension>
</complexContent>
</complexType>
<!-- DRM TOOL CONNECTION AND DISCONNECTION MESSAGES -->
<!--GetTools-->
<element name="GetTools" type="ipmpmsg:GetToolsType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolsType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
<!--GetToolsResponse-->
<element name="GetToolsResponse" type="ipmpmsg:GetToolsResponseType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolsResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpmsg:Tool" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Tool" type="ipmpmsg:toolType"/>
<!--It represents a DRM Tool, an extension of ipmpinfo:Tool-->
<complexType name="toolType">
<complexContent>
<extension base="ipmpinfo-msaf:ToolType">
<sequence>
<element name="alternates" type="ipmpinfo-msaf:ToolType" minOccurs="0"/>
<element ref="ipmpmsg:ParametricDescription" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--GetToolContext-->
<element name="GetToolContext" type="ipmpmsg:GetToolContextType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolContextType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
<!--GetToolContextResponse-->
<element name="GetToolContextResponse" type="ipmpmsg:GetToolContextResponseType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolContextResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="ToolContextID" type="unsignedInt" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--ConnectTool-->
<element name="ConnectTool" type="ipmpmsg:ConnectToolType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="ConnectToolType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpinfo-msaf:Tool"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--DisconnectTool-->
<element name="DisconnectTool" type="ipmpmsg:DisconnectToolType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="DisconnectToolType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="ToolContextID" type="unsignedInt"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--ParamtericDescription-->
<element name="ParametricDescription" type="ipmpmsg:ParametricDescriptionType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="ParametricDescriptionType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="descriptionComment" type="string" minOccurs="0"/>
<element name="majorVersion" type="byte"/>
<element name="minorVersion" type="byte"/>
<element name="paramToolDescription" type="ipmpmsg:paramToolDescriptionType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="paramToolDescriptionType">
<sequence>
<element name="class" type="string"/>
<element name="subClass" type="string"/>
<element name="typeData" type="string" minOccurs="0"/>
<element name="type" type="string" minOccurs="0"/>
<element name="addedData" type="string" minOccurs="0"/>
</sequence>
</complexType>
<!--ToolParamCapabilitiesQuery-->
<element name="ToolParamCapabilitiesQuery" type="ipmpmsg:ToolParamCapabilitiesQueryType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="ToolParamCapabilitiesQueryType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="toolParamDesc" type="ipmpmsg:ParametricDescriptionType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--ToolParamCapabilitiesResponse-->
<element name="ToolParamCapabilitiesResponse" type="ipmpmsg:ToolParamCapabilitiesResponseType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="ToolParamCapabilitiesResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="capabilitiesSupported" type="boolean"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- DRM TOOL NOTIFICATION -->
<!--NotifyToolEvent-->
<element name="NotifyToolEvent" type="ipmpmsg:NotifyToolEventType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="NotifyToolEventType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<sequence minOccurs="0">
<element name="OD_ID" type="unsignedInt"/>
<element name="ESD_ID" type="unsignedInt"/>
</sequence>
<element ref="ipmpmsg:EventType" maxOccurs="unbounded"/>
<element name="toolContextID" type="unsignedInt"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="EventType" type="ipmpmsg:EvType"/>
<simpleType name="EvType">
<annotation>
<documentation>
"00" – CONNECTED
"01" - CONNECTION_FAILED
"02" - DISCONNECTED
"03" - DISCONNECTION_FAILED
"04" - WATERMARKDETECTED
"05" - PARSE_TOOLPACKDATA_SUCCESS
"06" - PARSE_TOOLPACKDATA_FAILED
"07" - UNABLE_TO_PROCESS
"08" - TOOL_GROUP_NOT_FOUND
"09" - TERMINATION_FAILED
"10" - CONTROLPOINT_NOT_SUPPORTED
"11" - UNABLE_TO_PARSE_LICENSE
"12" - NO_VALID_LICENSE
"13" - LICENSE_VALIDATION_FAILED
"14" - READY_TO_PLAY
"15" - READY_TO_BE_TERMINATED
</documentation>
</annotation>
<restriction base="integer">
<enumeration value="00"/>
<enumeration value="01"/>
<enumeration value="02"/>
<enumeration value="03"/>
<enumeration value="04"/>
<enumeration value="05"/>
<enumeration value="06"/>
<enumeration value="07"/>
<enumeration value="08"/>
<enumeration value="09"/>
<enumeration value="10"/>
<enumeration value="11"/>
<enumeration value="12"/>
<enumeration value="13"/>
<enumeration value="14"/>
<enumeration value="15"/>
</restriction>
</simpleType>
<!--AddToolNotificationListener-->
<element name="AddToolNotificationListener" type="ipmpmsg:AddToolNotificationListenerType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="AddToolNotificationListenerType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="scope" type="string"/>
<element ref="ipmpmsg:EventType" maxOccurs="unbounded"/>
<!--see scope list in MPEG IPMPX spec-->
</sequence>
</extension>
</complexContent>
</complexType>
<!--RemoveToolNotificationListener-->
<element name="RemoveToolNotificationListener" type="ipmpmsg:RemoveToolNotificationListenerType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="RemoveToolNotificationListenerType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpmsg:EventType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- DRM PROCESSING -->
<!--KeyData-->
<element name="KeyData" type="ipmpmsg:KeyDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="KeyDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<choice maxOccurs="unbounded">
<element ref="ipmpmsg:Key"/>
<element ref="ipmpmsg:TimeKey"/>
</choice>
<element name="opaqueData" type="base64Binary" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="KeyBaseType" abstract="true"/>
<element name="Key" type="ipmpmsg:KeyType"/>
<complexType name="KeyType">
<complexContent>
<extension base="ipmpmsg:KeyBaseType">
<sequence>
<choice>
<element ref="xenc:EncryptedData"/>
<element ref="xenc:EncryptedKey"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="TimeKey" type="ipmpmsg:TimeKeyType"/>
<complexType name="TimeKeyType">
<complexContent>
<extension base="ipmpmsg:KeyType">
<sequence>
<element name="startDTS" type="unsignedLong" minOccurs="0"/>
<element name="startPacketID" type="unsignedInt" minOccurs="0"/>
<element name="expireDTS" type="unsignedLong" minOccurs="0"/>
<element name="expirePacketID" type="unsignedInt" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--RightsData-->
<element name="RightsData" type="ipmpmsg:RightsDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="RightsDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="rightsInfo" type="r-msaf:License"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--CanProcess-->
<element name="CanProcess" type="ipmpmsg:CanProcessType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="CanProcessType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="canProcess" type="boolean"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--OpaqueData-->
<element name="OpaqueData" type="ipmpmsg:OpaqueDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="OpaqueDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="opaqueData" type="base64Binary"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--AudioWatermarkingInit-->
<element name="AudioWatermarkingInit" type="ipmpmsg:AudioWatermarkingInitType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="AudioWatermarkingInitType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="inputFormat" type="ipmpmsg:AudioFormatType"/>
<element name="requiredOp" type="ipmpmsg:requiredOpType"/>
<element name="wmPayload" type="string" minOccurs="0"/>
<element name="wmRecipientID" type="anyURI" minOccurs="0"/>
<element name="opaqueData" type="base64Binary" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="AudioFormatType">
<sequence minOccurs="0">
<element name="nChannels" type="byte"/>
<element name="bitPerSample" type="byte"/>
<element name="frequency" type="decimal"/>
</sequence>
<attribute name="mimeType" type="string" use="required"/>
</complexType>
<simpleType name="requiredOpType">
<annotation>
<documentation>
"00" - INSERT_WM "01" - EXTRACT_WM "02" - REMARK_WM "03"
- DETECT_COMPRESSION
</documentation>
</annotation>
<restriction base="integer">
<enumeration value="00"/>
<enumeration value="01"/>
<enumeration value="02"/>
<enumeration value="03"/>
</restriction>
<!--see type list in MPEG IPMPX spec-->
</simpleType>
<!--VideoWatermarkingInit-->
<element name="VideoWatermarkingInit" type="ipmpmsg:VideoWatermarkingInitType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="VideoWatermarkingInitType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="inputFormat" type="ipmpmsg:VideoFormatType"/>
<element name="requiredOp" type="ipmpmsg:requiredOpType"/>
<element name="wmPayload" type="string" minOccurs="0"/>
<element name="wmRecipientID" type="anyURI" minOccurs="0"/>
<element name="opaqueData" type="base64Binary" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="VideoFormatType">
<sequence minOccurs="0">
<element name="frame_horizontal_size" type="unsignedShort"/>
<element name="frame_vertical_size" type="unsignedShort"/>
<element name="chroma_format" type="byte"/>
</sequence>
<attribute name="mimeType" type="string" use="required"/>
</complexType>
<!--SendAudioWatermark-->
<element name="SendAudioWatermark" type="ipmpmsg:SendAudioWatermarkType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="SendAudioWatermarkType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="wm_status" type="ipmpmsg:wm_statusType"/>
<element name="compression_status" type="ipmpmsg:compression_statusType"/>
<element name="payload" type="string" minOccurs="0"/>
<element name="opaqueData" type="base64Binary" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="wm_statusType">
<annotation>
<documentation>
"00" - WM_PAYLOAD "01" - WM_NOPAYLOAD "02" - NO_WM "03"
- WM_UNKNOWN
</documentation>
</annotation>
<restriction base="integer">
<enumeration value="00"/>
<enumeration value="01"/>
<enumeration value="02"/>
<enumeration value="03"/>
</restriction>
</simpleType>
<simpleType name="compression_statusType">
<annotation>
<documentation>
"00" - COMPRESSION "01" - NO_COMPRESSION "02" -
COMP_UNKNOWN
</documentation>
</annotation>
<restriction base="integer">
<enumeration value="00"/>
<enumeration value="01"/>
<enumeration value="02"/>
</restriction>
</simpleType>
<!--SendVideoWatermark-->
<element name="SendVideoWatermark" type="ipmpmsg:SendVideoWatermarkType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="SendVideoWatermarkType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="wm_status" type="ipmpmsg:wm_statusType"/>
<element name="compression_status" type="ipmpmsg:compression_statusType"/>
<element name="payload" type="string" minOccurs="0"/>
<element name="opaqueData" type="base64Binary" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--SelectiveDecryptionInit-->
<element name="SelectiveDecryptionInit" type="ipmpmsg:SelectiveDecryptionInitType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="SelectiveDecryptionInitType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="mimeType" type="string"/>
<element name="profileLevelIndication" type="string"/>
<element name="compliance" type="string"/>
<element name="bufInfoStruct" type="ipmpmsg:bufInfoStructType" minOccurs="0" maxOccurs="unbounded"/>
<choice>
<element name="contentSpecific" type="ipmpmsg:contentSpecificType" minOccurs="0"/>
<sequence>
<element name="nSegments" type="short"/>
<element name="RLE_Data" type="short" maxOccurs="unbounded"/>
</sequence>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="bufInfoStructType">
<sequence>
<element name="cipher_Id" type="anyURI"/>
<element name="syncBoundary" type="string"/>
<choice>
<sequence>
<element name="mode" type="anyURI" minOccurs="0"/>
<element name="blockSize" type="short"/>
<element name="keySize" type="short"/>
</sequence>
<element name="Stream_Cipher_Specific_Init_Info" type="hexBinary"/>
</choice>
</sequence>
</complexType>
<complexType name="contentSpecificType">
<sequence>
<element name="numFields" type="short"/>
<element name="fieldStruct" type="ipmpmsg:fieldStructType" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="fieldStructType">
<sequence>
<element name="field_id" type="anyURI"/>
<element name="fieldScope" type="short"/>
<element name="buf" type="short"/>
<element name="map" type="ipmpmsg:mapType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="mapType">
<sequence>
<element name="sizeMapTable" type="short" minOccurs="0"/>
<element name="mappingTable" type="short" minOccurs="0" maxOccurs="unbounded"/>
<element name="shuffleSpecificInfo" type="hexBinary" minOccurs="0"/>
</sequence>
</complexType>
<!-- USER INTERACTION MESSAGES -->
<!--UserQuery-->
<element name="UserQuery" type="ipmpmsg:UserQueryType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="UserQueryType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="altText" type="ipmpmsg:altTextType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="altTextType">
<sequence>
<element name="languageCode" type="language"/>
<element name="titleText" type="string" minOccurs="0"/>
<element name="displayText" type="ipmpmsg:displayTextType" minOccurs="0" maxOccurs="unbounded"/>
<element name="needReplyText" type="ipmpmsg:replyTextType" minOccurs="0" maxOccurs="unbounded"/>
<element name="inclOptionSelect" type="ipmpmsg:inclOptionSelectType" minOccurs="0" maxOccurs="unbounded"/>
<element name="SMIL_URL" type="string" minOccurs="0" maxOccurs="unbounded"/>
<element name="SMIL" type="hexBinary" minOccurs="0"/>
<!-- ISO 639-2:1998 bibliographic three character language code-->
</sequence>
</complexType>
<complexType name="displayTextType">
<sequence>
<element name="text" type="string"/>
</sequence>
<attribute name="ID" type="unsignedShort" use="required"/>
</complexType>
<complexType name="replyTextType">
<sequence>
<element name="text" type="string"/>
</sequence>
<attribute name="ID" type="unsignedShort" use="required"/>
<attribute name="subID" type="unsignedShort" use="required"/>
<attribute name="isHidden" type="boolean"/>
</complexType>
<complexType name="inclOptionSelectType">
<sequence>
<element name="promptText" type="string"/>
</sequence>
<attribute name="ID" type="unsignedShort" use="required"/>
<attribute name="subID" type="unsignedShort" use="required"/>
<attribute name="isExclusive" type="boolean"/>
</complexType>
<!--UserQueryResponse-->
<element name="UserQueryResponse" type="ipmpmsg:UserQueryResponseType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="UserQueryResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="replyText" type="ipmpmsg:responseReplyTextType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="responseReplyTextType">
<sequence>
<element name="languageCode" type="language"/>
<element name="replyText" type="ipmpmsg:replyTextType" minOccurs="0" maxOccurs="unbounded"/>
<element name="optionResult" type="ipmpmsg:optionResultType" minOccurs="0" maxOccurs="unbounded"/>
<!-- ISO 639-2:1998 bibliographic three character language code-->
</sequence>
</complexType>
<complexType name="optionResultType">
<sequence>
<element name="result" type="boolean"/>
</sequence>
<attribute name="ID" type="unsignedShort" use="optional"/>
<attribute name="subID" type="unsignedShort" use="optional"/>
</complexType>
<!-- SPECIFIC IPMP MESSAGES FOR THE MEDIA STREAMING PLAYER MAF -->
<!-- InitialiseTool -->
<element name="InitialiseTool" type="ipmpmsg:InitialiseToolType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="InitialiseToolType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="IPMPProcessorInstance" type="base64Binary"/>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="ipmpmsg:ControlPointID"/>
<element ref="ipmpmsg:ControlPointAddress" minOccurs="0"/>
</sequence>
<element ref="ipmpmsg:SequenceCode" minOccurs="0"/>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="ControlPointID" type="ipmpmsg:ControlPointType"/>
<complexType name="ControlPointType">
<annotation>
<documentation>
The Control Point ID is an identifier given by a
DMP-appointed Registration Authority with the purpose of
indicating a position in the media resource processing
chain, as defined in the DMP Terminology.
The following values are currently permitted :
"00" - NO_CONTROL_POINT
"01" - CONTROL_POINT_BEFORE_DEMULTIPLEXING
"02" - CONTROL_POINT_BEFORE_AUDIO_DECODING
"03" - CONTROL_POINT_AFTER_AUDIO_DECODING
"04" - CONTROL_POINT_BEFORE_VIDEO_DECODING
"05" - CONTROL_POINT_AFTER_VIDEO_DECODING
"06" - CONTROL_POINT_BEFORE_STORING
"07" - CONTROL_POINT_BEFORE_PLAYBACK
"08" - CONTROL_POINT_BEFORE_TRANSFERRING
</documentation>
</annotation>
<sequence>
<element name="ID" type="integer"/>
</sequence>
</complexType>
<element name="SequenceCode" type="short"/>
<element name="ControlPointAddress" type="base64Binary"/>
<!--ToolPack Extensions-->
<!--GetToolGroupReference-->
<element name="GetToolGroupReference" type="ipmpmsg:GetToolGroupReferenceType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolGroupReferenceType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
<!--GetToolGroupReferenceResponse-->
<element name="GetToolGroupReferenceResponse" type="ipmpmsg:GetToolGroupReferenceResponseType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolGroupReferenceResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="ToolGroupReference" type="base64Binary"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--GetToolReference-->
<element name="GetToolReference" type="ipmpmsg:GetToolReferenceType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolReferenceType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpmsg:IPMPToolID" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="IPMPToolID" type="anyURI"/>
<!--GetToolReferenceResponse-->
<element name="GetToolReferenceResponse" type="ipmpmsg:GetToolReferenceResponseType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolReferenceResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<sequence maxOccurs="unbounded">
<element ref="ipmpmsg:IPMPToolID"/>
<element name="ToolReference" type="base64Binary"/>
</sequence>
</sequence>
</extension>
</complexContent>
</complexType>
<!--ToolPackDataRequest-->
<element name="GetToolPackData" type="ipmpmsg:GetToolPackDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetToolPackDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
<!--ToolPackData-->
<element name="ToolPackData" type="ipmpmsg:ToolPackDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="ToolPackDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element name="opaqueData" type="base64Binary"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- ******************************************************************** -->
<!-- Interface Messages Between the Resource Processor and IPMP Processor -->
<!-- ******************************************************************** -->
<element name="InitialiseIPMPProcessor" type="ipmpmsg:InitialiseIPMPProcessorType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="InitialiseIPMPProcessorType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="ipmpmsg:ControlPointID"/>
<element ref="ipmpmsg:ControlPointAddress" minOccurs="0"/>
</sequence>
<element ref="ipmpinfo-msaf:IPMPGeneralInfoDescriptor" minOccurs="0"/>
<element ref="ipmpdidl-msaf:ProtectedAsset" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="GetProtectedAsset" type="ipmpmsg:GetProtectedAssetType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetProtectedAssetType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
<element name="GetProtectedAssetResponse" type="ipmpmsg:GetProtectedAssetResponseType"/>
<complexType name="GetProtectedAssetResponseType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpdidl-msaf:ProtectedAsset" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="GetRightsData" type="ipmpmsg:GetRightsDataType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="GetRightsDataType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="dii-msaf:Identifier" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="NotifyIPMPProcessorEvent" type="ipmpmsg:NotifyIPMPProcessorEventType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="NotifyIPMPProcessorEventType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType">
<sequence>
<element ref="ipmpmsg:EventType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="TerminateIPMPProcessor" type="ipmpmsg:TerminateIPMPProcessorType" substitutionGroup="ipmpmsg:Data_BaseClass"/>
<complexType name="TerminateIPMPProcessorType">
<complexContent>
<extension base="ipmpmsg:Data_BaseClassType"/>
</complexContent>
</complexType>
<!-- **************************************************************** -->
<!-- Legacy Messages -->
<!-- **************************************************************** -->
<!-- IPMP_Message -->
<element name="IPMP_Message" type="ipmpmsg:IPMP_MessageType"/>
<complexType name="IPMP_MessageType">
<complexContent>
<extension base="ipmpmsg:IPMPBaseType">
<sequence>
<choice>
<element name="URLString" type="anyURI"/>
<sequence>
<element name="IPMP_DescriptorIDEx" type="anyURI"/>
<element ref="ipmpmsg:Data_BaseClass" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<element name="IPMP_data" type="hexBinary"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<!--MessageFromBitstream-->
<element name="MessageFromBitstream" type="ipmpmsg:MessageFromBitstreamType" substitutionGroup="ipmpmsg:ToolMessageBase"/>
<complexType name="MessageFromBitstreamType">
<complexContent>
<extension base="ipmpmsg:ToolMessageBaseType">
<sequence>
<element ref="ipmpmsg:IPMP_Message" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!--DescriptorFromBitstream-->
<element name="DescriptorFromBitstream" type="ipmpmsg:DescriptorFromBitstreamType" substitutionGroup="ipmpmsg:ToolMessageBase"/>
<complexType name="DescriptorFromBitstreamType">
<complexContent>
<extension base="ipmpmsg:ToolMessageBaseType">
<sequence>
<element name="IPMP_Descriptor" type="hexBinary" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Figure 286: The ipmpmsg schema
The schema characterised by the following URI: urn:mpeg:mpeg4:IPMPSchema:2002 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:mpeg:mpeg4:IPMPSchema:2002"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:mpeg4ipmp="urn:mpeg:mpeg4:IPMPSchema:2002"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<element name="TerminalID" type="mpeg4ipmp:TerminalIDType">
<annotation>
<documentation>Identification of a terminal</documentation>
</annotation>
</element>
<complexType name="TerminalIDType">
<sequence>
<element name="TerminalType" minOccurs="0">
<complexType>
<sequence>
<element name="Vendor" type="string"/>
<element name="Model" type="string"/>
<element name="SerialNO" type="string" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="OperatingSystem" type="mpeg4ipmp:OSType" minOccurs="0"/>
<element name="CPU" type="mpeg4ipmp:CPUType" minOccurs="0"/>
<element name="Memory" type="mpeg4ipmp:MemoryType" minOccurs="0"/>
<element name="AsstHardware" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="SmartCard" minOccurs="0">
<complexType>
<sequence>
<element name="Vendor" type="string"/>
<element name="Model" type="string"/>
</sequence>
</complexType>
</element>
<element name="HardKey" minOccurs="0">
<complexType>
<sequence>
<element name="Type" type="string"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
</element>
<element name="Network" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="Type" type="string"/>
<element name="Details" type="string"/>
</sequence>
</complexType>
</element>
<element name="Downloading" minOccurs="0" maxOccurs="unbounded">
<complexType>
<attribute name="Capability" type="boolean" use="required"/>
</complexType>
</element>
<element name="RPCMechanism" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="Type" type="string"/>
<element name="Details" type="string"/>
</sequence>
</complexType>
</element>
<element name="Firmware" minOccurs="0" maxOccurs="unbounded">
<complexType>
<attribute name="Vendor" type="string" use="required"/>
<attribute name="Name" type="string" use="required"/>
<attribute name="Version" type="string" use="required"/>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="OSType">
<sequence>
<element name="Vendor" type="string"/>
<element name="Model" type="string"/>
<element name="Version" type="string"/>
<element name="SerialNO" type="string" minOccurs="0"/>
<element name="VirtualMachine" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="Vendor" type="string"/>
<element name="Name" type="string"/>
<element name="Version" type="string"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="CPUType">
<sequence>
<element name="Vendor" type="string"/>
<element name="Model" type="string"/>
<element name="Speed" type="integer"/>
</sequence>
</complexType>
<complexType name="MemoryType">
<sequence>
<element name="Vendor" type="string"/>
<element name="Model" type="string"/>
<element name="Size" type="integer"/>
<element name="Speed" type="integer"/>
</sequence>
</complexType>
</schema>
Figure 287: The mpeg4ipmp schema
C.13 The MPEG-7 Simple Metadata Profile schema
The schema characterised by the following URI: xxx is given below.
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- ****************************************************************************
This XML document was originally developed in the course of development of the
ISO/IEC 15938 standard (MPEG-7). This XML document contains either a part of
the MPEG-7 schema implementation for one or more MPEG-7 tools as specified by
the MPEG-7 Requirements or MPEG-7 description examples conformant to the
MPEG-7 schema.
ISO/IEC gives users of MPEG-7 free license to this XML document or modifications
Thereof for use in hardware or software products claiming conformance to MPEG-7.
Those intending to use this XML document in hardware or software products are
advised that its use may infringe existing patents. The original developers of
this XML document and his/her company, the subsequent editors and their companies,
and ISO/IEC have no liability for use of this XML document or modifications
thereof in an implementation.
Copyright is not released for non MPEG-7 conforming products. The organizations
Who contributed to this XML document retain the full right to use the code for
their own purpose, assign or donate their contribution to a third party and
inhibit third parties from using their contribution for non MPEG-7 conforming
products.
Copyright (c) 1999-2003 ISO/IEC.
This XML document is provided for informative purposes only. If any parts of this
XML document contradict the normative part of the corresponding standard document
then the normative part should be used as the definitive specification.
This notice must be included in all copies or derivative works.
************************************************************************** -->
<!--####################################################################### -->
<!-- ISO/IEC 15938 Information Technology-Multimedia Content Description Interface -->
<!-- Part 9: MPEG-7 Profiles and Levels (ISO/IEC 15938-9) -->
<!-- Simple Meatadata Profile -->
<!-- -->
<!-- Last updated: 22 July 2004 -->
<!-- ############################################################################# -->
<!-- SMP-Light, version:1, date:July 23, 2003 -->
<schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:mpeg7="urn:mpeg:mpeg7:smp:schema:2001" targetNamespace="urn:mpeg:mpeg7:smp:schema:2001" elementFormDefault="qualified" attributeFormDefault="unqualified">
<annotation>
<documentation>
This document contains MDS tools defined in ISO/IEC 15938-5
</documentation>
</annotation>
<!-- ########################################################### -->
<!-- import xml components -->
<!-- ########################################################### -->
<import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- ########################################################### -->
<!-- include MPEG-7 specific extensions for DDL(ISO/IEC 15938-2) -->
<!-- ########################################################### -->
<element name="Mpeg7">
<complexType>
<complexContent>
<extension base="mpeg7:Mpeg7Type">
<choice>
<element name="Description" type="mpeg7:CompleteDescriptionType" maxOccurs="unbounded"/>
</choice>
</extension>
</complexContent>
</complexType>
</element>
<!-- Definition of Mpeg7Type datatype -->
<complexType name="Mpeg7Type" abstract="true">
<sequence>
<!-- DescriptionProfile element added per ISO/IEC 15938 Part 5 Cor1 - July 2004 -->
<element name="DescriptionProfile" type="mpeg7:DescriptionProfileType" minOccurs="0"/>
</sequence>
<attribute ref="xml:lang" use="optional"/>
</complexType>
<!-- DescriptionProfileType datatype added per ISO/IEC 15938 Part 5 Cor1 - July 2004 -->
<!-- Definition of DescriptionProfileType datatype -->
<complexType name="DescriptionProfileType">
<attribute name="profileAndLevelIndication" use="required">
<simpleType>
<list itemType="anyURI"/>
</simpleType>
</attribute>
</complexType>
<complexType name="Mpeg7BaseType" abstract="true">
<complexContent>
<restriction base="anyType"/>
</complexContent>
</complexType>
<simpleType name="timePointType">
<restriction base="mpeg7:basicTimePointType">
<pattern value="(\-?\d+(\-\d{2}(\-\d{2})?)?)?(T\d{2}(:\d{2}(:\d{2}(:\d+)?)?)?)?(F\d+)?((\-|\+)\d{2}:\d{2})?"/>
</restriction>
</simpleType>
<simpleType name="basicTimePointType">
<restriction base="string">
<pattern value="\-?(\d+(\-\d{2}(\-\d{2})?)?)?(T\d{2}(:\d{2}(:\d{2}(:\d+(\.\d{2})?)?)?)?)?(F\d+)?((\-|\+)\d{2}:\d{2})?"/>
</restriction>
</simpleType>
<!-- Definition of mimeType datatype (ISO/IEC 15938-5: 5.6.2) -->
<simpleType name="mimeType">
<restriction base="string">
<whiteSpace value="collapse"/>
<pattern value='[!--[\(\)<>@,;:\\"/\[\]\?=]]+/[!--[\(\)<>@,;:\\"/\[\]\?=]]+'/>
</restriction>
</simpleType>
<complexType name="TextAnnotationType">
<choice maxOccurs="unbounded">
<element name="FreeTextAnnotation" type="mpeg7:TextualType"/>
<element name="StructuredAnnotation" type="mpeg7:StructuredAnnotationType"/>
</choice>
<attribute ref="xml:lang"/>
</complexType>
<complexType name="TextualType">
<simpleContent>
<extension base="mpeg7:TextualBaseType"/>
</simpleContent>
</complexType>
<complexType name="TextualBaseType" abstract="true">
<simpleContent>
<extension base="string">
<attribute ref="xml:lang" use="optional"/>
</extension>
</simpleContent>
</complexType>
<complexType name="StructuredAnnotationType">
<sequence>
<element name="Who" type="mpeg7:TermUseType" minOccurs="0" maxOccurs="unbounded"/>
<element name="WhatObject" type="mpeg7:TermUseType" minOccurs="0" maxOccurs="unbounded"/>
<element name="WhatAction" type="mpeg7:TermUseType" minOccurs="0" maxOccurs="unbounded"/>
<element name="Where" type="mpeg7:TermUseType" minOccurs="0" maxOccurs="unbounded"/>
<element name="When" type="mpeg7:TermUseType" minOccurs="0" maxOccurs="unbounded"/>
<element name="Why" type="mpeg7:TermUseType" minOccurs="0" maxOccurs="unbounded"/>
<element name="How" type="mpeg7:TermUseType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute ref="xml:lang" use="optional"/>
</complexType>
<complexType name="TermUseType">
<complexContent>
<extension base="mpeg7:InlineTermDefinitionType">
<attribute name="href" type="mpeg7:termReferenceType" use="optional"/>
</extension>
</complexContent>
</complexType>
<complexType name="InlineTermDefinitionType" abstract="true">
<sequence>
<element name="Name" minOccurs="0" maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension base="mpeg7:TextualType">
<attribute name="preferred" type="boolean" use="optional"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="Definition" type="mpeg7:TextualType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<simpleType name="termRelationQualifierType">
<union>
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="NT"/>
<enumeration value="BT"/>
<enumeration value="RT"/>
<enumeration value="US"/>
<enumeration value="UF"/>
</restriction>
</simpleType>
<simpleType>
<restriction base="mpeg7:termReferenceType"/>
</simpleType>
</union>
</simpleType>
<simpleType name="termReferenceType">
<union>
<simpleType>
<restriction base="NMTOKEN">
<whiteSpace value="collapse"/>
<pattern value=":[^:]+:[^:]+"/>
</restriction>
</simpleType>
<simpleType>
<restriction base="anyURI"/>
</simpleType>
</union>
</simpleType>
<complexType name="CreatorType">
<complexContent>
<extension base="mpeg7:MediaAgentType"/>
</complexContent>
</complexType>
<complexType name="MediaAgentType">
<sequence>
<element name="Role" type="mpeg7:ControlledTermUseType"/>
<choice>
<element name="Agent" type="mpeg7:AgentType"/>
</choice>
</sequence>
</complexType>
<complexType name="ControlledTermUseType">
<complexContent>
<extension base="mpeg7:InlineTermDefinitionType">
<attribute name="href" type="mpeg7:termReferenceType" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="AgentType" abstract="true">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="Icon" type="mpeg7:MediaLocatorType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="PersonType">
<complexContent>
<extension base="mpeg7:AgentType">
<sequence>
<choice maxOccurs="unbounded">
<element name="Name" type="mpeg7:PersonNameType"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="DSType" abstract="true">
<complexContent>
<extension base="mpeg7:Mpeg7BaseType">
<attribute name="id" type="ID" use="optional"/>
</extension>
</complexContent>
</complexType>
<complexType name="MediaLocatorType">
<sequence>
<choice minOccurs="0">
<element name="MediaUri" type="anyURI"/>
<element name="InlineMedia" type="mpeg7:InlineMediaType"/>
</choice>
<element name="StreamID" type="nonNegativeInteger" minOccurs="0"/>
</sequence>
</complexType>
<!-- Definition of InlineMedia datatype (ISO/IEC 15938-5: 6.5.3) -->
<complexType name="InlineMediaType">
<choice>
<element name="MediaData16" type="hexBinary"/>
<element name="MediaData64" type="base64Binary"/>
</choice>
<attribute name="type" type="mpeg7:mimeType" use="required"/>
</complexType>
<complexType name="PersonNameType">
<sequence>
<choice maxOccurs="unbounded">
<element name="GivenName" type="mpeg7:NameComponentType"/>
<element name="FamilyName" type="mpeg7:NameComponentType" minOccurs="0"/>
</choice>
</sequence>
<attribute ref="xml:lang" use="optional"/>
</complexType>
<complexType name="NameComponentType">
<simpleContent>
<extension base="mpeg7:TextualBaseType">
<attribute name="initial" type="string" use="optional"/>
<attribute name="abbrev" type="string" use="optional"/>
</extension>
</simpleContent>
</complexType>
<complexType name="CreationToolType">
<sequence>
<element name="Tool" type="mpeg7:TermUseType"/>
<element name="Setting" minOccurs="0" maxOccurs="unbounded">
<complexType>
<attribute name="name" type="string" use="required"/>
<attribute name="value" type="string" use="required"/>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="PlaceType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="GeographicPosition" minOccurs="0">
<complexType>
<sequence>
<element name="Point" type="mpeg7:GeographicPointType"/>
</sequence>
<attribute name="datum" type="string" use="optional"/>
</complexType>
</element>
</sequence>
<attribute ref="xml:lang" use="optional"/>
</extension>
</complexContent>
</complexType>
<complexType name="GeographicPointType">
<attribute name="longitude" use="required">
<simpleType>
<restriction base="double">
<minInclusive value="-180.0"/>
<maxInclusive value="180.0"/>
</restriction>
</simpleType>
</attribute>
<attribute name="latitude" use="required">
<simpleType>
<restriction base="double">
<minInclusive value="-90.0"/>
<maxInclusive value="90.0"/>
</restriction>
</simpleType>
</attribute>
<attribute name="altitude" type="double" use="optional"/>
</complexType>
<complexType name="CompleteDescriptionType" abstract="true"/>
<!-- EXTENSIONS for the MSP demo -->
<complexType name="ContentDescriptionType" abstract="true">
<complexContent>
<extension base="mpeg7:CompleteDescriptionType"/>
</complexContent>
</complexType>
<complexType name="ContentEntityType">
<complexContent>
<extension base="mpeg7:ContentDescriptionType">
<sequence>
<element name="MultimediaContent" type="mpeg7:MultimediaContentType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="MultimediaContentType" abstract="true">
<complexContent>
<extension base="mpeg7:DSType"/>
</complexContent>
</complexType>
<!-- Definition of Image Content Entity -->
<complexType name="ImageType">
<complexContent>
<extension base="mpeg7:MultimediaContentType">
<sequence>
<element name="Image" type="mpeg7:StillRegionType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- Definition of Video Content Entity -->
<complexType name="VideoType">
<complexContent>
<extension base="mpeg7:MultimediaContentType">
<sequence>
<element name="Video" type="mpeg7:VideoSegmentType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- ######################################## -->
<!-- Definition of VideoSegment DS (11.4.8) -->
<!-- ######################################## -->
<!-- Definition of VideoSegment DS -->
<complexType name="VideoSegmentType">
<complexContent>
<extension base="mpeg7:SegmentType">
<sequence>
<element name="MediaTime" type="mpeg7:MediaTimeType" minOccurs="0"/>
<element name="TemporalDecomposition" type="mpeg7:VideoSegmentTemporalDecompositionType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- ########################################### -->
<!-- Definition of MediaTime datatype (6.4.10) -->
<!-- ########################################### -->
<!-- Definition of MediaTime datatype -->
<complexType name="MediaTimeType">
<sequence>
<element name="MediaTimePoint" type="mpeg7:mediaTimePointType"/>
<element name="MediaIncrDuration" type="mpeg7:MediaIncrDurationType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="SegmentType" abstract="true">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="CreationInformation" type="mpeg7:CreationInformationType" minOccurs="0"/>
<!--element name="CreationInformation" type="mpeg7:CreationInformationType"/-->
<element name="TextAnnotation" minOccurs="0" maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base="mpeg7:TextAnnotationType">
<attribute name="type" use="optional">
<simpleType>
<union memberTypes="mpeg7:termReferenceType string"/>
</simpleType>
</attribute>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="mediaTimePointType">
<restriction base="mpeg7:basicTimePointType">
<pattern value="(\-?\d+(\-\d{2}(\-\d{2})?)?)?(T\d{2}(:\d{2}(:\d{2}(:\d+)?)?)?)?(F\d+)?"/>
</restriction>
</simpleType>
<complexType name="VideoSegmentTemporalDecompositionType">
<complexContent>
<extension base="mpeg7:TemporalSegmentDecompositionType">
<sequence>
<element name="VideoSegment" type="mpeg7:VideoSegmentType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- Definition of TemporalSegmentDecomposition DS -->
<complexType name="TemporalSegmentDecompositionType" abstract="true">
<complexContent>
<extension base="mpeg7:SegmentDecompositionType"/>
</complexContent>
</complexType>
<complexType name="SegmentDecompositionType" abstract="true">
<complexContent>
<extension base="mpeg7:DSType">
<attribute name="criteria" type="string" use="optional"/>
<attribute name="overlap" type="boolean" use="optional" default="false"/>
<attribute name="gap" type="boolean" use="optional" default="false"/>
</extension>
</complexContent>
</complexType>
<complexType name="StillRegionType">
<complexContent>
<extension base="mpeg7:SegmentType">
<sequence>
<element name="MediaTimePoint" type="mpeg7:mediaTimePointType"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- ############################################### -->
<!-- Definition of mediaDuration datatype (6.4.12) -->
<!-- ############################################### -->
<!-- Definition of mediaDuration datatype -->
<simpleType name="mediaDurationType">
<restriction base="mpeg7:basicDurationType">
<pattern value="\-?P(\d+D)?(T(\d+H)?(\d+M)?(\d+S)?(\d+N)?)?(\d+F)?"/>
</restriction>
</simpleType>
<simpleType name="durationType">
<restriction base="mpeg7:basicDurationType">
<pattern value="\-?P(\d+D)?(T(\d+H)?(\d+M)?(\d+S)?(\d+N)?)?(\d+F)?((\-|\+)\d{2}:\d{2}Z)?"/>
</restriction>
</simpleType>
<simpleType name="basicDurationType">
<restriction base="string">
<pattern value="\-?P(\d+D)?(T(\d+H)?(\d+M)?(\d+S)?(\d+N)?(\d{2}f)?)?(\d+F)?((\-|\+)\d{2}:\d{2}Z)?"/>
</restriction>
</simpleType>
<!-- ################################################### -->
<!-- Definition of MediaIncrDuration datatype (6.4.13) -->
<!-- ################################################### -->
<!-- Definition of MediaIncrDuration datatype -->
<complexType name="MediaIncrDurationType">
<simpleContent>
<extension base="integer">
<attribute name="mediaTimeUnit" type="mpeg7:mediaDurationType" use="optional"/>
</extension>
</simpleContent>
</complexType>
<!-- END of EXTENSIONS for the MSP demo -->
<complexType name="ContentManagementType" abstract="true">
<complexContent>
<extension base="mpeg7:CompleteDescriptionType"/>
</complexContent>
</complexType>
<complexType name="RatingType">
<sequence>
<element name="RatingValue" type="float"/>
<element name="RatingScheme">
<complexType>
<complexContent>
<extension base="mpeg7:TermUseType">
<attribute name="best" type="float" use="optional"/>
<attribute name="worst" type="float" use="optional"/>
<attribute name="style" use="required">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="higherBetter"/>
<enumeration value="lowerBetter"/>
</restriction>
</simpleType>
</attribute>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="MediaInstanceType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<choice>
<element name="MediaLocator" type="mpeg7:MediaLocatorType"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="CreationDescriptionType">
<complexContent>
<extension base="mpeg7:ContentManagementType">
<sequence>
<element name="CreationInformation" type="mpeg7:CreationInformationType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="CreationInformationType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="Creation" type="mpeg7:CreationType"/>
<element name="Classification" type="mpeg7:ClassificationType" minOccurs="0"/>
<element name="RelatedMaterial" type="mpeg7:RelatedMaterialType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="CreationType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="Title" type="mpeg7:TitleType" maxOccurs="unbounded"/>
<element name="TitleMedia" type="mpeg7:TitleMediaType" minOccurs="0"/>
<element name="Abstract" type="mpeg7:TextAnnotationType" minOccurs="0" maxOccurs="unbounded"/>
<element name="Creator" type="mpeg7:CreatorType" minOccurs="0" maxOccurs="unbounded"/>
<element ref="mpeg7:CreationCoordinates" minOccurs="0" maxOccurs="unbounded"/>
<element name="CreationTool" type="mpeg7:CreationToolType" minOccurs="0" maxOccurs="unbounded"/>
<element name="CopyrightString" type="mpeg7:TextualType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="CreationCoordinates">
<complexType>
<sequence>
<element name="Location" type="mpeg7:PlaceType" minOccurs="0"/>
<element name="Date" type="mpeg7:TimeType" minOccurs="0"/>
</sequence>
</complexType>
</element>
<complexType name="TitleType">
<simpleContent>
<extension base="mpeg7:TextualBaseType">
<attribute name="type" use="optional" default="main"/>
</extension>
</simpleContent>
</complexType>
<complexType name="TitleMediaType">
<sequence>
<element name="TitleImage" type="mpeg7:ImageLocatorType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="ImageLocatorType">
<complexContent>
<extension base="mpeg7:MediaLocatorType"/>
</complexContent>
</complexType>
<complexType name="TimeType">
<sequence>
<choice>
<element name="TimePoint" type="mpeg7:timePointType"/>
</choice>
</sequence>
</complexType>
<complexType name="ClassificationType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="Genre" minOccurs="0" maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base="mpeg7:ControlledTermUseType">
<attribute name="type" use="optional" default="main">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="main"/>
<enumeration value="secondary"/>
</restriction>
</simpleType>
</attribute>
</extension>
</complexContent>
</complexType>
</element>
<element name="ParentalGuidance" type="mpeg7:ParentalGuidanceType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ParentalGuidanceType">
<sequence>
<choice>
<element name="ParentalRating" type="mpeg7:ControlledTermUseType"/>
</choice>
</sequence>
</complexType>
<complexType name="RelatedMaterialType">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="DisseminationFormat" type="mpeg7:ControlledTermUseType" minOccurs="0"/>
<element name="MaterialType" type="mpeg7:TermUseType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ClassificationSchemeDescriptionType">
<complexContent>
<extension base="mpeg7:ContentManagementType">
<choice>
<element name="ClassificationScheme" type="mpeg7:ClassificationSchemeType" maxOccurs="unbounded"/>
<element name="ClassificationSchemeBase" type="mpeg7:ClassificationSchemeBaseType" maxOccurs="unbounded"/>
</choice>
</extension>
</complexContent>
</complexType>
<complexType name="ClassificationSchemeType">
<complexContent>
<extension base="mpeg7:ClassificationSchemeBaseType">
<sequence>
<element name="Term" type="mpeg7:TermDefinitionType" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ClassificationSchemeBaseType" abstract="true">
<complexContent>
<extension base="mpeg7:DSType">
<attribute name="uri" type="anyURI" use="required"/>
<attribute name="domain" use="optional"/>
</extension>
</complexContent>
</complexType>
<complexType name="TermDefinitionType">
<complexContent>
<extension base="mpeg7:TermDefinitionBaseType">
<sequence>
<element name="Term" minOccurs="0" maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base="mpeg7:TermDefinitionType">
<attribute name="relation" type="mpeg7:termRelationQualifierType" use="optional" default="NT"/>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="TermDefinitionBaseType" abstract="true">
<complexContent>
<extension base="mpeg7:DSType">
<sequence>
<element name="Name" minOccurs="0" maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension base="mpeg7:TextualType">
<attribute name="preferred" type="boolean" use="optional"/>
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
<attribute name="termID" type="NMTOKEN"/>
</extension>
</complexContent>
</complexType>
</schema>
Figure 288: The mpeg7smp schema
C.14 The Media Streaming Access Protocol schema
The schema characterised by the following URI: urn:mpeg:maf:schema:mediastreaming:accessprotocol:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:mpeg:maf:schema:mediastreaming:accessprotocol:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:msap="urn:mpeg:maf:schema:mediastreaming:accessprotocol:2007"
xmlns:didl-msx="urn:mpeg:maf:schema:mediastreaming:DIDLextensions"
xmlns:didl-msaf="urn:mpeg:mpeg21:2006:07-DIDL-NS"
xmlns:dii-msaf="urn:mpeg:mpeg21:2002:01-DII-NS"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:ipmpinfo-msx="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007"
xmlns:ipmpinfo-msaf="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS"
xmlns:r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:dia="urn:mpeg:mpeg21:2003:01-DIA-NS"
xmlns:msbp="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="urn:mpeg:mpeg21:2002:01-DII-NS" schemaLocation="http://www.dmpf.org/schemas/dii-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg21:2006:07-DIDL-NS" schemaLocation="http://www.dmpf.org/schemas/didl-msaf.xsd"/>
<import namespace="urn:mpeg:maf:Schema:mediastreaming:IPMPINFOextensions:2007" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msx.xsd"/>
<import namespace="urn:mpeg:mpeg21:2004:01-IPMPINFO-NS" schemaLocation="http://www.dmpf.org/schemas/ipmpinfo-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:DIDLextensions" schemaLocation="didl-msx.xsd"/>
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-DIA-NS" schemaLocation="http://www.dmpf.org/schemas/ued.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007" schemaLocation="http://www.dmpf.org/schemas/msbp.xsd"/>
<complexType name="AccessProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
<element name="Ack" type="msap:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="ContentIdentifierType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="ContentIdentifier" type="anyURI"/>
<element name="ResourceIdentifier" type="anyURI" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestContent" type="msap:RequestContentType"/>
<complexType name="RequestContentType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element name="ContentIdentifier" type="msap:ContentIdentifierType"/>
<element name="MimeType" type="string"/>
<element ref="r-msaf:license" minOccurs="0"/>
<element name="UsageEnvironmentDescription" type="dia:UsageEnvironmentType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestContentResult" type="msap:RequestContentResultType"/>
<complexType name="RequestContentResultType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element name="DI" type="didl-msaf:DIDLType" minOccurs="0"/>
<element name="ContentURL" type="msap:ContentURLType" minOccurs="0" maxOccurs="unbounded"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<complexType name="ContentURLType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="MimeType" type="string"/>
<element name="URL" type="anyURI"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestLicense" type="msap:RequestLicenseType"/>
<complexType name="RequestLicenseType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<choice>
<element name="ContentIdentifier" type="msap:ContentIdentifierType"/>
<element name="LicenseID" type="anyURI"/>
</choice>
<element ref="r-msaf:license" minOccurs="0"/>
<element name="DISignature" type="dsig:SignatureType" minOccurs="0"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestLicenseResult" type="msap:RequestLicenseResultType"/>
<complexType name="RequestLicenseResultType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element ref="r-msaf:license"/>
<element ref="dsig:Signature" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestIPMPToolBody" type="msap:RequestIPMPToolBodyType"/>
<complexType name="RequestIPMPToolBodyType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<element ref="ipmpinfo-msaf:IPMPToolID"/>
<element ref="ipmpinfo-msx:DeviceInformation"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestIPMPToolBodyResponse" type="msap:RequestIPMPToolBodyResponseType"/>
<complexType name="RequestIPMPToolBodyResponseType">
<complexContent>
<extension base="msap:AccessProtocolType">
<sequence>
<choice maxOccurs="unbounded">
<element ref="ipmpinfo-msx:ToolBody"/>
<element name="ToolURL" type="anyURI"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Figure 289: The msap schema
C.15 The Media Streaming Base Protocol schema
The schema characterised by the following URI: urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:msbp="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<complexType name="ProtocolBaseType" abstract="true"/>
<complexType name="ProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<element name="TransactionID" type="unsignedByte"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- **************************************************************** -->
<!-- ______________ Ack ___________________________ -->
<!-- **************************************************************** -->
<element name="Ack" type="msbp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="msbp:ProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<!-- **************************************************************** -->
<!-- ______________ ProtocolResult___________________ -->
<!-- **************************************************************** -->
<element name="ProtocolResult" type="msbp:ProtocolResultType"/>
<complexType name="ProtocolResultType">
<complexContent>
<extension base="msbp:ProtocolBaseType">
<sequence>
<choice>
<element name="ResultCode" type="msbp:ResultCodeType"/>
<element name="UserDefinedResult" type="string"/>
</choice>
<element name="DisplayString" type="string" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<simpleType name="ResultCodeType">
<annotation>
<documentation>
"00" - RESERVED
"01" - OK
"02" - UNKNOWN_MESSAGE
"03" - TIMEOUT
"04" - UNABLE_TO_PROCESS
"05" - UNKNOWN_FAILURE
"06" - PERMISSION_DENIED
"07" - BUSY
</documentation>
</annotation>
<restriction base="hexBinary">
<enumeration value="00"/>
<enumeration value="01"/>
<enumeration value="02"/>
<enumeration value="03"/>
<enumeration value="04"/>
<enumeration value="05"/>
<enumeration value="06"/>
<enumeration value="07"/>
</restriction>
</simpleType>
</schema>
Figure 290: The msbp schema
C.16 The Media Streaming Domain schema
The schema characterised by the following URI: urn:mpeg:maf:schema:mediastreaming:domain:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:mpeg:maf:schema:mediastreaming:domain:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:msd="urn:mpeg:maf:schema:mediastreaming:domain:2007"
xmlns:sx-msaf="urn:mpeg:mpeg21:2003:01-REL-SX-NS"
xmlns:r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-REL-SX-NS" schemaLocation="http://www.dmpf.org/schemas/rel-sx-msaf.xsd"/>
<import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<complexType name="DomainBaseType" abstract="true"/>
<complexType name="IDType">
<sequence>
<choice>
<element name="id" type="anyURI"/>
<element ref="dsig:X509Data" minOccurs="0"/>
</choice>
</sequence>
</complexType>
<element name="DomainID" type="msd:DomainIDType"/>
<complexType name="DomainIDType">
<complexContent>
<extension base="msd:IDType">
<sequence>
<element ref="msd:DomainManagerID"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="DACredentials" type="msd:DomainCredentialType"/>
<element name="DomainMembershipCredentials" type="msd:DomainCredentialType"/>
<complexType name="DomainCredentialType">
<sequence>
<element ref="msd:AccessID"/>
<element ref="msd:AccessPassword"/>
</sequence>
</complexType>
<element name="DomainManageInfo" type="msd:DomainManageInfoType"/>
<complexType name="DomainManageInfoType">
<complexContent>
<extension base="msd:DomainBaseType">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:DACredentials" minOccurs="0"/>
<element ref="msd:DomainMembershipCredentials" minOccurs="0"/>
<choice minOccurs="0" maxOccurs="2">
<element ref="msd:User"/>
<element ref="msd:Device"/>
</choice>
<element ref="msd:DomainKey"/>
<element name="Registration" type="dateTime"/>
<element ref="msd:Expiration"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="User" type="msd:UserType"/>
<complexType name="UserType">
<complexContent>
<extension base="msd:DomainBaseType">
<sequence>
<element ref="msd:UserIDList"/>
<element ref="msd:MaximumNumberOfUsers" minOccurs="0"/>
<element ref="msd:MaximumFrequencyOfUpdateUser" minOccurs="0"/>
<element ref="msd:UserRevocationList" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Device" type="msd:DeviceType"/>
<complexType name="DeviceType">
<complexContent>
<extension base="msd:DomainBaseType">
<sequence>
<element ref="msd:DeviceIDList"/>
<element ref="msd:MaximumNumberOfDevices" minOccurs="0"/>
<element ref="msd:MaximumFrequencyOfUpdateDevice" minOccurs="0"/>
<element ref="msd:DeviceRevocationList" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="UserRevocationList">
<complexType>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="msd:UserID"/>
</sequence>
</complexType>
</element>
<element name="DeviceIDList">
<complexType>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="msd:DeviceID"/>
<element ref="msd:Expiration"/>
</sequence>
</complexType>
</element>
<element name="UserIDList">
<complexType>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="msd:UserID"/>
<element ref="msd:Expiration"/>
</sequence>
</complexType>
</element>
<element name="DeviceRevocationList">
<complexType>
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="msd:DeviceID"/>
</sequence>
</complexType>
</element>
<element name="UseData" type="msd:UseDataType"/>
<complexType name="UseDataType">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:Record" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<element name="Record" type="msd:RecordType"/>
<complexType name="RecordType">
<sequence>
<element ref="msd:DeviceID"/>
<element name="StartTime" type="dateTime"/>
<element name="EndTime" type="dateTime"/>
<element name="NumberOfContentGroups" type="integer"/>
<element ref="msd:ContentGroupID" minOccurs="0" maxOccurs="unbounded"/>
<element name="NotificationFlag" type="boolean"/>
</sequence>
</complexType>
<element name="DomainManagerID" type="r-msaf:KeyHolder"/>
<element name="AccessPassword" type="string"/>
<element name="AccessID" type="string"/>
<element name="DomainKey" type="xenc:EncryptedKeyType"/>
<element name="UserID" type="msd:IDType"/>
<element name="DeviceID" type="msd:IDType"/>
<element name="LocalDomainID" type="msd:IDType"/>
<element name="ContentGroupID" type="anyURI"/>
<element name="MaximumNumberOfDevices" type="unsignedInt"/>
<element name="MaximumNumberOfUsers" type="unsignedInt"/>
<element name="MaximumFrequencyOfUpdateDevice" type="duration"/>
<element name="MaximumFrequencyOfUpdateUser" type="duration"/>
<element name="Expiration" type="sx-msaf:ValidityTimeMetered"/>
</schema>
Figure 291: The xxx schema
C.17 The Media Streaming Domain Protocol schema
The schema characterised by the following URI: urn:mpeg:maf:schema:mediastreaming:domainprotocol:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:mpeg:maf:schema:mediastreaming:domainprotocol:2007"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:msdp="urn:mpeg:maf:schema:mediastreaming:domainprotocol:2007"
xmlns:r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:msd="urn:mpeg:maf:schema:mediastreaming:domain:2007"
xmlns:msbp="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="urn:mpeg:maf:schema:mediastreaming:domain:2007" schemaLocation="http://www.dmpf.org/schemas/msd.xsd"/>
<import namespace="urn:mpeg:maf:schema:mediastreaming:baseprotocol:2007" schemaLocation="http://www.dmpf.org/schemas/msbp.xsd"/>
<import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<complexType name="DomainProtocolType" abstract="true">
<complexContent>
<extension base="msbp:ProtocolType"/>
</complexContent>
</complexType>
<element name="Ack" type="msdp:AckType"/>
<complexType name="AckType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence minOccurs="0">
<element ref="msbp:ProtocolResult"/>
</sequence>
<attribute name="Result" type="boolean" use="required"/>
</extension>
</complexContent>
</complexType>
<element name="AuthenticateReq" type="msdp:AuthenticateReqType"/>
<complexType name="AuthenticateReqType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DomainID" minOccurs="0"/>
<choice>
<element ref="msd:DACredentials"/>
<element ref="msd:DomainMembershipCredentials"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="LocalDomainIDRequest" type="msdp:RequestLocalDomainIDType"/>
<complexType name="RequestLocalDomainIDType">
<complexContent>
<extension base="msdp:DomainProtocolType"/>
</complexContent>
</complexType>
<element name="LocalDomainIDResponse" type="msdp:LocalDomainIDResponseType"/>
<complexType name="LocalDomainIDResponseType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:LocalDomainID"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestKey" type="msdp:RequestKeyType"/>
<complexType name="RequestKeyType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:ContentGroupID" minOccurs="0" maxOccurs="unbounded"/>
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="msd:DeviceID"/>
<element ref="msd:UserID"/>
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RequestKeyResponse" type="msdp:RequestKeyResponseType"/>
<complexType name="RequestKeyResponseType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DomainKey"/>
<element ref="msd:UserID" minOccurs="0" maxOccurs="unbounded"/>
<element ref="msd:DeviceID" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="AddDevice" type="msdp:AddDeviceType"/>
<complexType name="AddDeviceType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DeviceID"/>
<element ref="msd:Expiration" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="AddUser" type="msdp:AddUserType"/>
<complexType name="AddUserType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:UserID"/>
<element ref="msd:Expiration" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RenewDevice" type="msdp:RenewDeviceType"/>
<complexType name="RenewDeviceType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DeviceID"/>
<element ref="msd:UseData" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RenewUser" type="msdp:RenewUserType"/>
<complexType name="RenewUserType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:UserID"/>
<element ref="msd:UseData" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="AddDeviceResponse" type="msdp:LicenseResponseType"/>
<element name="AddUserResponse" type="msdp:LicenseResponseType"/>
<element name="RenewDeviceResponse" type="msdp:LicenseResponseType"/>
<element name="RenewUserResponse" type="msdp:LicenseResponseType"/>
<complexType name="LicenseResponseType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="r-msaf:license"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="LeaveDevice" type="msdp:LeaveDeviceType"/>
<complexType name="LeaveDeviceType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DeviceID"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="LeaveUser" type="msdp:LeaveUser"/>
<complexType name="LeaveUser">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:UserID"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="CreateDomain" type="msdp:CreateDomainType"/>
<complexType name="CreateDomainType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DACredentials"/>
<element ref="msd:Expiration"/>
<element ref="msd:MaximumNumberOfUsers" minOccurs="0"/>
<element ref="msd:MaximumNumberOfDevices" minOccurs="0"/>
<element ref="msd:MaximumFrequencyOfUpdateUser" minOccurs="0"/>
<element ref="msd:MaximumFrequencyOfUpdateDevice" minOccurs="0"/>
<element ref="msd:UserRevocationList" minOccurs="0"/>
<element ref="msd:DeviceRevocationList" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="CreateDomainResponse" type="msdp:CreateDomainResponseType"/>
<complexType name="CreateDomainResponseType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:DomainID"/>
<element ref="msd:DomainMembershipCredentials"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="RenewDomain" type="msdp:RenewDomainType"/>
<complexType name="RenewDomainType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:Expiration"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="DeleteDomain" type="msdp:DeleteDomainType"/>
<complexType name="DeleteDomainType">
<complexContent>
<extension base="msdp:DomainProtocolType"/>
</complexContent>
</complexType>
<element name="UnLicensedSimultaneousUseNotice" type="msdp:UnLicensedSimultaneousUseNoticeType"/>
<complexType name="UnLicensedSimultaneousUseNoticeType">
<complexContent>
<extension base="msdp:DomainProtocolType">
<sequence>
<element ref="msd:UseData" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
Figure 292: The msdp schema
C.18 The Media Streaming MPEG-21 REL Multimedia Extension One
The MPEG-21 REL Multimedia Extension One schema characterised by the following URI: urn:mpeg:mpeg21:2005:01-REL-M1X-NS is given below.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:mpeg:mpeg21:2005:01-REL-M1X-NS"
xmlns:rel-m1x-msaf="urn:mpeg:mpeg21:2005:01-REL-M1X-NS"
xmlns:rel-mx-msaf="urn:mpeg:mpeg21:2005:01-REL-MX-NS"
xmlns:rel-r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:rel-sx-msaf="urn:mpeg:mpeg21:2003:01-REL-SX-NS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-SX-NS" schemaLocation="http://www.dmpf.org/schemas/rel-sx-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-MX-NS" schemaLocation="http://www.dmpf.org/schemas/rel-mx-msaf.xsd"/>
<xsd:import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<!-- Elements -->
<xsd:element name="delist" type="rel-m1x-msaf:Delist" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="drmSystem" type="rel-m1x-msaf:DrmSystem" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="derivationConstraint" type="rel-m1x-msaf:DerivationConstraint" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="enlist" type="rel-m1x-msaf:Enlist" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="governedCopy" type="rel-m1x-msaf:GovernedCopy" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="governedMove" type="rel-m1x-msaf:GovernedMove" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="identityHolder" type="rel-m1x-msaf:IdentityHolder" substitutionGroup="rel-r-msaf:principal"/>
<xsd:element name="outputRegulation" type="rel-m1x-msaf:OutputRegulation" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="protectedResource" type="rel-m1x-msaf:ProtectedResource" substitutionGroup="rel-r-msaf:resource"/>
<xsd:element name="seekPermission" type="rel-m1x-msaf:SeekPermission" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="serviceLocation" type="rel-m1x-msaf:ServiceLocation" substitutionGroup="rel-r-msaf:serviceDescription"/>
<xsd:element name="startCondition" type="rel-m1x-msaf:StartCondition" substitutionGroup="rel-r-msaf:condition"/>
<!--Complex Types-->
<xsd:complexType name="Delist">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="DrmSystem">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element name="identifier" type="xsd:anyURI"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Enlist">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="DerivationConstraint">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence>
<xsd:element name="isPartOf" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="rel-m1x-msaf:protectedResource"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="resourceInclusionList" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="rel-m1x-msaf:protectedResource"/>
</xsd:sequence>
<xsd:attribute name="temporalRelation" type="xsd:QName" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="resourceExclusionList" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="rel-m1x-msaf:protectedResource"/>
</xsd:sequence>
<xsd:attribute name="temporalRelation" type="xsd:QName" use="optional"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="resourceReplacementList" minOccurs="0">
<xsd:complexType>
<xsd:sequence maxOccurs="unbounded">
<xsd:element ref="rel-m1x-msaf:protectedResource"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="GovernedCopy">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right">
<xsd:attribute name="governanceRule" type="xsd:QName"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="GovernedMove">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right">
<xsd:attribute name="governanceRule" type="xsd:QName"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="IdentityHolder">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Principal">
<xsd:sequence minOccurs="0">
<xsd:element name="idSystem" type="xsd:anyURI" minOccurs="0"/>
<xsd:element name="idValue">
<xsd:complexType mixed="true">
<xsd:sequence>
<xsd:any namespace="##any" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="OutputRegulation">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element name="regulation">
<xsd:complexType mixed="true">
<xsd:attribute name="typeOfSignal" type="xsd:QName" use="optional"/>
<xsd:attribute name="qualityOfSignal" type="xsd:QName" use="optional"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ProtectedResource">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Resource">
<xsd:sequence minOccurs="0">
<xsd:element ref="rel-r-msaf:digitalResource"/>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="xenc:EncryptedData"/>
<xsd:element ref="xenc:EncryptedKey"/>
</xsd:choice>
<xsd:element name="resourceLocator" type="xsd:anyURI" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SeekPermission">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element ref="rel-r-msaf:serviceReference"/>
<xsd:element name="cacheable" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="period" type="xsd:duration" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ServiceLocation">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:ServiceDescription">
<xsd:sequence minOccurs="0">
<xsd:element name="url" type="xsd:anyURI"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="StartCondition">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element ref="rel-r-msaf:condition"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- Simple Types -->
<xsd:simpleType name="LicenseType">
<xsd:list itemType="xsd:QName"/>
</xsd:simpleType>
<!-- Attributes -->
<xsd:attribute name="licenseType" type="rel-m1x-msaf:LicenseType"/>
</xsd:schema>
Figure 293: The rel-m1x-msaf schema
C.19 The MPEG-21 REL Multimedia Extension Two
The MPEG-21 REL Multimedia Extension Two schema characterised by the following URI: urn:mpeg:mpeg21:2006:01-REL-M2X-NS is given below.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:mpeg:mpeg21:2006:01-REL-M2X-NS"
xmlns:rel-m2x="urn:mpeg:mpeg21:2006:01-REL-M2X-NS"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:rel-sx-msaf="urn:mpeg:mpeg21:2003:01-REL-SX-NS"
xmlns:rel-mx-msaf="urn:mpeg:mpeg21:2003:01-REL-MX-NS"
xmlns:rel-r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:rel-m1x-msaf="urn:mpeg:mpeg21:2005:01-REL-M1X-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-SX-NS" schemaLocation="http://www.dmpf.org/schemas/rel-sx-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-MX-NS" schemaLocation="http://www.dmpf.org/schemas/rel-mx-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" schemaLocation="http://www.dmpf.org/schemas/rel-m1x-msaf.xsd"/>
<xsd:import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xsd:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<!-- Elements -->
<xsd:element name="export" type="rel-m2x:Export" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="extendRights" type="rel-m2x:ExtendRights" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="simultaneousAccess" type="rel-m2x:SimultaneousAccess" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="noSkipConstraint" type="rel-m2x:NoSkipConstraint" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="destinationPrincipal" type="rel-m2x:DestinationPrincipal" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="destinationCondition" type="rel-m2x:DestinationCondition" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="securitySystem" type="rel-m2x:SecuritySystem" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="proximity" type="rel-m2x:Proximity" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="scrambling" type="rel-m2x:Scrambling" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="timedExerciseLimit" type="rel-m2x:TimedExerciseLimit" substitutionGroup="rel-r-msaf:condition"/> <xsd:element name="timeShiftDuration" type="rel-m2x:TimeShiftDuration" substitutionGroup="rel-r-msaf:condition"/>
<!-- Complex Type -->
<xsd:complexType name="DestinationPrincipal">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element ref="rel-r-msaf:principal"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="DestinationCondition">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element ref="rel-r-msaf:condition"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Export">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ExtendRights">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right">
<xsd:sequence>
<xsd:element ref="rel-m1x-msaf:serviceLocation"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SimultaneousAccess">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element name="count" type="xsd:positiveInteger"/>
<xsd:element name="period" type="rel-r-msaf:ValidityInterval" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="isPartOf" minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="digitalResource" type="rel-r-msaf:DigitalResource"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SecuritySystem">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element name="identifier" type="xsd:anyURI"/>
<xsd:element name="level" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Proximity">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Scrambling">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:attribute name="cipherType" type="xsd:QName" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="TimedExerciseLimit">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:choice>
<xsd:element name="duration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="quantum" type="xsd:duration" minOccurs="0"/>
</xsd:choice>
<xsd:element name="count" type="xsd:integer" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="NoSkipConstraint">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:choice maxOccurs="unbounded" minOccurs="0">
<xsd:element name="interval" type="rel-m2x:RelTimeDuration"/>
<xsd:element name="object" type="rel-r-msaf:DigitalResource"/>
</xsd:choice>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="RelTimeDuration" >
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element name="relStartTime" type="xsd:duration"/>
<xsd:element name="relDuration" type="xsd:duration"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="TimeShiftDuration">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element name="duration" type="xsd:duration"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
Figure 294: The rel-m2x schema
C.20 The MPEG-21 REL Multimedia Extension Three
The MPEG-21 REL Multimedia Extension Three schema characterised by the following URI: urn:mpeg:mpeg21:2006:01-REL-M3X-NS is given below.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:mpeg:mpeg21:2006:01-REL-M3X-NS"
xmlns:rel-m3x="urn:mpeg:mpeg21:2006:01-REL-M3X-NS"
xmlns:rel-m1x-msaf="urn:mpeg:mpeg21:2005:01-REL-M1X-NS"
xmlns:rel-r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-MX-NS" schemaLocation="http://www.dmpf.org/schemas/rel-mx-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2005:01-REL-M1X-NS" schemaLocation="http://www.dmpf.org/schemas/rel-m1x-msaf.xsd"/>
<xsd:import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<xsd:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<!-- Elements -->
<xsd:element name="copyrightNotice" type="rel-m3x:CopyrightNotice" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="nonCommercialUse" type="rel-m3x:NonCommercialUse" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="sourceCode" type="rel-m3x:SourceCode" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="aggregate" type="rel-m3x:Aggregate" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="embed" type="rel-m3x:Embed" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="governedAdapt" type="rel-m3x:GovernedAdapt" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="governedAggregate" type="rel-m3x:GovernedAggregate" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="governedEmbed" type="rel-m3x:GovernedEmbed" substitutionGroup="rel-r-msaf:right"/>
<xsd:complexType name="CopyrightNotice">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence minOccurs="0">
<xsd:element name="copyrightString" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="noticeType" type="xsd:QName" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="NonCommercialUse">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="SourceCode">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="GovernedAdapt">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Aggregate">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="GovernedAggregate">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Embed">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="GovernedEmbed">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
Figure 295: The rel-m3x schema
C.21 The Media Streaming MPEG-21 REL Multimedia extension profile schema
The XML Schema for the profile elements and types of the MPEG REL multimedia extension, characterised by the following URI: urn:mpeg:mpeg21:2003:01-REL-MX-NS is given below.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:mpeg:mpeg21:2003:01-REL-MX-NS"
xmlns:rel-mx-msaf="urn:mpeg:mpeg21:2003:01-REL-MX-NS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:rel-r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="rel-r-msaf.xsd"/>
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-SX-NS" schemaLocation="rel-sx-msaf.xsd"/>
<xsd:import namespace="http://www.w3.org/2001/04/xmlenc#" schemaLocation="http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/xenc-schema.xsd"/>
<!-- Rights -->
<xsd:element name="derive" type="rel-mx-msaf:Derive" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="execute" type="rel-mx-msaf:Execute" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="play" type="rel-mx-msaf:Play" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="print" type="rel-mx-msaf:Print" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="adapt" type="rel-mx-msaf:Adapt" substitutionGroup="rel-r-msaf:right"/>
<!--Complex Types-->
<xsd:complexType name="Derive">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Execute">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Play">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Print">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Adapt">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
Figure 296: The rel-mx-msaf schema
C.22 The Media Streaming MPEG-21 REL core profile schema
The XML Schema for the profile elements and types of the MPEG REL core, characterised by the following URI: urn:mpeg:mpeg21:2003:01-REL-R-NS is given below.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:rel-r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:sccns="urn:uddi-org:schemaCentricC14N:2002-07-10"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xsd:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<!-- Elements -->
<xsd:element name="allConditions" type="rel-r-msaf:AllConditions" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="anXmlExpression" type="rel-r-msaf:AnXmlExpression"/>
<xsd:element name="condition" type="rel-r-msaf:Condition" substitutionGroup="rel-r-msaf:licensePart"/>
<xsd:element name="digitalResource" type="rel-r-msaf:DigitalResource" substitutionGroup="rel-r-msaf:resource"/>
<xsd:element name="forAll" block="#all" substitutionGroup="rel-r-msaf:licensePart" final="#all">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:LicensePart">
<xsd:choice minOccurs="0">
<xsd:element name="anXmlExpression" type="rel-r-msaf:AnXmlExpression"/>
<xsd:element name="propertyPossessor" type="rel-r-msaf:PropertyPossessor"/>
</xsd:choice>
<xsd:attribute name="varName" type="rel-r-msaf:VariableName"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="grant" type="rel-r-msaf:Grant" substitutionGroup="rel-r-msaf:resource"/>
<xsd:element name="keyHolder" type="rel-r-msaf:KeyHolder" substitutionGroup="rel-r-msaf:principal"/>
<xsd:element name="issue" type="rel-r-msaf:Issue"/>
<xsd:element name="issuer" type="rel-r-msaf:Issuer"/>
<xsd:element name="license" type="rel-r-msaf:License"/>
<xsd:element name="licensePart" type="rel-r-msaf:LicensePart"/>
<xsd:element name="possessProperty" type="rel-r-msaf:PossessProperty" substitutionGroup="rel-r-msaf:right"/>
<xsd:element name="propertyAbstract" type="rel-r-msaf:PropertyAbstract" substitutionGroup="rel-r-msaf:resource"/>
<xsd:element name="principal" type="rel-r-msaf:Principal" substitutionGroup="rel-r-msaf:resource"/>
<xsd:element name="propertyPossessor" type="rel-r-msaf:PropertyPossessor"/>
<xsd:element name="resource" type="rel-r-msaf:Resource" substitutionGroup="rel-r-msaf:licensePart"/>
<xsd:element name="right" type="rel-r-msaf:Right" substitutionGroup="rel-r-msaf:licensePart"/>
<xsd:element name="serviceDescription" type="rel-r-msaf:ServiceDescription" substitutionGroup="rel-r-msaf:licensePart"/>
<xsd:element name="serviceReference" type="rel-r-msaf:ServiceReference" substitutionGroup="rel-r-msaf:resource"/>
<xsd:element name="trustedRootIssuers" type="rel-r-msaf:TrustedRootIssuers"/>
<xsd:element name="validityInterval" type="rel-r-msaf:ValidityInterval" substitutionGroup="rel-r-msaf:condition"/>
<!--Complex Types-->
<xsd:complexType name="AllConditions">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence>
<xsd:element ref="rel-r-msaf:condition" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="AnXmlExpression" mixed="true" sccns:embeddedLangAttribute="rel-r-msaf:lang">
<xsd:complexContent mixed="true">
<xsd:extension base="rel-r-msaf:Resource">
<xsd:attribute name="lang" type="xsd:anyURI" default="http://www.w3.org/TR/1999/REC-xpath-19991116"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Condition">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:LicensePart"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="DigitalResource">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Resource">
<xsd:choice minOccurs="0">
<xsd:element name="secureIndirect" type="dsig:ReferenceType"/>
<xsd:element name="nonSecureIndirect" type="rel-r-msaf:NonSecureReference"/>
</xsd:choice>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Grant">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Resource">
<xsd:choice minOccurs="0">
<xsd:sequence>
<xsd:element ref="rel-r-msaf:forAll" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="rel-r-msaf:principal" minOccurs="0"/>
<xsd:element ref="rel-r-msaf:right"/>
<xsd:element ref="rel-r-msaf:resource" minOccurs="0"/>
<xsd:element ref="rel-r-msaf:condition" minOccurs="0"/>
</xsd:sequence>
</xsd:choice>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Issue">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Issuer">
<xsd:sequence>
<xsd:choice minOccurs="0">
<xsd:element ref="dsig:Signature"/>
<xsd:element ref="rel-r-msaf:principal"/>
</xsd:choice>
<xsd:element name="details" type="rel-r-msaf:IssuerDetails" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="IssuerDetails">
<xsd:sequence>
<xsd:element name="timeOfIssue" type="xsd:dateTime" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="KeyHolder">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Principal">
<xsd:sequence minOccurs="0">
<xsd:element name="info" type="dsig:KeyInfoType"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="License">
<xsd:choice>
<xsd:sequence>
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="rel-r-msaf:grant"/>
</xsd:choice>
<xsd:element ref="rel-r-msaf:issuer" minOccurs="0"/>
</xsd:sequence>
</xsd:choice>
<xsd:attribute name="licenseId" type="xsd:anyURI" use="optional"/>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
<xsd:complexType name="LicensePart">
<xsd:attribute name="licensePartId" type="rel-r-msaf:LicensePartId" use="optional"/>
<xsd:attribute name="licensePartIdRef" type="rel-r-msaf:LicensePartId" use="optional"/>
<xsd:attribute name="varRef" type="rel-r-msaf:VariableName" use="optional"/>
</xsd:complexType>
<xsd:complexType name="NonSecureReference">
<xsd:attribute name="URI" type="xsd:anyURI"/>
</xsd:complexType>
<xsd:complexType name="PossessProperty">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Right"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Principal">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Resource"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="PropertyAbstract">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Resource"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="PropertyPossessor">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Resource">
<xsd:sequence minOccurs="0">
<xsd:element ref="rel-r-msaf:propertyAbstract"/>
<xsd:element ref="rel-r-msaf:trustedRootIssuers" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Right">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:LicensePart"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Resource">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:LicensePart"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ServiceDescription">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:LicensePart"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ServiceReference">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Resource">
<xsd:sequence minOccurs="0">
<xsd:element ref="rel-r-msaf:serviceDescription"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="TrustRoot">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:LicensePart"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="TrustedRootIssuers">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:TrustRoot">
<xsd:sequence minOccurs="0">
<xsd:element ref="rel-r-msaf:principal" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ValidityInterval">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence>
<xsd:element name="notBefore" type="xsd:dateTime" minOccurs="0"/>
<xsd:element name="notAfter" type="xsd:dateTime" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- Simple Types-->
<xsd:simpleType name="LicensePartId">
<xsd:restriction base="xsd:NCName"/>
</xsd:simpleType>
<xsd:simpleType name="VariableName">
<xsd:restriction base="xsd:NCName"/>
</xsd:simpleType>
</xsd:schema>
Figure 297: The rel-r-msaf schema
C.23 The Media Streaming MPEG-21 REL Standard extension profile schema
The XML Schema for the profile elements and types of the MPEG REL standard extension, characterised by the following URI: urn:mpeg:mpeg21:2003:01-REL-SX-NS is given below.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="urn:mpeg:mpeg21:2003:01-REL-SX-NS"
xmlns:rel-sx-msaf="urn:mpeg:mpeg21:2003:01-REL-SX-NS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
xmlns:rel-r-msaf="urn:mpeg:mpeg21:2003:01-REL-R-NS"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="http://www.dmpf.org/schemas/rel-r-msaf.xsd"/>
<xsd:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
<!-- Elements -->
<xsd:element name="exerciseLimit" type="rel-sx-msaf:ExerciseLimit" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="propertyUri" type="rel-sx-msaf:PropertyUri" substitutionGroup="rel-r-msaf:propertyAbstract"/>
<xsd:element name="territory" type="rel-sx-msaf:Territory" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="validityIntervalFloating" type="rel-sx-msaf:ValidityIntervalFloating" substitutionGroup="rel-r-msaf:condition"/>
<xsd:element name="validityTimeMetered" type="rel-sx-msaf:ValidityTimeMetered" substitutionGroup="rel-r-msaf:condition"/>
<!--Complex Types-->
<xsd:complexType name="ExerciseLimit">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence>
<xsd:element name="count" type="xsd:integer" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="PropertyUri">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:PropertyAbstract">
<xsd:attribute name="definition" type="xsd:anyURI"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="Territory">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element name="location">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="country" type="xsd:QName" minOccurs="0"/>
<xsd:element name="region" type="xsd:QName" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="domain">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="uri" type="xsd:anyURI"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ValidityIntervalFloating">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence>
<xsd:element name="duration" type="xsd:duration" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="ValidityTimeMetered">
<xsd:complexContent>
<xsd:extension base="rel-r-msaf:Condition">
<xsd:sequence>
<xsd:element name="duration" type="xsd:duration" minOccurs="0"/>
<xsd:element name="quantum" type="xsd:duration" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<!-- Simple Types -->
<xsd:simpleType name="ProfileCompliance">
<xsd:list itemType="xsd:QName"/>
</xsd:simpleType>
<!-- Attributes -->
<xsd:attribute name="profileCompliance" type="rel-sx-msaf:ProfileCompliance"/>
</xsd:schema>
Figure 298: The rel-sx-msaf schema
C.24 The TV Anytime schema
The XML Schema for the profile elements and types of the MPEG REL standard extension, characterised by the following URI: urn:tva:metadata:2002 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns:tva="urn:tva:metadata:2002" xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:tva:metadata:2002" elementFormDefault="qualified" attributeFormDefault="unqualified">
<annotation>
<documentation xml:lang="en">
-------- This XML Schema file specifies normative DMP metadata types. It is a reduced profile ofr ETSI TS 102 822-3-1 V1.1.1 (2003-05)
It differs from ETSI TS 102 822-3-1 V1.1.1 (2003-05) in that it it does not include the following second level elements.
ServiceInformationTable
SegmentInformationTable
ProgramReviewTable
ProgramLocationTable.
UserDescriptionTable
All of which are defined in ETSI TS 102 822-3-1 V1.1.1 (2003-05) with minOccurrs=0
TVAMain and ProgramDescription
These omissions are made through a modified definition of TVAMAin and ProgrammeDesscription in the dmp:represent:Metadata namespace.
Apart from the omission of elements not used, all remaining elements are as ETSI TS 102 822-3-1 V1.1.1 (2003-05)
</documentation>
</annotation>
<import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<import namespace="urn:mpeg:mpeg7:schema:2001" schemaLocation="mpeg7.xsd"/>
<annotation>
<documentation xml:lang="en">
======== Section 5.3.3 BASIC TYPES</documentation>
</annotation>
<simpleType name="TVAIDType">
<restriction base="string">
<whiteSpace value="collapse"/>
</restriction>
</simpleType>
<simpleType name="TVAIDRefType">
<restriction base="string">
<whiteSpace value="collapse"/>
</restriction>
</simpleType>
<simpleType name="TVAIDRefsType">
<list itemType="tva:TVAIDRefType"/>
</simpleType>
<simpleType name="CRIDType">
<restriction base="anyURI">
<pattern value="(c|C)(r|R)(i|I)(d|D)://.*/.*"/>
</restriction>
</simpleType>
<complexType name="CRIDRefType">
<attribute name="crid" type="tva:CRIDType" use="required"/>
</complexType>
<complexType name="FlagType">
<attribute name="value" type="boolean" use="required"/>
</complexType>
<complexType name="TVATimeType">
<sequence>
<element name="TimePoint" type="mpeg7:timePointType"/>
<element name="Duration" type="mpeg7:durationType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="ControlledTermType">
<sequence>
<element name="Name" minOccurs="0">
<complexType>
<simpleContent>
<extension base="mpeg7:TextualType">
<attribute name="preferred" type="boolean" use="optional"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="Definition" type="mpeg7:TextualType" minOccurs="0"/>
</sequence>
<attribute name="href" type="mpeg7:termReferenceType" use="required"/>
</complexType>
<complexType name="TVAAgentType">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="PersonName" type="mpeg7:PersonNameType"/>
<element name="PersonNameIDRef">
<complexType>
<attribute name="ref" type="tva:TVAIDRefType" use="required"/>
</complexType>
</element>
<element name="OrganizationName" type="mpeg7:TextualType"/>
<element name="OrganizationNameIDRef">
<complexType>
<attribute name="ref" type="tva:TVAIDRefType" use="required"/>
</complexType>
</element>
</choice>
</sequence>
</complexType>
<attributeGroup name="fragmentIdentification">
<attribute name="fragmentId" type="tva:TVAIDType" use="optional"/>
<attribute name="fragmentVersion" type="unsignedLong" use="optional"/>
</attributeGroup>
<annotation>
<documentation xml:lang="en">
======== Section 5.3.4 DESCRIPTION</documentation>
</annotation>
<complexType name="KeywordType">
<simpleContent>
<extension base="mpeg7:TextualType">
<attribute name="type" use="optional" default="main">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="main"/>
<enumeration value="secondary"/>
<enumeration value="other"/>
</restriction>
</simpleType>
</attribute>
</extension>
</simpleContent>
</complexType>
<complexType name="GenreType">
<complexContent>
<extension base="tva:ControlledTermType">
<attribute name="type" use="optional" default="main">
<simpleType>
<restriction base="string">
<enumeration value="main"/>
<enumeration value="secondary"/>
<enumeration value="other"/>
</restriction>
</simpleType>
</attribute>
</extension>
</complexContent>
</complexType>
<simpleType name="SynopsisLengthType">
<restriction base="string"/>
</simpleType>
<complexType name="SynopsisType">
<simpleContent>
<extension base="mpeg7:TextualType">
<attribute name="length" type="tva:SynopsisLengthType" use="optional"/>
</extension>
</simpleContent>
</complexType>
<complexType name="RelatedMaterialType">
<sequence>
<element name="HowRelated" type="tva:ControlledTermType" minOccurs="0"/>
<element name="Format" type="tva:ControlledTermType" minOccurs="0"/>
<element name="MediaLocator" type="mpeg7:MediaLocatorType"/>
<element name="PromotionalText" type="mpeg7:TextualType" minOccurs="0" maxOccurs="unbounded"/>
<element name="SourceMediaLocator" type="mpeg7:MediaLocatorType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="CreditsItemType">
<complexContent>
<extension base="tva:TVAAgentType">
<sequence>
<element name="Character" type="mpeg7:PersonNameType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="role" type="mpeg7:termReferenceType" use="required"/>
</extension>
</complexContent>
</complexType>
<complexType name="CreditsListType">
<sequence>
<element name="CreditsItem" type="tva:CreditsItemType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="AwardsListItemType">
<sequence>
<element name="Title" type="mpeg7:TextualType"/>
<element name="Year" type="gYear"/>
<element name="Award" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="Category" type="mpeg7:TextualType"/>
<choice minOccurs="0">
<element name="Nominee" type="tva:CreditsItemType"/>
<element name="Recipient" type="tva:CreditsItemType"/>
</choice>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="AwardsListType">
<sequence>
<element name="AwardsListItem" type="tva:AwardsListItemType" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="BasicContentDescriptionType">
<sequence>
<element name="Title" type="mpeg7:TitleType" minOccurs="0" maxOccurs="unbounded"/>
<element name="MediaTitle" type="mpeg7:TitleMediaType" minOccurs="0" maxOccurs="unbounded"/>
<element name="ShortTitle" minOccurs="0" maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension base="mpeg7:TitleType">
<attribute name="length" type="unsignedShort" use="required"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="Synopsis" type="tva:SynopsisType" minOccurs="0" maxOccurs="unbounded"/>
<element name="PromotionalInformation" type="mpeg7:TextualType" minOccurs="0" maxOccurs="unbounded"/>
<element name="Keyword" type="tva:KeywordType" minOccurs="0" maxOccurs="unbounded"/>
<element name="Genre" type="tva:GenreType" minOccurs="0" maxOccurs="unbounded"/>
<element name="ParentalGuidance" type="mpeg7:ParentalGuidanceType" minOccurs="0" maxOccurs="unbounded"/>
<element name="Language" type="mpeg7:ExtendedLanguageType" minOccurs="0" maxOccurs="unbounded"/>
<element name="CaptionLanguage" minOccurs="0" maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension base="language">
<attribute name="closed" type="boolean" use="optional" default="true"/>
<attribute name="supplemental" type="boolean" use="optional" default="false"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="SignLanguage" minOccurs="0" maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension base="language">
<attribute name="primary" type="boolean" use="optional"/>
<attribute name="translation" type="boolean" use="optional"/>
<attribute name="type" type="string" use="optional"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="CreditsList" type="tva:CreditsListType" minOccurs="0"/>
<element name="AwardsList" type="tva:AwardsListType" minOccurs="0"/>
<element name="RelatedMaterial" type="tva:RelatedMaterialType" minOccurs="0" maxOccurs="unbounded"/>
<element name="ProductionDate" type="tva:TVATimeType" minOccurs="0"/>
<element name="ProductionLocation" type="mpeg7:regionCode" minOccurs="0" maxOccurs="unbounded"/>
<element name="CreationCoordinates" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="CreationDate" type="tva:TVATimeType" minOccurs="0"/>
<element name="CreationLocation" type="mpeg7:regionCode" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="DepictedCoordinates" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="DepictedDate" type="tva:TVATimeType" minOccurs="0"/>
<element name="DepictedLocation" type="mpeg7:PlaceType" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="ReleaseInformation" minOccurs="0" maxOccurs="unbounded">
<complexType>
<sequence>
<element name="ReleaseDate" minOccurs="0">
<complexType>
<choice>
<element name="DayAndYear" type="date"/>
<element name="Year" type="gYear"/>
</choice>
</complexType>
</element>
<element name="ReleaseLocation" type="mpeg7:regionCode" minOccurs="0"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<annotation>
<documentation xml:lang="en">
======== Section 5.3.5 AUDIO AND VIDEO INFORMATION</documentation>
</annotation>
<complexType name="AVAttributesType">
<sequence>
<element name="FileFormat" type="tva:ControlledTermType" minOccurs="0"/>
<element name="FileSize" type="unsignedLong" minOccurs="0"/>
<element name="System" type="tva:ControlledTermType" minOccurs="0"/>
<element name="BitRate" minOccurs="0">
<complexType>
<simpleContent>
<extension base="nonNegativeInteger">
<attribute name="variable" type="boolean" use="optional" default="false"/>
<attribute name="minimum" type="unsignedLong" use="optional"/>
<attribute name="average" type="unsignedLong" use="optional"/>
<attribute name="maximum" type="unsignedLong" use="optional"/>
</extension>
</simpleContent>
</complexType>
</element>
<element name="AudioAttributes" minOccurs="0">
<complexType>
<sequence>
<element name="Coding" type="tva:ControlledTermType" minOccurs="0"/>
<element name="NumOfChannels" type="unsignedShort" minOccurs="0"/>
<element name="MixType" type="tva:ControlledTermType" minOccurs="0"/>
</sequence>
</complexType>
</element>
<element name="VideoAttributes" minOccurs="0">
<complexType>
<sequence>
<element name="Coding" type="tva:ControlledTermType" minOccurs="0"/>
<element name="Scan" type="tva:ScanType" minOccurs="0"/>
<element name="HorizontalSize" type="unsignedShort" minOccurs="0"/>
<element name="VerticalSize" type="unsignedShort" minOccurs="0"/>
<element name="AspectRatio" type="tva:AspectRatioType" minOccurs="0" maxOccurs="2"/>
<element name="Color" type="tva:ColorType" minOccurs="0"/>
</sequence>
</complexType>
</element>
</sequence>
</complexType>
<simpleType name="ScanType">
<restriction base="string">
<enumeration value="interlaced"/>
<enumeration value="progressive"/>
</restriction>
</simpleType>
<simpleType name="ColorTypeType">
<restriction base="string">
<enumeration value="color"/>
<enumeration value="blackAndWhite"/>
<enumeration value="blackAndWhiteAndColor"/>
<enumeration value="colorized"/>
</restriction>
</simpleType>
<complexType name="ColorType">
<attribute name="type" type="tva:ColorTypeType" use="required"/>
</complexType>
<simpleType name="RatioType">
<restriction base="string">
<pattern value="\d+:\d+"/>
</restriction>
</simpleType>
<complexType name="AspectRatioType">
<simpleContent>
<extension base="tva:RatioType">
<attribute name="type" use="optional" default="original">
<simpleType>
<restriction base="string">
<enumeration value="original"/>
<enumeration value="publication"/>
</restriction>
</simpleType>
</attribute>
</extension>
</simpleContent>
</complexType>
<annotation>
<documentation xml:lang="en">
======== Section 5.3.6 PROGRAMME INFORMATION</documentation>
</annotation>
<complexType name="ProgramInformationType">
<sequence>
<element name="BasicDescription" type="tva:BasicContentDescriptionType"/>
<element name="OtherIdentifier" type="mpeg7:UniqueIDType" minOccurs="0" maxOccurs="unbounded"/>
<element name="AVAttributes" type="tva:AVAttributesType" minOccurs="0"/>
<element name="MemberOf" type="tva:BaseMemberOfType" minOccurs="0" maxOccurs="unbounded"/>
<element name="DerivedFrom" type="tva:DerivedFromType" minOccurs="0"/>
<element name="EpisodeOf" type="tva:EpisodeOfType" minOccurs="0"/>
<element name="PartOfAggregatedProgram" type="tva:CRIDType" minOccurs="0"/>
<element name="AggregationOf" minOccurs="0">
<complexType>
<sequence>
<element name="AggregatedProgram" type="tva:CRIDRefType" minOccurs="2" maxOccurs="unbounded"/>
</sequence>
<attribute name="type" use="required">
<simpleType>
<restriction base="string">
<enumeration value="omnibus"/>
<enumeration value="magazine"/>
</restriction>
</simpleType>
</attribute>
</complexType>
</element>
</sequence>
<attribute name="programId" type="tva:CRIDType" use="required"/>
<attributeGroup ref="tva:fragmentIdentification"/>
</complexType>
<complexType name="EpisodeOfType">
<complexContent>
<extension base="tva:BaseMemberOfType"/>
</complexContent>
</complexType>
<complexType name="BaseMemberOfType" abstract="true">
<complexContent>
<extension base="tva:CRIDRefType">
<attribute name="index" type="unsignedInt" use="optional"/>
</extension>
</complexContent>
</complexType>
<complexType name="MemberOfType">
<complexContent>
<extension base="tva:BaseMemberOfType"/>
</complexContent>
</complexType>
<complexType name="BaseDerivationReasonType" abstract="true"/>
<complexType name="DerivationReasonType">
<complexContent>
<extension base="tva:BaseDerivationReasonType">
<attribute name="value" use="required">
<simpleType>
<restriction base="string">
<enumeration value="violence"/>
<enumeration value="language"/>
<enumeration value="sex"/>
<enumeration value="duration"/>
<enumeration value="other"/>
</restriction>
</simpleType>
</attribute>
</extension>
</complexContent>
</complexType>
<complexType name="DerivedFromType">
<complexContent>
<extension base="tva:BaseMemberOfType">
<sequence>
<element name="DerivationReason" type="tva:BaseDerivationReasonType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<annotation>
<documentation xml:lang="en">
======== Section 5.3.7 GROUP INFORMATION</documentation>
</annotation>
<complexType name="BaseProgramGroupTypeType" abstract="true"/>
<complexType name="ProgramGroupTypeType">
<complexContent>
<extension base="tva:BaseProgramGroupTypeType">
<attribute name="value" use="required">
<simpleType>
<restriction base="string">
<enumeration value="series"/>
<enumeration value="show"/>
<enumeration value="programConcept"/>
<enumeration value="programCompilation"/>
<enumeration value="otherCollection"/>
<enumeration value="otherChoice"/>
</restriction>
</simpleType>
</attribute>
</extension>
</complexContent>
</complexType>
<complexType name="GroupInformationType">
<sequence>
<element name="GroupType" type="tva:BaseProgramGroupTypeType"/>
<element name="BasicDescription" type="tva:BasicContentDescriptionType"/>
<element name="MemberOf" type="tva:BaseMemberOfType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="groupId" type="tva:CRIDType" use="required"/>
<attribute name="ordered" type="boolean" use="optional" default="false"/>
<attribute name="numOfItems" type="unsignedInt" use="optional"/>
<attributeGroup ref="tva:fragmentIdentification"/>
</complexType>
<annotation>
<documentation xml:lang="en">
======== Section 5.7.1 INFORMATION TABLES</documentation>
</annotation>
<complexType name="ProgramInformationTableType">
<sequence>
<element name="ProgramInformation" type="tva:ProgramInformationType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="copyrightNotice" type="string" use="optional"/>
</complexType>
<complexType name="GroupInformationTableType">
<sequence>
<element name="GroupInformation" type="tva:GroupInformationType" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="copyrightNotice" type="string" use="optional"/>
</complexType>
<complexType name="CreditsInformationTableType">
<sequence>
<choice minOccurs="0" maxOccurs="unbounded">
<element name="PersonName">
<complexType>
<complexContent>
<extension base="mpeg7:PersonNameType">
<attribute name="personNameId" type="tva:TVAIDType" use="required"/>
<attributeGroup ref="tva:fragmentIdentification"/>
</extension>
</complexContent>
</complexType>
</element>
<element name="OrganizationName">
<complexType>
<simpleContent>
<extension base="mpeg7:TextualType">
<attribute name="organizationNameId" type="tva:TVAIDType" use="required"/>
<attributeGroup ref="tva:fragmentIdentification"/>
</extension>
</simpleContent>
</complexType>
</element>
</choice>
</sequence>
<attribute name="copyrightNotice" type="string" use="optional"/>
</complexType>
<element name="TVAContentLinks">
<complexType>
<sequence>
<element name="RelatedMaterial" type="tva:RelatedMaterialType" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<annotation>
<documentation xml:lang="en">
======== Section 5.7.2 TV-ANYTIME PROGRAM INFORMATION DOCUMENT</documentation>
</annotation>
<complexType name="ClassificationSchemeTableType">
<sequence>
<element name="CSAlias" minOccurs="0" maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base="mpeg7:ClassificationSchemeAliasType">
<attributeGroup ref="tva:fragmentIdentification"/>
</extension>
</complexContent>
</complexType>
</element>
<element name="ClassificationScheme" minOccurs="0" maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base="mpeg7:ClassificationSchemeType">
<attributeGroup ref="tva:fragmentIdentification"/>
</extension>
</complexContent>
</complexType>
</element>
</sequence>
</complexType>
</schema>
Figure 299: The tva schema
C.25 The Media Streaming TV Anytime profile schema
The XML Schema for the profile elements and types of the MPEG REL standard extension, characterised by the following URI: urn:mpeg:maf:Profile:mediastreaming:tva:2007 is given below.
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:mpeg:maf:Profile:mediastreaming:tva:2007" xmlns:tva="urn:tva:metadata:2002" xmlns:tva-msaf="urn:mpeg:maf:Profile:mediastreaming:tva:2007" xmlns:mpeg7="urn:mpeg:mpeg7:schema:2001" xmlns="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<import namespace="urn:mpeg:mpeg7:schema:2001" schemaLocation="http://www.dmpf.org/schemas/mpeg7.xsd"/>
<import namespace="urn:tva:metadata:2002" schemaLocation="http://www.dmpf.org/schemas/tva.xsd"/>
<element name="TVAMain" type="tva-msaf:TVAMainType"/>
<complexType name="TVAMainType">
<sequence>
<element name="CopyrightNotice" type="string" minOccurs="0"/>
<element name="ClassificationSchemeTable" type="tva:ClassificationSchemeTableType" minOccurs="0"/>
<element name="ProgramDescription" type="tva-msaf:ProgramDescriptionType" minOccurs="0"/>
</sequence>
<attribute ref="xml:lang" use="optional" default="en"/>
<attribute name="publisher" type="string" use="optional"/>
<attribute name="publicationTime" type="dateTime" use="optional"/>
<attribute name="rightsOwner" type="string" use="optional"/>
<attribute name="version" type="unsignedInt" use="optional"/>
</complexType>
<complexType name="ProgramDescriptionType">
<sequence>
<element name="ProgramInformationTable" type="tva:ProgramInformationTableType" minOccurs="0"/>
<element name="GroupInformationTable" type="tva:GroupInformationTableType" minOccurs="0"/>
<element name="CreditsInformationTable" type="tva:CreditsInformationTableType" minOccurs="0"/>
</sequence>
</complexType>
</schema>
Figure 300: The tva-msaf schema
The XML schema characterised by the following URI: http://www.w3.org/XML/1998/namespace is available at the following URL: http://www.w3.org/XML/2001/namespace.
C.27 The Digital Signature Schema
The Digital Signature schema characterised by the following URI: http://www.w3.org/2000/09/xmldsig# is available at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.
Annex D – Compatibility between TVA RMPI and DMP Represent License
This Annex explains how DMP Represent License (hereafter to be referred as the MPEG-21 REL DAC Profile) can handle and represent TV-Anytime RMPI information
D.1 Compatibility
There are 4 child elements in the ‘RMPI-MBAndM’ main type like following figure.

Figure 301: The RMPI-MBAndMType complex type
The first child element, rmpi:AncillaryRMPI does not convey usage rules or conditions but carry further information that is required while handling the content.

Figure 302: The AncillaryRMPI element
Since RMPI-MB(Macro Broadcast) can be considered as a specific instance of the RMPI-M (Macro), the classification between RMPI MB and M is not necessary in case that the RMPI License is converted into the DMP License.
This element can be represented by rel-sx-dac:profileCompliance attribute of rel-msaf:license element.
This element can be represented rel-msaf:issuer element.
This element can be represented by xenc:EncryptedData element which is child element of rel-m1x:encryptedResource element. If the MPEG-21 License has xenc:EcnryptedData element, it means that the delivered resource is encrypted with the method specified in the child elements.

Figure 303: The xenc:EncryptedData element
RMPI specifies possible ‘Cipher’ methods (i.e. encryption algorithms) for broadcast content. These are:
0 – No cipher
1 - AES
2 - Camellia
3 - DVB Common Scrambling Algorithm v1
4 - DVB Common Scrambling Algorithm v2
5- 3DES
6- M2
7-15: reserved for future use
The element xenc:EncryptionMethod element can fully express the encryption algorithm applied, as in the following example:
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
<xenc:EncryptionMethod Algorithm="AES"/>
<xenc:EncryptionMethod Algorithm="Camellia"/>
<xenc:EncryptionMethod Algorithm="DVB Common Scrambling Algorithm v1"/>
<xenc:EncryptionMethod Algorithm="DVB Common Scrambling Algorithm v2"/>
<xenc:EncryptionMethod Algorithm="3DES"/>
<xenc:EncryptionMethod Algorithm="M2"/>
This condition indicates the scrambling policy to implement.
‘maintain’ : Maintain original scrambling status including no scrambling.
‘change’ : Apply or re-apply RMP cipher.
rmpi:MBScramblingControl with the ‘change’ attribute can be represented by the rel-m2x-dac:scrambling element On the other hand, rmpi:MBScramblingControl with the ‘maintain’ attribute does not need any counter MPEG-21 REL element, because a license without rel-m2x-dac:scrambling element means encryption status of the delivered resource should not be changed while moving or copying to other device.
Since RMPI-MB(Macro Broadcast) can be considered as a specific instance of the RMPI-M(Macro), the same conversion mechanism as rmpi:MBScramblingControl can be applied.
The second child element, rmpi:ExtendRights gives some information and condition to the client to retrieve new rights to be applied to content when there is no proper rights in the current license.

Figure 304: The rmpi:ExtendRights element
D.1.2.1 ExtendRightsFlagGranted
With rel-m2x-dac:extendRights, MPEG-21 REL license allows the ExtendRights and without one, it does not allow. So the counterpart elements to neither rmpi:ExtendRightsFlagGranted nor rmpi:ExtendRightsFlagNotGranted flag is needed in the MPEG-21 REL.
This condition can be expressed by rel-m2x-m2x:securitySystem element.
D.1.2.3 SourceOfAdditionalRights
This information can be represented by rel-m2x-m2x:extendRights right as in following example.
<r:grant>
<m1x:identityHolder licensePartId=’device’>
<m1x:idSystem>urn:mpeg:mpeg21:2006-01-REL-M2X-NS:DM-00001000</m1x:idSystem>
<m1x:idValue>DE1234567</m1x:idValue>
</m1x:identityHolder>
<m2x:extendRights>
<m1x:serviceLocation>
<m1x:url>http://www.foo.org/extendLiceseService</m1x:url>
</m1x:serviceLocation>
</m2x:extendRights>
<digitalResource licensePartId=’news’>
<nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</digitalResource>
<m2x:securitySystem>
<m2x:identifier>urn:mpeg:mpeg21:security:system1</m2x:identifier>
<m2x:level>5</m2x:level>
</m2x:securitySystem>
</r:grant>
Figure 305: Example of conversion of rmpi:SourceOfAdditionalRights
The rmpi:ReceivingDomainRights element indicates the first TVA RMP-compliant domain that receives the Content and associated RMPI–MB via broadcast. Once the Content is in the Domain, the receiving domain is explicitly identified.

Figure 306: The rmpi:ReceivingDomainRights element
This information can be represented by rel-mx-dac:play element.
This information can be represented by rel-m2x-dac:export right and rel-m1x-dac:outputRegulation condition elements as shown in following example. The example shows the license allows only analog export with APSTB:O1 copy protection constraint.
<r:grant>
<m1x:identityHolder licensePartIdRef="device"/>
<m2x:export/>
<r:digitalResource licensePartIdRef="news"/>
<m1x:outputRegulation>
<m1x:regulation typeOfSignal="analog">APSTB:01</m1x:regulation>
</m1x:outputRegulation>
</r:grant>
Figure 307: Example of conversion of rmpi:AnalogExportRights element
This information can be represented by rel-m2x-dac:export right and rel-m1x-dac:outputRegulation condition elements as shown in the following example. The example shows the license allows only standard definition digital export with DTCP copy protection constraint.
<r:grant>
<m1x:identityHolder licensePartIdRef="device"/>
<m2x:export/>
<r:digitalResource licensePartIdRef="news"/>
<m1x:outputRegulation>
<m1x:regulation typeOfSignal="digital" qualityOfSignal="SD">DTCP</m1x:regulation>
</m1x:outputRegulation>
</r:grant>
Figure 308: Example of conversion of rmpi:DigitalExportSDRights element
This information can be represented by rel-m2x-dac:export right and rel-m1x-dac:outputRegulation condition elements as shown in the following example. The example shows the license allows only high definition digital export with HDCP copy protection constraint.
<r:grant>
<m1x:identityHolder licensePartIdRef="device"/>
<m2x:export/>
<r:digitalResource licensePartIdRef="news"/>
<m1x:outputRegulation>
<m1x:regulation typeOfSignal="digital" qualityOfSignal="HD">HDCP</m1x:regulation>
</m1x:outputRegulation>
</r:grant>
Figure 309: Example of conversion of rmpi:DigitalExportHDRights element
This information can be represented by rel-m2x-dac:securitySystem condition.
This information can be represented by rel-m2x-dac:timeShiftDuration condition.
This information can be represented by rel-msaf:validityInterval condition.
This information can be represented by rel-sx-dac:territory element.
D.1.3.9 AnalogExportSignalling
This information can be represented by rel-m2x-dac:export right and rel-m1x-dac:outputRegulation condition elements like in the example shown in Section C.19 – AnalogExportRights.
This information can be represented by rel-msaf:principal extension element such as rel-m1x-dac:identityHolder specifying the device ID, as shown in the following example.
<r:grant>
<m1x:identityHolder>
<m1x:idSystem>urn:dmp:2006-01-REL-DAC-NS:DM-1000:DO-0001</m1x:idSystem>
<m1x:idValue>DEVICE-00000001</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</r:digitalResource>
</r:grant>
Figure 310: Example of conversion of rmpi:SinglePointOfControl element
D.1.3.11 PhysicalProximityFlag
This information can be represented by means of the rel-m2x-dac:proximity condition element as shown in the following example.
<r:grant>
<m1x:identityHolder>
<m1x:idSystem>urn:dmp:2006-01-REL-DAC-NS:DM-1000 </m1x:idSystem>
<m1x:idValue>DOMAIN-1234567</m1x:idValue>
</m1x:identityHolder>
<mx:play/>
<r:digitalResource>
<r:nonSecureIndirect URI="urn:broadcast:news:2005_07_10-12H-00M"/>
</r:digitalResource>
<m2x:proximity/>
</r:grant>
Figure 311: Example of conversion of rmpi:PhysicalProximityFlag element
D.1.3.12 SimultaneousRendering
This information can be represented by rel-m2x-dac:simultaneousAccess element.
D.1.3.13 DomainID
This information can be represented by rel-msaf:principal element like in the example shown in Section D.1.3.2– SinglePointOfControl
Any Domain is any TVA RMP-compliant domain that can respond to the usage conditions stated within RMPI-MB and RMPI-M.

Figure 312: The rmpi:AnyDomain element
All ‘rmpi:AnyDomainRights’ can be also represented with ‘rmpi:ReceivingDomainRights’, because ‘rmpi:ReceivingDomain’ can be considered as a special case of ‘rmpi:AnyDomain’ from MPEG-21 REL perspective.
D.2 Mapping Table between RMPI and DMP Represent License
|
Function |
Semantic |
RMPI |
DMP Represent License |
|
Grant to |
Receiving Domain |
<rmpi:ReceivingDomainRights> |
|
|
Right |
play_right_flag (Play) |
<rmpi:PlayRightFlag> |
<mx:play/> |
|
analogue_export_right_flag (Analogue Export) |
<rmpi:AnalogExportRight> |
<m2x:export/> <m1x:outputRegulation> <m1x:regulation typeOfSignal="analog"/> </m1x:outputRegulation> |
|
|
digital_export_SD_flag (Digital SD Export) |
<rmpi:DigitalExportSDRight> |
<m2x:export/> <m1x:outputRegulation> <m1x:regulation typeOfSignal="digital" qualityOfSignal="SD"/> </m1x:outputRegulation> |
|
|
digital_export_HD_flag (Digital HD Export) |
<rmpi:DigitalExportHDRight> |
<m2x:export/> <m1x:outputRegulation typeOfSignal="digital" qualityOfSignal="HD"/> </m1x:outputRegulation> |
|
|
Constraints |
Geographic Control |
<rmpi:GeographicalControl> |
<sx:terrority> |
|
Single point of control |
<rmpi:SinglePointOfControl> |
<m1x:identityHolder> <m1x:idValue>DEVICE-ID</m1x:idValue> </m1x:identityHolder> |
|
|
Simultaneous Rendering Count |
<rmpi:SimultaneousRendering> |
<m2x:simultaneousAccess> <m2x:count>COUNT</m2x:count> </m2x:simultaneouseAccess> |
|
|
Physical Proximity |
<rmpi:PhysicalProximityFlag> |
<m2x:proximity/> |
|
|
Buffer Duration: |
<rmpi:BufferDuration> |
<m2x:timeShiftDuration> <m2x:duration>DURATION</m2x:duration> </m2x :timeShiftDuration> |
|
|
Time Window Start/End |
<rmpi:TimeWindow> |
<r:validityInterval> <r:notBefore>BEFORE_DATE_TIME</r:notBefore> <r:notAfter>AFTER_DATE_TIME</r:notAfter> </r:validityInterval> |
|
|
SD Digital Export Control |
<rmpi:DigitalExportSDRight> <rmpi:DigitalExportControl> |
<m1x:outputRegulation> <m1x:regulation typeOfSignal="digital" qualityOfSignal="SD"/>CONSTRAINT</m1x:regulation> </m1x:outputRegulation> |
|
|
HD Digital Export Control |
<rmpi:DigitalExportHDRight> <rmpi:DigitalExportControl> |
<m1x:outputRegulation> <m1x:regulation typeOfSignal="digital" qualityOfSignal="HD">CONSTRAINT</m1x:regulation> </m1x:outputRegulation> |
|
|
Analogue Export Signalling |
<rmpi:AnalogueExportSignaling> |
<m1x:outputRegulation> <m1x:regulation typeOfSignal="analog">CONSTRAINT</m1x:regulation> </m1x:outputRegulation> |
|
|
Analogue SD Control |
<rmpi:AnalogueExportSDControl> |
<m1x:outputRegulation> <m1x:regulation typeOfSignal="analog" qualityOfSignal="SD">CONSTRAINT</m1x:regulation> </m1x:outputRegulation> |
|
|
Grant to |
Any Domain |
<rmpi:AnyDomainRights> |
|
|
Right |
Play |
<rmpi:PlayRightFlag> |
<mx:play/> |
|
Analogue Export |
<rmpi:AnalogExportRight> |
<m2x:export/> <m1x:outputRegulation> <m1x:regulation typeOfSignal="analog"/> </m1x:outputRegulation> |
|
|
Digital SD Export |
<rmpi:DigitalExportSDRight> |
<m2x:export/> <m1x:outputRegulation> <m1x:regulation typeOfSignal="digital" qualityOfSignal="SD"/> </m1x:outputRegulation> |
|
|
Digital HD Export |
<rmpi:DigitalExportHDRight> |
<m2x:export/> <m1x:outputRegulation> <m1x:regulation typeOfSignal="digital" qualityOfSignal="HD"/> </m1x:outputRegulation> |
|
|
Constraints |
Geographic Control |
<rmpi:GeographicalControl> |
<sx:terrority> |
|
Single Point of Control |
<rmpi:SinglePointOfControl> |
<m1x:identityHolder> <m1x:idValue>DEVICE-ID</m1x:idValue> </m1x:identityHolder> |
|
|
Buffer Duration: |
<rmpi:BufferDuration> |
<m2x:timeShiftDuration> |
|
|
Time Window Start/End |
<rmpi:TimeWindow> |
<r:validityInterval> |
|
|
SD Digital Export Control |
<rmpi:DigitalExportSDRight> <rmpi:DigitalExportControl> |
<m1x:outputRegulation> <m1x:regulation typeOfSignal="digital" qualityOfSignal="SD">CONSTRAINT</m1x:regulation> </m1x:outputRegulation> |
|
|
HD Digital Export Control
|
<rmpi:DigitalExportHDRight> <rmpi:DigitalExportControl> |
<m1x:outputRegulation> <m1x:regulation typeOfSignal="digital" qualityOfSignal="HD">CONSTRAINT</m1x:regulation> </m1x:outputRegulation> |
|
|
Analogue Export Signalling |
<rmpi:AnalogueExportSignaling> |
<m1x:outputRegulation> <m1x:regulation typeOfSignal="analog">CONSTRAINT</m1x:regulation> </m1x:outputRegulation> |
|
|
Analogue SD Control |
<rmpi:AnalogueExportSDControl> |
<m1x:outputRegulation> <m1x:regualtion typeOfSignal="analog" qualityOfSignal="SD">CONSTRAINT</m1x:regulation> </m1x:outputRegulation> |
|
|
Identifiers |
Domain |
<rmpi:DomainId> |
<m1x:identityHolder> <m1x:idValue>DOMAIN-ID</m1x:idValue> </m1x:identityHolder> |
|
Single Point of Control |
<rmpi:SinglePointOfControl> |
<m1x:identityHolder> <m1x:idValue>DEVICE-ID</m1x:idValue> </m1x:identityHolder> |
|
|
Ancillary applies to both grants |
<rmpi:AncillaryRMPI> |
|
|
|
Ancillary |
Cipher Algorithm |
<rmpi:Cipher> |
<m1x:protectedResource> <xenc:encryptedData> <xenc:encryptedMethod algorithm="ALGORITHM"/> </xenc:encryptedData> </m1x:protectedResource> |
|
Scrambling control |
<rmpi:MBScramblingControl> <rmpi:MScramblingControl> |
<m2x:scrambling/>
|
|
|
Version of RMPI |
<rmpi:VersionOfRMPI> |
<r:license sx:profileCompliance="mpeg-rel-dac v1.0"> |
|
|
Origin of RMPI |
<rmpi:OriginOfRMPI> |
<r:issuer> |
|
|
RMPI-Type flag |
<rmpi:RMPITypeFlag> |
N/A |
|
|
Extend Rights Apply to both grants |
<rmpi:ExtendRights> |
|
|
|
Extend Rights |
Extend Right Granted |
<rmpi:ExtendRightsFlagGranted> |
<m2x:extendRights> |
|
Security Level |
<rmpi:SecurityLevel> |
<m2x:securitySystem> <m2x:level>securityLevel</m2x:level> </m2x> |
|
|
Source of Additional Rights |
<rmpi:SourceOfAdditionalRights> |
<m2x:extendRights> <m1x:serviceLocation>serviceURL</m1x:serviceLocation/> </m2x> |
|
Annex E – Rights Representation Data Ontology Web Language File
<?xml version="1.0"?>
<rdf:RDF
xmlns="http://dmag.upf.edu/dmp/CreationModel.owl#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xmlns:daml="http://www.daml.org/2001/03/daml+oil#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:assert="http://www.owl-ontologies.com/assert.owl#"
xml:base="http://dmag.upf.edu/dmp/CreationModel.owl">
<owl:Ontology rdf:about="">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>This is an ontology for describing the DMP Creation Model.</rdfs:comment>
<owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>6.1 For IDP2.3</owl:versionInfo>
</owl:Ontology>
<owl:Class rdf:ID="Render">
<owl:disjointWith>
<owl:Class rdf:ID="MakeAdaptation"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="MoveContent"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="MakeInstance"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="CreateWork"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:ID="Distributor"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="RightGivenBy"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="ModifyCopy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="MakeCopy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="PublicCommunication"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Distribute"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Synchronization"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:ID="Action"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="MakeManifestation"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Function of generating a human-perceivable signal</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:ID="Produce"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:ID="AdaptationInstance">
<rdfs:subClassOf>
<owl:Class rdf:ID="Instance"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:valuesFrom>
<owl:Class rdf:ID="AdaptationManifestation"/>
</owl:valuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="Uses"/>
</owl:onProperty>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="WorkInstance"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:ID="MakeAdaptationInstanceCopy"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="Supports"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>An object or event which is an example of an Identified Adaptation Manifestation (e.g. a File)</rdfs:comment>
</owl:Class>
<owl:Class rdf:ID="Enlarge">
<owl:disjointWith>
<owl:Class rdf:ID="Export"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="GovernedAdapt"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Embed"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL)Enlarge represents the Right to modify a resource by making it larger.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:ID="Reduce"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Modify"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#ModifyCopy"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="Delete"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="ExtendRights"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Extract"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:ID="Download">
<owl:disjointWith>
<owl:Class rdf:ID="Broadcast"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Stream"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#PublicCommunication"/>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Transfer a file or program from a central computer to a smaller computer or to a computer at a remote location</rdfs:comment>
</owl:Class>
<owl:Class rdf:ID="MakeWorkManifestation">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making a Manifestation from Work.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:ID="MakeAdaptationManifestation"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:ID="Creator"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="ResultsIn"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:ID="WorkManifestation"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:about="#MakeManifestation"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#CreateWork">
<owl:disjointWith>
<owl:Class rdf:about="#ModifyCopy"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of creating a Work without any previous meterial.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#MakeCopy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MoveContent"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Produce"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeInstance"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Synchronization"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#PublicCommunication"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:valuesFrom>
<owl:Class rdf:ID="Work"/>
</owl:valuesFrom>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Distribute"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Render"/>
</owl:Class>
<owl:Class rdf:ID="Adaptation">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A Work that is derived from another Work.</rdfs:comment>
<rdfs:subClassOf>
<owl:Class rdf:ID="IPEntity"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="Copy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Manifestation"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Product"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:about="#MakeAdaptationManifestation"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="DependsOn"/>
</owl:onProperty>
<owl:valuesFrom>
<owl:Class rdf:about="#Work"/>
</owl:valuesFrom>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Instance"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Work"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:ID="Adaptor">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="Can"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#MakeAdaptationManifestation"/>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:ID="Role"/>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A User who produces an Adaptation</rdfs:comment>
</owl:Class>
<owl:Class rdf:ID="MakeAdaptationManifestationCopy">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making a ManifestationCopy</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:ID="MakeWorkInstanceCopy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptationInstanceCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:ID="Instantiator"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:ID="MakeWorkManifestationCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#MakeCopy"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:ID="AdaptationManifestationCopy"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#MakeCopy">
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Synchronization"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean"
>true</owl:hasValue>
<owl:onProperty>
<owl:DatatypeProperty rdf:ID="requiresCreatorAuthorisation"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Distribute"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Produce"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#ModifyCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:about="#Copy"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>MechanicalReproduction. The Right required to Produce</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#MoveContent"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith>
<owl:Class rdf:about="#PublicCommunication"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Render"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeInstance"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:ID="EndUser">
<rdfs:subClassOf>
<owl:Class rdf:about="#Role"/>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A User in a Value-Chain who ultimately consumes Content</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Render"/>
<owl:Class rdf:about="#ModifyCopy"/>
<owl:Class rdf:about="#MoveContent"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Can"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Print">
<owl:disjointWith>
<owl:Class rdf:ID="Play"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:ID="Execute"/>
</owl:disjointWith>
<rdfs:subClassOf rdf:resource="#Render"/>
<owl:disjointWith>
<owl:Class rdf:ID="Uninstall"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Print refers to the making of a fixed physical representation, such as hard-copy prints of images or text, that may be perceived directly (that is, without any intermediary process) with one or more of the five human senses.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:ID="Install"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Instance">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>An object or event which is an example of an Identified Manifestation (e.g. a File)</rdfs:comment>
<owl:disjointWith rdf:resource="#Adaptation"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:valuesFrom>
<owl:Class rdf:about="#Manifestation"/>
</owl:valuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Uses"/>
</owl:onProperty>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Work"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Copy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Product"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#PublicCommunication"/>
<owl:Class rdf:about="#MakeCopy"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:about="#IPEntity"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Manifestation"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Produce">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Function of making Products</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:about="#Instantiator"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:DatatypeProperty rdf:about="#requiresCreatorAuthorisation"/>
</owl:onProperty>
<owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean"
>true</owl:hasValue>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#PublicCommunication"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MoveContent"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:about="#Product"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Render"/>
<owl:disjointWith rdf:resource="#MakeCopy"/>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith>
<owl:Class rdf:about="#ModifyCopy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Synchronization"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Distribute"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeInstance"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#MakeInstance">
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#PublicCommunication"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith>
<owl:Class rdf:about="#MoveContent"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#ModifyCopy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Synchronization"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom rdf:resource="#Instance"/>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Render"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Distribute"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making an Instance from a Manifestation.</rdfs:comment>
<owl:disjointWith rdf:resource="#Produce"/>
<owl:disjointWith rdf:resource="#MakeCopy"/>
</owl:Class>
<owl:Class rdf:about="#PublicCommunication">
<owl:disjointWith>
<owl:Class rdf:about="#Synchronization"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#ModifyCopy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:DatatypeProperty rdf:about="#requiresCreatorAuthorisation"/>
</owl:onProperty>
<owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean"
>true</owl:hasValue>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#MoveContent"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Distribute"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#MakeCopy"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:about="#Creator"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of performing a public reproduction</rdfs:comment>
<owl:disjointWith rdf:resource="#Render"/>
<owl:disjointWith rdf:resource="#MakeInstance"/>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith rdf:resource="#Produce"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#MakeWorkInstanceCopy">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:about="#Instantiator"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making a WorkInstanceCopy</rdfs:comment>
<rdfs:subClassOf rdf:resource="#MakeCopy"/>
<owl:disjointWith rdf:resource="#MakeAdaptationManifestationCopy"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeWorkManifestationCopy"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptationInstanceCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:ID="WorkInstanceCopy"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:ID="Producer">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Can"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Produce"/>
<owl:Class rdf:about="#MakeCopy"/>
<owl:Class rdf:about="#Synchronization"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:about="#Role"/>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A User who produces a Product from an Instance.</rdfs:comment>
</owl:Class>
<owl:Class rdf:ID="GovernedMove">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) This element represents the right to copy the resource and at the same time to result in certain rights being associated to the copied resource.</rdfs:comment>
<rdfs:subClassOf>
<owl:Class rdf:about="#MoveContent"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#MakeAdaptationInstanceCopy">
<owl:disjointWith rdf:resource="#MakeWorkInstanceCopy"/>
<rdfs:subClassOf rdf:resource="#MakeCopy"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making an AdaptationInstanceCopy</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#MakeWorkManifestationCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:ID="AdaptationInstanceCopy"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:about="#Instantiator"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#MakeAdaptationManifestationCopy"/>
</owl:Class>
<owl:Class rdf:about="#Reduce">
<owl:disjointWith>
<owl:Class rdf:about="#GovernedAdapt"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Embed"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Export"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Modify"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#ExtendRights"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Represents the right to modify a resource by taking away from it</rdfs:comment>
<rdfs:subClassOf>
<owl:Class rdf:about="#ModifyCopy"/>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Enlarge"/>
<owl:disjointWith>
<owl:Class rdf:about="#Extract"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Delete"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#MakeAdaptationManifestation">
<rdfs:subClassOf>
<owl:Class rdf:about="#MakeManifestation"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:about="#AdaptationManifestation"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making an AdaptationManifestation from an Adaptation.</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:about="#Creator"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#MakeWorkManifestation"/>
</owl:Class>
<owl:Class rdf:ID="WorkManifestationCopy">
<owl:disjointWith>
<owl:Class rdf:about="#AdaptationInstanceCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:valuesFrom>
<owl:Class rdf:about="#WorkManifestation"/>
</owl:valuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="ProducedFrom"/>
</owl:onProperty>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A copy of a WorkManifestation.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#AdaptationManifestationCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Copy"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#WorkInstanceCopy"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#WorkManifestation">
<rdfs:subClassOf>
<owl:Restriction>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#DependsOn"/>
</owl:onProperty>
<owl:valuesFrom>
<owl:Class rdf:about="#Work"/>
</owl:valuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:ID="MakeWorkInstance"/>
<owl:Class rdf:about="#MakeWorkManifestationCopy"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Class rdf:about="#Manifestation"/>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>An object or event which is an expression of a Manifestation of a Work</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#AdaptationManifestation"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Synchronization">
<owl:disjointWith>
<owl:Class rdf:about="#MoveContent"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#MakeInstance"/>
<owl:disjointWith rdf:resource="#PublicCommunication"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Function of concurrently performing/displaying two distinct IP Entities each for a different human sense e.g. text and audio or video and song</rdfs:comment>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Distribute"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#MakeCopy"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean"
>true</owl:hasValue>
<owl:onProperty>
<owl:DatatypeProperty rdf:about="#requiresCreatorAuthorisation"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Produce"/>
<owl:disjointWith>
<owl:Class rdf:about="#ModifyCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Render"/>
</owl:Class>
<owl:Class rdf:about="#Install">
<owl:disjointWith rdf:resource="#Print"/>
<owl:disjointWith>
<owl:Class rdf:about="#Play"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Install represents the right to follow the instructions provided by an installing resource.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Uninstall"/>
</owl:disjointWith>
<rdfs:subClassOf rdf:resource="#Render"/>
<owl:disjointWith>
<owl:Class rdf:about="#Execute"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Distribute">
<owl:disjointWith rdf:resource="#Synchronization"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean"
>true</owl:hasValue>
<owl:onProperty>
<owl:DatatypeProperty rdf:about="#requiresCreatorAuthorisation"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Produce"/>
<owl:disjointWith>
<owl:Class rdf:about="#ModifyCopy"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith rdf:resource="#MakeCopy"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom rdf:resource="#Producer"/>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Render"/>
<owl:disjointWith rdf:resource="#MakeInstance"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Right to sell, rent and lend</rdfs:comment>
<owl:disjointWith rdf:resource="#PublicCommunication"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#MoveContent"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Instantiator">
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#MakeInstance"/>
<owl:Class rdf:about="#MakeCopy"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Can"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A User who produces an Instance</rdfs:comment>
<rdfs:subClassOf>
<owl:Class rdf:about="#Role"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Role">
<owl:disjointWith>
<owl:Class rdf:ID="Permit"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Action"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A defined set of actions and corresponding conditions attributed to and required of a User. A user is any person or legal entity in a Value-Chain connecting (and including) Creator and End-User. For the purpose of the current phase of Approved Documents a User is represented by a device or by a User Identity on the Device (e.g. username/password).</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#IPEntity"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Product">
<owl:disjointWith rdf:resource="#Instance"/>
<owl:disjointWith>
<owl:Class rdf:about="#Copy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#IPEntity"/>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Render"/>
<owl:Class rdf:about="#Distribute"/>
<owl:Class rdf:about="#PublicCommunication"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A Content Item that adds value to IP Entities by including them with an appropriate Licence for the purpose of Publishing</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Manifestation"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class rdf:about="#Copy"/>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:ID="Origin"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Work"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:minCardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Origin"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Adaptation"/>
</owl:Class>
<owl:Class rdf:about="#Work">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A creation that retains intellectual or artistic attributes independently of its Manifestations</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Copy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom rdf:resource="#Work"/>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Origin"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Instance"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#IPEntity"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Manifestation"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#MakeAdaptation"/>
<owl:Class rdf:about="#MakeWorkManifestation"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Adaptation"/>
<owl:disjointWith rdf:resource="#Product"/>
</owl:Class>
<owl:Class rdf:about="#AdaptationManifestationCopy">
<owl:disjointWith rdf:resource="#WorkManifestationCopy"/>
<owl:disjointWith>
<owl:Class rdf:about="#WorkInstanceCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Copy"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#AdaptationInstanceCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ProducedFrom"/>
</owl:onProperty>
<owl:valuesFrom>
<owl:Class rdf:about="#AdaptationManifestation"/>
</owl:valuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A copy of an AdaptationManifestation</rdfs:comment>
</owl:Class>
<owl:Class rdf:ID="MakeAdaptationInstance">
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom rdf:resource="#AdaptationInstance"/>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom rdf:resource="#Adaptor"/>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#MakeWorkInstance"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making an Instance from an Adaptation</rdfs:comment>
<rdfs:subClassOf rdf:resource="#MakeInstance"/>
</owl:Class>
<owl:Class rdf:about="#GovernedAdapt">
<owl:disjointWith>
<owl:Class rdf:about="#Modify"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Enlarge"/>
<owl:disjointWith rdf:resource="#Reduce"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#ModifyCopy"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Export"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#ExtendRights"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Extract"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) This element represents the right to adapt the resource and results in certain rights being associated with the adapted resource.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Embed"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Delete"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Creator">
<rdfs:subClassOf rdf:resource="#Role"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Can"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#CreateWork"/>
<owl:Class rdf:about="#MakeWorkManifestation"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A User who generates a Work and makes its first Manifestation, also referred to as author</rdfs:comment>
</owl:Class>
<owl:Class rdf:about="#ModifyCopy">
<owl:disjointWith rdf:resource="#PublicCommunication"/>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith rdf:resource="#MakeCopy"/>
<owl:disjointWith rdf:resource="#Synchronization"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Produce"/>
<owl:disjointWith rdf:resource="#Render"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Distribute"/>
<owl:disjointWith>
<owl:Class rdf:about="#MoveContent"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Action of modifying a copy.</rdfs:comment>
<owl:disjointWith rdf:resource="#MakeInstance"/>
</owl:Class>
<owl:Class rdf:about="#Broadcast">
<owl:disjointWith>
<owl:Class rdf:about="#Stream"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Download"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Function that Delivers Content to a Device in a point-to-multipoint modality</rdfs:comment>
<rdfs:subClassOf rdf:resource="#PublicCommunication"/>
</owl:Class>
<owl:Class rdf:about="#WorkInstanceCopy">
<owl:disjointWith rdf:resource="#WorkManifestationCopy"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:valuesFrom>
<owl:Class rdf:about="#WorkInstance"/>
</owl:valuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ProducedFrom"/>
</owl:onProperty>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#AdaptationManifestationCopy"/>
<owl:disjointWith>
<owl:Class rdf:about="#AdaptationInstanceCopy"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Class rdf:about="#Copy"/>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A copy of a WorkInstance</rdfs:comment>
</owl:Class>
<owl:Class rdf:about="#ExtendRights">
<owl:disjointWith rdf:resource="#Enlarge"/>
<rdfs:subClassOf rdf:resource="#ModifyCopy"/>
<owl:disjointWith>
<owl:Class rdf:about="#Modify"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Export"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Embed"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Delete"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#GovernedAdapt"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21 REL) This element represents the right to extend the rights which are the originally transmitted.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Extract"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Reduce"/>
</owl:Class>
<owl:Class rdf:about="#MakeWorkManifestationCopy">
<owl:disjointWith rdf:resource="#MakeWorkInstanceCopy"/>
<rdfs:subClassOf rdf:resource="#MakeCopy"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom rdf:resource="#Instantiator"/>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#MakeAdaptationInstanceCopy"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom rdf:resource="#WorkManifestationCopy"/>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making a WorkManifestationCopy</rdfs:comment>
<owl:disjointWith rdf:resource="#MakeAdaptationManifestationCopy"/>
</owl:Class>
<owl:Class rdf:about="#AdaptationInstanceCopy">
<owl:disjointWith rdf:resource="#WorkManifestationCopy"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A copy of an AdaptationInstance</rdfs:comment>
<rdfs:subClassOf>
<owl:Class rdf:about="#Copy"/>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#WorkInstanceCopy"/>
<owl:disjointWith rdf:resource="#AdaptationManifestationCopy"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:valuesFrom rdf:resource="#AdaptationInstance"/>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ProducedFrom"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#AdaptationManifestation">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#DependsOn"/>
</owl:onProperty>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:valuesFrom rdf:resource="#Adaptation"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#MakeAdaptationInstance"/>
<owl:Class rdf:about="#MakeAdaptationManifestationCopy"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>An object or event which is an expression of an Adaptation</rdfs:comment>
<owl:disjointWith rdf:resource="#WorkManifestation"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#Manifestation"/>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Extract">
<owl:disjointWith>
<owl:Class rdf:about="#Embed"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#ExtendRights"/>
<owl:disjointWith>
<owl:Class rdf:about="#Delete"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Extract represents the Right to derive a new resource by taking a fragment out of an existing resource.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Export"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Enlarge"/>
<owl:disjointWith>
<owl:Class rdf:about="#Modify"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Reduce"/>
<rdfs:subClassOf rdf:resource="#ModifyCopy"/>
<owl:disjointWith rdf:resource="#GovernedAdapt"/>
</owl:Class>
<owl:Class rdf:about="#WorkInstance">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>An object or event which is an example of an Identified Manifestation of a Work (e.g. a File)</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Instance"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Uses"/>
</owl:onProperty>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:valuesFrom rdf:resource="#WorkManifestation"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom rdf:resource="#MakeWorkInstanceCopy"/>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#AdaptationInstance"/>
</owl:Class>
<owl:Class rdf:about="#Execute">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Execute represents the right to execute a digital resource.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Uninstall"/>
</owl:disjointWith>
<rdfs:subClassOf rdf:resource="#Render"/>
<owl:disjointWith rdf:resource="#Install"/>
<owl:disjointWith>
<owl:Class rdf:about="#Play"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Print"/>
</owl:Class>
<owl:Class rdf:about="#MoveContent">
<rdfs:subClassOf>
<owl:Class rdf:about="#Action"/>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Synchronization"/>
<owl:disjointWith rdf:resource="#Distribute"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeManifestation"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#MakeInstance"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(DMP-Move) The Function by which Device A Stores Content in Device B deleting the original Content in Device A.</rdfs:comment>
<owl:disjointWith rdf:resource="#Produce"/>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith rdf:resource="#MakeCopy"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class rdf:about="#Distributor"/>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Render"/>
<owl:disjointWith rdf:resource="#PublicCommunication"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#ModifyCopy"/>
</owl:Class>
<owl:Class rdf:about="#Stream">
<rdfs:subClassOf rdf:resource="#PublicCommunication"/>
<owl:disjointWith rdf:resource="#Download"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Function of Delivering Content to a Device where the transferred Content is processed for Rendering only and not Stored</rdfs:comment>
<owl:disjointWith rdf:resource="#Broadcast"/>
</owl:Class>
<owl:Class rdf:about="#Export">
<owl:disjointWith>
<owl:Class rdf:about="#Embed"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Reduce"/>
<owl:disjointWith>
<owl:Class rdf:about="#Delete"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Enlarge"/>
<rdfs:subClassOf rdf:resource="#ModifyCopy"/>
<owl:disjointWith rdf:resource="#ExtendRights"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Function of making available a Content Item to a non-DMP DRM system. (MPEG21REL) This element represents the right to export the associated broadcast program to another rendering or storage device</rdfs:comment>
<owl:disjointWith rdf:resource="#Extract"/>
<owl:disjointWith>
<owl:Class rdf:about="#Modify"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#GovernedAdapt"/>
</owl:Class>
<owl:Class rdf:about="#Permit">
<owl:disjointWith rdf:resource="#Role"/>
<owl:disjointWith>
<owl:Class rdf:about="#Action"/>
</owl:disjointWith>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Authorisation from one RightsOwner to one or more Agents to perform one or more Actions on a given IPEntity whose owner is the rights donors.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#IPEntity"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#MakeWorkInstance">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom rdf:resource="#Creator"/>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#MakeAdaptationInstance"/>
<rdfs:subClassOf rdf:resource="#MakeInstance"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
<owl:someValuesFrom rdf:resource="#WorkInstance"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making an Instance from a Work Manifestation.</rdfs:comment>
</owl:Class>
<owl:Class rdf:about="#Action">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Agents are defined by the actions that they realize on objects and therefore the definition of an action implies the corresponding agent to realize the action.</rdfs:comment>
<owl:disjointWith rdf:resource="#Permit"/>
<owl:disjointWith>
<owl:Class rdf:about="#IPEntity"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Role"/>
</owl:Class>
<owl:Class rdf:about="#Play">
<owl:disjointWith rdf:resource="#Print"/>
<owl:disjointWith rdf:resource="#Execute"/>
<owl:disjointWith>
<owl:Class rdf:about="#Uninstall"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#Install"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Represents the Right to derive a transient and directly perceivable representation of the Resource. The Function of Rendering a Resource</rdfs:comment>
<rdfs:subClassOf rdf:resource="#Render"/>
</owl:Class>
<owl:Class rdf:about="#Manifestation">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>An object or event which is an expression of a Work.</rdfs:comment>
<owl:disjointWith rdf:resource="#Product"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#MakeInstance"/>
<owl:Class rdf:about="#MakeCopy"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Work"/>
<owl:disjointWith rdf:resource="#Adaptation"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#DependsOn"/>
</owl:onProperty>
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int"
>1</owl:cardinality>
<owl:valuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Work"/>
<owl:Class rdf:about="#Adaptation"/>
</owl:unionOf>
</owl:Class>
</owl:valuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Instance"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#IPEntity"/>
</rdfs:subClassOf>
<owl:disjointWith>
<owl:Class rdf:about="#Copy"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:about="#Delete">
<owl:disjointWith rdf:resource="#Extract"/>
<owl:disjointWith rdf:resource="#GovernedAdapt"/>
<owl:disjointWith rdf:resource="#Enlarge"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Function of erasing a Content Item Stored on a Device. (MPEG21REL) Delete represents the right to destroy a digital resource.</rdfs:comment>
<rdfs:subClassOf rdf:resource="#ModifyCopy"/>
<owl:disjointWith rdf:resource="#Export"/>
<owl:disjointWith>
<owl:Class rdf:about="#Modify"/>
</owl:disjointWith>
<owl:disjointWith>
<owl:Class rdf:about="#Embed"/>
</owl:disjointWith>
<owl:disjointWith rdf:resource="#ExtendRights"/>
<owl:disjointWith rdf:resource="#Reduce"/>
</owl:Class>
<owl:Class rdf:about="#MakeManifestation">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making a Manifestation</rdfs:comment>
<owl:disjointWith rdf:resource="#MakeCopy"/>
<owl:disjointWith rdf:resource="#PublicCommunication"/>
<owl:disjointWith rdf:resource="#Render"/>
<owl:disjointWith rdf:resource="#MoveContent"/>
<owl:disjointWith rdf:resource="#MakeInstance"/>
<rdfs:subClassOf rdf:resource="#Action"/>
<owl:disjointWith rdf:resource="#ModifyCopy"/>
<owl:disjointWith rdf:resource="#Synchronization"/>
<owl:disjointWith rdf:resource="#Distribute"/>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith rdf:resource="#Produce"/>
<owl:disjointWith>
<owl:Class rdf:about="#MakeAdaptation"/>
</owl:disjointWith>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
<owl:someValuesFrom rdf:resource="#Manifestation"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
<owl:Class rdf:about="#Copy">
<owl:disjointWith rdf:resource="#Instance"/>
<rdfs:subClassOf>
<owl:Class rdf:about="#IPEntity"/>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Adaptation"/>
<owl:disjointWith rdf:resource="#Product"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The Function by which Device A Stores Content in Device B, preserving the original Content in Device A</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Produce"/>
<owl:Class rdf:about="#Distribute"/>
<owl:Class rdf:about="#Render"/>
<owl:Class rdf:about="#PublicCommunication"/>
<owl:Class rdf:about="#ModifyCopy"/>
<owl:Class rdf:about="#MoveContent"/>
<owl:Class rdf:about="#Synchronization"/>
<owl:Class rdf:about="#MakeCopy"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Supports"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ProducedFrom"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Instance"/>
<owl:Class rdf:about="#Manifestation"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#Manifestation"/>
<owl:disjointWith rdf:resource="#Work"/>
</owl:Class>
<owl:Class rdf:about="#MakeAdaptation">
<owl:disjointWith rdf:resource="#Render"/>
<owl:disjointWith rdf:resource="#Distribute"/>
<rdfs:subClassOf rdf:resource="#Action"/>
<owl:disjointWith rdf:resource="#MakeManifestation"/>
<owl:disjointWith rdf:resource="#Synchronization"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:someValuesFrom rdf:resource="#Adaptation"/>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#ResultsIn"/>
</owl:onProperty>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#MakeInstance"/>
<owl:disjointWith rdf:resource="#CreateWork"/>
<owl:disjointWith rdf:resource="#PublicCommunication"/>
<owl:disjointWith rdf:resource="#MakeCopy"/>
<owl:disjointWith rdf:resource="#MoveContent"/>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy"/>
</owl:onProperty>
<owl:someValuesFrom rdf:resource="#Creator"/>
</owl:Restriction>
</rdfs:subClassOf>
<owl:disjointWith rdf:resource="#ModifyCopy"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>The action of making an Adaptation</rdfs:comment>
<owl:disjointWith rdf:resource="#Produce"/>
</owl:Class>
<owl:Class rdf:about="#Modify">
<owl:disjointWith rdf:resource="#Reduce"/>
<owl:disjointWith rdf:resource="#Extract"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Modify represents the Right to make and save changes to a resource without creating a new resource.</rdfs:comment>
<owl:disjointWith>
<owl:Class rdf:about="#Embed"/>
</owl:disjointWith>
<rdfs:subClassOf rdf:resource="#ModifyCopy"/>
<owl:disjointWith rdf:resource="#Delete"/>
<owl:disjointWith rdf:resource="#Enlarge"/>
<owl:disjointWith rdf:resource="#ExtendRights"/>
<owl:disjointWith rdf:resource="#GovernedAdapt"/>
<owl:disjointWith rdf:resource="#Export"/>
</owl:Class>
<owl:Class rdf:about="#Distributor">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>A User who distributes a Product including public communication</rdfs:comment>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty>
<owl:ObjectProperty rdf:about="#Can"/>
</owl:onProperty>
<owl:someValuesFrom>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Distribute"/>
<owl:Class rdf:about="#PublicCommunication"/>
</owl:unionOf>
</owl:Class>
</owl:someValuesFrom>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf rdf:resource="#Role"/>
</owl:Class>
<owl:Class rdf:about="#IPEntity">
<owl:disjointWith rdf:resource="#Action"/>
<assert:notEmpty rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>SELECT ?subject ?object
WHERE { ?subject rdfs:subClassOf ?Copy }</assert:notEmpty>
<owl:disjointWith rdf:resource="#Permit"/>
<owl:disjointWith rdf:resource="#Role"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Any identifiable product of the mind attributable to any person(s) or legal entitie(s) that can be represented or communicated physically and protectable by copyright or similar laws.</rdfs:comment>
</owl:Class>
<owl:Class rdf:about="#Embed">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Embed represents the Right to include a resource in another resource.</rdfs:comment>
<owl:disjointWith rdf:resource="#GovernedAdapt"/>
<owl:disjointWith rdf:resource="#Modify"/>
<owl:disjointWith rdf:resource="#Reduce"/>
<owl:disjointWith rdf:resource="#Export"/>
<rdfs:subClassOf rdf:resource="#ModifyCopy"/>
<owl:disjointWith rdf:resource="#Enlarge"/>
<owl:disjointWith rdf:resource="#ExtendRights"/>
<owl:disjointWith rdf:resource="#Delete"/>
<owl:disjointWith rdf:resource="#Extract"/>
</owl:Class>
<owl:Class rdf:ID="Move">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Represents the right to relocate one resource from one place to another.</rdfs:comment>
<rdfs:subClassOf rdf:resource="#MoveContent"/>
</owl:Class>
<owl:Class rdf:about="#Uninstall">
<owl:disjointWith rdf:resource="#Execute"/>
<owl:disjointWith rdf:resource="#Install"/>
<rdfs:subClassOf rdf:resource="#Render"/>
<owl:disjointWith rdf:resource="#Play"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>(MPEG21REL) Uninstall represents the right to follow the instructions provided by an uninstalling resource.</rdfs:comment>
<owl:disjointWith rdf:resource="#Print"/>
</owl:Class>
<owl:ObjectProperty rdf:about="#Uses">
<rdfs:subPropertyOf>
<owl:ObjectProperty rdf:about="#Origin"/>
</rdfs:subPropertyOf>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#Supports">
<rdfs:range rdf:resource="#Action"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Declares which actions are meaningful over an IPentity.</rdfs:comment>
<rdfs:domain rdf:resource="#IPEntity"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#DependsOn">
<rdfs:subPropertyOf>
<owl:ObjectProperty rdf:about="#Origin"/>
</rdfs:subPropertyOf>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="RightsOwner">
<rdfs:range rdf:resource="#Role"/>
<rdfs:domain rdf:resource="#IPEntity"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Defines the owner of the rights over an ip entity.</rdfs:comment>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="PermitAction">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Relation used to express the Actions that are allowed to be performed.</rdfs:comment>
<rdfs:range rdf:resource="#Action"/>
<rdfs:domain rdf:resource="#Permit"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#ResultsIn">
<rdfs:domain rdf:resource="#Action"/>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty"/>
<rdfs:range rdf:resource="#IPEntity"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Declares which IPentity arises as a result of the execution of an action. It is a functional relation (i.e. the result of an action is a single individual)</rdfs:comment>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#Can">
<rdfs:range rdf:resource="#Action"/>
<rdfs:domain rdf:resource="#Role"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Defines the actions that a role can do.</rdfs:comment>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="SubjectOfPermit">
<rdfs:domain rdf:resource="#Permit"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Relation used to express which User receives a given permit.</rdfs:comment>
<rdfs:range rdf:resource="#Role"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#ProducedFrom">
<rdfs:subPropertyOf>
<owl:ObjectProperty rdf:about="#Origin"/>
</rdfs:subPropertyOf>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="PermitIPEntity">
<rdfs:range rdf:resource="#IPEntity"/>
<rdfs:domain rdf:resource="#Permit"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Relation used to express over which IP Entity Actions can be exercised</rdfs:comment>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#Origin">
<rdfs:domain rdf:resource="#IPEntity"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Defines the original ip entity of another ip entity (or itself for Work)</rdfs:comment>
<rdfs:range rdf:resource="#IPEntity"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:about="#RightGivenBy">
<rdfs:domain rdf:resource="#Action"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Declares which role can give rights over an action</rdfs:comment>
<rdfs:range rdf:resource="#Role"/>
</owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="HasConsentOver">
<rdfs:domain rdf:resource="#Role"/>
<rdfs:range rdf:resource="#IPEntity"/>
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Determines whether a role has the consent given by the Creator over an IPEntity to perform the actions that require it.</rdfs:comment>
</owl:ObjectProperty>
<owl:DatatypeProperty rdf:about="#requiresCreatorAuthorisation">
<rdfs:domain rdf:resource="#Action"/>
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/>
</owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="isDigital">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#boolean"/>
<rdfs:domain rdf:resource="#IPEntity"/>
</owl:DatatypeProperty>
<owl:FunctionalProperty rdf:ID="SourceOfPermit">
<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>Relation used to express the User who issues the permit</rdfs:comment>
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/>
<rdfs:domain rdf:resource="#Permit"/>
<rdfs:range rdf:resource="#Role"/>
</owl:FunctionalProperty>
</rdf:RDF>
Figure 313: RRD OWL file
Annex F– Example of Content Registration
The Registration Authority uses the namespace of DMPF and the DMPF scheme defines its syntax conforming to the URN syntax with a specific purpose of Identifying Content. In order to Use Content in accordance with the DMP specification, the ContentPro company asks a Registration Agency of its choice to assign the string 123456abc to a given Content Item. The Registration Agency, which was given the subordinate namespace I100 by the Registration Authority, will use the following identifier for content Registration: urn:dmpf:I100-123456abc. The syntax of Content Identifier is based on DMPF syntax.
This scheme can also be used to support linkage to other naming schemes. For example, in order to enable support for the ISBN naming scheme (ISBN no. 12345689), the Certification Agency establishes a link between the Content Identifier mentioned above, and the ISBN number. Then, the identifier urn:dmpi:isbn-12345689 can be used.
G.1 To Be Completed By Applicant Registration Agency
|
Name of organisation
|
||
|
Address, with street, city, country
|
||
|
Principal contact in organisation Position
|
||
|
|
Telephone number
|
Fax number
|
|
Legal status of organisation |
Anticipated date of first use of sub namespace
|
|
|
|
Expected number of identifiers maintained
|
|
|
|
Expected number of identifiers issued annually
|
|
|
|
List of countries in which the organisation is represented
|
|
|
Address for correspondence/billing
|
||
|
Authorised representative Name: _________________________________ Title: _________________________________ |
||
|
(On separate sheet) Details of provisions made by the application to safeguard conformance with the DMP specification (required to ensure compliance with the Registration Agency responsibilities)
|
|
We hereby apply for the assignment of an DMP subordinate namespace, and state that the use of the sub namespace will be in accordance with the DMP specification
Signature/date
|
Please return application to: The Registration Authority
Organization
Address here
Fax:
E-mail:
G.2 To Be Completed By The Registration Authority
|
Form received on
|
Subordinate namespace |
issued on |
|
Signature/date
|
||
Annex H– List of Traditional Rights and Usages
Since the beginning of 2004 DMP has collected a large number of Traditional Rights and Usages (TRU). Document dmp0270 (http://www.dmpf.org/open/dmp0270.zip) provides the full analysis of all TRUs collected. The list below is extracted from dmp0270.
|
# |
TRU |
Description of TRU |
|
01 |
TRU to quote |
Right to reproduce limited portions of another author's work, for a variety of reasons, and in a variety of ways usually involving some attribution. Permission from the original author is not required, however exercise of the quote TRU exposes the quoting author to possible legal challenges. |
|
02 |
TRU to make personal copy |
Civil law countries legal term is «private copy», while common law countries do not handle it specifically and consider it as part of fair use prerogatives (USA), or fair dealing and other exceptions for private study or research (UK). This mechanism allows certain acts that
pertain to exclusive right of reproduction without requesting prior
authorization. |
|
03 |
TRU to space shift content |
Digital media can be accessed wherever the User is. |
|
04 |
TRU to time shift content |
The ability to access content at a different time then when it was originally made available. |
|
05 |
TRU to make playback device |
The ability to manufacture or otherwise create devices for accessing Digital media. |
|
06 |
TRU to choose playback device |
The User may choose among different devices for accessing Digital media and does not need a different device for Digital media of different types or different devices for Digital media of the same type but from different sources. |
|
07 |
TRU to use content whose copyright has expired |
Under the Berne Convention, the minimum duration for copyright protection is the life of the author plus 50 years (Art. 7(1)). Signatory nations may provide longer durations if they so choose. The copyright law causes all copyrighted works which have reached the end of their term of copyright protection to fall into the Public Domain. Public Domain means that the creator of the work has given up or lost all rights to the work. It means that users may do anything with the work – read it, copy it, publish it, change it. |
|
08 |
TRU to communicate privately |
The power of an individual to decide who amongst a group of persons will be the recipient of his/her ideas, thoughts and emotions. |
|
09 |
TRU to publish content anonymously |
To publish content without revealing the identity of the publisher |
|
10 |
TRU to use content anonymously |
To use content without revealing the identity of the user |
|
11 |
TRU of attribution |
Defined narrowly for DMP process as the right to assert authorship of media for which a source is not given (or an incorrect source is given), in other words the right to demonstrate that one's name should be attached to an uncredited (or miscredited) work as that work's creator. The term is used elsewhere as largely synonymous with TRU to be recognized as the author (paternity). |
|
12 |
TRU of anonymity |
Privacy involves three basic aspects: · Autonomy: the capacity of members of society to function as individuals, uncoerced and with privacy. · Intrusion: one should be free from government surveillance with a reasonable expectation of privacy. · Informational privacy: individuals have the right to limit their personal domain by denying access of their personal information to others, or to limit how much personal information they are obligated to give to others. |
|
13 |
TRU to annotate for personal use |
The traditional right to augment media with additional information for personal use. The result could be regarded as a limited form of derivative work. However, whilst the publication of derivative works is typically restricted by copyright, end-users have not traditionally been restricted from making annotations for personal use. |
|
14 |
TRU to edit for personal use |
The ability to edit digital media for one’s personal use The User may edit, reorganize, mix or transform the Digital media as the User chooses as long as the User does not (re)distribute the edited results. |
|
15 |
TRU not to be counterfeited |
An editor/publisher of a collection of excerpts, some from the public domain and some copyright-protected, so the collection enjoys a new Middleman's copyright protection. Or a distributor of Rolex watches who inherits some of Rolex's right not to compete against illegal imitations. |
|
16 |
TRU that sales displays will follow acceptable practice |
The relationship between a distributor and a retail outlet. For example, expecting that stores will not make false claims about a product and will not improperly reproduce trade and service marks, as in a retail store clerk who might use magic markers to make a huge sign containing misspellings/misrepresentations or using completely wrong colors for a logo. |
|
17 |
TRU to be ignorant of usage |
The exchange of information and physical goods between people (e.g. Rights holders and End-users) who are separated by space and time is enabled by an infrastructure to store (time-shift) and forward (space-shift). Acting as middlemen, the providers of the infrastructure and the technology to exchange information and physical goods enjoy the TRU to be ignorant of the usage of their services. |
|
18 |
TRU to apply a rating to a piece of content |
An individual, organization, industry or government can apply a rating on some applicable scale to digital media |
|
19 |
TRU of continued access |
"As human beings, we benefit greatly from the works of others. Artists, thinkers, scholars, and performers create works that we all enjoy, learn from, and are inspired by."[...] "With ever changing technology, in order to preserve many works we will need to constantly move them ahead, copying them to each new media form before the previous one becomes obsolete. Also, as we create new media, we need to preserve the knowledge of the methods of converting from one media to another, so we can still access the old works that have not yet been moved ahead. This is crucial. Without this information, even preserved works could be unreadable." |
|
20 |
TRU of political freedom |
Some free speech rights mingle with fair use thinking to form a context for open communication, often greatly to the benefit of society as a whole as well as most, if not all of the individual players in a given digital media chain, from creators all the way to consumers. This generally includes the right to pursue some sort of business or commerce, to pass or influence legislation, to form licenses or agreements, and to generally strive to improve society for altruistic reasons. |
|
21 |
TRU of freedom of art |
"Along with science, research, and
teaching, art is free. The freedom guaranteed covers the artistic creation as
regards both the work produced and the effect produced by it." |
|
22 |
TRU to be recognized as the author (paternity) |
Right of the creator of a literary or artistic work to claim authorship or otherwise assert personal credit for the work's creation. |
|
23 |
TRU not to be miscredited as the author (misattribution) |
Defined narrowly for DMP process as the right to assert non-authorship of media for which one is given as the source, in other words the right to demonstrate that one's name should be removed from the credit for a work that one did not create. The term is used elsewhere as closely related to TRU to be recognized as the author (paternity). |
|
24 |
TRU for the author's work not to be tampered with (integrity) |
Right for the creator of a literary or artistic work to object to unreasonable modifications that distort or mutilate the work or otherwise present their work in a manner harmful to their reputation. |
|
25 |
TRU of "First sale"/Personal loan |
After the initial purchase, the purchased digital media may be disposed of in any way the purchaser chooses. Examples are, re-selling, loaning, giving away. |
|
26 |
TRU to transcode |
The ability of an individual to convert (readable, audible, visible,...) content from one media format to another media format. |
|
27 |
TRU to make prohibited content inaccessible |
The ability to identify content not meeting standards of acceptance in a given region/local and to disable its distribution and/or access. |
|
28 |
TRU to time based advertising |
The ability to include periodic advertisements during digital media access. |
|
29 |
TRU to digital media rental |
Selling access to digital media on a time limited basis. |
|
30 |
TRU to freedom from monitoring |
The traditional right to use personal property without any reference to another authority. The freedom not to be observed whilst doing so, or to have one's usage recorded or tracked. |
|
31 |
TRU of reverse engineering |
Reverse engineering means "the process of extracting know-how or knowledge from a human-made artifact". [...] "Human-made artifacts refers to objects that embody knowledge or know-how previously discovered by other people. Hence, the engineering required to uncover the knowledge is reverse engineering". [1] |
|
32 |
TRU of withdrawal/objection |
Moral right under several legal systems to either withdraw a published work from publication, requiring remuneration for Middlemen economically hurt by this, as well as the right to assert that a published work no longer reflects the creator's current views. |
|
33 |
TRU of fair use |
Fair Use is an important limitation on an author's or copyright holder's exclusive reproduction rights. Fair uses of content traditionally include such activities as copies for scholarship, research, news reporting, comment, criticism, and parody. |
|
34 |
TRU of reproduction |
Broad right to exclude others from copying protected material (unless authorised to do so), implemented with many national variations, generally including listed exceptions |
|
35 |
TRU of economic exploitation |
A creator's right to receive economic benefit from their intellectual product normally comprising a predictable distribution chain such that uses outside of that might be considered fair use; for movies a conventional media exploitation chronology supposes theatrical release followed by tape/optical media sales followed by pay TV then cable premium channels and then broadcast television |
|
36 |
TRU of distribution |
Generally used to describe the circulation of "fixated" copies, including many contractual arrangements; like TRU reproduction, distribution is often identified by exceptions to the Right-holders ability to exclude, however distribution also often applies to new technologies or usage patterns, also including TRU lending and TRU rental. |
|
37 |
TRU of contractual commerce |
A broad right pertaining to TRU political freedom because the ability to do commerce requires a degree of social stability for financial transactions governed by agreements to succeed; the right to pursue commerce including contracts -- the fixation of mutal agreements -- is legislatively governed by a myriad of large-to-small commercial laws |
|
38 |
TRU of reciprocal protection |
Reciprocal protection is a complex exchange based on a value-expression permitting complementary but not identical performance. Between nations, reciprocal protection often means treating authors from foreign countries the same way a country would normally treat its own nationals. The neighboring rights of performers might also be handled under reciprocal administration agreements between collecting societies. In principle, reciprocal agreements and exchanges (between private or corporate parties) should be digitally supported by DMP |
|
39 |
TRU of respect for sale royalties terms and conditions |
Part of the trio covering what users and consumers are bound by - in terms, conditions and legal liability - when transactions are made by sale, performance or resale. In this case of sale, for example, first sale doctrine in the U.S. exhausts the distribution right, but this does not necessarily carry over to digital (and it certainly does not apply in many other countries). Even when rights exist, contractual agreements often cut across those rights. Electronic sales should be able to come with a variety of very interesting terms and conditions indeed, some of them allowing free use, and/or use conditioned by the context of a marketing promotion. |
|
40 |
TRU of respect for performance royalties terms and conditions |
Part of the trio covering what users and consumers are bound by - in terms, conditions and legal liability - when transactions are made by sale, performance or resale. In this case of performance, it is extremely likely that the user or consumer has absolutely no idea as to what the legal doctrine of "performance" is, how it applies to them or how revenues are shared between collective management societies, publishers, songwriters and artists (recording "covers"). |
|
41 |
TRU of respect for resale royalties terms and conditions |
Part of the trio covering what users and consumers are bound by - in terms, conditions and legal liability - when transactions are made by sale, performance or resale. In this case of resale, actual instances are rare and normally confined to French droit de suite legislation or else transactions of fine art that have dramatically increased in value, to which some countries hold an artist entitled to a small percent of the sales price. |
|
42 |
TRU of equitable remuneration |
The right of equitable remuneration is generally invoked during a legislative taking of reproduction/distribution control away from a creator under a compulsory license such that the legislatively set compensation, normally managed by a collecting society, is termed "equitable remuneration" for the value of the work's use |
|
43 |
TRU of reputation |
Rights of reputation include an author's economic rights not to have their work presented in a manner harmful to their future sales, a celebrity's right not to have their physical image misused to create a false appearance of endorsement, and a moral right not to have works subjected to derogatory treatment. |
|
44 |
TRU of reasonable modification |
A traditional Middle-man's right in some national legislation, allowing publishers to take unobjectionable liberties in altering writer's manuscripts for publication. |
|
45 |
TRU of first publication/disclosure |
Right for the creator to control the manner in which their work is initially released or divulged to the public, including economic rights as well as a moral right recognised under several legal systems. |
|
46 |
TRU of parody |
A caricaturish and usually humorous form of criticism involving mocking or imitation often in outlandish style, generally incorporating direct references or reproductions of elements from some other work being mocked |
|
47 |
TRU of factual reporting |
News journalists enjoy a general liberty to state facts in their columns, and news photographers are able to run sufficiently newsworthy pictures without extensive rights clearing and licensing. |
|
48 |
TRU to restrict access to unpublished material |
A fundamental and traditional right of authors to create without the public having the right to see what they are working on while it is in the process of being created; poses interesting challenges when drafts are circulated to a limited group such as editors or first readers |
|
49 |
TRU of lending |
The (restrictive) lending right is retained by the author as a form of TRU distribution requiring permission, applying obviously to libraries but also potentially to digital transfer rights; this TRU only applies to some nations |
|
50 |
TRU of translation |
Translation rights are initially retained by the author but over time permit various developing nation uses, fair uses, and potential compulsory licensing and/or equitable remuneration so that published works can be consumed in other languages besides those that have been duly authorised; translators acquire a copyright in their translations but not to the prejudice of prior copyrights in the material that was translated |
|
51 |
TRU of regional pricing |
Authorisation to determine regional pricing schemes has commonly been delegated by creators and also Middle-Men to regional distributors by contractual agreement, however this long-term practice for physical goods is threatened by digital distribution over the Internet |
|
52 |
TRU of unpublished recording |
This TRU springs from the ability to use recording equipment to capture real events and people regardless of whether one has permission or licenses. A certain amount of leeway is traditional, and social policy has long tried to balance the usefulness of audio/visual/audiovisual capture devices with the vulnerability of copyrighted materials, possible invasions of privacy and any other potential dangers posed by allowing recording equipment to be freely sold and owned. The solution has normally been to either forbid the presence of cameras and recording equipment or else to forbid images or audio recordings being widely circulated or else used for profit (unless written permission is obtained). In other words, as long as newly recorded media remains unpublished, it may be owned and shown to family and friends. |
|
53 |
TRU of developing nations exception |
Developing nations (as defined by treaty) enjoy relatively lax standards of copyright protection to enable socially valuable uses in countries that qualify as relatively underfunded participants in the global economy |
|
54 |
TRU of copying for classroom instruction |
Classroom instruction enjoys wide liberties in the use of materials to convey educational information to students (this does not extend to distance learning or the sale of commercial educational products). |
|
55 |
TRU to access content in libraries |
The ability to access content in libraries when it is available. |
|
56 |
TRU of authenticity of content guaranteed |
The longer and the more populated by unknown middlemen is the value-chain between the creator and the end-user and the less means the end-user has to know that the particular piece of content is indeed authentical. |
|
57 |
TRU to choose the service |
To use services independently of the service provider |
|
58 |
TRU to choose the delivery system |
To use services independently of the connectivity provider |
|
59 |
TRU of moral rights |
A collection of rights distinguished from authors' economic rights under several legal systems, pertaining to the fundamental relationship between a creator and the literary and artistic works they have created, primarily including the rights of paternity and integrity. |
|
60 |
TRU of rental |
The (restrictive) rental right is retained by the author as a form of TRU distribution requiring permission, applying to commercial transactions; usually carried out including stated and implied licenses with the end-user; this TRU only applies to some nations |
|
61 |
TRU of communication to the public |
appears in the WCT/WPPT (WIPO Copyright Treaty and WIPO Performances and Phonograms Treaty) as an Internet-friendly way to give authors protection for Internet-based "performances" or data transfers by wire or wirelessly to individuals consuming the data at a time of their own choosing, related to TRU to technological access restrictions and TRU reproduction |
|
62 |
TRU of applying technological access restrictions |
Granted under WCT/WPPT (WIPO Copyright Treaty and WIPO Performances and Phonograms Treaty) giving authors regional protection against tampering devices or software that are designed to defeat content security technology, also prohibits tampering with rights management information, related to TRU communication to the public and TRU reproduction |
|
63 |
TRU to distribute lower-resolution copies only |
A primitive usage of the audio and audiovisual analogue industries in which master audio recordings, or film or video masters exist in a higher analogue resolution, or even higher digital resolution, with greater quality of 'signal' than copies released to the public; significant mainly as having affected the analogue past of TRU reproduction thus conditioning economic aspects within which Middle-men tried to "game" the system |
|
64 |
TRU to compel real-time only consumption |
Primitive analogue ability to perform written or composed creations in real-time only at a performance venue; significant mainly as having affected the analogue past of TRU reproduction thus conditioning economic aspects within which Middle-men tried to "game" the system |
|
65 |
TRU to restrict place of use |
Creator's right to specify place restrictions on where their creations are to be consumed, for example a restriction could apply authorising only built-to-spec kiosks; significant mainly as having affected the analogue past of TRU reproduction thus conditioning economic aspects within which Middle-men tried to "game" the system |
|
66 |
TRU to restrict time of use |
Creator's right to specify time restrictions on when their creations are to be consumed, for example a restriction could apply authorising only late-night performance of material unsuitable for minors or for example Christmas songs that sell only during that holiday season; significant mainly as having affected the analogue past of TRU reproduction thus conditioning economic aspects within which Middle-men tried to "game" the system |
|
67 |
TRU to make content creation device |
The ability to manufacture or otherwise create devices for creating content for Digital media. |
|
68 |
TRU to assign content description |
To relate content to descriptions that support some degree of interpretation of the content's meaning. |
|
69 |
TRU to access content of one's choice |
Traditionally users have enjoyed the possibility to access any type of content that was available (books, cassettes, broadcast transmissions) |
|
70 |
TRU to run applications of one's choice |
Traditionally users have enjoyed the possibility to run any types of application that was available on their PCs |
|
71 |
TRU to attach playback devices of one's choice to a network |
Traditionally users have enjoyed the possibility to attach any device to the telephone network that did not damage it |
|
72 |
TRU to access information about content |
Traditionally users have enjoyed the possibility to find descriptions of available content to guide their purchasing/viewing/listening/educational decisions |
|
73 |
TRU to share content with members of a group |
Sharing content with members of a group is distinct from sharing content via a public performance.This TRU is typically enjoyed in the private domain, where the group comprises people with whom the licensee of the content has some acquaintance, either through long-standing friendships, familial relationships or even as mere passing strangers.Traditionally, people rarely share their content, in the context of a private rendering of that work, with an anonymous group of total strangers. Some sharing is serial, in that the work is passed from the first purchaser of the content, to other people, once the first purchaser has finished with it. Other content sharing with members of a group is concurrent, where all members of the group witness a single rendering of the work simultaneously. · Some types of content are typically for personal consumption (a book) – this is an example of serial sharing, where the book can only be read by a single person at a time and is passed to other readers, either when the first reader has finished, or chapter-by-chapter, between a husband and wife, for example.The book can be gifted or sold, with no infringement of the author’s copyrights. · Others are typically shared (newspapers, magazines) – publishers of these works factor in the number of people that will typically consume a single copy into their business models, applying a multiplier to any sales of advertising impressions, for example.Newspapers and magazines are often supported entirely by advertising revenues. The marginal production cost of the additional impressions of an ad attributable to second and subsequent readers is precisely zero, since no additional copies of the ad have to be printed to make an impression, whereas the advertiser has accepted each copy to represent some multiple of impressions, agreed by reference to audited readership survey data.So there is economic advantage to the publisher of the magazine or newspaper in having the content shared. · Some are typically enjoyed in a group (a movie, a broadcast) – we like to gather in groups and watch things together, for the companionship of shared experience, to bond socially and to perhaps stimulate debate about the issues raised, after the movie or broadcast has finished.Sharing content with members of a group concurrently plays an important part in creating and maintaining social relationships. · Some have both personal and group-wise consumption modalities (music) – sometimes we listen to music to facilitate the euphoria of solitude, at other times to study it in concentrated detail, still other times as background sonic wallpaper to our daily activities and yet others as a group social event. Sometimes a member of the group, as the author of that work, owns the content that is shared, but often the content’s author is a third party. |
|
74 |
TRU to improve end-user experience |
The ability of an individual to create content and services that are expected to be of value to the end-user |
|
75 |
TRU to choose security |
To choose a system on which enough trust can be put to use it together with sensitive information |
|
76 |
TRU to restrict adaptation |
This is traditionally referred to as the right of adaptation and vests control in the creator over other's use of their work to create derivative works based on the original; in the event unauthorised adaptations are made, their copyright exists "without prejudice to the copyright in the original work" |
|
77 |
TRU to restrict performance |
This is traditionally referred to as the right of performance and vests control in the Author over other's use of their work to create performances, recordings or broadcasts bringing the original composition "to life"; there is a tension between this TRU controlling what may be done with works and the TRU |
|
78 |
TRU contracting for middle-men to broadcast |
Authors and other creators of media periodically need the distribution services provided by Middle-men who can arrange for the creator's media to be broadcast. |
|
79 |
TRU contracting for middle-men to publish |
Authors and other creators of media periodically need the distribution services provided by Middle-men who can arrange for the creator's media to be published. |
|
80 |
TRU contracting for middle-men to release |
Authors and other creators of media periodically need the distribution services provided by Middle-men who can arrange for the creator's media to be released. |
|
81 |
TRU contracting for middle-men to promote |
Authors and other creators of media -- as well as many Middle-men who might themselves already be media distributors -- periodically need the distribution-related services provided by Middle-men who can arrange for the creator's media to be promoted. Making known to potential users the existence of valuable content is a very important function that can typically not be performed by the creator. Content promotion to different users (particularly end-users) is regularly entrusted to middle-men (or, if within the same company, to another department in the same company). |
|
82 |
TRU of adaptation |
In opposition to the traditional creator's TRU to restrict adaptation, this TRU refers to the common tendency to create adaptations and derivative works regardless of whether these are legally authorised; creators of adaptations acquire a copyright in their adaptations but not to the prejudice of prior copyrights in the material that was adaptated |
|
83 |
TRU of performance |
In opposition to the traditional creator's TRU to restrict performance, this TRU refers to the common tendency to stage or broadcast performances of works regardless of whether these are legally authorised; performers acquire a copyright in their performances but not to the prejudice of prior copyrights in the material being performed |
|
84 |
TRU not to apply DRM to a piece of content |
These days, almost every word we write is automatically protected by copyright but this does not mean that we want or need it all automatically protected by DRM. There should be no technical or legal requirement to apply DRM to content if the rights holder does not wish it. |
|
85 |
TRU to syndication |
Through syndication a rights holder can simultaneously make his content available to several channels |
|
86 |
TRU to choose mode of economic compensation |
Choice of form of compensation to rights holders (creators, performers and interpreters) for consumption of content by end users.The right for anyone to use their original works or products as a token of exchange as in barter or alternate currency models. |
|
87 |
TRU to determine context of use |
Due to the moral rights attributed to authors over their content in a considerable number of legal jurisdictions (i.e. European continental Author Rights legislation), authors may invoke limitations of use or access to their content on the basis of context. |
|
88 |
TRU to make a print of a video scene (repurposing) |
Equipment has existed for a long time that enables an end-user to print a snap shot or screen capture from a TV program |
[1] In the case the target of the request is a specific Content Element (e.g. a Resource) part of the Content Item, the MimeType element shall contain the specific Resource Mime Type of that Resource.
[2] In the case the target of the request was a Content Element within a Content Item, the response may contain several ContentURL elements in the case the didl-msaf:Item representing the requested Content Element contains different types of information. As an example, the figure below shows a possible response obtained in the case a specific Resource to which streaming metadata is associated was requested:
[3] The reader is warned that in this document the word “represent A” means that A (typically an analogue entity) is represented in bits. Therefore no claim can be made in general that the representation of A is fully equivalent to A