Media Object Server (MOSä)
Protocol v2.6

MOS Protocol version 2.6
Document Revision WD-2001-08-09

Revision Date Thursday, August 09, 2001

Copyright Notice

License

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:

You can use and implement all or some of the messages defined by the protocol.
You may not modify message names, order of defined tags within a message, tag structure, defined values, standards and constants.
You may not process messages in a means that is dependent on non-standard messages, tags or structures.
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.
Implementations of the MOS Protocol following the above guidelines may claim to be “MOSä Compatible” or “MOSä v2.6 Compatible”
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.
It is inappropriate to make representations of MOS Compatibility unless you have followed these guidelines.

Abstract

MOS is a three 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.

Status of this document

This document reflects changes to the MOS protocol made during the MOS meeting at NAB 2001 and is referred to as MOS v2.6. Logic and message content of MOS v 2.5 have undergone minor changes based on agreements reached in the NAB 2001 meeting. Three additional messages and one additional data structure have been added to v2.6 and are noted below in bold red.

How to use this document

The document contains bookmarks and hyperlinks. The Table of Contents and other areas contain underlined. Depending on the viewer application used, clicking or double clicking on underlined links should take the viewer to the relevant portion of the document.

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.

Media Object Server Protocol 2.6

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” (Media Object Server) family of messages

3.1 mosAck - Acknowledge MOS Object Description
3.2 mosObj - MOS Object Description

3.3 mosReqObj - Request Object Description

3.10 mosReqAll - Request All Object Data from MOS
3.11 mosListAll - Listing of All Object Data from MOS

3.20 mosObjCreate – Mos Object Create

3.21 mosItemReplace – Replace an Item Reference in an NCS Story with updated Item sent from the MOS

4. “ro” (Running Order) family of messages

4.1 roAck - Acknowledge Running Order

4.2 roCreate – Create Running Order

4.3 roReplace - Replace Running Order

4.4 roMetadataReplace – Replace the metadata associated with a RO Playlist

4.5 roDelete - Delete Running Order

4.11 roReq - Request Running Order

4.12 roList - List Running Order

4.13 roReqAll - Request All Running Order Descriptions

4.14 roListAll - List All Running Order Descriptions

4.15 roStat - Status of a MOS Running Order

4.16 roReadyToAir - Identify a Running Order as Ready to Air

4.21 roStoryAppend - Append Stories to Running Order
4.22 roStoryInsert - Insert Stories in Running Order

4.23 roStoryReplace - Replace Story with Another in a Running Order

4.24 roStoryMove – Move a Story to a specific location in a Running Order

4.25 roStorySwap - Swap Positions of Stories in Running Order
4.26 roStoryDelete - Delete Stories from Running Order

4.31 roItemStat - Status of a Single Item in a MOS Running Order

4.32 roItemCue – Notification of an Item Event
4.33 roCtrl – Running Order Control

4.41 roStorySend – Sends story information, including body, from Running Order

5. Other messages and data structures

5.1 heartbeat - Connection Confidence Indicator

5.2 reqMachInfo - Request Machine Information
5.3 listMachInfo - Machine Description List

5.4 mosExternalMetadata – Method for including and transporting Metadata defined external to MOS

5.5 mosItemReference – Metadata block transferred by ActiveX Controls

6. Field Descriptions

7. Recent Changes

  7.1 Changes from MOS version 2.5 to 2.6 WD-2001-06-06
    7.2 Changes from MOS version 2.0 to 2.5 WD-2000-08-01
    7.3 Changes for MOS 2.0 WD-1999-05-12
    7.4 Changes from MOS version 1.52 to 2.0 WD-1999-03-17

7. MOS 2.6 DTD

8. References and Resources
    8.1 MOS Protocol Web Page
    8.2 XML FAQ
    8.3 Recommended Reading
    8.4 XML Web Sites

1. Introduction

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

Three new messages and one new data structure were added: mosItemReplace, roMetadataReplace, roStoryMove, and mosExternalMetadata.

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

      storyBody
      itemSlug
      description

And the data structure mosExternalMetadata

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.

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. Object Messages

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)>

Example

