Iso/Iec Tc Jtc1/Sc 29 N

INTERNATIONAL ORGANISATION FOR STANDARDISATION ORGANISATION INTERNATIONALE NORMALISATION ISO/IEC JTC 1/SC 29/WG 11 CODING OF MOVING PICTURES AND AUDIO

ISO/IEC JTC 1/SC 29/WG 11/N6783 October 2004, Palma de Majorca

Source: Multimedia Description Schemes Group Title: MPEG-21000:15-Event Reporting Committee Draft Status: APPROVED Editors: FX Nuttall, Youngjoo Song, Kyunghee Ji, A Tokmakoff, N Rump ISO/IEC JTC1/SC 29 N 6783

Date: 2004-09-16

ISO/IEC CD 21000-15

ISO/IEC TC JTC1/SC 29/WG 11

Secretariat: JISC

Information technology — Multimedia framework (MPEG-21) — Part 15: Event Reporting

Technologies de l'information — Cadre de multimédia (MPEG-21) — Partie 15: Communication d'événements

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.

Document type: International Standard Document subtype: Document stage: (30) Committee Document language: E

D:\Docs\2018-02-08\0d29f5f333800934a7337affd2f30a88.doc STD Version 2.1c2 ISO/IEC CD 21000-15 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: ISO Copyright Office Case postale 56 – CH-1211 Geneva 20 Tel. +41 22 749 01 11 Fax. +41 22 749 09 47 E-mail [email protected] Web www.iso.org

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

Violators may be prosecuted.

Contents Page

1 Scope...... 1 1.1 Background to Event Reporting...... 1 1.2 Organisation of the Document...... 2 2 Normative References...... 2 3 Terms and Definitions...... 2 4 Symbols and Abbreviated Terms...... 3 5 Reference Architecture...... 4 5.1 Creating and Processing Event Reports...... 5 5.2 Relationship of Event Reporting with other Parts of MPEG-21...... 5 6 Event Report Requests...... 6 6.1 High-level Structure...... 6 6.1.1 Syntax...... 6 6.1.2 Semantics...... 6 6.2 Event Report Request Descriptor...... 7 6.2.1 Syntax...... 7 6.2.2 Semantics...... 7 6.2.3 Event Report Request Lifetime...... 7 6.2.3.1 Syntax...... 8 6.2.3.2 Semantics...... 8 6.2.3.3 Example (informative)...... 8 6.2.4 Event Report Request History...... 8 6.2.4.1 Syntax...... 8 6.2.4.2 Semantics...... 9 6.2.4.3 Example (informative)...... 9 6.2.5 Event Report Request Priority...... 9 6.2.5.1 Syntax...... 9 6.2.5.2 Semantics...... 10 6.2.5.3 Example (informative)...... 10 6.3 Event Report Descriptor...... 10 6.3.1 Syntax...... 10 6.3.2 Semantics...... 10 6.3.3 Event Report Identifier...... 11 6.3.4 Event Report Description...... 11 6.3.4.1 Syntax...... 11 6.3.4.2 Semantics...... 11 6.3.4.3 Example...... 11 6.3.5 Event Report Access Control...... 12 6.3.6 Event Report Data...... 12 6.3.6.1 Syntax...... 12 6.3.6.2 Semantics...... 13 6.3.6.3 Example...... 13 6.3.7 Event Report Data Format...... 14 6.3.7.1 Syntax...... 14 6.3.7.2 Semantics...... 14 6.3.7.3 Example (informative)...... 14 6.3.8 Embedded Event Report Requests...... 15 6.3.8.1 Syntax...... 15 6.3.8.2 Semantics...... 15 6.3.8.3 Example (informative)...... 15 6.3.9 Event Report Delivery Parameters...... 16 6.3.9.1 Syntax...... 16 6.3.9.2 Semantics...... 16 6.3.9.3 Examples (informative)...... 16

IV © ISO/IEC 2004 – All rights reserved ISO/IEC CD 21000-15 6.4 Event Condition Descriptor...... 17 6.4.1 Syntax...... 17 6.4.2 Semantics...... 17 6.4.3 Time-based Events...... 18 6.4.3.1 Syntax...... 18 6.4.3.2 Semantics...... 18 6.4.3.3 Examples (informative)...... 18 6.4.4 Digital Item-related Events...... 19 6.4.4.1 Syntax...... 19 6.4.4.2 Semantics...... 20 6.4.4.3 Example (informative)...... 20 6.4.5 Peer-related Events...... 20 6.4.5.1 Syntax...... 20 6.4.5.2 Semantics...... 21 6.4.5.3 Example (informative)...... 21 7 Event Reports...... 21 7.1 High-level Structure...... 22 7.2 Event Report Descriptor...... 22 7.2.1 Syntax...... 22 7.2.2 Semantics...... 23 7.2.3 Event Report Description...... 23 7.2.3.1 Syntax...... 23 7.2.3.2 Semantics...... 23 7.2.3.3 Example (informative)...... 23 7.2.4 Event Report Status...... 24 7.2.4.1 Syntax...... 24 7.2.4.2 Semantics...... 24 7.2.4.3 Example (informative)...... 24 7.2.5 Creation...... 24 7.2.5.1 Syntax...... 24 7.2.5.2 Semantics...... 24 7.2.5.3 Example (informative)...... 25 7.3 Event Report Source...... 25 7.3.1 Syntax...... 25 7.3.2 Semantics...... 25 7.3.3 Example...... 25 7.4 Event Report Data...... 25 7.4.1 Syntax...... 25 7.4.2 Semantics...... 26 7.4.3 Example (Informative)...... 26 7.5 Embedded Event Report Requests...... 27 7.5.1 Syntax...... 27 7.5.2 Semantics...... 27 7.5.3 Example (informative)...... 27 8 General Aspects of Event Reporting...... 28 8.1 Carriage of Event Report Requests and Event Reports in Digital Items...... 28 8.2 Reference to other parts of MPEG-21...... 28 8.2.1 MPEG-21000:3 - Digital Item Identification...... 28 8.2.2 ISO/IEC 21000-4 - Intellectual Property Management and Protection...... 28 8.2.3 MPEG-21000:5 - Rights Expression Language...... 29 8.2.4 MPEG-21000:6 - Rights Data Dictionary is used to define:...... 29 8.2.5 Binary Format (as defined in ISO/IEC 21000-16)...... 29 9 Data Types...... 29 9.1 TimeType...... 29 9.1.1 Syntax...... 29 9.1.2 Semantics...... 30 9.1.3 Example (Informative)...... 31 9.2 ModificationType...... 31 9.2.1 Syntax...... 31 9.2.2 Semantics...... 32 9.2.3 Example...... 32 9.3 DIOperationType...... 32

