Digital cinema (D-cinema) operations — Part 4: Log record format specification

ISO 26430-4:2009 defines XML structures and schema for individual log records and sequences of those records in digital cinema applications. While not all log records require authentication, this specification provides for optional authentication of records and sequences of records, using digital signatures. Authentication requirements are established by separate application specifications. ISO 26430-4:2009 does not define a communications protocol, but is limited to specifying the structure and format of log records and their content. ISO 26430-4:2009 does not define a format for devices to use internally; it defines a format to be used when log records are interchanged with other devices.

Opérations du cinéma numérique (cinéma D) — Partie 4: Spécification du format d'enregistrement des résultats

General Information

Status
Published
Publication Date
02-Dec-2009
Technical Committee
Drafting Committee
Current Stage
9093 - International Standard confirmed
Start Date
05-Aug-2020
Completion Date
05-Aug-2020
Ref Project

Buy Standard

Standard
ISO 26430-4:2009 - Digital cinema (D-cinema) operations
English language
15 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO 26430-4:2009 - Digital cinema (D-cinema) operations
English language
15 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (sample)

INTERNATIONAL ISO
STANDARD 26430-4
First edition
2009-12-15
Digital cinema (D-cinema) operations —
Part 4:
Log record format specification
Opérations du cinéma numérique (cinéma D) —
Partie 4: Spécification du format d'enregistrement des résultats
Reference number
ISO 26430-4:2009(E)
ISO 2009
---------------------- Page: 1 ----------------------
ISO 26430-4:2009(E)
PDF disclaimer

PDF files may contain embedded typefaces. In accordance with Adobe's licensing policy, such files may be printed or viewed but shall

not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In

downloading a PDF file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat

accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.

Details of the software products used to create the PDF file(s) constituting this document can be found in the General Info relative to

the file(s); the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the files are suitable for

use by ISO member bodies. In the unlikely event that a problem relating to them is found, please inform the Central Secretariat at the

address given below.

This CD-ROM contains the publication ISO 26430-4:2009 in portable document format (PDF), which can be

viewed using Adobe® Acrobat® Reader, together with its electronic inserts.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.
COPYRIGHT PROTECTED DOCUMENT
© ISO 2009

All rights reserved. Unless required for installation or otherwise specified, no part of this CD-ROM may be reproduced, stored in a retrieval

system or transmitted in any form or by any means without prior permission from ISO. Requests for permission to reproduce this product

should be addressed to
ISO copyright office • Case postale 56 • CH-1211 Geneva 20 • Switzerland
Internet
...

INTERNATIONAL ISO
STANDARD 26430-4
First edition
2009-12-15
Digital cinema (D-cinema) operations —
Part 4:
Log record format specification
Opérations du cinéma numérique (cinéma D) —
Partie 4: Spécification du format d'enregistrement des résultats
Reference number
ISO 26430-4:2009(E)
ISO 2009
---------------------- Page: 1 ----------------------
ISO 26430-4:2009(E)
PDF disclaimer

This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but

shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In

downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat

accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.

Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation

parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In

the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

COPYRIGHT PROTECTED DOCUMENT
© ISO 2009

All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,

electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or

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 copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2009 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 26430-4:2009(E)
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.

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 26430-4 was prepared by the Society of Motion Picture and Television Engineers (as

SMPTE 430-4-2008) and was adopted, under a special “fast-track procedure”, by Technical Committee

ISO/TC 36, Cinematography, in parallel with its approval by the ISO member bodies.

ISO 26430 consists of the following parts, under the general title Digital cinema (D-cinema) operations:

⎯ Part 1: Key delivery message [equivalent to SMPTE 430-1]
⎯ Part 2: Digital certificate [equivalent to SMPTE 430-2]
⎯ Part 3: Generic extra-theater message format [equivalent to SMPTE 430-3]
⎯ Part 4: Log record format specification [equivalent to SMPTE 430-4]
⎯ Part 5: Security log event class and constraints [equivalent to SMPTE 430-5]

⎯ Part 6: Auditorium security messages for intra-theater communications [equivalent to SMPTE 430-6]

