And when we live in your Star Trek-style technoutopia, then we won't have to worry about business concerns in specs. Specs have had business concerns in them since... ever.
I'm talking about adding in mechanisms to support restrictions because of current legal situation. If you add in extensions that help DRM video, why not start adding in support for extensions that can prevent SSN or medical history from being displayed on the screen unless the local machine sends a valid fingerprint signature to the server? Of course that sounds ridiculous. Something like that doesn't belong in the spec. I fail to see the difference between that and EME.
I would argue the exact opposite.
This is more a problem with the developer of said site and not an issue with XMLhttprequest as you can build apps that are progressively enhanced for it and don't fail completely when JS/XMLHTTP is disabled.
Specs have had business concerns in them since... ever.
An obvious "business concern" is that any replacement system will accommodate future legislative changes. This has nothing to do with the functional (user) requirements (form design and submission process), and yet might dramatically change how you design and write such a system.
DRM, or rather the encryption scheme that makes it DRM, is much the same in that a design that supports it could similarly support related but more benign capabilities, such as compression or translation.
That too will influence an implementation, and makes such a non-functional requirement as important as a functional requirement.
That was my point. Why is it completely unrestricted? How hard is it to check a cookie and 401 if I'm not logged in? And if someone can fake an HTTPS cookie, they can do a lot more damage than download a video.
The first part does not imply the second. I know there are legal/licensing reasons for encryption but technology that is going to run the world of tomorrow should not be encumbered because of contractual obligations of today. I fail to see the technical reason why encryption is necessary for Netflix. HTML5 is a technical spec. It does not need to be riddled with extensions to fulfill business needs.
I can't view a stream if I'm not a paying member logged in to the website or XBox/Roku/AppleTV device. Once I am able to view the stream, encryption or not, I can record it through a number of hardware/software mechanisms if I am technically savvy. If I'm not technically savvy, I can't record it regardless of encryption. If I can somehow access the stream without logging in, say the files are stored on CDN and available to everyone over HTTP(S), then you should work on preventing that.
W3C/HTML5 are designing specs for the long haul. I am pretty sure I will be writing web apps in a decade too, like I did a decade ago. iTunes no longer has DRM'ed audio. Who knows, in a decade, Hollywood will give up DRM too, with pressure from Netflix, Apple, Amazon, and Google. But if engineers at these very companies that should be pushing for open-web, insist on burdening the spec to cope with DRM, I doubt we'll ever see that future.