© ISO/IEC 2004 – All rights reserved V ISO/IEC CD 21000-15 9.3.1 Syntax...... 32 9.3.2 Semantics...... 32 9.3.3 Example...... 32 9.4 PeerId Type...... 32 9.4.1 Syntax...... 32 9.4.2 Semantics...... 32 9.4.3 Example...... 32 9.5 UserId Type...... 32 9.5.1 Syntax...... 32 9.5.2 Semantics...... 33 9.5.3 Example...... 33 9.6 EventConditionGroup...... 33 9.6.1 Syntax...... 33 9.6.2 Semantics...... 34 9.6.3 Example...... 34 9.7 ExternalOperator...... 34 9.7.1 Syntax...... 34 9.7.2 Semantics...... 35 9.7.3 Example...... 35 9.8 InternalOperator...... 35 9.8.1 Syntax...... 35 9.8.2 Semantics...... 35 9.8.3 Example...... 36 Annex A (informative) XML Schema Definition...... 37

Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

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

The main task of technical committees is to prepare International Standards. Draft International Standards adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member 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 shall not be held responsible for identifying any or all such patent rights.

ISO/IEC 21000-15 was prepared by Technical Committee ISO/TC JTC1, 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 1: Vision, Technologies and Strategy;

 Part 2: Digital Item Declaration (DID);

 Part 3: Digital Item Identification (DII);

 Part 4: Intellectual Property Management (IPMP);

 Part 5: Rights Expression Language (REL);

 Part 6: Rights Data Dictionary (RDD);

 Part 7: Digital Item Adaptation (DIA);

 Part 8: Reference Software;

 Part 9: File Format;

 Part 10 Digital Item Processing (DIP);

 Part 11: Evaluation Methods for Persistent Association Technologies (PAT);

 Part12: Test Bed for MPEG-21 Resource Delivery;

 Part 13: Scalable Video Coding (SVC);

 Part 14: Conformance Testing;

 Part 15: Event Reporting (ER);

 Part 16: Binary Format.

Executive Summary for MPEG-21

Today, many elements exist to build an infrastructure for the delivery and consumption of multimedia content. There is, however, no 'big picture' to describe how these elements, either in existence or under development, relate to each other. The aim for MPEG-21 is to describe how these various elements fit together. Where gaps exist, MPEG-21 will recommend which new standards are required. ISO/IEC JTC 1/SC 29/WG 11 (MPEG) will then develop new standards as appropriate while other relevant standards may be developed by other bodies. These specifications will be integrated into the multimedia framework through collaboration between MPEG and these bodies.

The result is an open framework for multimedia delivery and consumption, with both the content creator and content consumer as focal points. This open framework provides content creators and service providers with equal opportunities in the MPEG-21 enabled open market. This will also be to the benefit of the content consumer providing them access to a large variety of content in an interoperable manner.

The vision for MPEG-21 is to define a multimedia framework to enable transparent and augmented use of multimedia resources across a wide range of networks and devices used by different communities.

This 15th part of MPEG-21 (ISO/IEC 21000-15) specifies Event Report Requests and Event Reports and how to use these in an MPEG-21 environment.

Information technology — Multimedia framework (MPEG-21) — Part 15: Event Reporting

1 Scope

This fifteenth part of MPEG-21, entitled Event Reporting, specifies:

• How to express Event Report Requests (ER-R) that contain information about which events to report, what information is to be reported and to whom;

• How to express Event Reports (ER) which are created by an MPEG-21 Peer in response to an Event Report Request when the condition of the ER-R is met; and

• How to use Digital Items – as specified in ISO/IEC 21000-2 – to package Event Reports and Event Report Request.

1.1 Background to Event Reporting

MPEG-21 has identified the need for Event Reporting in its vision for an interoperable multimedia framework. MPEG experts have therefore become engaged in the process of defining the detailed requirements for Event Reporting in order to understand what it might be appropriate for MPEG to specify. This document introduces the need for Event Reporting and a set of requirements that have been identified.

Event Reporting is required within the MPEG-21 Multimedia Framework in order to provide a standardised means for sharing information about Events amongst Peers and Users. Such Events relate to Digital Items and/or Peers that interact with them.

