1、 Copyright 2015 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved October 9, 2015 Table of Contents Page Foreword 3 Intellectual Property . 3 Introduction. 3 1 Scope . 4 2 Conformance Notation . 4 3 Normative References . 5 4 No
2、te on Wellformedness and Validation (Informative) . 5 5 Processing Model (Normative) 5 6 General Conventions (Normative) 5 6.1 BxfMessage Attributes . 6 6.2 Action Oriented Messages. 7 6.3 Query Oriented Messages . 7 6.4 Acknowledgment Messages 8 6.5 Reply Messages 8 6.6 Heartbeat Messages 9 7 Trans
3、port Protocol (Normative) . 10 7.1 Connection-Based Transport . 10 7.2 File-Based Transport . 11 8 Message Type Usages by Application Type (Informative) . 12 8.1 Asset Management 12 8.2 Automation . 13 8.3 Program Management . 14 8.4 Traffic . 15 9 Configuration 16 9.1 Overview (Informative) 16 9.2
4、Recommended Conventions and Configuration Types (Normative) 19 9.3 Requesting Configuration Information (Queries) (Normative) 28 9.4 Requesting New Configuration Values be Added (Normative) 30 9.5 Notifying Others when Values or Mappings Change (Normative) 31 10 Content . 34 10.1 Overview (Informati
5、ve) 34 10.2 Requesting Content Information (Queries) (Normative) . 42 10.3 Notifying Others when Content is Added (Normative) . 45 10.4 Notifying Others when Content is Updated (Normative) . 46 10.5 Notifying Others when Content is Removed (Normative) 47 Page 1 of 90 pages SMPTE RP 2021-9:2015 Revis
6、ion of SMPTE RP 2021-9:2012 SMPTE RECOMMENDED PRACTICE Implementing Broadcast Exchange Format (BXF) SMPTE RP 2021-9:2015 Page 2 of 90 pages 11 Content Transfer . 48 11.1 Overview (Informative) 48 11.2 Content Transfer Status Query (Normative) . 49 11.3 Dub Order (Normative) 49 11.4 Purge Order (Norm
7、ative) . 50 11.5 Record Order (Normative) . 50 11.6 Transfer Order (Normative) . 51 11.7 Content Transfer Status (Normative) 52 12 Format . 52 12.1 Overview (Informative) 52 12.2 Requesting Format Information (Queries) (Normative). 55 12.3 Notifying Others when Formats are Added 57 12.4 Notifying Ot
8、hers when Formats are Updated . 57 12.5 Notifying Others when Formats are Removed . 58 13 Schedule 58 13.1 Overview (Informative) 58 13.2 Requesting Schedule Information (Queries) (Normative) . 64 13.3 EPG Schedule Notifications (Normative) 65 13.4 Playlist Notifications (Normative) 66 13.5 As-run N
9、otifications (Normative) 68 Annex A Supported Extensions (Normative) . 70 A.1 Overview . 70 A.2 Usage Attribute . 70 A.3 Filename Element . 70 A.4 Root Element Extensions . 70 A.5 Extension Schemas 70 Annex B Message Type Usages (Normative) . 71 B.1 Registered Message Type Usages . 71 B.2 Informatio
10、n Message Syntax 74 B.3 Request and Reply Message Syntax 74 B.4 Query Message Syntax 74 B.5 Custom Message Type Usages 74 B.6 Application-Specific Message Type Usages 74 Annex C Error Handling (Informative) . 76 C.1 Overview . 76 C.2 Error Types . 76 C.3 Setting Errors Contextually . 77 C.4 Identify
11、ing Errors and Warnings . 77 C.5 Errors Implementation within BXF 78 Annex D Protocol Transport (Informative) . 80 D.1 Legend 80 D.2 Request Messagess . 80 D.3 Information Messages 83 D.4 Heartbeat Messages. 87 Annex E Bibliography (Informative) . 90 SMPTE RP 2021-9:2015 Page 3 of 90 pages Foreword
12、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, including Standar
13、ds, 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. SMPTE Engi
14、neering Documents are drafted in accordance with the rules given in its Standards Opeations Manual. SMPTE RP 2021-9 was prepared by Technology Committee 34CS. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation
15、of this Recommended Practice. 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 entirely informative and does n
16、ot form an integral part of this Engineering Document. This practice describes implementation recommendations for applications that plan to support SMPTE 2021, commonly known as Broadcast Exchange Format (BXF) version 4.0. The BXF protocol is a sophisticated language that allows different applicatio
17、n types (e.g., traffic, automation, etc.) to share information in a standardized format. The standard leaves many of the implementation details to the applications that are utilizing it. For example: Applications are only required to implement the aspects of the protocol that are relevant to the typ
18、e of integration they are providing. Content may be identified through an ISAN, house number and/or 1-N alternate identifiers. This “gray area“ makes it possible for applications to implement BXF solutions that, while compliant with the standard, may not be compatible with other BXF implementations.
19、 This recommended practice strives to address this ambiguity by identifying common implementation recommendations that can be shared amongst applications that intend to utilize the BXF protocol to exchange information. SMPTE RP 2021-9:2015 Page 4 of 90 pages 1 Scope This recommended practice has the
20、 following objectives: Describe the types of messages that will be communicated amongst applications and their corresponding formats within BXF SMPTE 2021. Describe the aspects of the BXF protocol which are recommended that applications support to achieve maximum interoperability and also to identif
21、y those aspects of the protocol that are not recommended at this time. Describe the approaches for representing errors within BXF messages. Describe how XML schema extensions should be implemented to maximize interoperability between systems. Describe the following extensions: o Usage attribute exte
22、nsion o Filename element extension o Configuration extension 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
23、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 “Informa
24、tive“ 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,
25、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 n
26、ot“ 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
27、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
28、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 definition. Tables shall be next, followed by formal languages, then figures, and then any o
29、ther language forms. SMPTE RP 2021-9:2015 Page 5 of 90 pages 3 Normative References The following standards contain provisions which, through reference in this text, constitute provisions of this recommended practice. At the time of publication, the editions indicated were valid. All standards are s
30、ubject to revision, and parties to agreements based on this recommended practice are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. SMPTE ST 2021-1:2015, Broadcast Exchange Format (BXF) Requirements and Informative Notes RFC 4122, A Un
31、iversally Unique Identifier (UUID) URN Namespace, IETF, 5 July 2005 4 Note on Wellformedness and Validation (Informative) Two approaches for determining the integrity of an XML document are wellformedness and validation. According to W3C: A “well-formed“ XML document is defined as an XML document th
32、at has correct XML syntax. This means: XML documents must have a root element; XML elements must have a closing tag; XML tags are case sensitive; XML elements must be properly nested; XML attribute values must always be quoted. This should not be confused with a valid XML document, which is defined
33、as a “well-formed“ XML document which also conforms to the rules of a Document Type Definition (DTD) or an XML Schema (XSD), which W3C supports as an alternate to DTD. The XML schemas that comprise the BXF protocol utilize a “lax” processing model for extensions (i.e., PrivateInformation). Therefore
34、, extensions that have an associated XML schema will validate when a message is processed, whereas extensions without schemas must be wellformed, but will not be validated. 5 Processing Model (Normative) The processing model describes the rules for handling elements and attributes within BXF message
35、s and extensions to those messages. The following rules shall apply to this practice: Ignore elements and attributes that are recognized, but not supported by an implementation. For example, if a house number and alternate identifiers are provided to uniquely identify content and a message consumer
36、only recognizes house number, then the alternate IDs should be ignored, as opposed to rejecting the message as invalid. Ignore elements and attributes that are specified within the extensible areas of the protocol (i.e., PrivateInformation) and are not recognized by the message consumer. 6 General C
37、onventions (Normative) The following conventions shall apply to all BXF messages: All element and attribute extensions to the BXF protocol shall have associated XML schemas (and namespaces) so that they can be uniquely identified and resolved. It is recommended that systems should utilize a single,
38、shared repository for BXF schemas and any extensions. Message consumers shall accept or reject a received message in its entirety. For example, if half of the events on a playlist message can be accepted and the other half cannot, the entire message should be rejected. This convention does not prohi
39、bit applications from accepting messages with warnings, where certain values, such as a description, are truncated due to field size restrictions. In this case, the entire message should still be accepted. SMPTE RP 2021-9:2015 Page 6 of 90 pages Optional elements and attributes that are not covered
40、within this document may be included within any message. These values may be consumed by applications that understand them, but they are not required to process a message. References to GUID in SMPTE 2021 and in this recommended practice shall be interpreted as UUID, as specified in RFC 4122. All da
41、te/time elements and attributes within a message shall be explicitly or implicitly represented using canonical UTC. Messages shall be processed in time sequence where message order is retained between a client and server. Message elements shall be processed in the order/sequence that they are specif
42、ied. A message may contain multiple instances of the same element (i.e., same unique identifier). For example, a schedule event is added and updated within an application. The associated changes may be combined into a single event element with an action of add, or specified using two event elements,
43、 with the add element followed by the update element, where both elements have the same unique identifier. All elements shall be processed in the specified sequence. BxfMessage/ext:usage: The usage extension attribute shall be included on every BXF message. It identifies the payload of the message i
44、n a contextual manner so the message consumer can process it in the proper context. Refer to Annex B for a list of recognized usages as well as conventions for creating additional usages. Note that usage values are not configuration types and are not mapped or configured at runtime. BxfMessage/BxfDa
45、ta/PrivateInformation/ext:Filename: The filename extension element is included in a BXF data message when the associated data is provided in a file form instead of the body of the message. This approach may be utilized when the amount of data is exceedingly large and chunking is not desired. Message
46、 length shall not exceed 2 MB. Applications should use internal algorithms to separate data into multiple messages. For example, if a user selects a months worth of schedule information to send, then the application should break the schedule information into multiple messages based on the date or so
47、me other criteria. 6.1 BxfMessage Attributes BxfMessage/id: The id attribute is required by the BXF schema. BxfMessage/dateTime: The date/time attribute is required by the BXF schema. It identifies when the message was created. BxfMessage/messageType: The message type attribute is required by the BX
48、F schema. It identifies the message type/category (e.g., request, reply, information, etc.). BxfMessage/origin: The origin attribute is required by the BXF schema. It identifies the message originator. This value shall be defined at runtime as an aspect of configuration. BxfMessage/originType: The o
49、rigin type attribute is required by the BXF schema. It identifies the originators type (e.g., Traffic system). If a valid type value does not exist in the ATSC code point registry, then a value of “Data_server” shall be used by default. BxfMessage/userName: The user name attribute is required by the BXF schema. It identifies the user that made the application changes which resulted in the message being created. If the message was generated
