SMPTE ST 2032-1-2007 Media Dispatch Protocol (MDP) Protocol Specification.pdf

《SMPTE ST 2032-1-2007 Media Dispatch Protocol (MDP) Protocol Specification.pdf》由会员分享，可在线阅读，更多相关《SMPTE ST 2032-1-2007 Media Dispatch Protocol (MDP) Protocol Specification.pdf（43页珍藏版）》请在麦多课文档分享上搜索。

1、 Copyright 2007 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Approved December 14, 2007 Table of Contents Page Foreword . 4 Introduction . 4 1 Scope 5 2 Conformance Notation 5 3 Normative References 5 4 Acronyms (Informative).

2、 6 5 Definitions . 7 6 Background (Informative) 8 7 Overview of Specification 8 7.1 Context for Media Dispatch Protocol (Informative). 8 7.2 Organizations and Agents. 9 7.3 Transactions and Projects 9 7.4 Manifest Document (Informative) 10 7.5 Transaction Lifecycle (Informative). 11 7.6 Messages (In

3、formative) 11 7.7 Transfer (Informative) . 12 7.8 Capabilities Document (Informative). 12 7.9 Mappings. 12 7.10 Profiles 13 7.11 Dark Metadata. 13 8 Message Set Specification 13 8.1 Parameters. 13 8.2 Commands. 14 8.2.1 cmd_initiatingtransaction. 14 8.2.2 cmd_sendingmanifest 15 Page 1 of 43 pages SM

4、PTE 2032-1-2007SMPTE STANDARD Media Dispatch Protocol (MDP) Protocol Specification SMPTE 2032-1-2007 Page 2 of 43 pages 8.2.3 cmd_pausetransfers.15 8.2.4 cmd_resumetransfers.16 8.2.5 cmd_completetransaction16 8.2.6 cmd_abortingtransaction17 8.2.7 cmd_sendingcapabilities17 8.2.8 cmd_requestnotifiatio

5、n17 8.2.9 cmd_sendingnotification17 8.3 Confirmations18 8.3.1 cnf_ok.18 8.3.2 cnf_refused18 8.3.3 cnf_error18 8.3.4 cnf_abort18 8.4 Queries .18 8.4.1 qry_requestmanifest.18 8.4.2 qry_reguestcapabilities19 8.5 Replies19 8.5.1 rpl_manifest19 8.5.2 rpl_capabilities.19 8.5.3 rpl_delayed19 8.5.4 rpl_erro

6、r19 8.5.5 rpl_abort19 9 Data Specification20 9.1 Data Structures20 9.2 Character Set.20 9.3 Element Tables20 9.4 Representation of Date and Time .20 9.5 manifest .21 9.6 transferoption 22 9.7 file23 9.8 hash25 9.9 transferwith.25 9.10 updated.25 9.11 capabilities26 9.12 ok27 9.13 error.27 SMPTE 2032

7、-1-2007 Page 3 of 43 pages 9.14 refused. 28 9.15 delayed. 28 9.16 abort . 28 10 Dictiionary . 28 10.1 Property Value Tables . 28 10.2 profile. 28 10.3 usecase. 29 10.4 mapping. 29 10.5 protocol (Administrative Register) . 29 10.6 direction. 31 10.7 hashtype. 31 10.8 status. 32 10.9 updatereason 33 1

8、0.10 reason 34 Annex A Bibliography (Informative) 36 Annex B Examples (Informative) 37 B.1 Example of Message Sequence. 37 B.2 Example Manifest Document 38 B.3 Example Capabilities Document. 40 Annex C Register Management (Normative) 41 C.1 protocol Property Dynamic Provisions 41 C.2 SMPTE Headquart

