Media Object Server (MOS)
Protocol

Working Draft for MOS Protocol version 2.5
Document Revision 2.5. Revision Date October 31, 2000

Abstract

MOS is an 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. This protocol is supported and developed through cooperative collaboration among equipment vendors, software vendors and end users.

Status of this document

This draft document reflects changes to the MOS protocol made during the MOS meeting at NAB 2000. Logic and message content of MOS version 1.x have undergone minor changes based on agreements reached in that meeting.
Five additional messages have been added to this revision of the documentation since the MOS 2.0 specification, and are included in this document.

Media Object Server Protocol 2.5

Table of Contents (NOTE: Additions/Changes to TOC since 2.04 are in BOLD) 1. Introduction
    1.1 Message Exchange
    1.2 Identification
    1.3 Encoding
2. MOS Message Format
    2.1 Extensible Markup Language (XML)
    2.2 Message Acknowledgement
    2.3 Message Transport
    2.4 Unknown Tags
    2.5 Object Description Format
    2.6 Languages
    2.7 Numbers
    2.8 Running Orders
    2.9 Samples
3. MOS Messages
    3.1 mosAck - Acknowledge MOS Object Description
    3.2 mosObj - MOS Object Description
    3.3 mosReqObj - Request Object Description
    3.4 mosReqAll - Request All Object Data from MOS
    3.5 mosListAll - Listing of All Object Data from MOS
    3.6 mosObjCreate – Mos Object Create
    3.7 roCreate – Create Running Order
    3.8 roAck - Acknowledge Running Order
    3.9 roReplace - Replace Running Order
    3.10 roDelete - Delete Running Order
    3.11 roReq - Request Running Order
    3.12 roList - List Running Order
    3.13 roStoryAppend - Append Stories to Running Order
    3.14 roStoryInsert - Insert Stories in Running Order
    3.15 roStorySwap - Swap Positions of Stories in Running Order
    3.16 roStoryReplace - Replace Story with Another in a Running Order
    3.17 roStoryDelete - Delete Stories from Running Order
    3.18 roStorySend – Sends Story Information including body from running Order
    3.19 roItemStat - Status of a Single Item in a MOS Running Order
    3.20 roStat - Status of a MOS Running Order
    3.21 roReadyToAir - Identify a Running Order as Ready to Air
    3.22 roReqAll - Request All Running Order Descriptions
    3.23 roListAll - List All Running Order Descriptions
    3.24 roItemCue – Notification of an Item Event
    3.25 roCtrl – Running Order Control
    3.26 heartbeat - Connection Confidence Indicator
    3.27 reqMachInfo - Request Machine Information
    3.28 listMachInfo - Machine Description List
4. Field Descriptions
5. Recent Changes
    5.1 Changes from MOS version 2.0 to 2.5 WD-2000-08-01
    5.2 Changes for MOS 2.0 WD-1999-05-12
    5.3 Changes from MOS version 1.52 to 2.0 WD-1999-03-17
6. MOS 2.5 DTD
7. References and Resources
    7.1 MOS Protocol Web Page
    7.2 XML FAQ
    7.3 Recommended Reading
    7.4 XML Web Sites

1. Introduction

This document reflects changes to the MOS protocol made during the MOS meeting at NAB 2000.

Five additional messages have been added.

In addition, an optional tag which explicitly defines the origin of an object has been added to the Item structure. This addition is reflected in all RO Construction messages (3.7, 3.9, 3.12-3.15) This additional information is related to the roStorySend and roItemCue messages new to this version.

A reminder: MOS equipment should 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.

1.1 Message Exchange

Both the NCS and MOS can originate messages. Transmitted messages require a response from the receiver before the transmitter will attempt to send the next message in the queue belonging to that specific port (either upper or lower). Upper and lower port messages are not related so that while a machine is waiting for a response on the lower port it may continue to have a dialog on the upper port.

Note: "Two Ports - Four Sockets" Each pair of communicating machines uses two ports. Each machine must be able to accept and handle messages on a minimum of two sockets per port. Once established, socket connections do not need to be dropped and then re-established between messages. Generally, the acknowledgment of a message should be sent down the same socket on which the original message was received. However, machines should be able to handle situations in which each message arrives in a separate, discrete socket session (though this is not very efficient).

/----Socket1
Lower Port (10540)----<
\----Socket2

/----Socket1
Upper Port (10541)----<
\----Socket2

Note: "Multiple MOS Connections" Each machine (NCS and MOS) should be capable of establishing and maintaining connections to multiple systems of the opposite type. e.g. An NCS should be capable of connecting to multiple Media Object Servers. Media Object Servers should also be capable of connecting to multiple NCSs.

1.2 Identification

In practice the MOS and NCS character names are predefined in each system and IP addresses associated with each name.

1.3 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.

2. MOS Message Format

