[Bug 25920] Remove extraction of default URL from createSession() algorithm

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

--- Comment #16 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #15)
> (In reply to Mark Watson from comment #14)
> > (In reply to David Dorwin from comment #12)
> > > (In reply to Mark Watson from comment #11)
> > > > As per comment #9, the change should not have removed the possibility for
> > > > the CDM to populate the destinationURL field.
> > > 
> > > I don't think comment #9 says this.
> > 
> > Well, that's what I understood during the discussion of this bug and would
> > certainly have objected at the time if the proposal was to remove the
> > possibility for the CDN to set the destinationURL. Apologies if that was my
> > min-understanding.
> 
> Ah, you were saying that comment #9 did not describe the removal so it
> should have been restored. I interpreted it as saying that comment says we
> should restore it. Thanks for clarifying.
> 
> > > Are there scenarios *not related to initData* that would use destinationURL
> > > in generateRequest()? If so, we should evaluate how they fit in an
> > > interoperable application before adding complexity to support them.
> > 
> > The initialization exchange is one. In this case the application may just
> > need a one-bit indication from the CDM as to whether the message is to be
> > sent to the initialization server or the regular application server. The
> > destinationURL can be used for that (this is what I mean about the
> > destinationURL containing information used for routing - it may not be the
> > actual URL, but it can be something which selects from amongst a set of URLs
> > known to the application).
> 
> It is unclear to me why the CDM should select a different server to perform
> initialization then ask the application to do the initialization.
> Initialization could a) be handled by the user agent with a central server,
> in which case it would not go through the EME APIs, or b) be handled in a
> per-application way via the EME APIs. In the latter case, why can't the
> initialization go through the same server (even if it is then handed off to
> another server).

The point here is that we had a stable design (CDM sets destinationURL in
keymessage event) which several people had determined was sufficient for their
use-cases, even if those use-cases were not spelled out in the discussions.

We did not agree to change this aspect of the design. We agreed to remove the
requirement that destinationURL be set equal to the defaultURL from the
initData. The change associated with this bug did more than was agreed.

So, we should first - as a matter of procedure - revert the part of the change
which was not agreed and *then* get to discussion of further changes people
would like.

> 
> It seems wrong that the CDM should be able to tell the application to use a
> server that is not its own. The assumption for the other uses of
> destinationURL is that the URL comes from the license. In that case, the
> license server (likely controlled and configured by the application author)
> can specify a different URL for certain messages (i.e. heartbeat). With
> default URL removed, maybe a better solution would be to replace
> MediaKeyMessageEvent's "destinationURL" attribute with a "type" attribute,
> which would allow the application to select the appropriate server from its
> list of servers. This would work for normal messages, heartbeat, and
> initialization.

Personally I have no strong opinion about what the field is called so long as
it is a free-form string or ArrayBuffer, rather than an integer. I've a
preference for it to be called something which implies the intended usage is to
influence the routing of the keymessage.

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

Received on Wednesday, 27 August 2014 23:15:03 UTC