The Digital Media Project  

Source

L. Chiariglione

Date

2004/02/20

Title

The DMP work plan

No.

0035/Heidelberg

 

The DMP work plan

 Disclaimer: This is the first draft of the DMP work plan developed at the first DMP meeting. It is likely to undergo several revisions before reaching stability and completeness.

 1. Introduction

The Digital Media Manifesto (DMM) was motivated by the realisation that while great digital technologies exist their application to media leads to results that are satisfactory to all value-chain users in a reduced number of cases, particularly those in which digital technologies are used a simple replacement of the corresponding analogue technologies.

Other usages of digital technologies are problematic because users can do things that were not possible or difficult or cumbersome with analogue technologies. While these limitations were the enabling factors of many value-chain businesses, some of the possibilities offered by digital technologies can be a cause of considerable economic harm for those businesses. Very often for these new things there is no law, regulation or court case that can guide those who want to exploit the new opportunities. If there are, application may be itself a matter of contention.

This situation is the main cause of what the DMM calls the “digital media stalemate”: the existence of great opportunities to many value-chain users and the virtual impossibility to exploit many of them. The DMM identifies seven major actions that must be undertaken to unleash the potential of digital media technologies.

The Digital Media Project (DMP) is an international organisation set up with the purpose of executing the actions advocated by the DMM.

The first DMP action addresses the issue of what users can and may do. Some users take the attitude that things that were allowed in the analogue domain should continue to be allowed in the digital domain as well. Others take the attitude that what can be done in the digital domain is “new” and therefore should be rediscussed. The DMP take neither and both of these attitudes at the same time Instead it utilises the process described in the following paragraph.

2. The seven-step DMP process

The process is described here because a large part of the DMP work plan is an implementation of the process.

  1. The DMP concentrates on what users have traditionally done. The reason is that if users have done certain things in the past it means that, at least in the analogue domain, there was a demand for that thing. So the first DMP step is to make a full “census” of what the DMP calls “Traditional Rights and Usages (TRU) of media users”.
    Note that by doing so the DMP does not claim that because a TRU existed in the past as a, say, legally endorsed right, it should continue to be endorsed in the digital domain as well. It simply says that some value-chain users used to have an interest in that TRU in an analogue domain and that there is a “prima facie” evidence that the same TRU should also be of interest in the digital domain.
    Digital Rights Management (DRM) is the technology already identified by the DMM that should enable a “controlled” exercise of some of those TRUs. Note that the way “control” will be implemented is not an issue at this stage of the process but will be considered later.
  2. The second step is to use the full set of TRUs to develop requirements (RQ) to be used in the design of what the DMM calls “Interoperable DRM Platform” (IDP). The “design” is embodied in Technical Specifications (TS).
    Note that a definition of “DRM Platform” is: A framework that enables management of user rights and protection of content under a variety of business models for content usage. The qualification “Interoperable” is added here because the platform should be designed to expose interfaces with known specifications that value-chain users can technically access.
    Even though technically part of IDP, the DMM has singled out “Interoperable End-user Devices” (IED) as critical elements. Here, too, the qualification “Interoperable” is added because IEDs should expose interfaces with known specifications so that they can be connected to the IDP.
    In order to make sure that all TRUs are indeed considered and therefore all relevant RQs are derived, the DMP process foresees the consideration of a number of Digital Media Business Models (DMBM). A DMBM can be considered as a set of TRUs that value-chain users have traditionally assembled in order to implement their business ideas. However, new DMBM can also make use of Digital Enabled Usages (DEU), i.e. usages that were either not possible or not considered in the analogue domains. DEUs considered acceptable will therefore be used to develop further RQs.
  3. The RQs developed in step 2. are used to develop IDP and IED TSs. The TSs will specify the interfaces of IDP and IED. It is expected that the meaning of TS in the DMP context will be somehow different from other Information and Communication Technologies (ICT) TSs. In any case IDP and IED TSs should concentrate on high-level protocols related to DRM functionality, without being prescriptive on, say, media-coding and Operating Systems, with the exception of possible parts that impact the DRM functionality. On the other hand they will have to be sufficiently specific that interoperability as advocated by DMP will be ensured.
  4. As mentioned above there is currently considerable disagreement on which TRUs should be supported in the digital domain and, if supported, to what extent they should be supported. While a DMP conforming IDP or IED should support the technical exercise of the TRUs, on the ground that there are DMBMs that require a possibly “controlled” exercise of some of those TRUs, actually deployed IDP or IEDs are likely not to allow the exercise of some of them. Therefore the DMP expects individual jurisdictions to determine which TRUs shall be mandatorily supported in IDPs and IEDs operating under their jurisdiction and which TRUs shall be left to individual negotiations. The DMP should then produce a set of Recommended Actions (RA) including a compendium of how TRUs have been converted into technically exploitable features of IDP and IED.
  5. As implied by the process described above, IDP and IED will be used to implement a variety of DMBMs. The specifications will then be used to develop RQs on the use of IDP and IED in a finite set of DMBMs.
  6. The RQs will be used to develop Recommended Practices (RP) for End-to-End Conformance (EEC).
  7. Value-chain users may wish to reference which EEC RP clauses should be referenced in their business agreements.

 3. 4. The DMP Work Items