The MOS Protocol is fundamentally a tagged text data stream. In the version 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.

2.1 Extensible Markup Language (XML)

The syntax of MOS v2.5 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.

2.2 Message Acknowledgement

When a message is sent by one device, it will not send another message until it receives an acknowledgement (“ACK”) or error (“NACK”) from the other device. Vendors should reset and/or retry when a timeout occurs.

2.3 Message Transport

MOS Lower Port (10540) is defined as the default TCP/IP port on which the NCS will accept connections from MOS devices. Multiple simultaneous connections are supported. This socket is referred to as “Media Object Metadata” port in the Message Types section.

MOS Upper Port (10541) is defined as the default TCP/IP port on which the MOS will accept connections from the NCS. Multiple simultaneous connections are supported. This socket is referred to as “Running Order” port in the Message Types section.

Ports 10520 and 10521 were specified as Lower and Upper Ports in previous versions of the MOS Protocol. Beginning in version 2.5 these ports are vendor selectable but site specific. All MOS enabled machines within a site or enterprise should communicate using the same ports. Because some vendors reported problems using port 10521 with Microsoft Windows NT the new port numbers used as examples are now 10540 and 10541.

For example, an NCS initiated create running order command and the MOS' associated ACK would take place on MOS Upper Port (10541). Object updates sent from the MOS and the associated NCS ACK would take place on MOS Lower Port (10540).

2.4 Unknown Tags

Should a MOS or NCS encounter an unknown message or data tag the device should ignore the tag and the data and continue to process the message. Unknown data tags should not generate an application error. The application has the option of indicating a warning.

2.5 Object Description Format

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.

2.6 Languages

   Data tags and constants are formatted as English.
   The only Data Fields that can contain other languages are:
      createdBy
      modifiedBy
      roSlug
      storySlug
      itemSlug
      description

2.7 Numbers

   Numbers are formatted as their text equivalent, e.g.:
      The decimal number 100 is represented as text “100”.
      Hex FF55 is represented as text “0xFF55” or “xFF55”.

2.8 Running Orders

      1) Running Order (Unique ID - may appear only once in the NCS)
         2) Story (Unique ID - may appear only once in the RO)
            3) Item (Unique ID - may appear only once in a story)
               4) Object (Unique ID - may appear only once in an item)

   It is assumed that all Unique ID’s (UID’s) created by one machine are respected by others.
   Order of data fields within an item is significant.
   Items are sent in the order they should be played.
   Order of items is significant.
   Multiple Running Orders may contain the same Story.
   Running Orders may contain zero or more Stories.
   Multiple stories can contain the same Object referenced by different Items.
   Stories can contain multiple Items.
   Item IDs may appear only once in a Story, but can appear in other Stories.
   Objects can appear multiple times in a Story, but only one object may appear in an Item.
   A Running Order Item is defined by the combination Running Order.Story.Item and contains the UID’s of the Running Order, Story
   and Item which together can identify a unique Item within a Running Order. Additions, deletions, and moves within the running
   order are referenced in this way to the Item.

2.9 Samples

Still Store and Character Generator media objects are defined as having 1 sample per second. They are special cases that require the NCS and MOS applications to understand they do not change every second.

3. MOS Messages

   In the Structural Outline sections below use of “?” specifies optional element, “+” specifies one or more of the element, and “*”
   specifies zero or more of the element. Elements without any of these three special characters are required.
   Tags enclosed in parenthesis and separated by "|" represent a selection.
   The Syntax section shows the definition of non-terminals for this message from the DTD.
   Examples shown are representative of syntax only and do not represent samples from any system.

3.1 mosAck - Acknowledge MOS Object Description

Purpose The MOS Acknowledgement for the MOS OBJ message.

Response

N/A

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

mos
    mosID
    ncsID
    mosAck
       objID
       objRev
       status
       statusDescription

