Much of the excitement about advancing the Web has been around HTML5 (the fifth version of the HyperText Markup Language) and its associated specifications; these describe appearance and interactive behavior of the Web.
The HyperText Transfer Protocol (HTTP) is the network protocol used to manage the transfer of HTML and other content, as well as applications that use HTTP. There has been significant progress in updating the HTTP standard.
The third edition of HTTP/1.1 is nearing completion by the HTTPbis working group of the IETF. This edition is a major rewrite of the specification to fix errors, clarify ambiguities, document compatibility requirements, and prepare for future standards. It represents years of editing and consensus building by Adobe Senior Principal Scientist Roy T. Fielding, along with fellow editors Julian Reschke, Yves Lafon, and Mark Nottingham. The six proposed RFCs define the protocol’s major orthogonal features in separate documents, thereby improving its readability and focus for specific implementations and forming the basis for the next step in HTTP evolution.
Now with HTTP/1.1 almost behind us, the Web community has started work on HTTP/2.0 in earnest, with a focus on improved performance, interactivity, and use of network resources.
Progress on HTTP/2.0 has been rapid; a recent HTTPbis meeting at Adobe offices in Hamburg made significant advancements on the compression method and interoperability testing of early implementations. For more details, I’ve written on why HTTP/2.0 is needed, as well as sounding some HTTP/2.0 concerns.
Adobe is actively supporting the development of the Encrypted Media Extensions (EME) to the HTML5 standard. We are working on implementations of the EME and its companion specification, MSE (Media Source Extensions) and have been regular participants in the task force working sessions and email discussions.
HTML has grown to include many capabilities which were previously only provided by browser plugins like Adobe Flash. As a result, more developers are choosing to build applications using Open Web technologies. However, there are applications that are not possible to build today without extending the browsers capabilities. The inclusion of the <video> tag in particular has been a huge step forward, but that capability is limited to playing unprotected videos. To enable the playing of protected videos like feature-length Hollywood films, developers are forced to rely on plugins or non-standard browser extensions. As Adobe supports Open Web development more and more, we need to find a way to provide this capability to developers. I believe the EME specification will help us provide this capability for customers using our Adobe Primetime products.
This EME specification provides benefits to multiple parties. Content providers will benefit from more standardization of the formats used for delivering protected audio and video, lowering their cost for delivering the content. Developers will benefit from easier and faster cross-platform development by leveraging the common Web stack along with the EME APIs. End users will benefit from being able to stay within the familiar browser environment instead of being forced out to standalone proprietary applications. End users may also benefit from increased content options, due to the lower costs to content providers I mentioned above. Everyone will benefit from the reduced API surface area (as compared to existing plugin based solutions) this exposes to malicious code on the web.
The EME working group has published its First Public Working Draft. We are working with the group to address the issues that have been raised so far and constructive comments are welcome. Adobe is working on our own implementations of EME and once ready, we will make them as widely available as possible. Adobe’s goal is to enable more content to flow to more people on more platforms. I believe strongly that this effort will help us towards achieving that goal.
Sr. Computer Scientist
In the last several weeks, Adobe has made two significant announcements about standards contributions. One announcement signaled the submission of a specification for Adobe’s Secure Real-Time Media Flow Protocol (RTMFP) to the Internet Engineering Task Force (IETF) and the other was an announcement by the W3C of stable and feature-complete HTML5 and Canvas 2D specifications to which Adobe contributed an endorsement (as well as providing Rik Cabanier as a co-editor of the Canvas 2D spec).
The two announcements are joined by a common thread: In both cases, Adobe felt that the market and our customers would benefit from the technology in the specifications. In the case of RTMFP, Adobe made a direct contribution of technology, which we believe has value for developers as the Internet continues to develop new applications and solutions. RTMFP may help solve some of the more vexing problems in real-time and peer-to-peer communications. It was submitted under a royalty-free grant – meaning that Adobe does not stand to profit from the contribution.
In both cases, Adobe is betting on the future. The technologies being offered are either proven and existing technologies (Adobe uses RTMFP in Flash and other products), and Canvas 2D is increasingly being deployed and being embraced by the market. What is different is that businesses and developers now have an available and stable specification for implementation and planning. We don’t know where the market will go – but we do know that providing a firm foundation for continued expansion makes it much easier to build for the future.
We’re also willing to bet that the increased transparency offered by standards will help make the Internet and the Web more useful and increase the numbers of users and developers. And that they, in turn, will see more and more opportunities for further development and use. And this grows the market and increases the utility of the Web for everyone.