[Bug 24082] New: Several issues discussed in the TF point to the need for defined extensibility points in EME

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

            Bug ID: 24082
           Summary: Several issues discussed in the TF point to the need
                    for defined extensibility points in EME
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: adrianba@microsoft.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

The goal of this bug is to replace bug 17660, which was opened a LOOONNNNGGG
time ago when the spec had a very different shape.

During the discussion of bug 17660, Joe proposed some different approaches that
overload the URL attribute of the message event to allow the CDM to communicate
to the application (without needing a round-trip to a server). If this is
needed, I would prefer to provide an explicit mechanism to support this
scenario rather than endorsing stuffing data into the URL that isn't the URL of
a license service.

Similarly, at TPAC we discussed Microsoft's implementation that allows the
application to provide additional data to be provided in createSession that
will be included by the CDM in the message event data. While it could be argued
that this is a transitional problem, we expect services using PlayReady to
continue to want to use this capability and blocking this in EME adds more cost
to service implementations.

In bug 24025, there is discussion of a new dictionary object that is passed to
the MediaKeys constructor including the possibility of including CDM specific
information here.

These issues and others suggestion that we need to consider how to handle this
while still keeping in mind the goals of maximizing interoperability as far as
possible through things like Common Encryption and as common application logic
as possible across browsers/CDMs.

We could choose to not support this kind of extensibility explicitly in the
spec but this won't prevent implementations adding the capabilities. I would
prefer that if this is going to happen that the framework be defined in the
spec so that extensions follow a common pattern. I don't think this reduces the
overall goal that people have to provide common players where possible.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 13 December 2013 00:47:27 UTC