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

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

--- Comment #18 from Mark Watson <watsonm@netflix.com> ---
(In reply to David Dorwin from comment #17)
> (In reply to Mark Watson from comment #16)
> > (In reply to David Dorwin from comment #15)
> > 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.
> 
> The spec is subject to change and improvement:
> "Implementers should be aware that this specification is not stable.
> Implementers who are not taking part in the discussions are likely to find
> the specification changing out from under them in incompatible ways. Vendors
> interested in implementing this specification before it eventually reaches
> the Candidate Recommendation stage should join the mailing list mentioned
> below and take part in the discussions."
> 
> There are no guarantees in this phase that incompatible changes won't be
> made, especially if they improve security, privacy, and interoperability or
> address architectural issues. Scenarios that have not been disclosed or
> adequately described to the group are especially likely to be impacted. 
> 
> > 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.
> 
> When implementing the change, there was no known use case for destinationURL
> in createSession() other than default URL. Rather than define what may be
> used to generate the URL, it was simpler to just specify "null". I disagree
> that the editors need approval for every such decision. We are now
> discussing use cases and alternative solutions, which I believe is a good
> outcome of that decision.

Of course I am aware of the boilerplate around the status of the specification.
Also the latitude afforded to Editor's to make proposals in advance of
obtaining approval or consensus. However, that latitude should not extend to
making changes which are clearly controversial or where there is explicit
disagreement.

I'm not sure how clear the status was with this bug, but what I remember is
that there was considerable opposition to the whole thing and that this
opposition evaporated when it was clarified that destinationURL would not be
removed from the message event and so could still be set by the CDM (this is
what I understood Comment #9 to say, but I see you could interpret the 'i.e',
rather than 'e.g.' as implying an assumed restriction as to when the CDM can
set this to a non-null value).

Anyway, we are going to need a way for the CDM to provide routing information
for messages. The alternative is that CDMs defined key-system specific message
formats with a routing part and a message part, where the routing part is
visible to the client application, or just that there are non-compliant EME
implementations where the destinationURL field is not null here.

> 
> > > 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.
> 
> I filed bug 26683.

Let's continue the discussion there.

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

Received on Thursday, 4 September 2014 00:40:47 UTC