One example relates to the monitoring of the usage of copyrighted material. The provider offering Digital Items for download would specify in an Event Report Request that, whenever a Resource within a Digital Item is rendered (e.g. played), he would receive an Event Report enabling him to manage his royalties. Upon rendering, the Peer will generate an MPEG-21 Event Report which will be delivered to the rights holder specified, in an Event Report Request, containing information about the Digital Item, the Resource, and the conditions under which it has been rendered.

In another example, Event Reports are necessary for network nodes to know the exact connectivity condition between two Peers when trying to deliver Digital Items. While a network Peer may receive Digital Items from some Peers and forward them to other Peers in its network, the network Peer will monitor its load. When a critical threshold is reached, an Event Report may be created and sent to neighbouring network Peers who will in turn re-route their Digital Items to avoid the congested network Peer.

Fundamentally, Event Reporting in MPEG-21 will benefit Users by:

 Standardising metrics and interfaces for performance of all reportable events in MPEG-21;

 Providing a means of capturing and containing these metrics and interfaces that refers to identified Digital Items, Peers, environments, processes, transactions and Users.

Examples where Event Reports may be requested include:

 Usage reports:

 Copyright reports;

 Monitoring of Performances;

 Marketing information;

 Technical reports:

 Bandwidth usage/Availability;

 Network congestion;

 Load balancing;

 Financial reports:

 Proof of purchase;

 License purchase and delivery.

1.2 Organisation of the Document

This standard comprises eight clauses. This first clause provides scope and the organisation of the specification. Clauses 2 to 4 contain a set of references, terms and definitions and abbreviations.

Clause 5 introduces a high level architecture for Event Reporting before Clauses 6 and 7 specify syntax and semantics of Event Report Request, and Event Reports. Clause 8 then specifies how to use Event Reporting within the context of other MPEG-21 Parts and clause 9 specifies the data types that are frequently used throughout the standard..

Finally, Annex A contains the XML Schema definition for the descriptors defined in Clauses 6 and 7.

2 Normative References

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.

ISO/IEC TR 21000 – Information Technology – Multimedia Framework (MPEG-21). All Parts

IETF RFC 2396. Uniform resource identifiers (URI): Generic syntax. 1988

IETF RFC 2141. Uniform Resource Name (URN). 1998

IETF RFC 1738. Uniform Resource Locators (URL). 1994

W3C. XML Schema – Part 1 Structures. 2001

W3C. XML Schema – Part 2. Data types. 2001

3 Terms and Definitions

For the purposes of this document, the following terms and definitions apply.

3.1 Digital Item Structured digital object with a standard representation, identification and metadata within the MPEG-21 framework.

3.3 Event The occurrence of a reportable activity.

3.4 Event Report The representation of an Event(s) as specified by the related Event Report Request.

3.5 Event Reporting An MPEG-21 Standard that provides a means to exchange information about Events, between Peers.

3.6 Event Report Request A request to report an Event(s).

3.7 Peer A Peer is a device or application that compliantly processes a Digital Item.1)

3.8 User User of a system. This includes all members of the value chain (e.g., creator, rights holders, distributors and consumers of Digital Items)

4 Symbols and Abbreviated Terms

DI Digital Item

DID Digital Item Declaration

DII Digital Item Identification

ER Event Report

ERL Event Reporting Language

ER-R Event Report Request

REL Rights Expression Language

RDD Rights Data Dictionary

1) The term “Terminal” has been deliberately avoided because of its connotation as being the end point in a chain of communication. However, the term Peer explicitly also includes devices or applications that create or alter Digital Items.

The diagram below depicts the general reference architecture for Event Reporting within MPEG-21. The architecture distinguishes five elements within a Peer that act upon receiving an Event Report Request. These elements are:

 Event Report Request Receiver (responsible for receiving an Event Report Request from another Peer);

 Event Report Request Parser (responsible for interpreting Event Report Requests);

 Event Watchdog (responsible for monitoring Events and detecting when ER-R conditions have been fulfilled);

 Event Report Builder (responsible for assembling reportable Event data and creating an Event Report); and

 Event Report Dispatcher (responsible for taking an Event Report and sending it off to the designated recipient Peers). g r r o r e e r d v e h i e s h c e r t c d l c t a i a a e u P p

R s B W i

R t - D R R

- n R

MPEG-21 Peer E e R R E v E E E

Event Report Request Event Report (ER-R) (ER)

Event 1.DI-related-User operations

2.Peer-related-internal processes

Figure 1 — Conceptual Diagram of Event Reporting

An Event Report Request (ER-R) is used to define the conditions (predicates) under which an Event is deemed to have occurred. Events defined by ER-Rs trigger the creation of an associated Event Report (ER), which contains information describing the Event, as specified in the associated ER-R.

Event Reporting is used to report on the occurrence of Events which may be either directly or indirectly related either to a DI or a Peer. The scope of Event Reporting scope is limited to reporting of Events between Peers, and does not include internal reporting of Events within a Peer.

This standard only specifies the syntax and semantics of Event Report Requests and Event Reports and how they can be integrated with other parts of MPEG-21.

Within MPEG-21 Event Reporting there are two major classes of “reportable” Events: a) Events which are generated as a result of User-related-operations on a specific instance of a Digital Item; and b) Events which are generated within a Peer that are related to internal Peer processes.

The Events listed under (a) only concern the usage of Digital Items. For example, when a Digital Item is played, this is considered to be a reportable Event as it deals exclusively with operations on a specific Digital Item instance.

In contrast, Events listed under (b) are associated with a Peer, rather than a specific Digital Item instance. These Events concern Peer actions and do not need to be related to interaction with Digital Item instances. They can be the result of any internal Peer process. For example, when a Peer detects that it has lost network connectivity, falls into this category.

