ISO 26430-4-2009 Digital cinema (D-cinema) operations - Part 4 Log record format specification《数字影院(D-影院)运营 第4部分 日志记录格式规范》.pdf

1、 Reference number ISO 26430-4:2009(E) ISO 2009INTERNATIONAL STANDARD ISO 26430-4 First edition 2009-12-15 Digital cinema (D-cinema) operations Part 4: Log record format specification Oprations du cinma numrique (cinma D) Partie 4: Spcification du format denregistrement des rsultats ISO 26430-4:2009(

2、E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobes 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 fil

3、e, parties accept therein the responsibility of not infringing Adobes 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 re

4、lative 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. COP

5、YRIGHT 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 belo

6、w or ISOs 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 copyrightiso.org Web www.iso.org Published in Switzerland ii ISO 2009 All rights reservedISO 26430-4:2009(E) ISO 2009 All rights reserved

7、iiiForeword 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

8、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 matt

9、ers 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 lea

10、st 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 Pictur

11、e 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-cin

12、ema) 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

13、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 26430-4:2009(E) iv ISO 2009 All rights reservedIntroduction This part of ISO 26430 comprises SMPTE 430-4-200

14、8, 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 a

15、n 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. Copyright 2008 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Appr

16、oved March 3, 2008 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 Ex

17、tension 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 Exam

18、ple 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 Page 1 of 16 pages SMPTE 430-4-2008SMPTE STANDARD D-Cinema Operations Log Record Format Specification ISO 26430-4:2009(E) ISO 2009 All right

19、s reserved 1SMPTE 430-4-2008 Page 2 of 16 pages 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 co

20、ntinents. SMPTEs Engineering Documents, including Standards, Recommended Practices and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-develop

21、ing 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 g

22、enerate 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. ISO 26430-4:2009(E) 2 ISO 2009 All rights reservedSMPTE 430-4-2008 Page 3 of 1

23、6 pages 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 o

24、f 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 fo

25、rmat 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

26、“, “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,

27、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 k

28、eywords, “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 co

29、urse 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

30、 “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.

31、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 editio

32、ns 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/xmlsche

33、ma-1-20041028/ XML-SCH-2XML 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

34、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/ ISO 26430-4:2009(E) ISO 2009 All rights reserved 3SMPTE 430-4-2008 Page 4 of 16 pages xml-dsig “XML-Signature Syntax and Processing“ W3C Recomm

35、endation 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 Stand

36、ard” 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 documen

37、ts 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, me

38、aning 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 flexibi

39、lity 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-auth

40、enticated 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

41、contained in Log Reports while preserving a record of that informations 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 whi

42、ch 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

43、 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 en

44、ough 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 translatio

45、n 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 correspondi

46、ng 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 k

47、ept within a device. Rather, this document specifies the format for producing authenticated log records, if a device is required to do so. ISO 26430-4:2009(E) 4 ISO 2009 All rights reservedSMPTE 430-4-2008 Page 5 of 16 pages 5 Definitions 5.1 Definition of Terms Log Event Any state or change of stat

48、e 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 contai

49、ning 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 XMLSc