<mos>
<mosID>aircache.newscenter.com</mosID>
<ncsID>ncs.newscenter.com</ncsID>
<mosAck>
 <objID>M000123</objID>
 <objRev>1</objRev>
 <status>ACK</status>
 <statusDescription></statusDescription>
</mosAck>
</mos>

3.2 mosObj - MOS Object Description

Purpose

Contains information that describes a unique MOS Object to the NCS. The NCS uses this information to search for and reference the MOS Object.

<objGroup> tag

No specific values for this element are officially defined. Definition of values is left to the configuration and agreement of MOS connected equipment. The intended use is for site configuration of a limited number of locally named storage folders in the NCS or MOS, such as “ControlA”, “ControlB” , “Raw”, “Finished”, etc. For editorially descriptive “category” information, it is suggested that the <externalMetadata> block be used.

ExternalMetadata Block

This data block can appear in several messages as a mechanism for transporting additional metadata, independent of schema or DTD. When found within the mosObj message, this block carries data defined external to the MOS Protocol.

External Metadata <scope> tag

The value of the <scope> tag implies through what production processes this information should travel.

A scope of “object” implies this information is generally descriptive of the object and appropriate for queries. The metadata should not be forwarded into Stories or Playlists.

A scope of “story” suggests this information may determine how the Object is to be applied in a Story. For instance, Intellectual Property Management. This information should be forwarded with the contents of a Story.

A scope of “playlist” suggests this information is specific to describing how the Object is to be published, rendered, or played to air and thus, should be included in the roCreate Play List Construction and roStorySend messages.

Scope allows systems to, optionally, roughly filter external metadata and selectively apply it to different production processes and outputs. Specifically, it is neither advisable nor efficient to send large amounts of inappropriate metadata to the Playlist in roCreate messages. In addition to these blocks of data being potentially very large, the media Object Server is, presumably, already aware of this data.

Response

mosAck

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

            mos
                mosID
                ncsID
                mosObj
                   objID
                   objSlug

mosAbstract?
objGroup?

objType

                   objTB
                   objRev
                   objDur
                   status
                   objAir
                   createdBy
                   created
                   changedBy
                   changed
                   description
                        (p | em | tab)*

mosExternalMetadata*
mosScope?

mosSchema

mosPayload

Syntax