The handling of Peer-related Events is not currently specified in this standard.

Event Report Requests are defined by a User. It comprises of, at least:

 A description of the Event;

 The syntax/format of the Event Report;

 The recipient(s) of the Event Report;

 Parameters related to delivery of the Event Report (e.g. recipients or time of delivery delivery mechanisms, ).

Upon the Event occurring, an Event Report may be generated and delivered to the specified recipient(s). The Event Report Request may specify that the generation and delivery of an Event Report is mandatory; this would be implemented using, for example, the Event Report Request as an “obligation” of a Rights Expression. This topic is discussed in further detail in Clause 8.2.

Event Reports, being Digital Items, will inherit their characteristics allowing identification, description and interaction with other MPEG-21 parts.

5.2 Relationship of Event Reporting with other Parts of MPEG-21

While it is possible to store and exchange Event Report Requests and Event Reports outside an MPEG-21 Digital Item, Clause of this specification defines how Event Report Requests and Event Reports are contained in Digital Items, more specifically a Digital Item Declaration as defined in ISO/IEC 21000-2.

The inclusion of Event Report Requests and Event Reports inside a Digital Item is shown in the XML example in Clause 8.1 provides a detailed description on how Event Report Requests and Event Reports are represented as Digital Items.

A detailed description of how other parts of MPEG-21 are integrated within Event Reporting is provided in clause 8

6 Event Report Requests

As indicated in section 5, the basic model of Event Reporting indicates that Events that need to be reported are specified by interested parties through the use of an Event Report Request. The ER-R’s purpose is to:

• describe the Event which is to be reported,

• indicate which Peers the Event should be reported to, and

The following clauses provide details on the syntax and semantics of ER-Rs.

6.1 High-level Structure

Event Report Requests are composed of three main sections as shown in Table1. Each main section comprises of several parts, which are specified in subsequent sub-clauses.

Event Report Requests are represented as DIs and to the maximum extent are using other parts of MPEG-21.

In this context there are 2 elements that need to be inserted, when applicable, at the top level of each DI containing an Event Report Request, before the Event Report Request Descriptor.

These 2 elements are:

 Event Report Request identifier  Event Report Request access control information

The syntax for specifying these 2 elements are provided in Clause ??

6.1.1 Syntax

6.1.2 Semantics

Table 1 — High-level Structure of Event Report Requests

Name Definition ERR Serves as the root element for describing an entire Event Report Request. ERRDescriptor Provides a description of the ERR including aspects such as the Lifetime, History and Priority of the ERR. See Clause 6.2 for a more detailed explanation. ERDescriptor Provides a description of the ER(s) which result from processing of this ERR. Contains aspects such as the Data items to be reported, the format they should be reported in, details of an optional embedded ERR, etc. See Clause 6.3 for a more detailed explanation. EventConditionDescriptor Provides a description of the conditions under which the ERR is deemed to have occurred. This may relate to DI-Operation-based conditions or Peer-based conditions. Clause 6.4 for a more detailed explanation.

An Event Report Request Descriptor’s purpose is to provide a mechanism to allow description of general ER- R parameters. It is in some ways analogous to a “header”, often used in communications protocols, since it provides general parameters of the ER-R.

For example, each ER-R includes a lifetime specification, which is used to indicate a validity period for the specific ER-R. Such a parameter is general in nature and can be utilised by all ER-Rs.

6.2.1 Syntax

6.2.2 Semantics

Table 2 Semantics of the Event Report Request Descriptor

Name Definition Descriptor Describes a specific Event Report Request instance. LifeTime Defines the expected lifetime of the Event Report Request. History Maintains an audit trail of the Event Report Request. Priority Provides the priority level of the Event Report Request. An Event Report Request with a “high” priority level should be processed in an expedited manner by a Peer.

6.2.3 Event Report Request Lifetime

This clause defines a Descriptor that specifies the lifetime of an ER-R, i.e. the period during which a Peer is requested to report on the occurrence of events, as defined by the ER-R. When such a time period has expired, the Peer is free to dispose of the ER-R as it feels fit. Note that this also means that if relevant events occur outside of the defined time period, the Peer will not create an associated Event Report.

6.2.3.1 Syntax

6.2.3.2 Semantics

Name Definition StartTime Start of the ER-R’s lifetime. The Peer is requested to activate the ER-R as of the specified moment in time. EndTime End of the ER-R’s lifetime. The Peer is requested to de-activate the ER-R as of the specified moment in time

6.2.3.3 Example (informative)

The following example shows the use of the ERRLifeTime descriptor for describing the lifetime of an Event Report Request. In this example, the Peer that receives the Event Report Request is only requested to create Event Reports between 1st July 2004 and 8th July 2004. It may also dispose of the ER-R after this period.

2004-07-01T00:00:00 2004-07-08T00:00:00

6.2.4 Event Report Request History

This clause defines a descriptor that represents the history of an ER-R, including its creation and subsequent modification. Both Creation and Modification are defined by specific data type.

Creation is of type CreationType as defined in clause 9.1.3.

Modification is of type ModificationType as defined in clause 9.2.

6.2.4.1 Syntax

6.2.4.2 Semantics

Name Definition History Provides an audit trail of ER-R modifications. Creation Information relating to the initial creation of the Event Report Request.

6.2.4.3 Example (informative)

The following example shows the use of the History descriptor for describing the creation and modification history of an Event Report Request.

GUID:1AC5-4527-A864-3EA2 2004-07-03T24:00:00 ERR Created

