Prior MOS Meetings

NAB 2017 Meeting:

When:  Tuesday April 25th, 2017, 3:00 – 5:00 PM PDT (local time), 6:00 – 8:00 PM US-EDT,    23:00 – 01:00 UTC

 Where:  Westgate Las Vegas Resort – Conference Rooms 7 and 8.

NAB 2017 Agenda:

  • IBC 2016 Review
  • MOS Emmy® Award
  • MOS v2.8.5 Documentation
  • MOS Device Discovery
  • Encryption & Security
  • Alternative Transports (Secure Web Socket Tunnel)
  • MOS Passive Mode

NAB 2017 Meeting Notes:

Digital Rights Management

Mike Palmer (Masstech): Mike presented the proposal to SMPTE, who liked it.  SMPTE would like the MOS group to continue work on it.  They see the scope of the proposal as being too narrow for the rest of SMPTE.

Mike will provide an updated copy of the proposal for the MOS Group website.

MOS 2.8.5

A draft for the revised specification has been posted on the MOS Group website.

Group members are encouraged to review it and provide comments to Phil Avner (pavner@ap.org).

Emmy Award

Displayed in the center of the meeting table.

Randall Meston (AP) said that NATAS still needs to vet the individual awards.

The group gave a hearty round of applause to the three designated individual award winners.

For others who would like an official NATAS plaque for the award, requests should go to Randall promptly.  There is a charge for the plaques, which will be the responsibility of the individual requesting it.  There are three offerings for the plaque.  Randall recommends the “Executive” one.

New Business:

MOS Device Discovery
Shawn Snider (Ross) proposed a means for a media server to “self register” with a newsroom system.  It would configure itself with the newsroom system.

Shawn characterized it as creating a dynamic ecosystem.

As more devices move to a cloud, resources move around frequently.  It could become burdensome to have to frequently reconfigure systems.

With the anchor of a persistent ID, the systems should be able to reconfigure itself as needed.