<!ELEMENT mosObj (objID, objSlug, mosAbstract, objGroup?, objType, objTB, objRev, objDur, status, objAir, createdBy, created, changedBy, changed, description, mosExternalMetadata*)>
<!ELEMENT description (#PCDATA | p | em | tab)*>
<!ELEMENT p (#PCDATA | em | tab)*>

<!ELEMENT mosExternalMetadata (mosScope?, mosSchema, mosPayload)>

<!ELEMENT mosScope (object | story | playlist)>

<!ELEMENT mosSchema (#PCDATA)>

<!ELEMENT mosPayload (#PCDATA)>

Example

<mos>

<mosID>aircache.newscenter.com</mosID>

<ncsID>ncs.newscenter.com</ncsID>

<mosObj>

<objID>M000123</objID>

<objSlug>Hotel Fire</objSlug>

<mosAbstract>

Hotel Fire

vo

:30

</mosAbstract>

<objGroup>Show 7</objGroup>

<objType>VIDEO</objType>

<objTB>60</objTB>

<objRev>1</objRev>

<objDur>1800</objDur>

<status>NEW</status>

<objAir>READY</objAir>

<createdBy>Chris</createdBy>

<created>1998-10-31T23:39:12</created>

<changedBy>Chris</changedBy>

<changed>1998-10-31T23:39:12</changed>

<description>

Exterior footage of

Baley Park Hotel

on fire with natural sound. Trucks are visible for the first portion of the clip.

CG locator at 0:04 and duration 0:05, Baley Park Hotel.

<tab/>

Cuts to view of fire personnel exiting hotel lobby and cleaning up after the fire is out.

Clip has been doubled for pad on voice over.

</description>

<mosExternalMetadata>

<mosScope>STORY</mosScope>

<mosSchema>http://MOSA4.com/mos/supported_schemas/MOSAXML2.08</mosSchema>

<mosPayload>

<Owner>SHOLMES</Owner>

<ModTime>20010308142001</ModTime>

<mediaTime>0</mediaTime>

<TextTime>278</TextTime>

<ModBy>LJOHNSTON</ModBy>

<Approved>0</Approved>

<Creator>SHOLMES</Creator>

</mosPayload>

</mosExternalMetadata>

</mosObj>

</mos>

3.3 mosReqObj - Request Object Description

Purpose

Message used by NCS to request object description.

Response

mosObj - if objID is found
mosAck - otherwise

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

mos
    mosID
    ncsID
    mosReqObj
       objID

Syntax

<!ELEMENT mosReqObj (objID)>

Example

<mos>

<mosID>aircache.newscenter.com</mosID>

<ncsID>ncs.newscenter.com</ncsID>

<mosReqObj>

<objID>M000123</objID>

</mosReqObj>

</mos>

3.10 Object Resynchronization/Rediscovery

3.11 mosReqAll - Request All Object Data from MOS

Purpose

Method for the NCS to request the MOS send it mosObj messages for every Object in the MOS. Pause, when greater than zero, indicates the number of seconds to pause between MOS objects in the mosListAll message. Pause of zero indicates that all objects should be sent using mosObj messages.

Response

mosListAll - if pause > 0
mosObj - otherwise

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

mos
    mosID
    ncsID
    mosReqAll
       pause

Syntax

<!ELEMENT mosReqAll (pause)>

Example

<mos>

<mosID>aircache.newscenter.com</mosID>

<ncsID>ncs.newscenter.com</ncsID>

<mosReqAll>

<pause>0</pause>

</mosReqAll>

</mos>

3.12 mosListAll - Listing of All Object Data from MOS

Purpose

Send MOS object descriptions in a format similar to mosObj sequentially from the MOS to the NCS in response to the mosReqAll message. There is a pause between each object as defined in the mosReqAll message.

Response

None

Port

MOS Lower Port (10540) - Media Object Metadata

Structural Outline

mos
    mosID
    ncsID
    mosListAll
        (objID, objSlug, mosAbstract?, objGroup?, objType, objTB, objRev, objDur, status, objAir,
         createdBy, created, changedBy, changed, description, mosExternalMetadata*)+

Syntax

<!ELEMENT mosListAll ((objID, objSlug, mosAbstract?, objGroup?, objType, objTB, objRev, objDur, status, objAir, createdBy, created, changedBy, changed, description, mosExternalMetadata*)*)>
<!ELEMENT description (#PCDATA | p | em | tab)*>
<!ELEMENT p (#PCDATA | em | tab)*>

Example

<mos>

<mosID>aircache.newscenter.com</mosID>

<ncsID>ncs.newscenter.com</ncsID>

<mosListAll>

<objID>M000123</objID>

<objSlug>HOTEL FIRE</objSlug>

<objType>VIDEO</objType>

<objCategory>RAW</objGroup>

<objTB>60</objTB>

<objRev>3</objRev>

<objDur>1530</objDur>

<status>UPDATED</status>

<objAir>READY</objAir>

<createdBy>Chris</createdBy>

<created>1998-10-31T23:39:12</created>

<changedBy>Chris</changedBy>

<changed>1998-11-01T14:35:55</changed>

<description>

Exterior footage of

Baley Park Hotel

on fire with natural sound. Trucks are visible for the first portion of the clip.

CG locator at 0:04 and duration 0:05, Baley Park Hotel.

<tab/>

Media Object Server (MOSä) Protocol v2.6

Copyright Notice

License

Abstract

Status of this document

How to use this document

Media Object Server Protocol 2.6

Table of Contents

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

MOS Messages

3. Object Messages

3.1 mosAck - Acknowledge MOS Object Description

Purpose

Response

Port

Structural Outline

Syntax

Example

3.2 mosObj - MOS Object Description

Purpose

<objGroup> tag

ExternalMetadata Block

External Metadata <scope> tag

Response

Port

Structural Outline

Syntax

Example

3.3 mosReqObj - Request Object Description

Purpose

Response

Port

Structural Outline

Syntax

Example

3.10 Object Resynchronization/Rediscovery

3.11 mosReqAll - Request All Object Data from MOS

Purpose

Response

Port

Structural Outline

Syntax

Example

3.12 mosListAll - Listing of All Object Data from MOS

Purpose

Response

Port

Structural Outline

Syntax

Example

Media Object Server (MOSä)
Protocol v2.6