ISO 26430-4:2009
(Main)Digital cinema (D-cinema) operations — Part 4: Log record format specification
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
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
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
...
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
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.