⎯ Part 9: Key delivery bundle [equivalent to SMPTE 430-9]
© ISO 2009 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 26430-4:2009(E)
Introduction

This part of ISO 26430 comprises SMPTE 430-4-2008, together with Annex ZZ (which provides equivalences

between ISO standards and SMPTE standards referenced in the text) and the following additional information

related to subclause 6.1 (Record Text Extension Type) concerning the “RecordDescriptionText” element.

The optional language attribute is an xs:language language code and indicates the language used for

Record Description Text . If the language attribute is not present, the default value en is used.

iv © ISO 2009 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008
SMPTE STANDARD
D-Cinema Operations —
Log Record Format Specification
Page 1 of 16 pages
Table of Contents Page

Foreword ................................................................................................................................................. 2

Introduction ............................................................................................................................................. 2

1 Scope ................................................................................................................................................ 3

2 Conformance Notation ...................................................................................................................... 3

3 Normative References ...................................................................................................................... 3

4 Overview (Informative)..................................................................................................................... 4

5 Definitions ......................................................................................................................................... 5

5.1 Definition of Terms................................................................................................................... 5

5.2 Namespace Prefixes................................................................................................................ 5

5.3 Log Record Namespace .......................................................................................................... 5

6 Component Data Types .................................................................................................................... 6

6.1 Record Text Extension Type.................................................................................................... 6

6.2 Event Token Types .................................................................................................................. 6

6.3 Reference ID Types ................................................................................................................. 7

7 Log Record Type Descriptions.......................................................................................................... 8

7.1 Log Record Header Type......................................................................................................... 8

7.2 Log Record Body Type ............................................................................................................ 10

7.3 Log Record Signature Type..................................................................................................... 12

7.4 Log Record and Report Types................................................................................................. 14

8 Schema (Informative)....................................................................................................................... 14

9 Log Record Chaining (Informative).................................................................................................. 15

10 Example Instances (Informative) ..................................................................................................... 16

10.1 Example Log Record ............................................................................................................. 16

10.2 Example Log Report .............................................................................................................. 16

10.3 Example Authenticated Log Report ....................................................................................... 16

11 Glossary of Acronyms....................................................................................................................... 16

Copyright © 2008 by THE SOCIETY OF
Approved
MOTION PICTURE AND TELEVISION ENGINEERS
March 3, 2008
595 W. Hartsdale Ave., White Plains, NY 10607
(914) 761-1100
© ISO 2009 – All rights reserved 1
---------------------- Page: 5 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008
Foreword

SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards

developing organization. Headquartered and incorporated in the United States of America, SMPTE has

members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards,

Recommended Practices and Engineering Guidelines, are prepared by SMPTE’s Technology Committees.

Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates

closely with other standards-developing organizations, including ISO, IEC and ITU.

SMPTE Engineering Documents are drafted in accordance with the rules given in Part XIII of its

Administrative Practices.
SMPTE Standard 430-4 was prepared by Technology Committee DC28.
Introduction

Many devices in D-Cinema exhibition environments must generate log records, which can record all manner

of events in the normal and exceptional operation of systems. In order to achieve interoperability, it is

desirable that log records are presented in a common basic format.
Page 2 of 16 pages
2 © ISO 2009 – All rights reserved
---------------------- Page: 6 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008
1 Scope

The purpose of this document is to define XML structures and schema for individual log records and

sequences of those records in D-Cinema applications. While not all log records require authentication, this

specification provides for optional authentication of records and sequences of records, using digital

signatures. Authentication requirements are established by separate application specifications. This

document does not define a communications protocol, but is limited to specifying the structure and format of

log records and their content. This document does not define a format that devices must use internally, but it

does define a format that is to be used when log records are interchanged with other devices.

2 Conformance Notation

Normative text is text that describes elements of the design that are indispensable or contains the

conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful

to the user, but not indispensable, and can be removed, changed, or added editorially without affecting

interoperability. Informative text does not contain any conformance keywords.

All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as

"Informative" or individual paragraphs that start with "Note:”

The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the

document and from which no deviation is permitted.

The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as

particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but

not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated

but not prohibited.

The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.

The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be

defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision

will never be defined in the future.

