DSCA Avails WG

1. DSCA Avails WG August 6, 2019 with notes

2. Agenda • Action items from last meeting • 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)

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

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

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

6. New Values and Templates

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

8. Status of new features • Status and Bonus • 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)

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

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

11. 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 Original Price TPR Price Original Price

12. Review Status Template (from Excel)

13. Review Bonus Template (from Excel)

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

15. Discuss TPR Deferred to next meeting

16. Backup/Reference Material

17. Avails Bonus (XML) June 10, 2019

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

19. Excel v1.9 requirements • Added fields • 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)

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

21. 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-emight 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?)

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

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