[Home] [Up]		Media Object Server (MOS) Protocol Working Draft for MOS Protocol version 2.5 Document Revision 2.5. Revision Date October 31, 2000 Abstract MOS is an 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. This protocol is supported and developed through cooperative collaboration among equipment vendors, software vendors and end users. Status of this document This draft document reflects changes to the MOS protocol made during the MOS meeting at NAB 2000. Logic and message content of MOS version 1.x have undergone minor changes based on agreements reached in that meeting. Five additional messages have been added to this revision of the documentation since the MOS 2.0 specification, and are included in this document. Media Object Server Protocol 2.5 Table of Contents (NOTE: Additions/Changes to TOC since 2.04 are in BOLD) 1. Introduction 1.1 Message Exchange 1.2 Identification 1.3 Encoding 2. MOS Message Format 2.1 Extensible Markup Language (XML) 2.2 Message Acknowledgement 2.3 Message Transport 2.4 Unknown Tags 2.5 Object Description Format 2.6 Languages 2.7 Numbers 2.8 Running Orders 2.9 Samples 3. MOS Messages 3.1 mosAck - Acknowledge MOS Object Description 3.2 mosObj - MOS Object Description 3.3 mosReqObj - Request Object Description 3.4 mosReqAll - Request All Object Data from MOS 3.5 mosListAll - Listing of All Object Data from MOS 3.6 mosObjCreate – Mos Object Create 3.7 roCreate – Create Running Order 3.8 roAck - Acknowledge Running Order 3.9 roReplace - Replace Running Order 3.10 roDelete - Delete Running Order 3.11 roReq - Request Running Order 3.12 roList - List Running Order 3.13 roStoryAppend - Append Stories to Running Order 3.14 roStoryInsert - Insert Stories in Running Order 3.15 roStorySwap - Swap Positions of Stories in Running Order 3.16 roStoryReplace - Replace Story with Another in a Running Order 3.17 roStoryDelete - Delete Stories from Running Order 3.18 roStorySend – Sends Story Information including body from running Order 3.19 roItemStat - Status of a Single Item in a MOS Running Order 3.20 roStat - Status of a MOS Running Order 3.21 roReadyToAir - Identify a Running Order as Ready to Air 3.22 roReqAll - Request All Running Order Descriptions 3.23 roListAll - List All Running Order Descriptions 3.24 roItemCue – Notification of an Item Event 3.25 roCtrl – Running Order Control 3.26 heartbeat - Connection Confidence Indicator 3.27 reqMachInfo - Request Machine Information 3.28 listMachInfo - Machine Description List 4. Field Descriptions 5. Recent Changes 5.1 Changes from MOS version 2.0 to 2.5 WD-2000-08-01 5.2 Changes for MOS 2.0 WD-1999-05-12 5.3 Changes from MOS version 1.52 to 2.0 WD-1999-03-17 6. MOS 2.5 DTD 7. References and Resources 7.1 MOS Protocol Web Page 7.2 XML FAQ 7.3 Recommended Reading 7.4 XML Web Sites 1. Introduction This document reflects changes to the MOS protocol made during the MOS meeting at NAB 2000. Five additional messages have been added. In addition, an optional tag which explicitly defines the origin of an object has been added to the Item structure. This addition is reflected in all RO Construction messages (3.7, 3.9, 3.12-3.15) This additional information is related to the roStorySend and roItemCue messages new to this version. A reminder: MOS equipment should 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. 1.1 Message Exchange Both the NCS and MOS can originate messages. Transmitted messages require a response from the receiver before the transmitter will attempt to send the next message in the queue belonging to that specific port (either upper or lower). Upper and lower port messages are not related so that while a machine is waiting for a response on the lower port it may continue to have a dialog on the upper port. Note: "Two Ports - Four Sockets" Each pair of communicating machines uses two ports. Each machine must be able to accept and handle messages on a minimum of two sockets per port. Once established, socket connections do not need to be dropped and then re-established between messages. Generally, the acknowledgment of a message should be sent down the same socket on which the original message was received. However, machines should be able to handle situations in which each message arrives in a separate, discrete socket session (though this is not very efficient). /----Socket1 Lower Port (10540)----< \----Socket2 /----Socket1 Upper Port (10541)----< \----Socket2 Note: "Multiple MOS Connections" Each machine (NCS and MOS) should be capable of establishing and maintaining connections to multiple systems of the opposite type. e.g. An NCS should be capable of connecting to multiple Media Object Servers. Media Object Servers should also be capable of connecting to multiple NCSs. 1.2 Identification In practice the MOS and NCS character names are predefined in each system and IP addresses associated with each name. 1.3 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. 2. MOS Message Format The MOS Protocol is fundamentally a tagged text data stream. In the version 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. 2.1 Extensible Markup Language (XML) The syntax of MOS v2.5 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. 2.2 Message Acknowledgement When a message is sent by one device, it will not send another message until it receives an acknowledgement (“ACK”) or error (“NACK”) from the other device. Vendors should reset and/or retry when a timeout occurs. 2.3 Message Transport MOS Lower Port (10540) is defined as the default TCP/IP port on which the NCS will accept connections from MOS devices. Multiple simultaneous connections are supported. This socket is referred to as “Media Object Metadata” port in the Message Types section. MOS Upper Port (10541) is defined as the default TCP/IP port on which the MOS will accept connections from the NCS. Multiple simultaneous connections are supported. This socket is referred to as “Running Order” port in the Message Types section. Ports 10520 and 10521 were specified as Lower and Upper Ports in previous versions of the MOS Protocol. Beginning in version 2.5 these ports are vendor selectable but site specific. All MOS enabled machines within a site or enterprise should communicate using the same ports. Because some vendors reported problems using port 10521 with Microsoft Windows NT the new port numbers used as examples are now 10540 and 10541. For example, an NCS initiated create running order command and the MOS' associated ACK would take place on MOS Upper Port (10541). Object updates sent from the MOS and the associated NCS ACK would take place on MOS Lower Port (10540). 2.4 Unknown Tags Should a MOS or NCS encounter an unknown message or data tag the device should ignore the tag and the data and continue to process the message. Unknown data tags should not generate an application error. The application has the option of indicating a warning. 2.5 Object Description Format 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. 2.6 Languages Data tags and constants are formatted as English. The only Data Fields that can contain other languages are: createdBy modifiedBy roSlug storySlug itemSlug description 2.7 Numbers Numbers are formatted as their text equivalent, e.g.: The decimal number 100 is represented as text “100”. Hex FF55 is represented as text “0xFF55” or “xFF55”. 2.8 Running Orders 1) Running Order (Unique ID - may appear only once in the NCS) 2) Story (Unique ID - may appear only once in the RO) 3) Item (Unique ID - may appear only once in a story) 4) Object (Unique ID - may appear only once in an item) It is assumed that all Unique ID’s (UID’s) created by one machine are respected by others. Order of data fields within an item is significant. Items are sent in the order they should be played. Order of items is significant. Multiple Running Orders may contain the same Story. Running Orders may contain zero or more Stories. Multiple stories can contain the same Object referenced by different Items. Stories can contain multiple Items. Item IDs may appear only once in a Story, but can appear in other Stories. Objects can appear multiple times in a Story, but only one object may appear in an Item. A Running Order Item is defined by the combination Running Order.Story.Item and contains the UID’s of the Running Order, Story and Item which together can identify a unique Item within a Running Order. Additions, deletions, and moves within the running order are referenced in this way to the Item. 2.9 Samples Still Store and Character Generator media objects are defined as having 1 sample per second. They are special cases that require the NCS and MOS applications to understand they do not change every second. 3. MOS Messages In the Structural Outline sections below use of “?” specifies optional element, “+” specifies one or more of the element, and “*” specifies zero or more of the element. Elements without any of these three special characters are required. Tags enclosed in parenthesis and separated by "\|" represent a selection. The Syntax section shows the definition of non-terminals for this message from the DTD. Examples shown are representative of syntax only and do not represent samples from any system. 3.1 mosAck - Acknowledge MOS Object Description Purpose The MOS Acknowledgement for the MOS OBJ message. Response N/A Port MOS Lower Port (10540) - Media Object Metadata Structural Outline mos mosID ncsID mosAck objID objRev status statusDescription Syntax
`<!ELEMENT mosAck (objID, objRev, status, statusDescription)>`