A conformant implementation according to this document is one that includes all mandatory provisions

("shall") and, if implemented, all recommended provisions ("should") as described. A conformant

implementation need not implement optional provisions ("may") and need not implement them as described.

3 Normative References

The following standards contain provisions which, through reference in this text, constitute provisions of this

standard. At the time of publication, the editions indicated were valid. All standards are subject to revision,

and parties to agreements based on this standard are encouraged to investigate the possibility of applying the

most recent edition of the standards indicated below.

[XML-SCH-1] XML Schema Part 1: Structures URL http://www.w3.org/TR/xmlschema-1-20041028/

[XML-SCH-2]XML Schema Part 2: Datatypes http://www.w3.org/TR/xmlschema-2-20041028/

Internet Engineering Task Force (IETF) (1997, May) URN Syntax, [WWW document]. URL

http://www.ietf.org/rfc/rfc2141.txt

[RFC 3280] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

URL: http://www.ietf.org/rfc/rfc3280.txt

[xml-c14n] Canonical XML Version 1.0 W3C Recommendation 15 March 2001 http://www.w3.org/TR/xml-c14n/

Page 3 of 16 pages
© ISO 2009 – All rights reserved 3
---------------------- Page: 7 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008

[xml-dsig] "XML-Signature Syntax and Processing" W3C Recommendation 12 February 2002

http://www.w3.org/TR/xmldsig-core/

[RFC 3275] "XML-Signature Syntax and Processing" http://www.ietf.org/rfc/rfc3275.txt

[DCMLTypes] XML Data Types for Digital Cinema. ( SMPTE 433-2008)
[DC-Cert] D-Cinema Digital Certificate (SMPTE 430-2-2006)

[SHA-1] “FIPS PUB 180-1 Secure Hash Standard” http://www.itl.nist.gov/fipspubs/fip180-1.htm

[RFC 2253] “Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished

Names” http://www.ietf.org/rfc/rfc2253.txt
4 Overview (Informative)

The Log Record Format standardizes the reporting format for information that documents the usage and

behavior of a Digital Cinema system. This format is intended to be used for communicating log event

information at such points in the system where interoperability or a common format is a requirement. This

format may be used to construct records that are unidirectional in nature, meaning that a bi-directional

communications channel is not required in order to interpret the record content. However, additional

efficiencies and features such as dynamic text internationalization can be achieved in a bi-directional

communications environment.

In order to provide for maximum flexibility while maintaining interoperability, the Log Record format is

designed to support a number of features which may be optional or required depending on any requirements

which may be imposed by an application specification which uses this format. This format supports both

authenticated and non-authenticated log records for security and non-security logging purposes, respectively.

The format also supports record "sequences", or Log Reports, to reduce authentication overhead, and

provides for "filtering" of authenticated record sequences in cases where it may be desirable to excise

information contained in Log Reports while preserving a record of that information's existence.

In order to accomplish these objectives, the Log Record structure is broken down into three major sub-parts:

Header, Body, and Signature, the first of which is required in a Log Record, and the second and third of which

are optional. In addition, a number of fields in these sub-parts are optional for Log Records which are not

required to support authentication, but available and may be required where authentication is a requirement.

In Log Reports, some Body sections may be removed by filtering, so the Header is the only required part of a

Log Record in a Log Report.

The Log Record Header contains enough information to identify the source, time, and classification of the log

record. It may also include hashes to support data integrity and authentication. Conceptually, the Log Record

Header contains just enough information to support automated classification and sorting of log events, without

revealing information that may be considered sensitive or non-public.

The Log Record Body contains either the detail of the logged information in human-readable form, or index

information to enable the translation of the log detail into human readable form, or both. This includes all

available information about the logged event, except that which is conveyed in the Log Header. The Log

Record Body is not encrypted, but may be authenticated through a hash of its contents, which is contained in

the corresponding Log Record Header, which may be signed by a Log Signature. The (optional) Log

Signature provides authentication of the header(s) of the current Log Record, or optionally authentication over

a number of log records in a sequence.

This document does not specify the internal format for log records kept within a device. Rather, this document

specifies the format for producing authenticated log records, if a device is required to do so.