GUID:1AC5-4527-A864-3EA2 CISAC:IPI:P-1435 6382 2004-07-04T24:00:00 Add "Location" item to the ReportData

GUID:54A9-32CA-9836-AC30 CISAC:IPI:P-1435 6382 2004-07-05T24:00:00

6.2.5 Event Report Request Priority

This field specifies a Priority Level for the Event Report Request. It allows ER-R’s to be identified as being of high priority and thus, to be serviced by a Peer before other ER-R’s of lower priority.

6.2.5.1 Syntax

6.2.5.2 Semantics

Name Definition PriorityLevel Specifies the priority level for an ER-R. Priority levels are designated “0”, “1”, “2”, “3”, “4” and “5”,

© ISO/IEC 2004 – All rights reserved 9 ranging from highest priority to lowest. Event Report Requests shall be processed according to their assigned priority. When two Event Report Requests have the same assigned priority, the Peer may make an arbitrary decision regarding the order in which they are processed. If no Priority level is given, level 2 is assumed, which corresponds to a “middle” priority.

6.2.5.3 Example (informative)

The following example shows the use of the ERRPriorityLevelType element for setting the priority level of an Event Report. This ER-R shall be processed with the highest priority level.

6.3 Event Report Descriptor

6.3.1 Syntax

6.3.2 Semantics

Name Definition ERDescriptorInERR Describes Event Report(s) that will be created as the result of processing the associated ER-R. Identifier Specifies a unique identifier to be used in the ER which is created as a result of an ER-R. See Clause 6.3.3. Description Free form string field to provide comments on the Event Report. See Clause 6.3.4. AccessControl Provides information about which Peers and/or Users are allowed to access the ER. See Clause 6.3.5. Data Specifies the data items that to be reported within the ER. See Clause 6.3.6. Format Specifies the format of the reported data items that are reported within the ER. See Clause 6.3.7. EmbeddedERR Provides the priority level of Event Report Request. Event Report Request with a high priority level needs to be processed first. See Clause 6.3.8. DeliveryParams Defines parameters associated with the ER’s recipient(s), delivery time and delivery mechanism(s). See Clause 6.3.9.

This identifier may be unique, in which case it is only valid for the first ER created in association with the ER- R. Alternatively, such an identifier can be a "base" identifier which is used when creating unique identifiers for all related ERs.

6.3.4 Event Report Description

An Event Report Description is a free-form string that provides descriptive comments on the Event Report.

6.3.4.1 Syntax

6.3.4.2 Semantics

Name Definition

Description Free form string field to provide comments on the Event Report.

6.3.4.3 Example

The following example shows the use of the ErDescription in an ERR which provides free form string description to explain the ER which associate ERR wants to get reported

This is ER which MPEG wants to get reported when Andrew plays the “LetItBe.mp3”.

6.3.5 Event Report Access Control

This section specifies access rights which will apply to all Event Reports that are generated as a result of processing an ER-R.

Johnny Dood READ point to the ERR using XPATH in the DI

6.3.6 Event Report Data

This element contains the data fields which are to be reported in the Event Report. The specification of the data fields are provided using either:

 A reference to an external source describing an XML Schema;

In either case, the data fields specified must be referred to using RDD terms.

6.3.6.1 Syntax

Name Definition Data Describes the data that ER-R requests to be reported. The PeerId, UserId, DII, Related DII, Time and Location are optional sub-elements which can be requested to be sent when a specified Event occurs. PeerId Peer that will create the ER. UserId User that will create the ER. Time Time as returned by the Peer Location Location information of Peer. DII Referenced DII Related DII Related DII DIOperation One of the registered Verbs within the RDD. DIMetadata This is an identifier pointing to the element that needs to be reported from the DI identified by the DII.

DIMetadata is a Digital Item Identifier as specified in MPEG-21000:3.

In the referenced Digital Item, will need to carry local Identifiers in the form …. We will then use Xpath to identify the specific XML tags to be reported.

6.3.6.3 Example

urn:mpegRA:mpeg21:dii:isrc

6.3.7 Event Report Data Format

Event Reports have payload data that contains the data fields that an Event Report has been requested to contain (as specified in clause 6.3.6). However, the format of the data in the Event Report also needs to be specified, to ensure that it can be correctly interpreted by Peers that receive the ER. It is the purpose of Event Report Data Format to provide a means to describe the format of the Event Report’s payload data.

There are four methods that can be used:

• a reference to an externally located schema that defines the syntax of the payload data,

• an inline schema that defines the syntax of the payload data,

• a mime type which indicates that the format is a well-known type, such as, for example CSV (comma separated file).

• a default XML-based format which is used in the absence of any of the above specifiers

6.3.7.2 Semantics

Name Description

ReportFormat Defines the format of the Event Report contained within the ERData statement

6.3.7.3 Example (informative)

text/xml

6.3.8 Embedded Event Report Requests

For recursive Event Report generation, Event Report Requests can be embedded within Event Reports. Upon receipt of an Event Report that contains an embedded Event Report Request, the receiving Peer shall extract the embedded ER-R and process it accordingly.

This mechanism can, for example, be used for acknowledgment of receipt or for implementing aggregation / forwarding Event Reports.

6.3.8.1 Syntax

Name Definition

EmbeddedERR Describes the embedded ERR. An ERR can be embedded with an ERR or ER for acknowledgment of reception of ERR or ER forwarding of ER.

6.3.8.3 Example (informative)

Example of an embedded ER-R

ID:mepg:mpeg21:DII:ERRDID:002

Example of a reference to an ER-R

6.3.9 Event Report Delivery Parameters

