international organisation for … · web viewthis section is meant to summarize the validation...

ISO/IEC CD 21000-8

INTERNATIONAL ORGANISATION FOR STANDARDISATIONORGANISATION INTERNATIONALE DE NORMALISATION

ISO/IEC JTC1/SC29/WG11CODING OF MOVING PICTURES AND AUDIO

ISO/IEC JTC1/SC29/WG11

MPEG03/N6470March 2004

Title: Text of ISO/IEC 21000-8 CD MPEG-21 Reference Software Status: approvedEditors: Frederik De Keukelaere, Gerrard Drury, Christian Timmerer, Xin Wang

Warning

This document is not an ISO International Standard. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an International Standard.

Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.

ISO/IEC CD 21000-8

Copyright notice

This ISO document is a working draft or committee draft and is copyright-protected by ISO. While the reproduction of working drafts or committee drafts in any form for use by participants in the ISO standards development process is permitted without prior permission from ISO, neither this document nor any extract from it may be reproduced, stored or transmitted in any form for any other purpose without prior written permission from ISO.

Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or to ISO's member body in the country of the requester:

[Indicate the full address, telephone number, fax number, telex number, and electronic mail address, as appropriate, of the Copyright Manger of the ISO member body responsible for the secretariat of the TC or SC within the framework of which the working document has been prepared.]

Reproduction for sales purposes may be subject to royalty payments or a licensing agreement.

Violators may be prosecuted.

ISO/IEC CD 21000-8

Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.

ISO/IEC 21000-8 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information Technology, Subcommittee SC 29, Coding of Audio, Picture, Multimedia and Hypermedia Information.

ISO/IEC 21000 consists of the following parts, under the general title Information technology — Multimedia framework (MPEG-21):

Part 8: Reference Software

Part [n]:

Part [n+1]:

3

ISO/IEC CD 21000-8

Information technology — Multimedia framework (MPEG-21) — Part 8: Reference Software

1 Introduction

Editors notes: revise introduction to describe that the reference software includes software modules corresponding to individual MPEG-21 parts and integrated software

The current reference software supports ISO/IEC 21000:2, or Digital Item Declarations in terms of reading the XML document and offering a Digital Item Declaration (DID) parser, which validates incoming DIDs against ISO/IEC 21000-2. This means: validating incoming DIDs against

the DIDL Schema that is defined within ISO/IEC 21000-2, and the additional validation rules that are defined within ISO/IEC 21000-2.

2 Reference Software availabilityThe reference software is available from www.titr.uow.edu.au/mpeg using the current MPEG username and password combination.

3 Software for Individual Parts3.1 DID

This clause describes a description of the MPEG-21 DID parser that was submitted as reference software by Multimedia Lab-Ghent University. This reference software contains Java source code for parsing and validating MPEG-21 Digital Item Declarations against the MPEG-21 DID Extensions AMD1 specification. More specifically, the DID parsers checks whether an incoming DID document is valid against the MPEG-21 DID Schema; it also checks whether all validation rules that are defined within the MPEG-21 DID specification are fulfilled.