Page 4 of 16 pages
4 © ISO 2009 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008
5 Definitions
5.1 Definition of Terms

 Log Event – Any state or change of state in a system that is desirable to record in a log. Such an

event results in the recording of log data.
 Log Data – Log Event information that is recorded and stored in a Log Record.
 Log Record – Standardized XML structure representing a discrete logged event.
 Log Report – Standardized XML structure containing one or more log records.
5.2 Namespace Prefixes

The following table lists the namespace prefixes used in the XSDL and XML examples in this document.

Please refer to the normative references in this document and in [DCMLTypes] for specific references to the

namespaces referred to in this table. Note that the prefixes themselves are not normative, and that instance

documents may assign alternative prefixes in practice.
Prefix
Namespace Reference
xs XMLSchema
ds Xmldsig
xsi XMLSchema-Instance
dcml DcmlTypes
lr LogRecord [This Document]
5.3 Log Record Namespace

The types defined in this document shall be included in an XML namespace, whose Namespace Name (URI)

shall be:
http://www.smpte-ra.org/schemas/430-4/2008/LogRecord/

When published, the version number of the XML Schema representation of the namespace shall be set to

"1.0", where "1" is the major part of the version number, and "0" is the minor part. If the namespace is

subsequently revised to add new types not defined in this standard, but not to modify any of the existing types

in a way that breaks reverse compatibility, the minor part of the version number shall be incremented by one.

If the namespace is subsequently modified with result of changing any of the types defined in this document

in a way that breaks reverse compatibility, the major part of the version number shall be incremented by one.

The version number shall be specified by the version attribute the xs:schema element of the XML schema

that this namespace represents.
Page 5 of 16 pages
© ISO 2009 – All rights reserved 5
---------------------- Page: 9 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008
6 Component Data Type

This section describes component data types, which shall be used in the construction of a Log Record. See

[XML-SCH-2] and [DCMLTypes] for the definitions of the underlying XML data types.

6.1 Record Text Extension Type

The RecordTextExtension type is meant to contain human readable text and optionally positional parameter

replacement codes. The purpose of this data type is to provide for human readable interpretations of record

content, in multiple languages where appropriate.

Requesting a set of these description items for a particular language can be done at any time that log records

need to be consolidated or interpreted. An XML element based on this type must include one and only one

recordTextID element, but may contain more than one recordDescriptionText element in order to express the

content in more than one language.
6.1.1 Record Text Extension Fields
The RecordTextExtension Type shall consist of the following elements.
6.1.1.1 Record Text ID

The RecordTextID element shall be a UUID that represents the conceptual information expressed in the

RecordDescriptionText field, regardless of the language used to express it.
6.1.1.2 Record Description Text

The RecordDescriptionText element shall be a block of UTF-8 encoded text that describes the meaning of the

record in human readable form. The record text may include positional replacement markers in place of which

values from the Parameters List of the record may be substituted.
6.1.2 Schema Representation
Expressed in XSDL, the RecordTextExtension Type shall be defined as follows:



minOccurs="1" maxOccurs="unbounded"/>


6.2 Event Token Types

In the header and body sections of Log Records, XML "tokens" are used to represent the values of the record

fields. The following XML type extends the XML "token" type to include optional scope attributes in order to

specify the allowable values for those fields.
6.2.1 Event Type Type

The Event Type Type shall be used to specify types and subtypes of Log Events in Log records. This Type

shall be defined in XSDL as follows:
Page 6 of 16 pages
6 © ISO 2009 – All rights reserved
---------------------- Page: 10 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008







Note that the "scope" attribute is required but not specified, and no default scope is provided. For each

application specification that uses this Log Record Format Specification, that specification document must

specify one or more scope URIs for this type, and specify the list of allowed tokens defined by that scope.

6.3 Reference ID Types

In the body section of Log Records, it is frequently necessary to identify an entity both by name and by a

UUID. The following Types define the framework to be used in expressing these name/value pairs.

6.3.1 Reference ID Type

The Reference ID Type defines a name/value pair which is scoped to indicate the range of possible names for

the identifiers. This Type shall be defined in XSDL as follows:






Reference ID scopes and scope URIs may be defined by other documents as needed, but the specific

definitions are outside the scope of this document, as they as are application-specific.

6.3.2 Referenced ID List Type

In the body section of a Log Record, elements of type Reference ID shall be grouped in a list. The list Type

shall be defined in XSDL as follows:


minOccurs="1" maxOccurs="unbounded"/>


Page 7 of 16 pages
© ISO 2009 – All rights reserved 7
---------------------- Page: 11 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008
7 Log Record Type Descriptions

A Log Record shall always consist of at least a Log Record Header and a Log Record Body. A Log Record

may also contain a Log Signature. This section defines the XML Types that represent Log Record Headers,

Bodies, and Signatures.
7.1 Log Record Header Type

This type provides a structural format for the fields, content types and references for a Log Record Header.

The Log Event Header shall include the fields described below except where they are optional for the

application. Fields marked Optional may be required by other constraints documents for certain applications.

7.1.1 Event ID

The EventID element is a UUID that identifies a specific Log Record. Since Log Record Headers may be

processed independently from Log Record Bodies, an identical copy of this UUID shall appear in the Log

Record Body to associate the header and body if they become separated. If unique identification of a logged

event is required, the contents of the EventID element shall be used for that purpose.

7.1.2 Time Stamp

The Time Stamp element shall indicate the time and date that the event was detected. The Time Stamp shall

be represented as an XML "dateTime" type. The Timezone section of the dateTime item shall be present, and

shall be the local time zone of the location at which the reporting equipment is installed. [Note: This requires

that relative time stamps must be converted to absolute local time at or before the time that the formatted Log

Record is generated.]
7.1.3 Event Sequence (optional)

When a Log Report is generated by a device, the device shall set the EventSequence element to a value of

its choice for the first Log Record in the sequence, and shall increment the EventSequence value by one for

each subsequent record in the sequence. EventSequence numbers shall not be interpreted as uniquely

identifying an event, but shall only designate the sequence number of the event in the current sequence, if the

record is part of a sequence.

Note: The EventSequence values, used in concert with the chained header hashes, can be used to check that the

sequence of Log Headers in a Log Report is complete.
7.1.4 Device Source ID

The Device Source ID shall be an element of type device Identifier List Type (defined in [DCMLTypes]) that

identifies the device that generated the event that the Log Record represents. This list shall contain at least

one device identifier that identifies the source of the Log Event as recorded in the instant Log Record.

7.1.5 Event Class

The EventClass element shall contain a URI identifying the class of the logged event. The EventClass is

intended to express the general classification of the Log Event represented by the Log Record, and to identify

the scope or namespace defining the Event Types and SubTypes in that class. This class may be used to

facilitate searching and sorting on groups or sequences of Log Records. A particular event may be defined

within more than one class, and the same event may be reported under more than one class if required by the

application. The EventClass shall be represented in XML using the xs:anyURI type. .The definition of specific

Event Classes is outside the scope of this document. Examples of possible classes are listed in the following

table.
Page 8 of 16 pages
8 © ISO 2009 – All rights reserved
---------------------- Page: 12 ----------------------
ISO 26430-4:2009(E)
SMPTE 430-4-2008
Example Event Classes (Informative)
Class Class Description
Security Event records related to security
Operational Operational events
Health Status or change of status of system health items
Maintenance Maintenance events
Debug Debugging event records
7.1.6 Event Type

Within an Event Class, this field indicates the type of event that is logged. The event type shall be

represented by an Event Type Type. The scope attribute is required, and must be specified by another

document that defines Log Records for a particular Class.

Where Event Types are standardized or are published in separate documents, the scope attribute URI of the

Event Type shall be defined and shall indicate the allowable values of this field for that class of events.

Informative Note: This document does not specify any EventType scopes. Not all Classes of Events will have all of the

possible event types published - for example, Debug Class events will likely be vendor-specific. However, it is required

that Event Types for all other classes will be standardized in one or more separate documents. The following table gives

examples of possible EventType tokens that might be defined for an Event Class in a separate document.

Example Event Type Tokens (Informative)
Token Description
power a power event
timeline a timeline event
network a network ev
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.