This section defines how, when and to whom the ER will be delivered by defining a set of descriptors.

6.3.9.1 Syntax

Name Definition DeliveryParams Specifies all the relevant parameters for the delivery of Event Reports. Recipient Specifies the Peer and/or User that shall receive the Event Report DeliveryTime Specifies the time of delivery of the Event Report DITransportService Describes the service that transports Digital Items from one Peer to another

6.3.9.3 Examples (informative)

MAC:00-08-E3-AE-1E-62 Andrew

MAC:00-08-E3-AE-1E-64 Andrew

2004-03-31T00:00:00

6.4 Event Condition Descriptor

An Event occurs when a set of specified conditions are met. This clause defines how Conditions are expressed. Elements that can be used to define Conditions under which an Event is deemed to have occurred are:

 Time-based (specifies a time period in which the Event must occur),

 DI-related operations that have been applied to the specified resource, defined by ISO/IEC 21000-6:2004;

 Peer-related operations (events that are related to the Peer itself rather than an instance of a Digital Item),

 Combinations thereof.

In the case of a governed Digital Item, semantics for the conditions may be found in the governing Rights Expression. These semantics shall be used for the expression of Conditions in an Event Report.

6.4.1 Syntax

6.4.2 Semantics

Name Definition EventConditionDescripto Specifies the conditions under which an event is deemed to have occurred. It may consist of r several conditions. EventConditionGroup Specifies the Event conditions. It consists of TimeCondition, DIOperationCondition and PeerCondition. It is defined in Clause 9.6 TimeCondition Specifies a time-based condition. DIOperationCondition Specifies condition on Peer’s DI-related operation. PeerCondition Specifies other event conditions except time-based Condition and DI-related Condition. It enables Users to define new Event Conditions as necessary. This element is used to extend the Event Condition into any other relevant namespace (e.g. DIA, DIP, MPEG-7).

6.4.3 Time-based Events

Event Reports may be requested upon a specific time Event. Event Reporting specifies a number of ways of expressing time Events

All time Events are based on a generic Time type, as described in clause 9.1

6.4.3.1 Syntax

Name Definition TimeEvent TimeEvent is of type TimeType as described in Clause 9.1 Operator It is used when the Event occurs by the combinations of TimeCondition and/or DIOperationCondition. Specifies the logical operators and parenthesis operator. It is of type ExternalOperator is defined in Clause 9.7.

6.4.3.3 Examples (informative)

2004-03-31T00:00:00 In this example, an ER can be created anytime, until March 31st 2004.

P1D P3D In this example, an ER may be created from 1day before the specified time until 3 days after the specified time.

2004-07-01T00:00:00 1W7D P1M P1D 2004-12-31T00:00:00 In this example, an ER may be created on each Sunday of 1st week of month (from July, 2004 to December 2004).

6.4.4 Digital Item-related Events

This element specifies conditions depending in operations on a specific instance of Digital item. The conditions relate to the User who interacts with the Digital Item, the type of interaction and the specific Digital Item (or parts thereof) that a User or Peer interacted with.

The Operation element is of type DIOperationType and is defined in clause 9.3

6.4.4.1 Syntax

6.4.4.2 Semantics

Name Definition UserId Specifies the User who has performed the operation on the DI. PeerId Specifies the Peer who has performed the operation on the DI. Operation Specifies the User action which triggers an Event. It is restricted to being one of the RDD terms. DII Specifies the referenced DI according to MPEG-21000:3. RelatedDII Specifies a DII related to the DII above according to MPEG21000-3. Operator It is used when the Event occurs by the combinations of TimeCondition and/or PeerCondition. Specifies the logical operators and parenthesis operator. It is of type ExternalOperator is defined in clause 9.8.

6.4.4.3 Example (informative)

A typical example of event Reporting is when a Event Report is to be send when a song has been played. The following example specifies that the an Event Report be send when Joe Smith plays the song contained in the Digital Item 0824. The Action "PLAY" is hereby referenced by the RDD identifier (1588:843) as specified in MPEG-21000:6. More information on this syntax may be found in clause 8.2

Jo* Smith urn:mpeg:mpeg21:2002:01-RDD-NS:1588:843 mpeg:mpeg21:DII:DI:08241

6.4.5 Peer-related Events

MPEG-21 Peers may make use of numerous parts of MPEG-21, such as DIA, DIP, IPMP, etc. In addition, Peers may also have functionality that is not part of MPEG-21’s family of standards, yet it wishes to report Events on, or wishes to include data from in Event Reports themselves. Examples include:

• bandwidth-related data that can be used as a Condition for an Event Report, or may be included within a periodic Event Report (i.e. average Peer connectivity status over the last 24 hours).

© ISO/IEC 2004 – All rights reserved 19 • Peer manufacturer characteristics that provide model, brand, firmware version etc., which can be used within a Condition, or contained within an Event Report’s payload data.

These Events and reportable data items are not directly related to a Peer’s operations on DI’s and as such, are classified as Peer-related Events. Such Events and reportable data items are described by terms that are recognized within their own extensible namespace(s).

6.4.5.1 Syntax

6.4.5.2 Semantics

Name Description PeerEvent Specifies other Event Conditions except time-based Condition and DI-related Condition. It is needed for User to be allowed to define a new Event Condition as necessary because it’s impossible to define all kinds of Condition of Events for various Users at this time. Therefore, this element is used to extend the Event Condition from any other namespace. To extend the Event Condition, using this element, define any condition in any other namespace. It can have InternalOperator as attributes. The InternalOperator is defined in clause 9.9. Operator It is used when the Event occurs by the combinations of several conditions. Specifies the logical operators and parenthesis operator. It is of type ExternalOperator as defined in Clause 9.7.

