SMPTE ST 430-4-2008 D-Cinema Operations Log Record Format Specification ( For Subscription Customers Only To Obtain you Complimentary Spreadsheet Contact IHS at 1-800-854-7179 USA.pdf

《SMPTE ST 430-4-2008 D-Cinema Operations Log Record Format Specification ( For Subscription Customers Only To Obtain you Complimentary Spreadsheet Contact IHS at 1-800-854-7179 USA.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 430-4-2008 D-Cinema Operations Log Record Format Specification ( For Subscription Customers Only To Obtain you Complimentary Spreadsheet Contact IHS at 1-800-854-7179 USA.pdf（16页珍藏版）》请在麦多课文档分享上搜索。

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

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

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 P

4、age 1 of 16 pages SMPTE 430-4-2008SMPTE STANDARD D-Cinema Operations Log Record Format Specification SMPTE 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 incor

5、porated in the United States of America, SMPTE has members in over 80 countries on six continents. 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

6、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 Techno

7、logy 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 bas

8、ic format. SMPTE 430-4-2008 Page 3 of 16 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 au

9、thentication 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 cont

10、ent. 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 th

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

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

13、 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 neg

14、ative 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 ma

15、y 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 recommend

16、ed 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.

17、 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: Str

18、uctures URL http:/www.w3.org/TR/xmlschema-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

19、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/ SMPTE 430-4-2008 Page 4 of 16 pages xml-dsig “XML-Signature Syntax and Processing“ W3C Recommendation 12

20、 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:/

21、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 usag

22、e 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

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

24、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 l

25、og 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 i

26、n 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 which are opti

27、onal. 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 r

28、equired 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 inform

29、ation 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 lo

30、g 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 Reco

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

32、a device. Rather, this document specifies the format for producing authenticated log records, if a device is required to do so. SMPTE 430-4-2008 Page 5 of 16 pages 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 e

33、vent 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 foll

34、owing 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 i

35、nstance 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 (

36、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 ad

37、d 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 docum

38、ent 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. SMPTE 430-4-2008 Page 6 of 16 pages 6 Component Dat

39、a 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 optio

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

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

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

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

44、XSDL, the RecordTextExtension Type shall be defined as follows: 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

45、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: SMPTE 430-4-2008 Page 7 of 16 pages Note that the “scope“ attribute is required but not

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

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

48、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 Li

49、st 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: SMPTE 430-4-2008 Page 8 of 16 pages 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 Signature