The DMP will produce different types of Approved Documents (AD)

The DMM identifies policy actions such as Phasing out Analogues Legacies (PAL), Deployment of Broadband Access (DBA) and Development of and Access to Standards (DAS). The DMP will produce RAs on these actions as well.

In addition to the IDP and IED TSs above the DMP intends to address objectives within a shorter time frame, because there are some urgent market needs and there is expectation that some IEDs will have looser connections with the rest of the IDP. These IEDs, called IED-s must fit in the full IED (IED-f) TSs, possibly as reduced-functionality profiles. These TSs should also include the necessary conformance RPs. 

WI

Output

Object

Development tools

Acr-onym

Begin

End

#WD

1.

RA

Traditional Rights and Usages

RQs & CfC

TRU

04/02

05/04

3

2.

RA

Phasing out Analogue Legacies

CfC

PAL

04/10

05/10

2

3.

RA

Deployment of Broadband Access

CfC

DBA

04/04

05/04

2

4.

RA

Development of and Access to Standards

CfC

DAS

04/02

05/04

2

5.

TS

Interoperable DRM Platform

RQs & CfP

IDP

04/07

05/10

3

6.

TS

Interoperable End-user Devices (short)

RQs & CfP

IED-s

04/04

05/04

2

7.

TS

Interoperable End-user Devices (full)

RQs & CfP

IED-f

04/07

05/10

3

8.

RP

End-to-End Conformance

IDP & IED-f TSs

EEC

05/04

06/07

3

 4. The DMP Timeline 


WI

GA#

GA01

GA02

GA03

GA04

GA05

GA06

GA07

GA08

GA09

GA10

GA11

date

04/02

04/04

04/07

04/10

05/01

05/04

05/07

05/10

06/01

06/04

06/07

1

TRU

RQ

CfC

WD1

WD2

WD3

RA

 

 

 

 

 

2

PAL

-

-

-

RQ

CfC

WD1

WD2

RA

 

 

 

3

DBA

-

RQ

CfC

WD1

WD2

RA

 

 

 

 

 

4

DAS

-

RQ

CfC

WD1

WD2

RA

 

 

 

 

 

5

IDP

-

-

RQ

CfP

WD1

WD2

WD3

TS

 

 

 

6

IED-s

-

RQ

CfP

WD1

WD2

TS

 

 

 

 

 

7

IED-f

-

-

RQ

CfP

WD1

WD2

WD3

TS

 

 

 

8

EEC

-

-

-

-

-

RQ

CfP

WD1

WD2

WD3

RP

 5. Interdependencies

 6. Acronyms

CfC:

 

Call for Contributions

CfP:

 

Call for Proposals

RQ:

 

Requirements

RA:

 

Recommended Actions

RP:

 

Recommended Practices

TS:

 

Technical Specification

WD

 

 Working Draft