6.4.5.3 Example (informative)

In this example an Event Report will be generated if and when the Peer is located in Korea

As indicated previously, the basic model of Event Reporting indicates that Events that need to be reported (as specified by an ER-R) are represented as an Event Report. The ER’s purpose is to:

 indicate which Peer created the ER,

 define the data items that are to be included in such an Event Report(s).

 provide a reference to the originating ER-R,

 provide status information regarding its completion and creation, along with a free-form description.

The following clauses provide details on the syntax and semantics of ERs.

7.1 High-level Structure

Event Report Requests are composed of thee main sections as shown in table 3. Each main section comprises of several parts, which are specified in subsequent sub-clauses.

Event Reports are represented as DIs and where appropriate, make use existing parts of MPEG-21.

In this context, there is one element that needs to be inserted, when applicable, at the top level of each DI containing the Event Report, before the Event Report Descriptor. This element is the Event Report identifier, whose syntax is provided in Clause 8.2.

Table 3 — Event Report Structure

Main Section Content Event Report Descriptor Description – free-form string field. Status – Provides information on whether the Peer was able to compliantly generate the Event Report. Creation – provides information regarding the creation of the Event Report. Event Report Source Reference to the ER-R that created ER. Event Report Data Contains the “payload” data of the Event Report. Embedded Event Report Request(s) Is an Event Report Request that is associated with the Event Report.

7.2 Event Report Descriptor

Event Reports are always identified by a Digital Item Identifier as specified in ISO/IEC 21000-3. The identification of an ER is ensured by the fact that the Descriptor element (as defined in ISO/IEC 21000-2) containing the ER is uniquely identified by a Digital Item Identifier.

7.2.2 Semantics

Name Definition ERDescriptor Describes an Event Report. Description Free form string field to provide comments on the Event Report Status Represents the completion status of the ER. The value is TRUE if the ER has been properly generated in compliance original ER-R. If a known problem has occurred during the creation of the ER, this flag will be set to FALSE. Creation Provides information regarding the creation of the Event Report.

7.2.3 Event Report Description

Free form string field to provide comments on the Event Report

7.2.3.1 Syntax

7.2.3.2 Semantics

Name Definition

Description Free form string field to provide comments on the Event Report

7.2.3.3 Example (informative)

This is ER which MPEG wants to get reported when Andrew plays the “LetItBe”.

This defines a Boolean flag indicating whether the Peer was able to properly generate the Event Report.

7.2.4.1 Syntax

7.2.4.2 Semantics

Name Definition Status Status value is TRUE if the ER has been generated by the Peer in compliance with the ER-R. The value is FALSE when the Peer encountered errors while generating the Event Report.

7.2.4.3 Example (informative)

The example below indicates that the Event Report has been generated according to all the requirements as described in the relevant ER-R.

7.2.5 Creation

This clause defines a descriptor that describes the creation of the Event Report.

7.2.5.1 Syntax

7.2.5.2 Semantics

Name Definition Creation Information relating to the initial creation of the Event Report.

7.2.5.3 Example (informative)

The following example shows the use of the History descriptor for describing the History of an Event Report Request:

7.3 Event Report Source

The User may ask that along the Event Report, the ER-R that generated the Event Report be provided. This would allow the recipient to cross check the validity of the Event Report.

The Original event Report Request may be provided inline or as a reference.

7.3.1 Syntax

7.3.2 Semantics

Name Definition OriginalERR The Identifier of the ER-R which requested the ER or the Original ER-R itself.

7.3.3 Example

mpeg:mpeg21:dii:ERRID:002

7.4 Event Report Data

This Event Report Data element within an Event Report provides a place for inclusion of “payload” data into an ER. This payload data corresponds to the report data items that were specified in the associated ER-R (see section 6.3.6), which are formatted according to the format specification also included in the originating ER-R (see section 6.3.7).

7.4.1 Syntax

7.4.2 Semantics

Name Definition ERData Embeds data that the Peer reports.

7.4.3 Example (Informative)

IP:192.168.1.21 Play 2004-07-01T00:00:00 dii:mpeg:mpeg21:ERDID:002 Hello sunshine

INSERT ITEM-SPECIFIC XML PAYLOAD HERE

INSERT ITEM-SPECIFIC XML PAYLOAD HERE INSERT ITEM-SPECIFIC XML PAYLOAD HERE

The embedding of an ER-R within an ER can be used for functionalities such as acknowledgment of receipt or forwarding of the Event Report to another Peer. The Embedded ER-R may either be inline, or a reference to an external ER-R.

7.5.1 Syntax

7.5.2 Semantics

Name Definition EmbeddedERR Specifies the embedded ER-R. It can either be the ER-R itself or a reference to it. An ER-R can be embedded with an ER for acknowledgment of reception of an ER or forwarding of that ER.

7.5.3 Example (informative)

Example: An ER-R, fully embedded within the ER.

ID:mepg:mpeg21:DII:ERRDID:002

Example: An ER-R, only referenced within the ER.

8 General Aspects of Event Reporting

8.1 Carriage of Event Report Requests and Event Reports in Digital Items

Both ER and ER-R are represented as Digital Items, and therefore natively inherit all of the properties of Digital Items.

Event Reports Requests and Event Reports are encapsulated in descriptor elements.

A Digital Item may contain any number of Event Report Requests or Event Reports.

Figure 2 — Example of an Event Report embedded within a Digital Item

