1、Approved July 14, 2017 Copyright 2017 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue., White Plains, NY 10601 (914) 761-1100 SMPTE ST 430-16:2017 SMPTE STANDARD D-Cinema Operations Extended Facility List Message Page 1 of 35 pages Table of Contents 1 Scope 3 2 Conformance
2、Notation 3 3 Normative References 4 4 Overall 5 4.1 Schema 5 4.2 Instance 5 4.3 FLM Document 5 5 Structure 6 5.1 General 6 5.2 FacilityListMessageType 6 5.3 FacilityInfoType 7 5.4 FacilityCapabilitiesType 9 5.5 AuditoriumType 10 5.6 AuditoriumCapabilitiesType 12 5.7 SuiteType 16 5.8 NonSecurityDevic
3、eList 17 5.9 DeviceType 17 5.10 DeviceCapabilitiesType 19 5.11 AddressListType 21 5.12 ContactType 22 5.13 Digital3DsystemType 23 5.14 DeliveryMethodType 24 5.15 AddressType 25 5.16 EmailType 26 5.17 PhysicalType 26 5.18 ModemType 27 5.19 NetworkType 27 5.20 SatelliteDeliveryType 27 5.21 ComponentTy
4、pe 28 SMPTE ST 430-16:2017 Page 2 of 35 pages 5.22 WatermarkingType 29 5.23 ScopedStringType 30 5.24 EmailAddressType 30 5.25 ISO3166CountryCode 31 5.26 LuminanceUnitEnum 31 5.27 LengthUnitEnum 31 Annex A Consolidated Schema (Informative) 33 Annex B Example Instance (Informative) 34 Bibliography 35
5、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. SMPTEs Engineering Documents, includin
6、g 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-developing organizations, including ISO, IEC and ITU.
7、SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual. This SMPTE Engineering Document was prepared by Technology Committee 21DC. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essen
8、tial to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. Introduction This section is enti
9、rely informative and does not form an integral part of this document. To issue D-Cinema Packages and corresponding Key Delivery Messages, it is necessary to collect information on the devices present at the target exhibition facility, e.g. digital certificates, 3D capabilities, etc. SMPTE ST 430-7:2
10、008, which specifies a Facility List Message (FLM) structure for this purpose, has been superseded in practice by ad-hoc solutions. This document updates SMPTE ST 430-7:2008 to specify an Extended FLM structure, which builds on the latter. As depicted in Figure 1, each Extended FLM instance contains
11、 information on a single facility, which houses multiple auditoriums and devices. Devices can be associated with either the facility as a whole or with each auditorium individually, where they are grouped into playback suites. Multiple components software, hardware and firmware can be associated wit
12、h each device. SMPTE ST 430-16:2017 Page 3 of 35 pages Figure 1: Extended Facility List Message Structure Specific capabilities, e.g. 3D playback, can be associated with facilities, auditoriums and devices. This allows, for instance, a capability enabled by the combination of multiple devices to be
13、associated with an auditorium. This specification defines a number of capabilities, and allows other specifications to easily define additional capabilities as needed. 1 Scope This document specifies the Extended Facility List Message structure, which allows information on the equipment deployed at
14、a D-Cinema facility to be exchanged between parties for the purpose of issuing D-Cinema Packages, as specified in SMPTE ST 429-2, and corresponding Key Delivery Messages, as specified in ST 430-1. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensa
15、ble 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 conform
16、ance 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:” F L M ( )F a c i l i t y i n f o r m a t i o n ( )C a p a b i l i t i e s ( )D e v i c e ( )A u d i t o r i u
17、 m ( )C a p a b i l i t i e s ( )S u i t e ( )D e v i c e ( )N o n S e c u r i t y D e v i c e ( )SMPTE ST 430-16:2017 Page 4 of 35 pages 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. T
18、he 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 o
19、r 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 key
20、word “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 describ
21、ed. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definiti
22、on; Tables shall be next; then formal languages; then figures; and then any other language forms. 3 Normative References The following standards contain provisions which, through reference in this text, constitute provisions of this engineering document. At the time of publication, the editions indi
23、cated were valid. All standards are subject to revision, and parties to agreements based on this engineering document are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. Internet Assigned Numbers Authority (1987). Eggert, P. and A. Olso
24、n, “Sources for Time Zone and Daylight Saving Time Data“ (ftp:/ftp.iana.org/tz/code/tz-link.htm) SMPTE ST 430-1:2009, D-Cinema Operations Key Delivery Message SMPTE ST 430-2:2006, D-Cinema Operations Digital Certificate. SMPTE ST 428-12:2013, D-Cinema Distribution Master Common Audio Channels and So
25、undfield Groups ITU-T Recommendation E.123 (02/2001), Notation for national and international telephone numbers, e-mail addresses and Web addresses ISO 3166-1, Codes for the representation of names of countries and their subdivisions Part 1: Country codes World Wide Web Consortium (W3C) (2004, Octob
26、er 28). XML Schema Part 1: Structures (Second Edition). World Wide Web Consortium (W3C) (2004, February 4). Extensible Markup Language (XML) 1.0 (Third Edition). SMPTE ST 430-16:2017 Page 5 of 35 pages Internet Engineering Task Force (IETF) (2008, October). RFC 5322 Internet Message Format. World Wi
27、de Web Consortium (W3C) (2002, February 12). XML Signature Syntax and Processing. 4 Overall 4.1 Schema This specification uses inline XML Schema definitions, as specified in W3C XML Schema Part 1: Structures, to specify XML structures. All definitions shall belong to the XML Schema. These schema def
28、initions shall belong to the XML Schema whose root element is listed in Table 1. Table 1: XML Schema Root Element Definition In the event of a conflict between schema definitions and the prose, the prose shall take precedence. Imported namespaces shall correspond to the specifications defined in Tab
29、le 2. Table 2: Imported Namespaces Namespace Specification http:/www.smpte-ra.org/schemas/433/2008/dcmlTypes/ SMTPE ST 433 http:/www.w3.org/2000/09/xmldsig# W3C XML Signature Syntax and Processing NOTE: The http:/www.w3.org/2000/09/xmldsig# namespace is imported since its KeyInfo element is used in
30、the Facility List Message structure to carry the digital certificate chains associated with a device (see Section 5.9.13). The Signature element defined in the same namespace is not used however. 4.2 Instance A Facility List Message instance is FacilityListMessage element, as specified in Table 3. T
31、able 3: FacilityListMessage element definition 4.3 FLM Document An FLM Document is an XML document whose root is a Facility List Message instance. An FLM Document shall use UTF-8 encoding, as specified in W3C Extensible Markup Language (XML). SMPTE ST 430-16:2017 Page 6 of 35 pages 5 Structure 5.1 G
32、eneral To avoid duplication between text and schema, the cardinality and default values of elements are specified in the XML schema definitions only. 5.2 FacilityListMessageType 5.2.1 General The FacilityListMessageType type shall be as specified in Table 4. Table 4: FacilityListMessageType schema d
33、efinition 5.2.2 MessageId The MessageId element shall uniquely identify the Facility List Message instance. Any two Facility List Message instances may have identical MessageId values if and only if the two instances are identical. 5.2.3 IssueDate The IssueDate element shall indicate the time and da
34、te at which the Facility List Message was issued. SMPTE ST 430-16:2017 Page 7 of 35 pages 5.2.4 AnnotationText The AnnotationText element shall be a free-form annotation associated with the Facility List Message instance. It is intended for display to the user. 5.2.5 FacilityInfo The FacilityInfo el
35、ement shall describe the facility. 5.2.6 AuditoriumList Each Auditorium element within the AuditoriumList element shall be associated with a single auditorium within the facility. The auditorium should be for current or anticipated D-Cinema use. 5.2.7 Extensions Extensions elements containing inform
36、ation intrinsic to the message, and not specifically to the facility and its components, should be added in the Extensions element. Implementations may ignore children element of Extensions. 5.3 FacilityInfoType 5.3.1 General The FacilityInfoType type shall be as specified in Table 5. Table 5: Facil
37、ityInfoType Schema Definition SMPTE ST 430-16:2017 Page 8 of 35 pages Extensions elements containing information intrinsic to the facility and generally applicable to all facilities should be added using the any extension point. Extension elements describing capabilities offered by individual device
38、s should be added to the Capabilities element. Implementations may ignore extension elements. 5.3.2 FacilityID The FacilityID element shall uniquely identify the facility across Facility List Message instances. 5.3.3 AlternateFacilityIDList Each AlternateFacilityID element of the AlternateFacilityID
39、List element shall uniquely identify the facility. Members of the AlternateFacilityIDList element may change across Facility List Message instances targeted at the same facility. 5.3.4 FacilityName The FacilityName element shall be the name of the facility. 5.3.5 FacilityTimeZone The FacilityTimeZon
40、e element shall be the time zone of the facility and shall be a TZ name as specified in the IANA Sources for Time Zone and Daylight Saving Time Data. The FacilityTimeZone element should be present. NOTE: Unless this element is present, the time window of a Key Delivery Message, as specified in SMTPE
41、 ST 430-1, targeted to the facility cannot be authored accurately. 5.3.6 Circuit The Circuit element shall be the name of the circuit to which the facility belongs. 5.3.7 ContactList The ContactList element provides information on how to contact personnel at the facility. Each Contact element of the
42、 ContactList element shall be a point of contact associated with the facility. Contact element should be listed in order of decreasing preference. 5.3.8 AddressList Each element of the AddressList element shall be an address associated with the facility. SMPTE ST 430-16:2017 Page 9 of 35 pages 5.3.9
43、 DeviceList Each Device element shall correspond to a device associated with the facility as a whole, i.e. as opposed to a single auditorium. EXAMPLE: A satellite catcher can be listed as a member of this element. 5.3.10 Capabilities The Capabilities element shall indicate capabilities associated wi
44、th the facility as a whole. 5.4 FacilityCapabilitiesType 5.4.1 General The FacilityCapabilitiesType shall be as defined Table 6. Table 6: FacilityCapabilitiesType Schema Definition Additional capabilities associated with a facility may be introduced by adding extension elements using the any extensi
45、on point. Implementations may ignore extension elements they do not recognize. 5.4.2 KDMDeliveryMethodList Each DeliveryMethod element of the KDMDeliveryMethodList element shall indicate a method by which a Key Delivery Message may be delivered to the facility 5.4.3 DCPDeliveryMethodList Each Delive
46、ryMethod element of the DCPDeliveryMethodList element shall indicate a method by which a D-Cinema Package may be delivered to the facility. SMPTE ST 430-16:2017 Page 10 of 35 pages 5.5 AuditoriumType 5.5.1 General The schema for the AuditoriumType is shown in Table 7. Table 7: AuditoriumType Schema
47、Definition Extensions elements containing information intrinsic to the auditoriums and generally applicable to any auditorium should be added using the any extension point. Extension elements describing capabilities offered by auditorium should be added to the Capabilities element. Implementations m
48、ay ignore extension elements. 5.5.2 AuditoriumNumberOrName The AuditoriumNumberOrName element shall be the unique and persistent number or name of the auditorium across Facility List Message instances. SMPTE ST 430-16:2017 Page 11 of 35 pages 5.5.3 AuditoriumInstallDate The AuditoriumInstallDate ele
49、ment shall indicate when the auditorium became, or will become, available for D-Cinema service, i.e. consumer viewing of digitally-projected motion picture content. NOTE: For testing, KDMs can be issued for auditoriums not yet in service. 5.5.4 ScreenWidth The ScreenWidth element shall be the width of the auditoriums screen with masking fully open. The units attribute shall indicate the units of measure of the ScreenWidth value. 5.5.5 SeatingCapacity The SeatingCapacity element shall be the seating capacity of the auditorium. 5.5.6 SuiteList Each Suite element of the Sui