The DID reference software consists of a number of independent modules, running on J2SE 1.4.2 or greater Apache XercesJ 2.5.0 (http://xml.apache.org/xerces2-j/) Apache Jakarta Log4J 1.2.6+ (http://jakarta.apache.org/log4j/)

Note: The source code of the DID parser is commented using standard JavaDoc. All JavaDocs are included in the reference software, and can be found in the “doc” directory.

3.2 REL

3.2.1 Schema checker

Description: The schema checker validates a set of REL Licenses against the XML Schemas specified in the Licenses. It validates syntactically the REL Licenses files and/or the REL Licenses contained in the directory specified by the user.

Input:

o A list of licenses and/or directories that contain licenses

Output:

1

http://www.titr.uow.edu.au/mpeg

ISO/IEC CD 21000-8o valid, not valid, reasons why, according to the XML schemas specified within the

licenses

Architecture:

3.2.2 REL License Validation rules checker

Description: The Validation Rules checker validates if an schema valid REL license is a valid REL License according to the MPEG-21 REL standard specification. A license will be REL syntactic conformant if it complies all the rules specified in document (m10001).

Input: o schema valid license

Output:o REL syntactic conformant or not, reasons why

Architecture:

3.2.3 Authorization request validation rules checker

Description: The authorization request validation rules checker checks if an authorization request is valid according to the MPEG-21 REL standard specification. An authorization request is syntactic conformant if it complies all the rules specified in document (m10290).

Input: o Schema valid authorization request

2

ISO/IEC CD 21000-8 Output:

o Validation rule conformant or not, reasons why Architecture:

3.2.4Interpretation conformance

Description: The Interpretation Conformance checks if the Authorization Story is an Authorization Proof for the Authorization Request. This module implements the auhtorizaiton proof algorithm and if the authorizer is present and has an authorization story, the authorization request and story files must be generated and will be the input to the

Input: o Any valid authorization requesto Any valid authorization story

Output: o Authorization story IS/IS NOT authorization proof for the authorization request

Architecture:

3

ISO/IEC CD 21000-8

3.3 RDD

3.3.1 RDD database query

Input:o A Term

Output: o The genealogy as a Vector of relationships o The IsTypeOf hierarchy of the Term as a tree

Software Details: o Language: Java o Platform: Any Java 1.4.1 platform; any JDBC database (or the included

standalone database) Delivery Plan:

o Initial version was uploaded to the MPEG-21 Reference Software site, July 2003o Updated version with API provided in October 2003

Status: o Completeo A new version that supports integration with REL has been uploaded to the

MPEG-21 Reference Software site, November 2003.

3.4 DIA

In order to allow building application on top of the MPEG-21 DIA references software an API should be provided. In particular, the API shall exercise/represent all normative features specified in the ISO/IEC 21000-7 specification. The structure of this API is shown in Table 1.

The API provides access to information in the DIA description tools (e.g.: getAvailableBandwidth) as well as methods for their normative processes (e.g.: BintoBSD or gBSDtoBin).

Table 1 — Common structure of MPEG-21 DIA API

Java package name Description

org.iso.mpeg.mpeg21.dia Defines the API of the DIA root elements.

org.iso.mpeg.mpeg21.dia.ued Defines the API to the Usage Environment Description tool.

org.iso.mpeg.mpeg21.dia.ued.uc Defines the API to the User Characteristics

org.iso.mpeg.mpeg21.dia.ued.tc Defines the API to the Terminal Characteristics tool.

org.iso.mpeg.mpeg21.dia.ued.nc Defines the API to the Network Characteristics tool.

org.iso.mpeg.mpeg21.dia.ued.nec Defines the API to the Natural Environment Characteristics tool.

org.iso.mpeg.mpeg21.dia.bsdl Defines the API to the BSDtoBin and BintoBSD processes.

org.iso.mpeg.mpeg21.dia.gbsd Defines the API to the gBSDtoBin process.

org.iso.mpeg.mpeg21.dia.aqos Defines the API to the AdaptationQoS tool.

org.iso.mpeg.mpeg21.dia.bsdlink Defines the API to the BSDLink tool.

org.iso.mpeg.mpeg21.dia.mda Defines the API to the MetadataAdaptation tool.

4

ISO/IEC CD 21000-8org.iso.mpeg.mpeg21.dia.sm Defines the API to the Session Mobility tool.

org.iso.mpeg.mpeg21.dia.diac Defines the API to the DIA Configuration tool.

3.5 File format

No software yet in this section.

3.6 DIP

DIP Reference Software comprises

reference implementations of DIBOs

reference implementation of DIME

DIML (ECMAScript) bindings for DIBOs

Java bindings for DIBOs

Calling of Java based DIxOs from DIMs

Applications supporting DIP can be built on top of the DIP Reference Softwrae utilizing APIs in the following Java packages

Java package name Description

org.iso.mpeg.refsw.mpeg21.dip Package containing all the MPEG-21 DIP reference software.

org.iso.mpeg.refsw.mpeg21.dip.dibo Package containing reference implementations of DIBOs.

org.iso.mpeg.refsw.mpeg21.dip.dime Package containing reference implementation of DIM Engine.

org.iso.mpeg.refsw.mpeg21.dip.dime.dibo Package containing classes for binding DIBO implementations to DIML (ECMAScript) API.

4 Integrated SoftwareNote: this clause depends on the definition of MPEG-21 architecture or cross-part MPEG-21 profiles

5 Annex A. Utility Software for Individual Parts5.1 DID

A demonstration program, called DIDLTest, is included in the aforementioned DID reference software package (clause 3.1). This program can be used to test the reference software. It takes a DID document as input and writes a tree of the (parsed and validated) DID document to the screen. In case of validation errors, the program reports this error, together with the validation rule that is not met by the DID under consideration.

This DID utility software can be started with the following command (from within the classes directory):java -classpath .; ../lib/xmlParserAPIs.jar; ../lib/xercesImpl.jar; ../lib/log4j.jar DIDLTest

5

ISO/IEC CD 21000-8Alternatively, when working under Windows, it can be run by double-clicking the DIDLTest.bat file.

Below, two example outputs are given: a first one corresponding to the validation of a valid DID document; a second one that corresponds to the validation of an invalid DID document.

Example output (without a validation error):

Parsed URL: file:/Y:/example_01.xml

DIDL available = true Item available = true Descriptor available = true Statement available = true Choice available = true Selection available = true predicate = UNDECIDED Item available = false Condition available = true Component available = true Resource available = true Item available = false Condition available = true Component available = true Resource available = true Item available = true Component available = true Resource available = true

Press any key to continue...

Example output (with a validation error):

Invalid DID:

****** Validation Error ******Validation rule: <Annotation>: An ANNOTATION that does not contain a REFERENCE child element must have a TARGET attribute.

<?xml version="1.0" encoding="UTF-8"?><Annotation xmlns="urn:mpeg:mpeg21:2002:01-DIDL-NS"> <Assertion target="#choice_01" true="choice_01_select_id_01"/></Annotation>

5.2 REL

5.2.1 Simple REL license interpreter

Input:o REL licenseo Query consisting of a principal, one right, resource, time, exercise count (optional)

Output:o Authorization result: YES, or NO with reasons why in a log file

5.2.1.1 Implementations from ContentGuard Software Details:

o Languages: C++o Supported platforms: Windows XP, Windows 2000 Server, Windows ME,

Windows NT 4.0 Workstation, Windows 98 SE, Window CE, and Linuxo Architecture:

6

ISO/IEC CD 21000-8

Delivery Plan: o initial module uploaded in Oct. 2002 (m9067)o a WinCE version of the initial module uploaded in January, 2003 (m9379)o an integrated and enhanced version for both Windows and WinCE uploaded in

March, 2003 (m9581)o a Linux porting version of m9581 uploaded in July, 2003 (m9898)o a Java version that is capable of interpreting some rights and conditions for

adapting and processing digital items and resources Status:

o The versions in m9067 and m9379 support one right (play) and one condition (validity interval)

o The version in m9581 supports one additional condition (exerciseLimit)o Updated versions that reflect the FDIS version of the REL spec have been

uploaded to the MPEG-21 Reference Software Contribution site.o Delivery of the first implementation of Java version by March 2004.

5.2.1.2 Implementation from Chinese Academy of Sciences Software Details:

o Languages: C++o Supported platforms:

Red Hat Linux 7.3 (tested) g++ 3.1 Apache XML Xerces p arser in C++ , version 2.2 Apache XML Xalan XSLT and XPATH processor in C++ , version 1.5.

o Architecture: same as the ContentGuard implementation Delivery Plan:

o Initial version was uploaded in July 2003 (m9729) Status:

7

ISO/IEC CD 21000-8o Updated when necessary

5.2.1.3 Implementation from Universitat Pompeu Fabra, Spain

Description: The Simple REL License Interpreter first validates the input license against the REL XML schemas. Then a query with the data associated to the user (principal, right, resource and optionally the number of times the right has been exercised) is constructed dynamically and it is executed against the REL License File. The result of the query are the conditions associated to the matching grants, if any. Finally the conditions are evaluated, and if they are satisfied the user is authorized.The implementation supports all the rights and all the conditions in the REL, but it does not support variables. The validation process implemented only supports two conditions, validityInterval and exerciseLimit.

Input:

o REL license

o Query consisting of a principal, one right, resource, time, exercise count (optional)

Output:

o Authorization result: YES, or NO with reasons why in a log file

Architecture:

5.2.2 Simple REL License Creator

Description:

8

REL License File

User File Results File

Log File

Validate Interval

Parser (Xerces)

XQueryy

Return conditions

associated to the matching grants

Validate Exercise Limit

REL Parser Module Condition Evaluator

Condition File

License Transformation

Temp License

ISO/IEC CD 21000-8 Input:

o Target principal

o What resource

o Right

o Conditions

o Issuer

Output:

o REL license

Architecture:

HTML web page for information introduction Tomcat Servlet Engine

1. Information needed to create a new license

2. GeneratedREL License

REL Schema Checker

3. Input: REL License

4. Output: Validation result

License creation result

REL License Creator Servlet

Client sideServer side

5. Result of license creation

HTML web page for information introduction Tomcat Servlet Engine

1. Information needed to create a new license

2. GeneratedREL License

REL Schema Checker

3. Input: REL License

4. Output: Validation result

License creation result

REL License Creator Servlet

Client sideServer side

5. Result of license creation

5.3 RDD

5.3.1 RDD browser interface

Input:o A Term

Output: o Term Definition, Genealogy

Software Details: o HTMLo Windows, any browser

Delivery Plan: TBDo Initial version was uploaded to the MPEG-21 Reference Software site, March

2003 Status:

o Complete

9

ISO/IEC CD 21000-8

5.3.2 Multilingual RDD registry

Input: Query on RDD term Output:

o RDD Terms in user preferred translated languages (TermDescription, ActionFamily, ContextFamily, Synonym, etc)

o XML format RDD term attribute description Software Details:

o Language: Visual Basico Platform: Any platform supported by Microsoft .Net framework. (e.g., Windows

98, 2000, NT, ME, XP). Delivery Plan:

o Initial version was uploaded July 2003 (m9748) Status:

o Version 1.0

5.3.3 RDDOnto: RDD described with RDF and RDFS

Description: The RDDOntoAPI constructs and poses a RQL query to a Sesame repository that contains RDDOnto. The query asks for all the superclasses of the input act type that correspond to all its supertypes.

Input:

o A query about a Term

Output:

o The genealogy and IsTypeOf hierarchy of the Term

5.4 DIA

This section comprises the current available utility software modules:

Module A. AudioPresentationPreferencesInput DI Resources: Audio MP3

DS: AudioPresentationPreferencesDescriptor

Output DI Resources: Audio MP3

Model example Audio adaptation

Software Details

Language (Visual) C++

Independent/Integrated modules

Integrated modules

Status Uploaded

Delivery plan -

ToDo -

10

ISO/IEC CD 21000-8Module B. Audio Soundfield

Input DI Resources: Audio MP3DS: audio presentation preference descriptor

Output DI Resources: audio MP3


Software Details



Integrated modules

Status Uploaded

Delivery plan -

ToDo -

Module C. DisplayPresentationPreferencesInput DI Resources: Images (BMP and JPEG)

DS: DisplayPresentationPreferencesType

Output DI Resource: Selected images (BMP and JPEG)

Model example BMP images

Software Details

Language C++/Java


Two independent modules: one for generating XDI; one for the adaptation

Status Uploaded

Delivery plan -

ToDo -

Module D. StereoscopicVideoConversionInput DI Resources: DI

DS: TerminalCapabilities

Output DI Resources: Adapted Streaming resourcesDIADMs

Model example Demonstrate on-the-fly adaptive media streaming using

Software Details

Language Java


Integrated module

11

ISO/IEC CD 21000-8

Status Uploaded

Delivery plan -

ToDo -

Module E. GraphicsPresentationPreferenceInput DI Resource: 3D Graphics

DS: GraphicsPresentationPreference

Output DI Resources: Adapted 3D Graphics

Model example demonstrate adaptation of 3D graphics according to Graphics Presentation preference

Software Details

Language C++


Integrated module

Status Uploaded

Delivery plan -

ToDo -

Module F. ModalityConversionPreferenceInput DI Resources: Video, Image, Audio, Text, Graphics

DS: ModalityConversionPreference, PresentationPriority, Transmoding

Output DI Resources: Video, Image, Audio, Text, Graphics

Model example demonstrate working of the relevant DSs

Software Details

Language C++, Java


Independent module

Status Uploaded

Delivery plan -

ToDo -

Module G. PresentationPriorityPreferenceContact see Module F, ModalityConversion

Input DI

Output DI

12

ISO/IEC CD 21000-8Model example

Software Details

Language


Status

Delivery plan

ToDo

Module H. FocusOfAttentionInput DI Resource: Video (MPEG-1), Text, Audio (WAV)

DS: SegmentPresentationPreference, SoniferousSpeedPreference

Output DI Resource: Video (MPEG-1), Text, Audio (WAV)

Model example -

Software Details

Language C++


Independent modules

Status Uploaded

Delivery plan -

ToDo -

Module I. AudioImpairmentInput DI Resources: Audio MP3

DS: AudioImpairment

Output DI Resources: Adapted Audio


Software Details



Integrated module

Status Uploaded

Delivery plan -

ToDo need packaging as DID

13

ISO/IEC CD 21000-8

Module J. VisualImpairmentInput DI Resources: Image

DS: ColorVisionDeficiency, VisionImpairment

Output DI Resources: Adapted image

Model example BMB bitmap adaptation

Software Details



Integrated modules

Status Uploaded

Delivery plan -

ToDo -

Module K. ColorVisionDeficiencyContact see Module J, VisualImpairment

Input DI

Output DI

Model example

Software Details

Language


Status

Delivery plan

ToDo

Module L. MobilityCharacteristicsInput DI Resources: Contains multiple references to resources

DS: Instantiated description of mobility characteristics (as text file at present)

Output DI Contains a single reference to a resource and a textual description (statement) that is relevant to the User based on the input mobility characteristics description

Model example Classify the User as pedestrian, urban vehicle or highway vehicle. Adapt Digital Item by deleting fragments of the Digital Item that are not relevant to this particular User

14

ISO/IEC CD 21000-8

Software Details

Language C++, simple software easily portable to other languages


Classification and adaptation process

Software to generate mobility trajectories based on a modified 2D fractional Brownian motion model outside the adaptation engine (optional)

Software to extract mobility characteristics description from the input trajectories outside the adaptation engine (optional)

Status Uploaded

Delivery plan -

ToDo -

Module M. DestinationInput DI Resources: MPEG-1 video

DS: UserDestination Description

Output DI Resources: Filtered MPEG-1 video and JPEG images

Model example Filtering and searching of MPEG-1 video based on User Destination

Software Details

Language C++


Independent module

Status Uploaded

Delivery plan -

ToDo -

Module N. LocationContact see Destination

Input DI

Output DI

Model example

Software Details

Language


Status

15

ISO/IEC CD 21000-8

Delivery plan

ToDo

Module O. TimeContact see Destination

Input DI

Output DI

Model example

Software Details

Language


Status

Delivery plan

ToDo

Module P. AudioEnvironmentInput DI Resources: Audio MP3

DS: AudioEnvironment characteristics descriptor

Output DI Resources: Audio MP3


Software Details

Language C++


Integrated module

Status Uploaded

Delivery plan -

ToDo -

Module Q. IlluminationCharacteristicsInput DI Resources: Images (BMP)

DS: IlluminationCharacteristicsType

Output DI Resources: Selected image (BMP)

Model example BMP images

16

ISO/IEC CD 21000-8

Software Details

Language C++/Java


One integrated Module

Status Uploaded

Delivery plan -

ToDo -

Module R. BSDLInput DI Resources: MPEG-4 Elementary Stream, JPEG2000 image,

MPEG-4 VTCDS: BSD

Output DI Resources: Adapted resourcesDS: Transformed BSD

Model example MPEG-4 video elementary stream, JPEG2000, MPEG-4 VTC

Software Details

Language Java, XSLT


Philips software (Bin2BSD, BSD2Bin), XSLT style sheets doing transformations

Status Uploaded

Delivery plan -

ToDo -

Module S. gBSDInput DI Resources: MPEG-4 Elementary Stream, JPEG2000 image,

DS: gBSD, Adaptation Hint

Output DI Resources: Adapted resourcesDS: Transformed gBSD

Model example MPEG-4 video elementary stream, JPEG2000

Software Details

Language Java, XSLT


gBSD2Bin, XSLT style sheets doing transformations

Status Uploaded

Delivery plan 2003/11/15

ToDo New version according to Section Error: Reference source not found.

17

ISO/IEC CD 21000-8

Module T. AdaptationQoSInput DI Resources: MPEG-4 Video ES, MPEG-4 VTC

DS: Adaptation QoS

Output DI Adapted MPEG-4 Video ES, MPEG-4 VTC

Model example MPEG-4 video ES, MPEG-4 VTC adaptation

Software Details

Language (Visual) C++ / Java


Two integrated modules

Status Uploaded

Delivery plan -

ToDo -

Module U. AudioAdaptationQoSInput DI Resources: MPEG-4 Audio BSAC & AAC

DS: AdaptationQoS

Output DI Resources: MPEG-4 Audio BSAC & AAC (adapted)

Model example Audio-specific adaptation operations (channel dropping, audio FGS, spectral band reduction)

Software Details

Language C


Independet module

Status Uploaded

Delivery plan -

ToDo -

Module V. UCDInput DI DS: UCD and AdaptationQoS, UED referenced through UCD.

Output DI Decisions for multiple adaptation units in non-normative form in terms of IOPin values.

Model example Fully format independent decision making based on constraints for a variety of use cases involving several formats.

Software Details


18

ISO/IEC CD 21000-8Independent/Integrated modules

Integrated modules

Status Uploaded

Delivery plan -

ToDo -

Module W. BSDLinkInput DI Resources: JPEG2000, MPEG4-VES, MPEG4-VTC, MC-

EZBC (fully scalable video proposal for Scalable Video)DS: BSDTrI, gBSD, BSDLinkDecisions for multiple adaptation units in non-normative form obtained as output of software in 5.22.

Output DI Resources: Adapted JPEG2000, MPEG4-VES, MPEG4-VTC, MC-EZBC (fully scalable video proposal for Scalable Video)DS: Adapted gBSD

Model example Parameter passing in BSDLink from decisions to transformation stylesheet (BSDTrI), followed by processing of the BSDTrI to obtained adapted resource and adapted bit-stream.

Software Details



Integrated modules

Status Uploaded

Delivery plan -

ToDo -

Module X. MetaDataAdaptationInput DI Resources: MPEG video

DS: VideoSegment Visual Descriptor

Output DI Resources: MPEG videoDS: VideoSegment Visual Descriptor

Model example Metadata adaptation

Software Details



Integrated module

Status Uploaded

19

ISO/IEC CD 21000-8

Delivery plan -

ToDo -

Module Y. MetadataAdaptationIntegrationInput DI Resources: MPEG-7 Metadata (two or more instances)

DS: Metadata adaptation

Output DI Resources: MPEG-7 Metadata (one instance)

Model example demonstrate integration of multiple metadata instances

Software Details

Language C++


Independent module

Status Uploaded

Delivery plan -

ToDo -

Module Z. Session MobilityInput DI Resources: audio MP3

DS: auditory impairment descriptor

Output DI Context Digital Items for Session Mobility

Model example -

Software Details

Language Java


Integrated with JAVA DID classes

Status Uploaded

Delivery plan -

ToDo -

Module AA. DIA ConfigurationInput DI Resources: DI

DS: TerminalCapabilities

Output DI Resources: adapted streaming resources

DIADMs

Model example demonstrate on-the-fly adaptive media streaming using DIA descriptors

20

ISO/IEC CD 21000-8

Software Details

Language Java


Integrated modules

Status Uploaded

Delivery plan -

ToDo -

5.5 File format

No software yet in this section.

5.6 DIP

5.6.1 Module A

Contributor: University of Wollongong (contact: Gerrard Drury)

Available: December 2003

Description:

This is an updated version of a previous contribution modified to utilize distributed Object Map technology in performing the Core Experiment on Object Map (see N5942, m10417).

It is available at the same location as the reference software (see clause 3.1). The demonstration software utilizes the DIP reference software DIME implementation and of DIBO implementations.

The demonstration software is developed in Java and requires the following components to be installed prior to running the demonstration software.

Java 1.4 or later: http://java.sun.com/java/1.4/

Java Media Framework (JMF) 2.1.1a or later: http://java.sun.com/products/jmf/

The demonstration software is integrated with the following reference software for other parts of MPEG-21(included in the demonstration software download).

DID reference software described in 3.1 – usage of the DID parser

The demonstration software utilizes the following third party libraries (included in the demonstration software download).

Xerces-J from Apache XML DOM parser: http://xml.apache.org/xerces2-j/index.html

Log4j from Apache logging utility: http://jakarta.apache.org/log4j/docs/index.html

FESI ECMAScript interpreter: http://www.lugrin.ch/fesi/

On a Windows platform, the demonstration software can be started by double-clicking the dimldemo.bat batch file. On other unix-like Java enabled platforms, a command similar to the following can be used (assumes command is run from the same directory in which the demonstration software is located):

$ java –classpath=lib/thirdParty/log4j.jar:\lib/thirdParty/xercesImpl.jar:\

21

http://www.lugrin.ch/fesi/

http://jakarta.apache.org/log4j/docs/index.html

http://xml.apache.org/xerces2-j/index.html

http://java.sun.com/products/jmf/

http://java.sun.com/java/1.4/

ISO/IEC CD 21000-8lib/thirdParty/xmlParserAPIs.jar:\lib/thirdParty/fesi.jar:\lib/mpeg21-dime-demo.jar org.iso.mpeg.mpeg21.dimengine.demo.DIMEDemoGui

The demonstration software provides a basic GUI that allows a user to open a DID containing Digital Item Methods integrated in to the DID according to the DIP specification. Note that sample DIDs containing DIMs are also available from the same location as the software.

The DIMs in the Digital Item are displayed in a list and the user can select a DIM in the list, then click the button labeled Execute to execute the DIM.

5.6.2 Module B

Contributor: Ghent University (contact: Frederik De Keukelaere)


Description:

Software developed for Core Experiment on Object Map (see N5942, m10386).

[Frederik De Keukelare]

5.6.3 Module C

Contributor: Information and Communications University (contact: Munchurl Kim)


Description:

Software developed for the Core Experiment on DIBO Explorations (see N,5943 m10363).

[Munchurl Kim]

5.7 Testbed

No software description yet in this section.

6 Annex B. Integrated Utility Software6.1 Integrated REL-RDD software

6.1.1 REL license interpretation using RDD term genealogy

6.1.1.1 REL license interpretation using RDD term genealogy – Implementation using SESAME

Description: The software first validates syntactically the REL License, constructs a temporal license if the original one uses the licesensePartId or licensePartIdRef attributes and obtains the conditions associated to the matching grants. If no matching grants are found for the query constructed with the user data, it interacts with the RDDOnto and retrieves all the supertypes of the user right, then new queries are constructed for each one of the parent rights and are executed until a matching grant is found. The RDDOntoAPI constructs and poses a RQL query to a Sesame repository that contains RDDOnto. The query asks for all the superclasses of the input act type that correspond to all its supertypes. Finally, the conditions are evaluated, and if they are satisfied then the user is authorized.

Input:

o REL license

o Query consisting of principal, right, resource, time, exercise count (optional)

Output:

22

ISO/IEC CD 21000-8o Authorization result: YES, or NO with reasons why in a log file

Architecture:

6.1.1.2 REL license interpretation using RDD term genealogy – Implementation using Web Services

Description: The software first validates syntactically the REL License, constructs a temporal license if the original one uses the licesensePartId or licensePartIdRef attributes and obtains the conditions associated to the matching grants. If no matching grants are found for the query constructed with the user data, it interacts with the RDDOnto and retrieves all the supertypes of the user right, then new queries are constructed for each one of the parent rights and are executed until a matching grant is found. The service method invoked is the getRDDSuperTypes that retrieves from the RDD ontology all the parents of the given right.Finally, the conditions are evaluated, and if they are satisfied then the user is authorized.

Input:

o REL license

o Query consisting of principal, right, resource, time, exercise count (optional)

Output:

o Authorization result: YES, or NO with reasons why in a log file

Architecture:

23

ISO/IEC CD 21000-8

6.2 Integrated REL-DID Software

6.2.1 REL license interpretation within DID

Input: o DID expression (with information on REL licenses)o Query consisting of principal, right, resource, time, exercise count (optional)

Output: o Authorization result: YES, or NO with reasons why in a log file

Software Detailso Language:

Javao Architecture:

Delivery Plan: o First version by the March 2004 meeting.o ContentGuard and UGent to submit their implementation by the March 2004

meeting.

24

ISO/IEC CD 21000-8 Status:

o The first version has been submitted (m10421) from UPF. which uses XQuery to extract REL licenses from DIDL expressions.

o Another version has been submitted (m10521) from ContentGuard, Inc. and Ghent University.

6.3 Integrated REL-RDD-DID Software

6.3.1 REL License Interpretation within DID using RDD term genealogy

Description: First, the DID document is parsed by the DID Parser to check its validity. If it is not valid, the reasons why are printed in the Log file. Otherwise the resource (in url or urn format) is extracted from the User Query file. Then, the DID document is traversed to identify the resource. Finally, the DID document is traversed to find all the licenses that match the resource. If no matching license is obtained the License Extractor directly gives the Output file. Otherwise, a temporal LicenseFile file is created and the REL license interpreter using RDD term genealogy is invoked with inputs the license file extracted and the user query file. This module first validates syntactically the REL License and obtains the conditions associated to the matching grants. If no matching grants are found for the query constructed with the user data, it interacts with the RDDOnto and retrieves all the supertypes of the user right, then new queries are constructed for each one of the parent rights and are executed until a matching grant is found. Finally, the conditions are evaluated, and if they are satisfied then the user is authorized.

Input:

o DID expression (with information on REL licenses)o Query consisting of principal, right, resource, time, exercise count (optional)

Output:o Authorization result: YES, or NO with reasons why in a log file

Architecture:

25

ISO/IEC CD 21000-8

6.4 Integrated DID-DIA software

No software description yet in this section.

6.5 Integrated DID-DIP software

7 Annex C. Integration with other MPEG SoftwareNo software description yet in this section.

8 Annex D. Auxiliary Information for REL Reference Software8.1 Validation Rules

8.1.1 Introduction

This section is meant to summarize the validation rules for XML documents to be valid MPEG-21 REL expressions (i.e., REL Licenses) beyond simple XML schema validation against the REL schemas [1]. It is also meant to be just informative; in case there is any inconsistence with the MPEG-21 REL specification, the REL specification is always considered as normative.

This section intends to provide these REL validation rules so that applications can be built to verify if an XML document is a valid REL expression according the MPEG-21 REL standard specification [1]. These applications include the piece of the MPEG-21 REL reference software, “validation rule checker”, specified in [2].

The scope of validation rules is on those for validating if an XML document is itself a valid REL expression. It is outside of the scope of validation rules to list any constraints on authorization requests such as the constraint requiring the Resource Member of an authorization request to be an r:Grant or r:GrantGroup if the Right Member of that authorization request is an r:issue.

For convenience, the validation rules that are copied directly from the MPEG-21 REL specification [1] are highlighted.

8.1.2 REL Validation Rules

8.1.2.1 LicensePartId and LicensePartIdRef

8.1.2.1.1 The Rule

These rules are given in 6.3 of the REL [1]. The following provisions apply to r:License elements that contain r:LicensePart elements having the r:licensePartId or r:licensePartIdRef attributes.

1. An r:LicensePart shall not have both the r:licensePartId attribute and the r:licensePartIdRef attribute.

2. For a given r:LicensePartId value v and r:License l, l shall not contain more than one r:LicensePart having an r:licensePartId attribute with the value v.

26

ISO/IEC CD 21000-83. If an r:LicensePart has an r:licensePartIdRef attribute, then it shall have

empty content. As a corollary, types that are derivations of the type r:LicensePart should allow their content to be empty (for otherwise their r:licensePartIdRef attribute shall not be used).

4. If an r:LicensePart a has an r:licensePartIdRef attribute with a certain value v, then there shall exist some (other) r:LicensePart b in the same r:License as a such that all of the following are true:

b has an r:licensePartId attribute with value v,

the expanded element name of b exactly matches that of a, and

b is not an ancestor of a.

5. With the exception of signature verification and License issuer resolution (see 6.4), the following two processing steps shall be carried out before the other License processing steps defined in this part of ISO/IEC 21000. In particular, they shall be carried out before the evaluation of Variable references or the testing of equality.

If an r:LicensePart a has an r:licensePartIdRef attribute with a certain value v, and b is the r:LicensePart in the same r:License as a that has an r:licensePartId attribute with value v, then the semantics of the r:License containing a and b are as if

a were removed from the r:License and replaced with an element that is Equal to b,

the r:licensePartId attributes were removed from and all of its descendants, and

any preserved attributes that has were removed from , and any preserved attributes that a has were added to , where here a preserved attribute is

any attribute of type xsd:ID or

any attribute for which id is the local part of its Qualified Name.

If an r:License contains no r:LicensePart elements with an r:licensePartIdRef attribute, then the semantics of that r:License are as if the r:licensePartId attribute were removed from all r:LicensePart elements in that r:License with an r:licensePartId attribute.

NOTE 1 It is the intent of 5 to enable the useful definition and incorporation of other identification systems on r:LicensePart elements beyond the document-global xsd:ID-typed identifiers.

NOTE 2 Circular references such as that shown in Example 1 are not allowed because, after one application of provision 5, the semantics will be as shown in Example 2, which violates provision 4.

27

ISO/IEC CD 21000-8EXAMPLE 1

<r:license>

<r:grantGroup licensePartId="x">

<r:grantGroup licensePartIdRef="y"/>

</r:grantGroup>

<r:grantGroup licensePartId="y">

<r:grantGroup licensePartIdRef="x"/>

</r:grantGroup>

</r:license>

EXAMPLE 2

<r:license>


<r:grantGroup>


</r:grantGroup>

</r:grantGroup>


<r:grantGroup>


</r:grantGroup>

</r:grantGroup>

</r:license>

8.1.2.1.2 Examples that Violate the Rules

6. An r:LicensePart shall not have both the r:licensePartId attribute and the r:licensePartIdRef attribute.

<r:license>

<r:grant>

<r:keyHolder licensePartId="Eva">

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>

<dsig:Modulus>KtdToQQyzA==</dsig:Modulus>

<dsig:Exponent>AQABAA==</dsig:Exponent>

</dsig:RSAKeyValue>

</dsig:KeyValue>

28

ISO/IEC CD 21000-8</r:info>

</r:keyHolder>

<mx:play/>

<r:digitalResource>

<r:nonSecureIndirect URI="http://www.onlinemusic.com/song.mp3"/>

</r:digitalResource>

<r:validityInterval>

<r:notBefore>2003-01-01T00:00:00</r:notBefore>

<r:notAfter>2003-12-31T12:59:59</r:notAfter>

</r:validityInterval>

</r:grant>

<r:grant>

<r:keyHolder licensePartId="Silvia" licensePartIdRef="Eva"/>

<mx:play/>

<r:digitalResource>







</r:grant>

<r:issuer/>

</r:license>

7. For a given r:LicensePartId value v and r:License l, l shall not contain more than one r:LicensePart having an r:licensePartId attribute with the value v.

<r:license>

<r:grant>

<r:keyHolder licensePartId="Alice">

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:play/>

<r:digitalResource licensePartId="Alice">




29

ISO/IEC CD 21000-8<r:notBefore>2003-01-01T00:00:00</r:notBefore>



</r:grant>

<r:issuer/>

</r:license>

8. If an r:LicensePart has an r:licensePartIdRef attribute, then it shall have empty content.

<r:license>

<r:grant>


<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:play/>

<r:digitalResource>







</r:grant>

<r:grant>

<r:keyHolder licensePartIdRef="Alice">

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:enlarge/>

<r:digitalResource>



30

ISO/IEC CD 21000-8<r:validityInterval>




</r:grant>

<r:issuer/>

</r:license>

9. If an r:LicensePart a has an r:licensePartIdRef attribute with a certain value v, then there shall exist some (other) r:LicensePart b in the same r:License as a such that all of the following are true:

1. b has an r:licensePartId attribute with value v,

<r:license>

<r:grant>


<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:play/>

<r:digitalResource>







</r:grant>

<r:grant>

<r:keyHolder licensePartIdRef="Lora"/>

<mx:enlarge/>

<r:digitalResource>







</r:grant>

<r:issuer/>

31

ISO/IEC CD 21000-8</r:license>

the expanded element name of b exactly matches that of a

<r:license>

<r:grant>


<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:play/>

<r:digitalResource licensePartIdRef="Alice"/>





</r:grant>

<r:issuer/>

</r:license>

b is not an ancestor of a.

A direct example:<r:license>

<r:grant licensePartId="x">

<r:issue/>

<r:grant licensePartIdRef="x"/>

</r:grant>

</r:license>

An indirect example:<r:license>



</r:grantGroup>



</r:grantGroup>

</r:license>

32

ISO/IEC CD 21000-88.1.2.2 Variable reference and conceptually abstract elements and types

8.1.2.2.1 The Rules

6.5.2 and 6.6 of the REL [1] specify the following rules:

Let a be an r:LicensePart. If a/@r:varRef exists, then a shall have empty content and the value of a/@r:varRef shall be the name of some Variable whose scope includes a.

If a conceptually abstract element appears in an r:License, it shall either have a type that is not conceptually abstract or appear in the form of a Variable reference, as described in 6.5.2.

If a conceptually abstract type appears in an r:License, it shall belong to an element that either is not conceptually abstract or appears in the form of a Variable reference, as described in 6.5.2.

The following is a list of the conceptually abstract elements and types.

Conceptually abstract elements Conceptually abstract types

r:licensePart

r:principal

r:right

r:resource

r:condition

r:anXmlPatternAbstract

r:principalPatternAbstract

r:rightPatternAbstract

r:resourcePatternAbstract

r:conditionPatternAbstract

r:dcConstraint

r:trustRoot

r:serviceDescription

r:propertyAbstract

sx:name

r:LicensePart

r:Principal

r:Right

r:Resource

r:Condition

r:AnXmlPatternAbstract

r:PrincipalPatternAbstract

r:RightPatternAbstract

r:ResourcePatternAbstract

r:ConditionPatternAbstract

r:DcConstraint

r:TrustRoot

r:ServiceDescription

r:PropertyAbstract

sx:Name

sx:StatefulCondition


Let a be an r:LicensePart. If a/@r:varRef exists, then a shall have empty content <r:license>

<r:grant>

<r:forAll varName="content">

<r:anXmlExpression/>

33

ISO/IEC CD 21000-8</r:forAll>

<mx:print/>

<mx:diReference varRef="content">

<mx:identifier/>

</mx:diReference>





</r:grant>

<r:issuer/>

</r:license>

and the value of a/@r:varRef shall be the name of some Variable whose scope includes a.

<r:license>

<r:grant>

<r:forAll varName="AliceClub">

<r:propertyPossessor>

<sx:propertyUri definition="urn:edu:elibrary"/>

</r:propertyPossessor>

</r:forAll>

<r:principal varRef="AliceClub1"/>

<mx:print/>

<r:digitalResource>

<r:nonSecureIndirect URI="http://www.onlinemusic.com/mySong.mp3"/>






</r:grant>

<r:issuer/>

</r:license>

If a conceptually abstract element appears in an r:License, it shall either have a type that is not conceptually abstract or appear in the form of a Variable reference, as described in 6.5.2.

An example of an element of a conceptually abstract type but with no variable reference: <r:license>

<r:grant>

<r:keyHolder>

<r:info>

34

ISO/IEC CD 21000-8<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:right xsi:type="r:Right"/>

<mx:diReference>

<mx:identifier>someResourceUri</mx:identifier>

</mx:diReference>

</r:grant>

<r:issuer/>

</r:license>

Another example of an element of a conceptually abstract type but with no variable reference: <r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:right/>

<mx:diReference>

<mx:identifier>someResourceUri</mx:identifier>

</mx:diReference>

</r:grant>

<r:issuer/>

</r:license>

8.1.2.3 LicensePart optional content model

8.1.2.3.1 The Rules

7.4.1 of the REL [1] specifies the following rule:

If the syntax of a particular derivation of the type r:LicensePart declares its content model as optional, the semantics of that optional content model, unless specified otherwise, is that it shall not be omitted in an r:LicensePart of that derivation unless that r:LicensePart has an r:licensePartIdRef or r:varRef attribute.

35

ISO/IEC CD 21000-8

The following is a list of types that cannot be empty unless used with r:licensePartIdRef or r:varRef.

Types Elements using those types directly

r:Datum

r:DepthConstraint

r:DigitalResource

r:ExerciseMechanism

r:ExistsRight

r:Fulfiller

r:Grant

r:GrantGroup

r:GrantGroupPattern

r:GrantPattern

r:KeyHolder

r:PatternFromLicensePart

r:PrerequisiteRight

r:PropertyPossessor

r:Revocable

r:RevocationFreshness

r:ServiceReference

r:TrustedRootGrants

r:TrustedRootIssuers

sx:CallForCondition

sx:FeeFlat

sx:FeeMetered

sx:FeePerInterval

sx:FeePerUse

sx:FeePerUsePrePay

sx:Rate

sx:StateReferenceValuePattern

sx:Territory

sx:Uddi

sx:ValidityIntervalDurationPattern

sx:ValidityIntervalStartsNow

sx:ValidityTimePeriodic

sx:WsdlAddress

sx:WsdlComplete

r:datum

r:depthConstraint

r:digitalResource

and sx:WsdlAddress/sx:kind/sx:wsdl

and sx:WsdlComplete/sx:wsdl

r:exerciseMechanism

r:existsRight

r:fulfiller

r:grant

r:grantGroup

r:grantGroupPattern

r:grantPattern

r:keyHolder

r:patternFromLicensePart

r:prerequisiteRight

r:propertyPossessor

r:revocable

r:revocationFreshness

r:serviceReference

r:trustedRootGrants

r:trustedRootIssuers

sx:callForCondition

sx:feeFlat

sx:feeMetered

sx:feePerInterval

sx:feePerUse

sx:feePerUsePrePay

sx:rate

sx:stateReferenceValuePattern

sx:territory

sx:uddi

sx:validityIntervalDurationPattern

sx:validityIntervalStartsNow

sx:validityTimePeriodic

sx:wsdlAddress

sx:wsdlComplete

36

ISO/IEC CD 21000-8anonymous type defined in mx:complement

mx:Destination

mx:DiCriteria

mx:DiItemReference

mx:DiPartOf

mx:DiReference

mx:IsMarked

mx:Mark

mx:ResourceSignedBy

mx:Source

mx:Transaction

mx:complement

mx:destination

mx:diCriteria

mx:diItemReference

mx:diPartOf

mx:diReference

mx:isMarked

mx:mark

mx:resourceSignedBy

mx:source

mx:transaction

The following is a list of types that declare an optional content model but specify an exception to the rule of 7.4.1.

Types Elements using those types directly

anonymous type defined in mx:union

anonymous type defined in mx:intersection

mx:RequiredAttributeChanges

mx:ProhibitedAttributeChanges

mx:union

mx:intersection

mx:requiredAttributeChanges

mx:prohibitedAttributeChanges


<r:license>

<r:grant>

<r:keyHolder/>

<mx:play/>

<r:digitalResource>



</r:grant>

<r:issuer/>

</r:license>

8.1.2.4 Encrypted content

8.1.2.4.1 The Rules

7.3.6 of the REL [1] specifies the following rule:

An r:EncryptedContent shall have an xenc:Type attribute with a value of http://www.w3.org/2001/04/xmlenc#Content.

37

ISO/IEC CD 21000-88.1.2.4.2 Examples that Violate the Rules

<r:license>

<r:grant>

<r:encryptedGrant>

<xenc:CipherData>

<xenc:CipherValue/>

</xenc:CipherData>

</r:encryptedGrant>

</r:grant>

</r:license>

8.1.3 References

1. w5839, ISO/IEC 21000, Part 5, Rights Expression Language, FDIS, August 2003.2. w5840, MPEG-21 REL/RDD Software Implementation Plan v.3, Trondheim, Norway, July

2003.3. m10001, MPEG-21 REL Validation Rules, Brisbane, Australia, October 2003.

8.2 Data Types for Interpretation Conformance

8.2.1 Introduction

This section describes the inputs and outputs for the interpretation conformance reference software, as described in [2], for MPEG-21 REL [1]. As shown in the following diagram, the interpretation conformance reference software takes as input an RELAuthorizationRequest and a set of RELAuthorizationStories and produces as output an RELAuthorizationResult.

The ouput RELAuthorizationResult can have two values: RELProven, if there is an authorization proof within the input set of

RELAuthorizationStories for the input RELAuthorizationRequest and all other authorization proofs used in establishing that authorization proof are also within the input set of RELAuthorizationStories, and

RELNotProven, otherwise (i.e., if there is no authorization proof within the input set of RELAuthorizationStories for the input RELAuthorizationRequest or if not all other authorization proofs used in establishing that authorization proof are also within the input set of RELAuthorizationStories).

It is important to understand that the main function of the interpretation conformance reference software for REL is to test if an application interprets REL Licenses in a way that is conformant to the REL specification. If an application is intended to permit (or not permit) a Principal to use a

38

ISO/IEC CD 21000-8Resource only based upon a set of REL Licenses, it should be possible to construct an RELAuthorizationRequest that reflects the intended request and a set of RELAuthorizationStories, such that the application permits the use if and only if when they are passed as as its inputs, the interpretation conformance reference software yields an RELAuthorizationResult with the value RELProven. If this is the case, then the application is said to be interpretation conformant to the REL specification [1] in making that permission (or no permission) decision.

8.2.2 Data Types

Unless specified otherwise below, NULL values and encrypted things are not allowed.

8.2.2.1 RELAuthorizationRequest

Member Data type Allowed values

principal RELNode Any r:Principal or NULL

Note: A NULL value here corresponds to the case where the Principal Member of the authorization request is absent as described in the REL.

right RELNode Any r:Right

resource RELNode Any r:Resource or NULL

Note: A NULL value here corresponds to the case where the Resource Member of the authorization request is absent as described in the REL.

interval RELInterval Any

context RELAuthorizationContext Any

licenses Vector<RELNode> Any r:License elements each with one r:issuer child

roots Vector<RELNode> Any r:Grant elements

8.2.2.2 RELAuthorizationContext


properties Map<RELPropertyName, Object> Any

8.2.2.3 RELAuthorizationStory


G RELNode Any primitive grant

H RELNode Any r:Grant or r:GrantGroup

E RELAuthorizer Any or NULL

39

ISO/IEC CD 21000-8

Note: A NULL value here corresponds to the case where the authorizer member of the authorization story is absent as described in the REL.

8.2.2.4 RELAuthorizer


license RELNode Any r:License with one r:issuer child

principal RELNode Any r:Principal

instant RELDateTime Any

context RELAuthorizationContext Any

story RELAuthorizationStory Any

8.2.2.5 RELAuthorizationResult


result enumeration "RELProven" or "RELNotProven"

Note: If the RELAuthorizationContext in the input does not contain all the needed properties, the RELAuthorizationResult will be RELNotProven. If there are other exceptions such as "out of memory," "can not read input file," etc., these should be handled as exceptions and shouldn't have any normative implications within the Reference Software part.

8.2.2.6 RELInterval


Start RELDateTime Any

End RELDateTime Any

8.2.2.7 RELPropertyName


qname RELQName Any

40

ISO/IEC CD 21000-8parameters Vector<Object> Any

8.2.2.8 RELQName


Ns String Any URI

local String Any xsd:NCName

8.2.2.9 RELNode

Used for XML nodes.

8.2.2.10 RELDateTime

Used for xsd:dateTime values.

8.2.2.11 Vector

Used for any ordered tuples that do not have their own specific type.

8.2.3 XML Representation

In order to be able to store inputs in files, an input file format is needed. The attached XML Schemas can be used for this purpose.

<?xml version="1.0" encoding="UTF-8"?>

<xsd:schema targetNamespace="urn:mpeg:mpeg21:2003:01-SW-NS:REL" xmlns:swrel="urn:mpeg:mpeg21:2003:01-SW-NS:REL" xmlns:r="urn:mpeg:mpeg21:2003:01-REL-R-NS" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xsd:import namespace="urn:mpeg:mpeg21:2003:01-REL-R-NS" schemaLocation="rel-r.xsd"/>

<xsd:element name="RELAuthorizationRequest">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="principal">

<xsd:complexType>

<xsd:sequence minOccurs="0">

<xsd:element ref="r:principal"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="right">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="r:right"/>

</xsd:sequence>

41

ISO/IEC CD 21000-8</xsd:complexType>

</xsd:element>

<xsd:element name="resource">

<xsd:complexType>


<xsd:element ref="r:resource"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="interval">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="swrel:RELInterval"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="context">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="swrel:RELAuthorizationContext"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="licenses">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="r:license" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="roots">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="r:grant" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="RELAuthorizationStory">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="g">

<xsd:complexType>

<xsd:sequence>

42

ISO/IEC CD 21000-8<xsd:element ref="r:grant"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="h">

<xsd:complexType>

<xsd:choice>

<xsd:element ref="r:grant"/>

<xsd:element ref="r:grantGroup"/>

</xsd:choice>

</xsd:complexType>

</xsd:element>

<xsd:element name="e">

<xsd:complexType>


<xsd:element name="RELAuthorizer"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="RELAuthorizationContext">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="properties">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="property" minOccurs="0" maxOccurs="unbounded">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="swrel:RELPropertyName"/>

<xsd:any namespace="##any" processContents="lax"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="RELAuthorizer">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="license">

43

ISO/IEC CD 21000-8<xsd:complexType>

<xsd:sequence>

<xsd:element ref="r:license"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="principal">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="r:principal"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="instant" type="xsd:dateTime"/>

<xsd:element name="context">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="swrel:RELAuthorizationContext"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="story">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="swrel:RELAuthorizationStory"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="RELAuthorizationResult">

<xsd:simpleType>

<xsd:restriction base="xsd:NMTOKEN">

<xsd:enumeration value="RELProven"/>

<xsd:enumeration value="RELNotProven"/>

</xsd:restriction>

</xsd:simpleType>

</xsd:element>

<xsd:element name="RELInterval">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="start" type="xsd:dateTime"/>

<xsd:element name="end" type="xsd:dateTime"/>

</xsd:sequence>

</xsd:complexType>

44

ISO/IEC CD 21000-8</xsd:element>

<xsd:element name="RELPropertyName">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="qname">

<xsd:complexType>

<xsd:sequence>

<xsd:element ref="swrel:RELQName"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="parameters">

<xsd:complexType>

<xsd:sequence>

<xsd:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name="RELQName">

<xsd:complexType>

<xsd:sequence>

<xsd:element name="ns" type="xsd:anyURI"/>

<xsd:element name="local" type="xsd:NCName"/>

</xsd:sequence>

</xsd:complexType>

</xsd:element>

</xsd:schema>

8.2.4 References

1. w5839, ISO/IEC 20001, Part 5, Rights Expression Language, FDIS, August 2003.2. w5840, MPEG-21 REL/RDD Software Implementation Plan v.3, Trondheim, Norway, July

2003.3. m10000, Data Types for MPEG-21 REL Interpretation Conformance Software, Brisbane,

Australia, October 2003.

8.3 REL Authorization Request Validation Rules

The REL Authorization Request Validation Rules consist of a set of rules that apply to the individual members of any Authorization Request, and a set of rules that apply to the Right member of an Authorization Request, based on its values from the specific rights in the REL specification [1].

45

ISO/IEC CD 21000-8

8.3.1 Rules for any Authorization Request

The following table lists the members of an Authorization Request in the order of their appearance in the Authorization Request and any rules that are relevant to each member.

Authorization Request Member Validation Rules

r:Principal None.

r:Right None.

r:Resource None.

Interval of time None.

Authorization Context Must not have two properties that share the same property name. Each property consists of exactly one name and one value.

r:License elements Each of the r:License elements l must have exactly one l/r:issuer child. In addition, all the r:License elements must pass all of the REL validation rules applicable to a r:License element [4].

r:Grant elements Must pass all of the REL validation rules related to a r:Grant element [4].

Additionally, the following rule applies to the Authorization Request as a whole: No fields in the Authorization Request may contain an r:encryptedLicense,

r:encryptedGrant, or r:encryptedGrantGroup.

8.3.2 Rules for the Right Member

Depending on the value of the Right Member of an Authorization Request, additional rules apply. The following sub-sections provide the r:Rights defined in the Core and Multimedia Schemas of the MPEG-21 REL standard specification [1] and the rules that they impose. For convenience, the validation rules that are copied directly from the MPEG-21 REL specification [1] are highlighted.

8.3.2.1 r:IssueIf r:Issue is used as the Right Member of an authorization request, then the Resource Member of that authorization request shall be present and shall be an r:Grant or an r:GrantGroup. (Section 7.6.1 [1])

8.3.2.2 r:ObtainIf r:Obtain is used as the Right Member of an authorization request, then the Resource Member of that authorization request shall be present and shall be an r:Grant or an r:GrantGroup and, letting be the Authorization Context Member of that authorization request, .r:fulfiller() shall identify the Principal who is requested to be the issuer of l. (Section 7.6.2 [1])

46

ISO/IEC CD 21000-88.3.2.3 r:PossessPropertyIf r:PossessProperty is used as the Right Member of an authorization request, then the Resource Member of that authorization request shall be present and shall be an r:PropertyAbstract. (Section 7.6.3 [1])

8.3.2.4 r:RevokeIf r:Revoke is used as the Right Member of an authorization request, then the Resource Member of that authorization request shall be present and shall identify a revocable. (Section 7.6.4 [1])

8.3.2.5 mx:AdaptIf mx:Adapt is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the SourceOfAdaptation as defined in ISO/IEC 21000-6 [3] and, letting be the Authorization Context Member of that authorization request, both .mx:source() shall identify the repository that is the PlaceOfAdaptingFrom as defined in ISO/IEC 21000-6 and .mx:destination() shall identify the repository that is the PlaceOfAdaptingTo as defined in ISO/IEC 21000-6. (Section 9.6.1 [1])

8.3.2.6 mx:DeleteIf mx:Delete is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the DeletedResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, .mx:source() shall identify the repository that is the PlaceOfDeleting as defined in ISO/IEC 21000-6. (Section 9.6.2 [1])

8.3.2.7 mx:DiminishIf mx:Diminish is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the SourceOfDiminution as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, both .mx:source() shall identify the repository that is the PlaceOfDiminishingFrom as defined in ISO/IEC 21000-6 and .mx:destination() shall identify the repository that is the PlaceOfDiminishingTo as defined in ISO/IEC 21000-6. (Section 9.6.3 [1])

8.3.2.8 mx:EmbedIf mx:Embed is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the EmbeddedResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, both .mx:source() shall identify the repository that is the PlaceOfEmbeddingFrom as defined in ISO/IEC 21000-6 and .mx:destination() shall identify the repository that is the PlaceOfEmbeddingTo as defined in ISO/IEC 21000-6. (Section 9.6.4 [1])

8.3.2.9 mx:EnhanceIf mx:Enhance is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the SourceOfEnhancement as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, both S.mx:source() shall identify the repository that is the PlaceOfEnhancingFrom as defined in ISO/IEC 21000-6 and .mx:destination() shall identify the repository that is the PlaceOfEnhancingTo as defined in ISO/IEC 21000-6. (Section 9.6.5 [1])

8.3.2.10 mx:EnlargeIf mx:Enlarge is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the EnlargedResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request,

47

ISO/IEC CD 21000-8.mx:source() shall identify the repository that is the PlaceOfEnlarging as defined in ISO/IEC 21000-6. (Section 9.6.6 [1])

8.3.2.11 mx:ExecuteIf mx:Execute is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the ExecutedResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, .mx:source() shall identify the repository that is the PlaceOfExecuting as defined in ISO/IEC 21000-6. (Section 9.6.7 [1])

8.3.2.12 mx:InstallIf mx:Install is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the InstallingResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request .mx:source() shall identify the repository that is the PlaceOfInstalling as defined in ISO/IEC 21000-6. (Section 9.6.8 [1])

8.3.2.13 mx:ModifyIf mx:Modify is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the ModifiedResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, .mx:source() shall identify the repository that is the PlaceOfModifying as defined in ISO/IEC 21000-6. (Section 9.6.9 [1])

8.3.2.14 mx:MoveIf mx:Move is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the MovedResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, both .mx:source() shall identify the repository that is the Origin as defined in ISO/IEC 21000-6 and .mx:destination() shall identify the repository that is the Destination as defined in ISO/IEC 21000-6. (Section 9.6.10 [1])

8.3.2.15 mx:PlayIf mx:Play is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the SourceOfPlaying as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, .mx:source() shall identify the repository that is the PlaceOfPlayingFrom as defined in ISO/IEC 21000-6. (Section 9.6.11 [1])

8.3.2.16 mx:PrintIf mx:Print is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the SourceOfPrintedResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, .mx:source() shall identify the repository that is the PlaceOfPrintingFrom as defined in ISO/IEC 21000-6. (Section 9.6.12 [1])

8.3.2.17 mx:ReduceIf mx:Reduce is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the ReducedResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request, .mx:source() shall identify the repository that is the PlaceOfReducing as defined in ISO/IEC 21000-6. (Section 9.6.13 [1])

48

ISO/IEC CD 21000-88.3.2.18 mx:UninstallIf mx:Uninstall is used as the Right Member of an authorization request, then both the Resource Member of that authorization request shall be present and shall identify the UninstallingResource as defined in ISO/IEC 21000-6 and, letting be the Authorization Context Member of that authorization request .mx:source() shall identify the repository that is the PlaceOfUninstalling as defined in ISO/IEC 21000-6. (Section 9.6.14 [1])

8.3.3 Rule Validation Examples

For some of the rules, examples are provided to show how the rule is accomplished and how the rule can be violated.

8.3.3.1Examples for r:obtain

The example below shows an REL Authorization Request file that accomplishes the rule for r:obtain listed in Section 2.2.2.

8.3.3.1.1 Example that Accomplishes the RuleThe highlighted parts are:

• The Resource member of the Authorization Request that shall be present and shall be a r:grant or r:grantGroup.

• The Context member that shall be present and shall identify the Principal who is requested to be the issuer of the license.

<RELAuthorizationRequest xmlns="urn:mpeg:mpeg21:2003:01-SW-NS:REL" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 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:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:mpeg:mpeg21:2003:01-SW-NS:REL sw-rel.xsd">

<principal>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</principal>

<right>

<r:obtain/>

</right>

<resource>

<r:grant>

<mx:play/>

<r:digitalResource>


49

ISO/IEC CD 21000-8</r:digitalResource>





</r:grant>

</resource>

<interval>

<RELInterval>

<start>2003-10-29T17:00:00</start>

<end>2003-10-29T18:00:00</end>

</RELInterval>

</interval>

<context>

<RELAuthorizationContext>

<properties>

<property>

<RELPropertyName>

<qname>

<RELQName>

<ns>urn:mpeg:mpeg21:2003:01-REL-R-NS</ns>

<local>fulfiller</local>

</RELQName>

</qname>

<parameters/>

</RELPropertyName>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>

<dsig:Modulus>X0j9q99yzA==</dsig:Modulus>


</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</property>

<property>

<RELPropertyName>

<qname>

<RELQName>


<local>issueTime</local>

</RELQName>

</qname>

<parameters>

50

ISO/IEC CD 21000-8 <r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:obtain/>

<r:grant>

<mx:play/>

<r:digitalResource>







</r:grant>





</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>


51

ISO/IEC CD 21000-8 <dsig:Exponent>AQABAA==</dsig:Exponent>

</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</parameters>

</RELPropertyName>

<RELSimple xsi:type="xsd:dateTime">2003-11-21T17:00:00</RELSimple>

</property>

<property>

<RELPropertyName>

<qname>

<RELQName>


<local>issueContext</local>

</RELQName>

</qname>

<parameters>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:obtain/>

<r:grant>

<mx:play/>

<r:digitalResource>







</r:grant>





</r:grant>

52

ISO/IEC CD 21000-8 <r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:obtain/>

<r:grant>

<mx:play/>

<r:digitalResource>







</r:grant>


53

ISO/IEC CD 21000-8 <r:notBefore>2003-01-01T00:00:00</r:notBefore>



</r:grant>


<properties/>

</RELAuthorizationContext>

</parameters>

</RELPropertyName>

<RELSimple xsi:type="xsd:string">true</RELSimple>

</property>

</properties>


</context>

<licenses>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:obtain/>

<r:grant>

<mx:play/>

<r:digitalResource>







</r:grant>





</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

54

ISO/IEC CD 21000-8<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

</licenses>

<roots>

<r:grant>

<r:forAll varName="anyResource"/>

<r:issue/>

<r:resource varRef="anyResource"/>

</r:grant>

</roots>

</RELAuthorizationRequest>

8.3.3.1.2 Example that Violates the RuleThe example below shows a REL Authorization Request file that does not accomplish the rule for r:obtain in Section 2.2.2, because of the resource member of the authorization request does not identify a r:grant or r:grantGroup because it is empty.


<principal>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</principal>

<right>

<r:obtain/>

</right>

<resource/>

55

ISO/IEC CD 21000-8<interval>

<RELInterval>

<start>2003-10-29T17:00:00</start>

<end>2003-10-29T18:00:00</end>

</RELInterval>

</interval>

<context>


<properties>

<property>

<RELPropertyName>

<qname>

<RELQName>


<local>fulfiller</local>

</RELQName>

</qname>

<parameters/>

</RELPropertyName>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</property>

<property>

<RELPropertyName>

<qname>

<RELQName>



</RELQName>

</qname>

<parameters>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>


56

ISO/IEC CD 21000-8 <dsig:Exponent>AQABAA==</dsig:Exponent>

</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:obtain/>

<r:grant>

<mx:play/>

<r:digitalResource>







</r:grant>





</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</parameters>

</RELPropertyName>

57

ISO/IEC CD 21000-8 <RELSimple xsi:type="xsd:dateTime">2003-11-21T17:00:00</RELSimple>

</property>

<property>

<RELPropertyName>

<qname>

<RELQName>



</RELQName>

</qname>

<parameters>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:obtain/>

<r:grant>

<mx:play/>

<r:digitalResource>







</r:grant>





</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



58

ISO/IEC CD 21000-8 </dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:obtain/>

<r:grant>

<mx:play/>

<r:digitalResource>







</r:grant>





</r:grant>


<properties/>


59

ISO/IEC CD 21000-8</parameters>

</RELPropertyName>


</property>

</properties>


</context>

<licenses>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:obtain/>

<r:grant>

<mx:play/>

<r:digitalResource>







</r:grant>





</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

60

ISO/IEC CD 21000-8</r:keyHolder>

</r:issuer>

</r:license>

</licenses>

<roots>

<r:grant>


<r:issue/>


</r:grant>

</roots>


8.3.3.2Examples for mx:adapt

The example below shows a REL Authorization Request file that accomplishes the rule for mx:adapt listed in Section 2.2.5.

8.3.3.2.1 Example that Accomplishes the Rules The highlighted parts are:

• The resource member of the authorization request that shall be present and shall identify the source of adaptation.

• The context member that shall be present and shall identify the repositories.


<principal>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</principal>

<right>

<mx:adapt/>

</right>

<resource>

<r:digitalResource>

<r:nonSecureIndirect URI="http://www.onlinephotos.com/Image.jpg"/>

61

ISO/IEC CD 21000-8</r:digitalResource>

</resource>

<interval>

<RELInterval>

<start>2003-10-29T17:00:00</start>

<end>2003-10-29T17:59:59</end>

</RELInterval>

</interval>

<context>


<properties>

<property>

<RELPropertyName>

<qname>

<RELQName>

<ns>urn:mpeg:mpeg21:2003:01-REL-MX-NS</ns>

<local>source</local>

</RELQName>

</qname>

<parameters/>

</RELPropertyName>

<r:keyHolder>

<r:info>

<dsig:KeyName>sourceDevice</dsig:KeyName>

</r:info>

</r:keyHolder>

</property>

<property>

<RELPropertyName>

<qname>

<RELQName>


<local>destination</local>

</RELQName>

</qname>

<parameters/>

</RELPropertyName>

<r:keyHolder>

<r:info>

<dsig:KeyName>destinationDevice</dsig:KeyName>

</r:info>

</r:keyHolder>

</property>

<property>

<RELPropertyName>

<qname>

62

ISO/IEC CD 21000-8<RELQName>



</RELQName>

</qname>

<parameters>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:adapt/>

<r:digitalResource>



</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

63

ISO/IEC CD 21000-8</parameters>

</RELPropertyName>


</property>

<property>

<RELPropertyName>

<qname>

<RELQName>



</RELQName>

</qname>

<parameters>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:adapt/>

<r:digitalResource>



</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

64

ISO/IEC CD 21000-8 <dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:adapt/>

<r:digitalResource>



</r:grant>


<properties/>


</parameters>

</RELPropertyName>


</property>

</properties>


</context>

<licenses>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

65

ISO/IEC CD 21000-8 <mx:adapt/>

<r:digitalResource>



</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

</licenses>

<roots>

<r:grant>


<r:issue/>


</r:grant>

</roots>


8.3.3.2.2 Example that Violates the RulesThe example below shows an REL Authorization Request that does not accomplish the rule for mx:adapt in Section 2.2.5, because of the Resource member of the Authorization Request does not identify a source of adaptation because it is empty.


<principal>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

66

ISO/IEC CD 21000-8</r:keyHolder>

</principal>

<right>

<mx:adapt/>

</right>

<resource/>

<interval>

<RELInterval>

<start>2003-10-29T17:00:00</start>

<end>2003-10-29T17:59:59</end>

</RELInterval>

</interval>

<context>


<properties>

<property>

<RELPropertyName>

<qname>

<RELQName>


<local>source</local>

</RELQName>

</qname>

<parameters/>

</RELPropertyName>

<r:keyHolder>

<r:info>

<dsig:KeyName>sourceDevice</dsig:KeyName>

</r:info>

</r:keyHolder>

</property>

<property>

<RELPropertyName>

<qname>

<RELQName>


<local>destination</local>

</RELQName>

</qname>

<parameters/>

</RELPropertyName>

<r:keyHolder>

<r:info>

<dsig:KeyName>destinationDevice</dsig:KeyName>

</r:info>

</r:keyHolder>

67

ISO/IEC CD 21000-8</property>

<property>

<RELPropertyName>

<qname>

<RELQName>



</RELQName>

</qname>

<parameters>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:adapt/>

<r:digitalResource>



</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



68


</dsig:KeyValue>

</r:info>

</r:keyHolder>

</parameters>

</RELPropertyName>


</property>

<property>

<RELPropertyName>

<qname>

<RELQName>



</RELQName>

</qname>

<parameters>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:adapt/>

<r:digitalResource>



</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

69

ISO/IEC CD 21000-8 </r:license>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:adapt/>

<r:digitalResource>



</r:grant>


<properties/>


</parameters>

</RELPropertyName>


</property>

</properties>


</context>

<licenses>

<r:license>

<r:grant>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



70


</dsig:KeyValue>

</r:info>

</r:keyHolder>

<mx:adapt/>

<r:digitalResource>



</r:grant>

<r:issuer>

<r:keyHolder>

<r:info>

<dsig:KeyValue>

<dsig:RSAKeyValue>



</dsig:RSAKeyValue>

</dsig:KeyValue>

</r:info>

</r:keyHolder>

</r:issuer>

</r:license>

</licenses>

<roots>

<r:grant>


<r:issue/>


</r:grant>

</roots>


8.3.4 References1. w5839, ISO/IEC 21000, Part 5, Rights Expression Language, FDIS, July 2003.2. w5931, MPEG-21 REL/RDD Software Implementation Plan v.4, Brisbane, Australia, October

2003.3. w5842, ISO/IEC 21000, Part 6, Rights Data Dictionary, FDIS, July 2003.4. w6068, ISO/IEC 21000, Part 8, MPEG-21 Reference Software, Working Draft v3.0, Brisbane,

Australia, October 2003.

71

international organisation for … · web viewthis section is meant to summarize the validation...

Documents