8.2 Reference to other parts of MPEG-21

Event Reporting is making use whenever possible to all the other parts of MPEG-21. The other parts of MPEG-21 as referenced by Event Reporting as follows:

8.2.1 MPEG-21000:3 - Digital Item Identification

This part is used to identify all Digital Items, or parts thereof. All Event Report Request and Event Reports carry at least a DII statement at the top level of their respective Digital Item.

8.2.2 ISO/IEC 21000-4 - Intellectual Property Management and Protection.

This part is used to govern Event Report Requests and Event Reports and to make the creation and sending of Event Reports a condition of rights expressions governing content Digital Items;

8.2.3 MPEG-21000:5 - Rights Expression Language

This part is used to define the access rights that are granted to the Users of Event Reports and Event Report Request. The REL expression, if present, will be inserted at the top level of the Digital Item containing the Event Report Request or the Event Report. Further, the proper execution of an Event Report Request may be an “obligation” expressed by a Rights Expression

8.2.4 MPEG-21000:6 - Rights Data Dictionary is used to define:

This part is used to specify:

 the terms that will be used when tracking the modifications of Event Report Requests o The only verb that may be used is Modify. More specific Action (ie. delete) may be described in the associated free form description field.  the actions on Digital Items that may represent a Event condition o The actions that may be reported upon:  Play  Move

< mpeg:mpeg21ra:RDD:xxx:yyy>

Where xxx is the RDD identifier as defined in Annex 5 of MPEG-21000:6 and yyy is an identifier t be defined by the RDD registration authority.

Note: this exact syntax is not definitive, as it will be specified by the RDD registration authority, not yet operational. (see A.5 of MPEG-21000:6)

8.2.5 Binary Format (as defined in ISO/IEC 21000-16)

In order to fulfil the requirement of efficient coding of Event Report Requests and Event Reports, there is a need to be able to have a Binary representation of Event Reporting descriptors. Details of this are beyond the scope of this report (see MPEG-21 Part 16, Binarization).

9 Data Types

This specification makes use of a number of re-usable DataTypes that have been referenced in preceding clauses. The syntax and semantics of these Types is given in subsequent clauses.

9.1 TimeType

9.1.1 Syntax

< xsd:complexType="TimeType">

9.1.2 Semantics

Name Definition TimeType Time structure for MPEG-21 Event Reporting SpecificTime Specific time instinct. Composed of onTime, afterOn and beforeOn ElapsedTime Duration time interval for a certain base such as an Event. Composed of beginElapse and endElapse. PeriodicTime Represents time that recurs periodically. Composed of Start, DayofWeek, Period, Duration and End. onTime Represents a specific time instinct. afterOn After a specific time beforeOn Before a specific time beginElapse Indicates the beginning time of; if absent, the delivery is considered to begin when an event occurs. endElapse Indicates the end time of duration sTime Indicates that elapsed time starts from the specific time of the day; for example, the midnight of the day event occurs. sDuration Indicates that that elapsed time starts from some elapsed duration after a certain base; for example, from 2 hours after an Event eTime Indicates that elapsed time ends by the specific time of the day. eDuration Indicates that that elapsed time ends by some elapsed duration after a certain base Start Indicates the start of the periodic time. DayofWeek Describes the day of a certain week.

It has the format nWmD, where nW represents the number

© ISO/IEC 2004 – All rights reserved 29 of weeks, mD the day of week. For example “2W1D” means Monday of 2nd week. An optional preceding minus sign ('-') is allowed, to indicate a negative representation. For example, “-1W2D” means Tuesday of last week”. Period Indicates the interval of periods.

Duration Represents the length of the time slide.

End Indicates the end of the periodic time.

9.1.3 Example (Informative)

9.2 ModificationType

9.2.1 Syntax

A special attribute must reflect that a Modification can be a "Creation".

9.2.2 Semantics

9.2.3 Example

9.3 DIOperationType

9.3.1 Syntax

9.3.3 Example

9.4 PeerId Type

9.4.1 Syntax

9.4.2 Semantics

9.4.3 Example

9.5 UserId Type

9.5.1 Syntax

9.5.2 Semantics

9.5.3 Example

9.6 EventConditionGroup

9.6.1 Syntax

Name Definition EventConditionGroup Specifies the Event Conditions. It consists of TimeCondition, DIOperationCondition and PeerCondition. TimeCondition Specifies a time-based condition. DIOperationCondition Specifies condition on Peer’s DI-related operation. PeerCondition Specifies other event conditions except time-based Condition and DI-related Condition. It enables Users to define new Event Conditions as necessary. This element is used to extend the Event Condition into any other relevant namespace (e.g. DIA, DIP, MPEG-7).

9.6.3 Example

9.7 ExternalOperator

9.7.1 Syntax

9.7.2 Semantics

Name Definition ExternalOperator Specifies the operators among the Event conditions. kind Specifies the operator. Includes the logical operators and parenthesis operators. location Specifies the location of operator. It consists of prefix and postfix. The prefix takes precedence over postfix based on condition.

9.7.3 Example

9.8 InternalOperator

9.8.1 Syntax

9.8.2 Semantics

Name Definition InternalOperator Specifies the operator used for PeerEvent to express the Peer’s status such as NetworkCongestion >= 0.8. kind Specifies the internal operator of Peer Event. Includes the arithmetic operators and comparison operators. location Specifies the location of operator. It consists of prefix, infix and postfix. The prefix takes precedence over postfix based on condition.

9.8.3 Example

XML Schema Definition

To be provided at a later stage