Mark Gilbert (Gallery) suggested looking to the existing NMOS standard (http://nmos.tv/) or Apple’s Bonjour (https://developer.apple.com/bonjour/)

Mike Palmer noted that this had been discussed six-to-eight years ago.  It was dropped because there was no business driver at that time. The environment has changed, and he now supports the idea.

There was discussion about the possibility of rogue systems trying to register themselves on users’ systems.  There was general agreement that any standard for auto discovery/registration/configuration would be contingent on a human accepting any machine-initiated action.

Encryption and Security
As MOS messages move between sites, and especially to cloud-based systems, companies are more aware of security issues.  There is no security in socket communications.

We discussed the idea of moving MOS socket communication inside SSL wrappers

There are several products available that wrap socket messages through a Port 443 encrypted channel.

Warren Davis (Bitcentral) reports that Fox has been requesting two-step authentication.

Concern was raised about the expense and work to use SSL certificates issued by major Certificate Authorities (i.e.: not self-generated certificates).

Could be any port (not tied to 443), though Port 443 is a well-known port for network administrators.

Mark Gilbert suggested looking at Hamachi (https://www.vpn.net/).

Jim Stringer (Telescript West) was concerned about reliance on third-party products that could be pulled from the market at any time.

There was general consensus around the idea that the MOS Group should not create yet another encryption standard.  Rather, companies employing the MOS Protocols (media servers and newsroom system vendors) could certify one or more off-the-shelf solutions that users of MOS Protocol systems could reliably utilize themselves.

It was suggested that if a proposal is too complex there would be a low adoption rate.

Passive MOS
This proposal from Shawn Snider would be for something similar to Passive FTP, in that all MOS Protocol “conversations” would originate from the same (secure) side of a connection.

A MOS Protocol communication between two devices would be made up of two Passive MOS connections between the devices.

Mark Gilbert suggests that routing all MOS communication through a VPN tunnel (such as Hamachi) would obviate the need for the security that would be gained through a Passive MOS arrangement.

System Release Certification
Sean Cullinan (ENPS) raised the issue of the time it takes for MOS Protocol participating vendors to certify their products against other systems.

This results in our mutual customers delaying their adoption of new versions of products because of fear of issues arising from updated software.

Jim Martinolich (ChyronHego) says that most issues are around ActiveX plug-ins.  Basic Newsroom system server to MOS device is much simpler and straight-forward.

Jim Stringer says that solutions need to work right directly out-of-the box.

Mike Palmer suggests that in self-registration processes, only specifically approved versions of software be allowed to work together.

It was discussed that there should be specific test procedures and regimens (designed to be automatable) that would be the gold standard for certifying compatibility.

Jim Stringer said that, as a MOS device vendor, he sees differences in MOS Protocol implementation among newsroom system vendors.  As an example, Jim cited a difference between ENPS and Octopus in use of Story Numbers.

Eira Monstad (Vizrt) says that most problems arise from procedures (or sequences of MOS messages), not from individual malformed messages.

Working groups were suggested for Device Discovery, Encryption & Security and Release Certification topics.

Old Business

Floated Stories
Shawn Snider raised again his earlier proposal for a means to differentiate between when a story/media object is truly removed from a Running Order, and when it is floated.

In the latter case, there is a likelihood that the story/media object will be returned to the active Running Order.  Object and status updates for a floated story or object should continue to be handled, in anticipation of its return to active status in the Running Order.

In an earlier meeting, the subject became, in Shawn’s opinion, overly complicated.

Shawn would like to lead a group to reexamine the proposal.

Acknowledgement Messages
The question of the meaning of Ack was raised again.

Should a device sending an Ack message mean that the message to which it is responding has arrived, and (optionally) been vetted for valid formatting?

Or should the Ack message mean that the MOS device receiving the MOS Protocol message has successfully completed handling the incoming message?

In the first case, an Ack message may be sent when there was actually some problem with the information contained in the original message – which would not be discovered until the MOS device has tried to do whatever-it-needs-to-do with the information.  This could necessitate that a subsequent message be sent to verify operation – or more importantly, tell the originating system that the requested action could NOT be fully executed.

In the second case, operations are held up and other systems get out of synch because other work has continued while waiting for the Ack message to arrive.

Different vendors have implemented in different ways.  This creates a problem for our systems and for our mutual customers.

It is proposed that we come to a definitive meaning for the Ack message.

Heartbeats
Jim Stringer raised the question of what to do when there is no reply to a Heartbeat message. Especially in a communication string where there is intermingling of heartbeat and more-executive messages.

And related to that, since the correct reply to a Heartbeat message is another Heartbeat message, how do we formally state that this loop should not result in race condition of two devices sending and replying to Heartbeat messages with each other.

NAB 2017 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we have a WebEx session available.

Address: http://enps.webex.com

Meeting number:    796 541 465
Meeting password:  EMMY2017
Voice Bridge:
US  1-650-3057453
UK  0 2034333870
Conference Code: 566 221 8711

IBC 2016:

When: 12 September 2016 (Monday)
Time:     16:30 – 18:30 CEST
10:30 – 12:30 US-EDT
07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109.  The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

IBC MOS Conference Location

(Click for a larger version)

IBC 2016 Agenda:

  • IABM Industry Collaborative Group (ICG) Endorsement
  • NAB 2016 Review
    • NATAS – Waiting to hear back after voting
    • News Distribution Rights
      • White paper (with no major changes) to be presented at upcoming SMPTE conference in LA
    • Story Status Tag
    • MOS item representations of IP Video streams
  • MOS Protocol Documentation Clarifications
    • roElementAction
  • Any other business

IBC 2016 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we will have a WebEx session available with audio bridge.

WebEx Screen Share:
https://enps.webex.com/enps/j.php?MTID=mf5489c972102baffed46806cf82404be 

…or…

http://enps.webex.com 
Meeting number:    795 557 374
Meeting password:    C92DWDQ3

Audio Bridge:
650-3057453    (US)
0 2034333870   (UK)
0 207946543   (Amsterdam)

Access phone numbers elsewhere around the world:
https://www.tcconline.com/offSite/OffSiteController.jpf?cc=7077863143

Conference Code:    707 786 3143 #

Slide deck from the meeting can be seen here.

NAB 2016 Meeting:

When:  Tuesday April 19th, 2016, 3:00 – 5:00 PM PDT (local time), 6:00 – 8:00 PM US-EDT,    23:00 – 01:00 UTC

NAB 2016 Agenda:

  • Review IBC 2015 Meeting
  • Story Status Tag

In many situations MOS devices would greatly benefit from the knowledge of stories that are “floated”.   The proposal of “storyStatus” would no longer have the NRCS ignore these stories, rather it would send them out as part of the standard roConstruction messages with a new flag of “floated”.

See the StoryStatus proposal (PDF)

  • Proposal for News Distribution Rules

NDR is a proposed model of data representation and rules   which allow a distribution point to determine if it is allowed to forward, redistribute or incorporate the described content in derivative works.  Modeled on existing methods used for many years to control news distribution, this method adds the benefits of unambiguous rules and machine interpretation.

This is a suggested topic of discussion for the MOS Group because MOS enabled systems carry much of the content to which NDR would be applied.  Thus, compatibility and synergy of MOS and NDR would be beneficial.

See the NDR Proposal (PDF)

NAB 2016 Meeting Notes:

1. HTML5

The HTML5 plug-in proposal was brought up for discussion and vote.

Vizrt (Via Ross Video) proposed amending the proposal to include a requirement that both HTTP and HTTPS be supported.

The amended text would be:

The NCS hosting container should allow connections via HTTP, or secure connections via HTTPS from pages in the plug-in browser components to back-end web servers utilizing SSL server certificates.

Any resources incorporated in the HTTPS page of a device plugin also needs to be served out over HTTPS in secure deployments. This includes, but is not limited to:

<script> (Javascript)
<link> (CSS)
<iframe>
XMLHttpRequest requests
Fonts cursors and images referenced in CSS
<object> data and subresources
<img> sources
<audio> sources
<video> sources

The full proposal, as amended, was adopted by acclamation.

2. Floating

Kurt Simons proposed changes to the process when “Floating” a story in a Running Order.

In addition to the use case made in Kurt’s proposal, the use case of floating a story because a linked media object is not ready – but a user still wants to be able to see status updates in the Running Order – was cited.

Also, related issues: floating just a media object and implications for redirection.

As this would break some old workflows, a new “full-dot” version number would be assigned to a MOS update with these changes.

Kurt will write up some examples for discussion by the MOS group.

3. Industry issues

Mike Palmer announced that IABM will nominate MOS to be a recognized protocol of the group.

Also that MOS has been nominated for a technical EMMY award.

4. NDR

Mike Palmer presented a proposal for News Distribution Rules – A standardized way to express rights usage rules for distributed media.

It would include breakdown by organization and to the segment level in edited clips.

Because lists of included and excluded users could get long, the proposal says that portions may be expressed in YAML or Base64.

Mike will provide some samples of how a variety of rights situations could be expressed in his proposed format.
After discussion on the MOS Protocol website forum, the hope is that we can hold a vote on this proposal at the MOS Conference at IBC later this year.

5. IP Video

Mark Gilbert raised the issue that the MOS Group should look at IP Video, and determine if/how the MOS Protocol should be updated to work with it.

Where:  Westgate Las Vegas Resort – Conference Rooms 7 and 8.

MOS_MEETING_MAP_NAB_2014

NAB 2016 Remote Participation:

For those unable to attend the MOS Group meeting in person at NAB, remote access will be available live from anywhere in the world via WebEx.

Address:                           http://enps.webex.com
Meeting number:        796 234 414
Meeting password:    MOSmeeting

Voice Call-in numbers:

(US)     +1 650.305.7453
(UK)    +44 203.433.3870
(Germany)  +49 21197190097

Other world-wide numbers can be found at: https://www.tcconline.com/listNumbersByCode.action?confCode=7077863143

Conference Code: 707 786 3143

IBC 2015:

When: 14 September 2015 (Monday) Time: 16:30 – 18:30 CEST,  10:30 – 12:30 US-EDT,  07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109.  The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

IBC MOS Conference Location

(Click for a larger version)

IBC 2015 Agenda:

  • NAB 2015 Review
  • See Revision 2 of the proposed HTML5 Protocol document here.
  • Discussions regarding implementation of the HTML5 Plug In
    • Comments from VizRT regarding implementation of the HTML5 plug in here:
    • Discussion regarding UCS-2 vs. HTML5 Plug In and encoding
  • Discussion on mosAbstract being required vs. optional

IBC 2015 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we will have a WebEx session available with audio bridge.

Login for WebEx video:

https://enps.webex.com/enps/j.php?MTID=m82c002723df9945f719432d6df4ddb0f

Alternate:
Address:        http://enps.webex.com
Meeting number:      793 919 863
Meeting password:    IBC2015

Voice Call-in numbers:

+1 6503057453 (US)
+44 2034333870 (UK)
+31  207946543 (Holland)
+49 21197190097 (Germany)

Other world-wide numbers can be found at: https://www.tcconline.com/listNumbersByCode.action?confCode=7077863143

Conference Code: 707 786 3143

NAB 2015 Meeting:

When:  Tuesday April 14th, 2015, 3:00 – 5:00 PM PDT (local time), 6:00 – 8:00 PM US-EDT, 23:00 – 01:00 UTC

Where:  Westgate Las Vegas Resort – Conference Rooms 7 and 8.MOS_MEETING_MAP_NAB_2014

NAB 2015 Agenda:

IBC 2014 Review

HTML 5 supplement to ActiveX,  group discussion and vote on adoption.  See Revision 2 of the proposal [PDF].

Generic CG Item (Graphics Builder Object) group discussion.  See the draft proposal [PDF].

Comments from PixelPower on the generic CG item proposal.  See the comments from PixelPower [PDF].

Comments from VizRT on the generic CG item proposal. See the comments from VizRT [PDF].

Download the NAB 2015 MOS Meeting Presentation [PDF].

NAB 2015 Remote Participation:

For those unable to attend the MOS Group meeting in person at NAB, remote access will be available live from anywhere in the world via WebEx.

Address:                           http://enps.webex.com
Meeting number:        794 514 747
Meeting password:    MOSCONF
Join by phone:
Call-in toll-free number: 1-866-235-4843 (US)
Call-in number: 1-650-305-7453 (US)
Conference Code: 707 786 3143

Dial-in numbers for other parts of the world.

 

IBC 2014:

When: 15 September 2014 (Monday) Time: 16:30 – 18:30 CEST,  10:30 – 12:30 US-EDT,  07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G-109.  The RAI Elicium building is in Area 13 which is centrally located within the exhibit halls (between hall 2 and hall 10).

IBC MOS Conference Location

(Click for a larger version)

IBC 2014 Agenda:

  • Changes to the mosprotocol.com website (forums)
  • MOS Protocol 2.8.4 XSD corrections
  • Protocol Documentation corrections (use of quotes)
  • NAB 2014 review
    • Standard vocabulary for objPath/objProxyPath Tech Descriptions  (subgroup & discussion forum required?)
    • Codifying that paths need to be direct paths to the object – not involve client-side redirection
    •  Codifying that objPaths and objProxyPaths end in file type extension
    • Sub/daughter running orders
    • HTML5 supplement to ActiveX discussion (subgroup & discussion forum required?)
  • New Business
    • MOS standard for pushing content into graphics (subgroup & discussion forum required?)
    • Can we define a better process to formally approve changes to the protocol?
  • Any other business

IBC 2014 Remote Participation:

For those unable to be part of the MOS Group meeting in person, we will have a WebEx session available with audio bridge.

——————–

NAB 2014 Meeting:

When:

Tuesday April 8, 2014, 3:00 – 5:00 PM PDT (local time),  6:00 – 8:00 PM US-EDT,  23:00 – 01:00 UTC

Where:

LVH – Conference Rooms 8 and 9.

MOS_MEETING_MAP_NAB_2014

(Click for a larger version)

NAB 2014 Agenda:

    • Changes to the mosprotocol.com website
    • IBC & NAB 2013 review
    • MOS Protocol 2.8.4 XSD erratum
    • Mac OsX paths addition to objPaths
    • objPaths media representations discussion
    • MOS Profile 7 – Clarification of itemID handling in response to roReqStoryAction
    • MOS Profile 7 – Proposal for extension: roCreate from MOS system (discussion)
    • Sub running orders
    • “single-item” stories (items / objects in RO without story wrapper)
    • Declaration of story types
    • HTML5 supplement to ActiveX discussion

Download the NAB 2014 MOS Meeting presentation [PDF].

Download MOS Protocol Web Control Proposal Rev 2 [PDF].

NAB 2014 Remote Participation:

For those unable to be part of the MOS Group meeting in person at NAB, access will be available via WebEx.

Address: https://enps.webex.com/ Meeting Number: 798 883 117 Meeting Password: MOSNAB2014

Or you may use the login URL: https://enps.webex.com/enps/j.php?MTID=m4a7efb83638a1e9d5fe8c62cfd76ac2e

To view in other time zones or languages, please see: https://enps.webex.com/enps/j.php?ED=189933442&UID=1357243897&PW=NMThhNGZkNjg0&ORT=MiMxMQ%3D%3D

For audio only, join the telephone bridge: +1-650-305-7453 (US) You may find other global numbers at: https://www.tcconline.com/offSite/OffSiteController.jpf?cc=7077863143 Conference Code: 798 883 117

Assistance for the WebEx connection can be found at: https://enps.webex.com/enps/mc On the left navigation bar, click “Support”.

IBC 2013:

When: 16 September 2013 (Monday) Time: 16:30 – 18:30 CEST 10:30 – 12:30 US-EDT 07:30 – 09:30 US-PDT

Where: The RAI Elicium – Room G111 The RAI Elicium building is in Area 13 which is centrally located

Download the IBC 2013 presentation [PDF]

IBC 2013 Agenda:

    • MOS Protocol enhancement: MOS formatting content for Graphics/CGs
    • Successor to ActiveX
    • Please take the opportunity to read this paper prepared by Shawn Snider of Ross Video prior to our meeting.

IBC 2013 Meeting Notes:

(Coming Soon)

NAB 2013:

When: Tuesday, April 9, 2013 3:00-5:00 local time (15:00-17:00 UTC-0700)

Where: Las Vegas Hotel (LVH) Conference Rooms 8 & 9

Download the NAB 2013 presentation [PDF]

NAB 2013 Agenda:

    • roElementStat

Proposal to modify section 3.7.2 roElementStat – Status of a Single Element in a MOS Running Order Proposal is to add bi-directional aspect to roElementStat message. This would allow the NCS to make a MOS aware of status of a specified item or story relative to a particular Running Order.

    • A consistent meaning for ACK

There has been discussion about how ACK sometimes means that a MOS message has been accepted and cleanly parsed (without regard for the instruction being successfully executed), and other times where an ACK means that an action has been taken before an ACK is returned. Should ACK have a consistent meaning?

    • Rest/JSON

Last fall, following the IBC MOS meeting, there was a series of discussions about the prospect of adding a Rest/JSON version of MOS. This would complement the existing socket and webservices versions of the Protocol.

NAB 2013 Meeting Notes:

    • roElementStat bi-directional aspect was formally adopted
    • Object and proxy paths:
      1. Decided that the field should be a call that will return the file.
      2. Decided that the character string following the last slash should be the full file name including extension
      3. Discussion of whether to include additional field to designate MIME types
      4. Discussion of permissibility of HTTP client-side redirects was to be put up for discussion on the board
    • Rest/JSON version of MOS:
      1. Consensus of the group was to table this proposal for now.