MOS Protocol version 2.8.2
Document Revision 533
Revision Date: Wednesday, September 5, 2005
Copyright 2000, 2001, 2002, 2003, 2004, 2005 All Rights Reserved.
This document is provided to You under the conditions outlined below. These conditions are designed to guarantee the integrity of the MOSä Protocol and to ensure the compatibility of solutions implementing the MOSä Protocol. Use or implementation of the MOSä Protocol as described herein, may only occur if You agree to these conditions. Failure to follow these conditions shall void this license. “You” shall mean you as an individual, or, where appropriate, the company or other entity on whose behalf you are using this document, and includes any entity which controls, is controlled by, or is under common control with You.
You must agree to the following in order to use the MOSä Protocol:
1. You must use and implement all messages defined by the MOS protocol MOS 2.8.2 Profiles listed below per the profiles supported by your device.
2. You may not modify message names, order of defined tags within a message, tag structure, defined values, standards and constants.
3. You may not process messages in a means that is dependent on non-standard messages, tags or structures.
4. You may add additional tags to messages, but the modified messages must contain the defined minimum required tags for each message, in the order defined by this document.
5. Implementations of the MOS Protocol following the above guidelines may claim to be “MOSä Compatible” or “MOS v2.8.2 Compatible”
6. If You add additional tags, it is strongly recommended these be included and encapsulated only within the provided <mosExternalMetadata> structure and not inserted into the pre-defined body of the message.
7. You are not allowed to make representations of MOS Compatibility unless you have followed these guidelines.
MOS is a six year old, evolving protocol for communications between Newsroom Computer Systems (NCS) and Media Object Servers (MOS) such as Video Servers, Audio Servers, Still Stores, and Character Generators. The MOS Protocol development is supported through cooperative collaboration among equipment vendors, software vendors and end users.
This document reflects changes to the MOS protocol discussed during the MOS meetings at NAB 2005 and IBC 2004 and is referred to as MOS v2.8.2. This is the final draft. Changes are summarized here.
The document contains bookmarks and hyperlinks. The Table of Contents and other areas contain underlined phrases. Depending on the viewer application used, clicking or double clicking on underlined links will take the viewer to the relevant portion of the document.
Please make special note of the Profiles section which provides context for the use of command messages which are later defined in detail.
Examples of each MOS message and data structure are included. These messages may be used for testing. Developers are encouraged to cut these messages from the document, change the value of ID tags as appropriate, and paste the modified messages into validation tools. Other than these example messages, validation tools are not provided by the MOS Group.
1. Introduction
2. MOS Profiles
2.1. Profile 0 – Basic Communication
2.2. Profile 1 - Basic Object Based Workflow
2.3. Profile 2 – Basic Running Order / Content List Workflow
2.4. Profile 3 – Advanced Object Based Workflow
2.5. Profile 4 – Advanced RO/Content List Workflow
2.7. Profile 6 – MOS Redirection
2.8. Profile 7 – MOS RO/Content List Modification
3. Media Object Server Protocol Message Definition
“mos” (Media Object Server) family of messages
3.1. Basic Object Communication
3.1.1. mosAck - Acknowledge MOS Object Description
3.1.2. mosObj - MOS Object Description
3.1.3. mosReqObj - Request Object Description
3.2. Object Resynchronization / Rediscovery
3.2.1. mosReqAll - Request All Object Data from MOS
3.2.2. mosListAll - Listing of All Object Data from MOS
mosReqObjList family of messages
3.2.3 mosReqSearchableSchema
3.2.4 mosListSearchableSchema
3.2.5 mosReqObjList
3.2.6 mosObjList
3.3. Object and Item Management
3.3.1. mosObjCreate – Mos Object Create
3.3.2. mosItemReplace – Replace an Item Reference in an NCS Story with updated Item sent from the MOS
3.3.3 mosReqObjAction – NCS requests action on MOS object
“ro” (Running Order) family of messages
3.4. ro Playlist Construction
3.4.1. roAck - Acknowledge Running Order
3.4.2. roCreate – Create Running Order
3.4.3. roReplace - Replace Running Order
3.4.4. roMetadataReplace – Replace the metadata associated with a RO Playlist
3.4.5. roDelete - Delete Running Order
3.5. ro Synchronization, Discovery & Status
3.5.1. roReq - Request Running Order
3.5.2. roList - List Running Order
3.5.3. roReqAll - Request All Running Order Descriptions
3.5.4. roListAll - List All Running Order Descriptions
3.5.5. roStat - Status of a MOS Running Order
3.5.6. roReadyToAir - Identify a Running Order as Ready to Air
3.6. ro Story and Item Sequence Modification
NOTE: The following messages are included only for backwards compatibility with MOS v2.6 and have been replaced by 3.6.12 roElementAction in MOS version 2.8. These messages will be dropped from future versions of the Protocol.
3.6.1. roStoryAppend - Append Stories to Running Order
3.6.2. roStoryInsert - Insert Stories in Running Order
3.6.3. roStoryReplace - Replace Story with Another in a Running Order
3.6.4. roStoryMove – Move a Story to a specific location in a Running Order
3.6.5. roStorySwap - Swap Positions of Stories in Running Order
3.6.6. roStoryDelete - Delete Stories from Running Order
3.6.7. roStoryMoveMultiple – Move one or more stories to a new position in the playlist
3.6.8. roItemInsert – Insert Items in Story
3.6.9. roItemReplace – Replace an Item with one or more Items in a Story
3.6.10. roItemMoveMultiple – Move one or more Items to a specified position within a Story
3.6.11. roItemDelete – Delete Items in Story
3.6.12. roElementAction – Performs specific Action on a Running Order
3.7. ro Control and Status feedback
3.7.1. roItemStat - Status of a Single Item in a MOS Running Order
3.7.2. roItemCue – Notification of an Item Event
3.7.3. roCtrl – Running Order Control
3.8. Metadata Export
3.8.1. roStorySend – Sends story information, including body, from Running Order
3.9. MOS RO/Content List Modification
3.9.1. roReqStoryAction – MOS requests action on NCS story
4. Other messages and data structures
4.1. Other messages and data structures
4.1.1. heartbeat - Connection Confidence Indicator
4.1.2. reqMachInfo - Request Machine Information
4.1.3. listMachInfo - Machine Description List
4.1.4. mosExternalMetadata – Method for including and transporting Metadata defined external to MOS
4.1.5. mosItemReference – Metadata block transferred by ActiveX Controls
4.1.6. messageID – Unique Identifier for Requests
4.1.7. objPaths – Unambiguous pointers to media files
5. ActiveX Control Specification
5.1 Methods, Events and Data Types
5.3 ActiveX Communication messages
5.3.1. ncsAck
5.3.2. ncsReqAppInfo
5.3.3. ncsAppInfo
5.3.4. ncsReqAppMode
5.3.5. ncsStoryRequest
5.3.6. ncsItemRequest
5.3.7. roStorySend
5.3.8. ncsItem
5.3.9. mosItemReplace
7.1. Changes from MOS version 2.8.1 to 2.8.2
7.2. Changes from MOS version 2.8 to 2.8.1
7.3. Changes from MOS version 2.6 to 2.8
7.4. Changes to MOS version 2.6 WD-2001-08-09
7.5. Changes from MOS version 2.5 to 2.6 WD-2001-06-06
7.6. Changes from MOS version 2.0 to 2.5 WD-2000-08-01
7.7. Changes for MOS 2.0 WD-1999-05-12
7.8. Changes from MOS version 1.52 to 2.0 WD-1999-03-17
9.2. XML FAQ
9.3. Recommended Reading
9.4. XML Web Sites
This document reflects changes to the MOS protocol discussed during the MOS Working Group meetings at NAB 2005 and IBC 2004.
The roAck and roItemStat messages now contain an optional itemChannel element. Its purpose is to allow the NCS to reflect a new channel when the MOS changes the channel on an item.
The mosObj message now contains an optional objPaths element. Its purpose is to allow the MOS to indicate how to retrieve its media objects.
A new message called mosReqObjAction has been added to Profile 3. It is a generalization of the mosObjectCreate message, in that it allows an NCS to modify or delete the placeholder MOS objects that it creates.
A new profile “Profile 7 – MOS RO/Content List Modification” has been added. Its purpose is to allow a MOS to make changes to the running order in an NCS. The profile contains one new message called roReqStoryAction. This message allows the MOS to add, modify, or delete stories in the NCS. Correspondingly, there is a new tag called mosProfile7 in the listMachInfo message.
The roElementAction message has a new operation “SWAP.” This repairs an oversight made in version 2.8, where the roStorySwap message was supposed to be replaced by roElementAction, but how was never specified.
A reminder: MOS Protocol v2.8.2 compatible equipment will ignore, without error, any unknown tags in a message, so long as the message or structure contains properly formatted XML content and the minimum subset of required MOS tags for that message or structure.
The purpose of these profiles is to define basic levels of functionality enabled by the MOS Protocol v2.8.2.
There are seven Profiles defined:
Profile 0 – Basic Communications
Profile 1 – Basic Object Based Workflow
Profile 2 – Basic Running Order/Content List Workflow
Profile 3 – Advanced Object Based Workflow
Profile 4 – Advanced RO/Content List Workflow
Profile 7 – MOS RO/Content List Modification
Vendors wishing to claim MOS compatibility must fully support, at a minimum, Profile 0 and at least one other Profile.
When claiming MOS compatibility or using the MOS Logo, vendors must clearly state which profiles of one through six they support. For instance “MOS Compatible – Profiles 1,2,3,4,6”
In order to claim support for a specific profile the vendor must fully implement all messages in the manner specified by the profile. In addition, the vendor must fully implement and support the workflow described by the profile.
If a vendor does not state profile support, or does not support all messages or functionality described by a profile, or does not support at least two profiles, one of them being Profile 0, they cannot claim MOS compatibility.
Optional functionality is clearly identified with the word “Optional” or with the phrase “Recommended Work Practice” in bold, followed with optional information in italics.
All other functionality is required.
The purpose of MOS Profiles is to describe minimum levels of functionality and support. Vendors are encouraged to derive more complex levels of functionality from any Profile so long as support is maintained for the basic profile and MOS syntax and transport rules are not compromised.
This Profile enables basic MOS XML message exchange and discovery between applications and machines using TCP/IP sockets.
Messages required for support of Profile 0:
General Work Flow for Profile 0
· Establish communication to another MOS device
· Send a <heartbeat> message to another application and receive a <heartbeat> message in response
· Send a <reqMachInfo> message to another application and receive a <listMachInfo> message in response.
Implementation Notes
This Profile encompasses the most basic requirements and functions to support MOS Protocol message transfer. The three basic messages included in this profile, <heartbeat>, <reqMachInfo> and <listMachInfo> can be exchanged between any MOS v2.8.2 compliant devices
Profile 0 required MOS message support
The heartbeat message is designed to allow one application to confirm to another that it is still alive and communications between the two machines is viable.
An application will respond to a heartbeat message with another heartbeat message. However, care should be taken in implementation of this message to avoid an endless looping condition on response.
Recommended Work Practice: It is useful for a MOS Protocol enabled application to be aware of the three levels of connectivity which are required for MOS message exchange:
1)
Network Connectivity: You
must be able to “
2) Socket Connectivity: You must be able to establish a socket connection with the remote application
3) Application Response: You must be able to receive an ACK message in response to the message you have transmitted.
If you can send a <heartbeat> message and receive a <heartbeat> message in response you have verified the continuity at all three levels.
Each heartbeat message contains a time stamp. This gives each application the opportunity to synchronize time of day, with a relatively low degree of precision, and to be aware of the other machine’s local offset from GMT.
This message is a request for the target machine to respond with a listMachInfo message.
This message allows the machine to identify itself with manufacturer ID, model, hardware and software revisions, MOS version supported, etc.
This message identifies which MOS Profiles it supports.
The machine may also optionally identify information necessary for remote devices to install and configure an associated ActiveX control.
Recommended Work Practice: Applications may optionally use the information contained in this message to provide automatic or semi-automatic configuration.
General Explanation of MOS message format and construction
Identification
In practice the MOS and NCS character names are predefined in each system and IP addresses associated with each name.
Encoding
The supported character encoding is ISO 10646 (Unicode) in UCS-2, as defined in The Unicode Standard, version 2.0. All MOS message contents are transmitted in Unicode, high-order byte first, also known as “big endian.”
MOS Message Format
The MOS Protocol is fundamentally a tagged text data stream. In versions 2.x, data fields are character delimited using Extensible Markup Language (XML™) tags defined in the MOS Data Type Definition (DTD). In MOS v1.x data fields were delimited using a proprietary format.
Extensible Markup Language (XML)
The syntax of MOS v2.8.2 is an application of XML, an international standard for describing document content structure. XML is a simple, flexible text format based on SGML (ISO 8879). XML is an abbreviated version of SGML, to make it easier for you to define your own document types, and to make it easier for programmers to write programs to handle them. It omits the more complex and less-used parts of SGML in return for the benefits of being easier to write applications, easier to understand, and more suited to delivery and interoperability over the Web.
All tags are case sensitive. All MOS messages must be well formed XML, but are not required to be valid.
Each MOS message begins with the root tag (“mos”), followed by the MOS and NCS ID (“mosID” and “ncsID”), and followed by the message type. Data follows in tagged form.
Vendors are encouraged to add CR/LF and Tabs within a message to improve readability for debugging purposes.
Unknown Tags
Should a MOS or NCS encounter an unknown message or data tag the device will ignore the tag and the data and continue to process the message. Unknown data tags will not generate an application error. The application has the option of indicating a warning.
Data Format for Object <description> field
The value of Object <description> is restricted to plain Unicode UCS-2 text that includes Tab, CR, LF and the optional markup for paragraphs, tabs and emphasis. Formatted text such as HTML, RTF, etc. will not be allowed in the unstructured description area.