[Bug 26811] New: Separate definitions of Initialization Data Types from Stream Format parsing

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26811

            Bug ID: 26811
           Summary: Separate definitions of Initialization Data Types from
                    Stream Format parsing
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P4
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org
            Blocks: 26738

Currently, the Encrypted Media Extensions Stream Format and Initialization Data
Format Registry [1] is organized such that each Initialization Data Type has
its own page, which covers both the Initialization Data format and - where
applicable - how to parse the associated stream (i.e. container).

However:
 * The Initialization Data Type and stream format are used by two different
parts of implementations:
  - The user agent uses the stream format to extract the initialization data,
but does not necessarily care about its format.
  - The CDM only needs to know how to parse the Initialization Data format and
does not need to parse the stream/container.
  - Note: A packager, which is not covered by the spec, needs to know both.
 * Initialization Data Types do not necessarily have an associated container
(e.g. "keyids")
 * An Initialization Data Type may apply to more than one stream/container
format (bug 26738).

We should have a table and page for Initialization Data Types and separate
pages for stream/container parsing information. Maybe we can use the MIME type
as the index for a table pointing to the latter pages.


[1]
https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/initdata-format-registry.html

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 15 September 2014 20:24:45 UTC