DSCA Avails WG August 6, 2019 with notes

Agenda Action items from last meeting Review Status and Bonus Tab Eric to work with WG in collecting data regarding potential issues with FE in practice, developing proposal more fully including sample use cases Craig to consider removing ‘Metadata’ as progress code from status reporting Craig to add Date Stamp to status reporting Craig to consider/report back on making ‘End’ date optional in status reporting Eric to coordinate discussion of issues re reporting wholesale price with WG members, report back in upcoming WG meeting Review Status and Bonus Tab Discus TPR (time permitting)

Avails New 'EntryType' Revised EntryType proposal [AI #1]

New 'EntryType' – Problem Space It is important that both parties (studios and retailers/platforms) agree on the “scope” of an Avails (i.e., what gets updated and what doesn’t). Otherwise, the platform might have the wrong data. Full Extract is one definition of scope: Content (via ALID and/or AltID), Business type (TVOD, SVOD, AVOD, etc.), Territory, and partners (studio/platform combination) But it is not the only possible scope, and the Full Extract model is not sufficient on its own New TPR and Bonus tabs will not work with Full Extract XML is much more flexible (work underway in API working group)

Proposal When no AvailID present, must use Full Extract, Full Delete model This eliminates the complex and questionable matching logic from the original proposal When AvailID present, can use Create, Delete, Update EntryType values These EntryType values that apply one “row” Update – Changes certain values of an existing Avail record Create – Adds one unique Avail record (cannot already exist) Delete – Removes one existing avail record All operations against AvalID For example, when performing an update, the record with the same AvailID is replaced AvailIDs are immutable When new EntryType values are accepted is a subject of Best Practices and bilateral agreements. Like not use for Avails Almost certain must be used for standalone Bonus and TPR tabs Note: Independent of this, recommend using AvailID as a regular practice Tentatively approved, pending better examples and time for review

New Values and Templates

New Templates Three topics that potentially require new Excel ‘templates’* Avails Status Bonus TPR For each of these Add a few new fields to the master spreadsheet—this is the critical part Define which fields are optional/required for each application Publish templates (like “Movies”, “TV” and “Collections” in 1.8) *A template is an excel tab constructed to demonstrate appropriate use of fields for a given use. Templates include “TV” and “Movie”. “Status”, “Bonus” and “TPR” templates would be added.

Status of new features Status and Bonus TPR Fields discussed at last meeting Discussed changes incorporated and will be discussed today (presentation attached) Template drafted TPR Still awaiting requirements; in particular, Merchandized TPRs and non-Merchandized TPRs (per Google presentation at BAM)

Status: Miscellaneous Date of report [AI #3] Issue: There is no way to know the date and time when status was determined. This has issues such as creating ambiguity between Ready and Live (might have been ready then, but live now) Solution: Added StatusEntryDate ISO date+time format (e.g., 2019-08-04T04:13:00Z) Do we want to suggest that the entire report have the same value, or allow flexibility? Recommendation: Flexibility (no sense start on the wrong foot) Agreement to allow unique date+time in each row, although there’s an expectation that all rows will likely be the same StatusEndDate [AI #4] Issue: No means to specify open end date Solution: Allow “Open” value in StatusEndDate Approved

Status: Remove Metadata Status value? [AI #2] Argument for removal Why differentiate metadata? If we go down this route, we could have numerous other categories (images, subs, dubs, etc.). Let’s keep it simple. If you need full status, use Asset Status object. Argument against removal Metadata is different : Used differently, produced by distinct parties, and has distinct timing This was part of DEG proposal—it was discussed and decided that studios need metadata status. Observations Maybe we want to simplify further to: Live, Ready, Blocked (e.g., SLA Violation), In-Process “Blocked” collapses Missing Content and Assets Rejected. It’s the only status that required action. Might want progress codes for multiple categories (Video, Audio, Metadata, Images, Dubs, Subs, etc.) Discussion: Keep as-is? Just remove “Metadata”? Simplify (e.g., “Metadata”, “Missing Content” and “Missing Assets”  “Blocked”)? Simplify and add categories? Proposal accepted: Live, Ready, Blocked (e.g., SLA Violation), In-Process

Status: Price [AI #5, partial] What price is reported back? Actual WSP (i.e., WSP retailer understands applies to the offer in that window)? Note that even if TPRs are reported in the first model below, status must always be unique rows (second model) Original Price TPR Price

Review Status Template (from Excel)

Review Bonus Template (from Excel)

Questions Can we just reuse LicenseType? Not sure why we previously concluded that bonus offer might have its own LicenseType Question deferred to next meeting

Discuss TPR Deferred to next meeting

Backup/Reference Material

Avails Bonus (XML) June 10, 2019

Delivering Bonus Content Problem Need ability to provide details about Bonus/VAM/EC to partners Feature to which bonus applies Identification of bonus titles Any licensing terms (e.g., date that doesn’t align with feature date) This information may come from organization distinct from Avails generation Currently solved with mostly-manual processes Solution Short Term: Avails-like (1.7.2 or later) spreadsheet with Bonus information This is a stopgap measure Long Term: MDDF (XML Avails, MMC, MEC, Status, API, etc.) accommodates this

Excel v1.9 requirements Added fields Added template Information to tie to original offer Bonus terms Bonus metadata Information to tie bonus offering to media files Added template Additional template illustrating usage (like movies, TV and collections)

New Terms Information to tie to original offer (new fields) Identification (matches Full Extract/Delete scope) ALID LicenseType Territory Conditions/Filters MediaProfile If blank, applies to all media profiles If present, applies to that media profile and better @condition (sold/not-sold/window, etc.) Still discussing

FAQ Does each featurette need its own ALID, or just an ID of some sort? Yes, everything must have an ALID. Presumably this would be derived from the feature ALID For example, md:alid:eidr-s:abcd-abcd-abcd-abcd-abcd-e might become md:alid:eidr- x:abcd-abcd-abcd-abcd-abcd-e:bonus_1 Would each featurette have its own MEC document? Metadata must be provided: Titles, and possibly synopsis and artwork are generally required. This would generally be the same format as the main feature. Hopefully this is MEC. Can CPE or MMC be translated to this? A cursory evaluation says yes. A lot of information is discarded In MMC and CPE don’t explicitly use ALID for the bonus material. Recommendation pending (ExperienceID?)

Existing Fields reused Bonus Avail ID and Business Data Identification (same rules as Avails) LicenseType Business Terms – mostly inherits terms of original offer Bonus metadata Required/Optional – Rules are different for bonus Required subset drafted WorkType, title information, metadata reference, ratings, runtime, etc.

Current Status Fields included in current draft of 1.9 Far right of Avails-TitleList tab End of Data Dictionary tab Template pending Reminder: This is a stopgap measure, people should be moving towards MMC and CPE