Media Object Server (MOS) Protocol

Abstract

Status of this document

Media Object Server Protocol 2.5

1. Introduction

1.1 Message Exchange

1.2 Identification

1.3 Encoding

2. MOS Message Format

2.1 Extensible Markup Language (XML)

2.2 Message Acknowledgement

2.3 Message Transport

2.4 Unknown Tags

2.5 Object Description Format

2.6 Languages

2.7 Numbers

2.8 Running Orders

2.9 Samples

3. MOS Messages

3.1 mosAck - Acknowledge MOS Object Description

Response

Port

Structural Outline

Syntax

Example

3.2 mosObj - MOS Object Description

Response

Port

Structural Outline

Syntax

Example

3.3 mosReqObj - Request Object Description

Response

Port

Structural Outline

Syntax

Example

3.4 mosReqAll - Request All Object Data from MOS

Response

Port

Structural Outline

Syntax

Example

3.5 mosListAll - Listing of All Object Data from MOS

Response

Port

Structural Outline

Syntax

Example

3.6 mosObjCreate – MOS Object Create

Purpose

Response

Port

MOS Lower Port (10540) – MOS Object

Structural Outline

mos mosID ncsID mosObjCreate objSlug objType objTB objDur? time? createdBy? description?

Syntax

Example

3.7 roCreate - Create Running Order

Response

Port

Structural Outline

Syntax

Example

3.8 roAck - Acknowledge Running Order

Response

Port

Structural Outline

Syntax

Example

3.9 roReplace - Replace Running Order

Response

Port

Structural Outline

Syntax

Example

3.10 roDelete - Delete Running Order

Response

Port

Structural Outline

Media Object Server (MOS)
Protocol

mos
mosID
ncsID
mosObjCreate
objSlug
objType
objTB
objDur?
time?
createdBy?
description?

mos
mosID
ncsID
roStorySend
roID
storyID
storySlug
storyBody
storyPresenter*
storyPresenterRR*
p*
em*
tab*
pi*
pkg*
b*
I*
u*
storyItem*
itemID
itemSlug?
objID
mosID*
itemChannel?
itemEdStart?
itemEdDur?
itemTrigger?
macroIn?
macroOut?