9、ers Office Procedure 42 Annex D Administrative Register Submission Form (Normative) . 43 SMPTE 2032-1-2007 Page 4 of 43 pages Foreword SMPTE (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in

10、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 a bona fide

11、 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 2032-1 was prepared by Technology Commi

12、ttee See on Committee on Television Systems Technology. Introduction This section is entirely informative and does not form an integral part of this document. The Media Dispatch Protocol (MDP) is a means of orchestrating the delivery of media files over IP networks. It defines a standard mechanism f

13、or implementations to initiate a delivery, to negotiate the details of the delivery, to provide information about the progress of the delivery, and to provide a confirmation of the outcome of the delivery. MDP allows organizations to transfer files at agreed times, using agreed transfer protocols, a

14、nd using an agreed set of secure technologies (where appropriate). However, the protocol is not overly prescriptive in regards to which protocols or technologies shall be used; rather it provides a framework which allows organizations to choose those that best suit their own needs. MDP is a multi-pa

15、rt standard: Part 1, this part, defines the logical messages, data structures and data dictionary of MDP. Part 2, the MDP mapping specification, defines representations of the messages and structures defined in Part 1. Part 3, the MDP profile specification, defines subsets of the protocol and rules

16、on the use of these subsets. Part 4, the MDP Engineering Guideline, introduces and describes MDP and how it can be used in particular scenarios. SMPTE 2032-1-2007 Page 5 of 43 pages 1 Scope This standard defines the message set, data structures and data dictionary of the Media Dispatch Protocol (MDP

17、) for orchestrating the transfer of files across IP networks. The standard also specifies requirements on mapping specifications that define representations of the messages and data structures. The standard also defines requirements on profile specifications that define subsets of the protocol and r

18、ules on the use of those subsets. 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 indispens

19、able, 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 paragra

20、phs 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 parti

21、cularly 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 act

22、ion 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 th

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

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

25、andard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. W3C XML Schema 1.1 Part 2: Datatypes IETF RFC 1321, The MD5 Message-Digest Algorithm IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types IETF RFC 2

26、279, UTF-8 A Transformation Format of ISO 10646 SMPTE 2032-1-2007 Page 6 of 43 pages ISO/IEC 3309:1993, Information Technology Telecommunications and Information Exchange Between Systems High-Level Data Link Control (HDLC) Procedures Frame Structure ISO/IEC 8601:2000, Data Elements and Interchange F

27、ormats Information Interchange Representation of Dates and Times ISO/IEC 10646:2003, Information Technology Universal Multiple-Octet Coded Character Set (UCS) FIPS 180-2, Secure Hash Signature 4 Acronyms (Informative) CRC: Cyclic Redundancy Check FIPS: Federal Information Processing Standards (issue

28、d by NIST) FTP: File Transfer Protocol HTTP: Hypertext Transfer Protocol IANA: Internet Assigned Numbers Authority IETF: Internet Engineering Task Force ISO: International Organization for Standardization MD5: Message-Digest Algorithm 5 MDP: Media Dispatch Protocol MIME: Multipurpose Internet Mail E

29、xtensions MXF: Material Exchange Format NIST: National Institute of Standards and Technology RFC: Request For Comment SFTP: Secure File Transfer Protocol SHA: Secure Hash Algorithm TLS: Transport Layer Security URI: Uniform Resource Identifier URL: Uniform Resource Locator UTF-8: 8-bit UCS/Unicode T

30、ransformation Format W3C: World Wide Web Consortium XML: Extensible Markup Language SMPTE 2032-1-2007 Page 7 of 43 pages 5 Definitions Agent: A software entity that acts on behalf of an organization to implement the Media Dispatch Protocol. Authenticate: Confirm the identity of an agent. Command: A

31、message that typically causes change within a transaction or sends information. Confirmation: A message that provides an immediate positive or negative acknowledgement of a command. Data structure: A defined piece of information that may be carried within a message. May be an element, property or li

32、st. Dictionary: Allowed values of properties. Element: A data structure containing other elements, lists or properties. Note: the term “element” is used in other SMPTE documents and might have a different meaning in these. Encrypt: Secure a message or transfer, for example by means of a cipher. File

33、: A unit of content, typically a stored media file, though files may be dynamically generated. Hash type: Algorithm used in an integrity check process. Initiator agent: The agent that sends a message to initiate a transaction. Integrity check: Verify that a file has been transferred correctly, for e

34、xample by means of a hashing algorithm. List: A data structure containing a single unordered set of properties or elements of the same type. Note: the term “list” is used in other SMPTE documents and might have a different meaning in these. Manifest document: A representation of the details and stat

35、e of a transaction. Takes the form of an element. Mapping: A specification for how MDP messages and data structures shall be represented on the network. Media Dispatch Protocol: A standard mechanism for two organizations to initiate a delivery, agree on the details of how it should happen, and manag

36、e the delivery. Message: A message passed between agents. May be a command, confirmation, query or reply. Message endpoint: A URL at which an agent receives a message. Negotiation: The process by which agents agree the details of the transfers within a transaction. Organization: A company, corporati

37、on, department, etc. that requires delivery of files to or from another organization. Parameter: Information passed within a message. Pause: Stop a transfer in such a way that it can be later resumed. Profile: A specification of a subset of MDP intended to aid interoperability. Defines which message

38、s and data may and may not be used, and defines allowed sequences of messages and actions. SMPTE 2032-1-2007 Page 8 of 43 pages Property: A data structure containing a single simple value. Pull-mode transfer: A transfer initiated from the receiving end. Push-mode transfer: A transfer initiated from

39、the sending end. Query: A message that allows an agent to request information from another agent. Reply: A message in immediate response to a query. Resume: Restart a paused transfer. Target agent: The agent that receives a message to initiate a transaction. Transaction: The sequence of steps undert

40、aken by two agents while negotiating and performing the transfer of a set of files. Transfer: File transfer. Transfer endpoint: A sending or receiving URL used for a file transfer. 6 Background (Informative) Treating media as files within systems and within organizations is now commonplace, with int

41、eroperability aided through standards such as MXF (SMPTE 377M). Furthermore, as high-bandwidth IP-based networks become increasingly cost-effective, delivery of media content as files is becoming an attractive alternative to the physical movement of tapes, films or disks, or the use of video and aud

42、io circuits. A range of mechanisms exist to transfer files, including well-known protocols such as FTP (RFC 959) and HTTP (RFC 2616), secure protocols such as SFTP and HTTPS (RFC 2818), as well as high-performance transfer protocols developed by academic and commercial organizations. These mechanism

43、s can be expected to change with time as better protocols are developed and standardized. Often, file delivery will be required as part of an automated workflow. For example approval of a program by a producer might trigger initiation of a delivery, and completion of the delivery might cause an asse

44、t management system to automatically update its database with details of the content. To achieve interoperability between systems and/or organizations within an automated workflow, it is important to have standards for formats and metadata, and for network protocols. But it is also necessary to have

45、 a standard approach for initiation of a delivery, for negotiation of the file set to be sent, the delivery mechanism and other details of the transfer, and for reporting the progress and outcome of the transaction. The Media Dispatch Protocol provides such a standard. 7 Overview of Specification 7.

46、1 Context for Media Dispatch Protocol (Informative) Figure 1 shows MDP in the context of two organizations that need to deliver media as files. MDP agents, usually referred to in this standard simply as “agents”, are software entities that manage the deliveries. Typically an agent will provide an AP

47、I to allow media applications to request deliveries, check on how they are progressing, and be informed of their outcome. The applications accessing the API might range from a simple user interface application to a complex workflow automation system. Where delivery occurs across the Internet or othe

48、r public network, often an agent will run on a separate computer outside a firewall. SMPTE 2032-1-2007 Page 9 of 43 pages For simplicity, Figure 1 shows file transfer as occurring between the same systems on which the agents are hosted. However, in general this might not be the case. For example MDP

49、 supports a scenario where the agent receiving the files performs a pull-mode transfer from a separate server on which the files reside, but which does not itself run an MDP agent. Figure 1 Context for Media Dispatch Protocol Agents communicate with each other to agree what files will be transferred, by what mechanism, and when, and to exchange information on the progress and outcome of the transfers. This communication is performed using the Media Dispatch Protocol, and is implemented using a standard set of mess