With this latest version, we are demonstrating another important interoperability scenario - roaming between two different connections (e.g. Wi-Fi and 3G, or Wi-Fi and Ethernet) - with negligible impact on the user experience. The simple, flexible, expressive APIs underlying the CU-RTC-Web architecture allowed us to implement this important scenario just by building the appropriate JavaScript code and without introducing any changes in the spec, because CU-RTC-Web is a lower level API than the current proposed WebRTC API draft. 

By comparison, the current high level proposed WebRTC API draft would not allow JavaScript developers to implement this scenario: the current draft would need to see modifications done under the hood at the Platform level by the developers developing the browser capability itself.

This example also illustrates that we should not assume that everything that will ever be done with WebRTC is already known at the time the standard is developed. It is tempting to develop an opaque, high level API that is optimized for some well-understood scenarios, but that requires development of new, probably non-interoperable extensions to cover new scenarios… or creating yet another standard to enable such applications. We believe that web developers would prefer to be empowered by a lower level, general API that truly enables evolving, interoperable scenarios from day one. Our earlier CU-RTC-Web blog described critical requirements that a successful, widely adoptable Web RTC browser API will need to meet, particularly in the area of network transport. We mentioned how the RealtimeTransport class connects a browser with a peer, providing a secured, low-latency path across the network.

Rather than using an opaque and indecipherable blob of SDP: Session Description Protocol (RFC 4566) text, CU-RTC-Web allows applications to choose how media is described to suit application needs. The relationship between streams of media and the network layer they traverse is not some arcane combination of SDP m= sections and a=mumble lines. Applications build a real-time transport and attach media to that transport.

If you want to learn more about the challenges that SDP brings, some very insightful comments have been recently shared by Robin Raymond of Open Peer on the RTCWEB IETF mailing list.  Go here to see Robin's well-crafted Blog post on the issues - SDP the WebRTC Boat Anchor.  As a community, it is important we continue to share these views as inaction will constitute a self-defeating choice, for which the industry would pay a high price for years to come.

As with our previous release, we hope that publishing this latest working prototype in HTML5Labs provides guidance in the following areas:

• Clarify the CU-RTC-Web proposal with interoperable working code so others can understand exactly how the API could be used to solve real-world use cases.
• Encourage others to show working example code that shows exactly how their proposals could be used by developers to solve use cases in an interoperable way.
• Seek developer feedback on how the CU-RTC-Web addresses interoperability challenges in Real Time Communications.
• Provide a source of ideas for how to resolve open issues with the current draft API as the CU-RTC-Web proposal is cleaner and simpler.

Earlier in February we had published on HTML5Labs an updated version of our HTTP/2.0 prototype that introduced support for ALPN. Shortly thereafter, on Thursday 2/21, Stephan Friedl and Andrei Popov proposed an update to the ALPN spec draft that refines the protocol in a couple of important aspects:

- "Application Layer Protocol Negotiation Extension" now defines ProtocolNameList and ProtocolName as variable-length arrays, as typically done in TLS. This increases payload size by 2 bytes, but allows the use of the normal TLS parsers.

- "Protocol Selection" defines a new fatal alert no_application_protocol, to be used with ALPN extension only, instead of using a generic handshake_failure alert. This is done to help distinguish application protocol negotiation issues from other handshake failures.

Today, we are posting a further update that accounts for those improvements. The new prototype also leverages OpenSSL on Apache as a backend. We are making the corresponding patch available in the download tab together with the new client installer.

-------Original Release: 2/15/2013-------

As part of the HTTP/2.0 effort, the industry is collaborating to reinforce Internet communication security in the IETF Transport Layer Security Working Group (TLS WG). Two security experts from Cisco and Microsoft have submitted ALPN-01 (Application Layer Protocol Negotiation), a safer and simpler application protocol negotiation approach, backed up by a new HTML5 Labs HTTP/2.0 prototype by Microsoft Open Technologies, Inc. incorporating an initial implementation of ALPN-01.

The new ALPN-01 (Application Layer Protocol Negotiation) Internet draft proposes a protocol negotiation in accordance with established TLS architecture with the following benefits:

-        ALPN places ownership of protocol selection on the server, not the client. This allows the server to select an appropriate certificate based on the application protocol, which is in line with existing TLS handshake extensions.

-        ALPN performs protocol negotiation by default in the clear: in general is no need for encrypted communication during the handshake. This permits servers to differentiate routing, QOS and firewalling by protocol.

-        For use cases that can justify the tradeoff with additional latency, ALPN still retains support for confidential protocol negotiation through standard TLS renegotiation.

We think the Media Capture API, developed in the W3C Device API and Policy working group, provides a good foundation for developing this technology and in our proposal we made some suggestions about how to enhance the API. While the discussions in the incubator group continue, we've been working on a prototype to better share our thinking.

The first release of the prototype implements the Audio portion of this W3C specification. We have also included a sample that demonstrates how to properly utilize the APIs that the IE9 plugin exposes.

Download the prototype now!

Install the prototype, open the sample in IE and click on the microphone icon:
the web page will capture the sound until it either hears silence.. When the Play button is pressed, the sounds just captured will play back.

We think the Media Capture API, developed in the W3C Device API and Policy working group, provides a good foundation for developing this technology and in our proposal we made some suggestions about how to enhance the API. While the discussions in the incubator group continue, we've been working on a prototype to better share our thinking.

The first release of the prototype implements the Audio portion of this W3C specification. We have also included a sample that demonstrates how to properly utilize the APIs that the IE9 plugin exposes.

Download the prototype now!

Install the prototype, open the sample in IE and click on the microphone icon:
the web page will capture the sound until it either hears silence.. When the Play button is pressed, the sounds just captured will play back.

Prototype Details

IndexedDB is a W3C draft Web specification for the storage of large amounts of structured data in the browser, using indexes that allow for high performance searches on this data. The IndexedDB API is currently being standardized by the W3C Web Applications Working Group. IndexedDB can be used for browser implemented functions like bookmarks, and as a client-side cache for web applications such as email.

For feedback please use this mailing list.

W3C provides the following mailing list (W3C WebApps WG DL) for feedback about the IndexedDB Spec.

Related Links

• Claudio Caldato's blog
• IndexedDB Fed 04, 2011 Editor's Draft Specification
• IndexedDB Nov 2, 2010 Editor's Draft Specification
• Pablo Castro's Blog

In this latest iteration, we have made three changes in particular to advance discussions on the HTTP/2.0 initial draft and thinking around interoperable implementations:
Negotiation: we have improved upon our initial implementation of the protocol upgrade that we released last month, supporting the scenario where the server does not accept a protocol upgrade.
Flow Control: our prototype uses an infinite Window Update size that is effectively the simplest possible implementation and can be expected to be chosen for many real-world deployments, e.g. by specialized devices for the "Internet of things."
Server push: we have implemented a behavior on the client that resets connections upon receipt of unrequested data from the server. This is particularly important where push might be especially unwelcome on mobile/low bandwidth connections.
This iteration continues to demonstrate our ongoing commitment to the HTTP/2.0 standardization process. Throughout this journey, we have honored the tenets that we stated in earlier updates:
• Maintain existing HTTP semantics.
• Maintain the integrity of the layered architecture.
• Use existing standards when available to make it easy for the protocol to work with the current Web infrastructure.
• Be broadly applicable and flexible by keeping the client in control of content.
• Account for the needs of modern mobile clients, including power efficiency, support for HTTP-based applications, and connectivity through tariffed networks.
These tenets will continue to inform the direction of both our proposals to the IETF and of our engineering efforts.
Please try out the prototype, give us feedback and we'll keep you posted on next steps in the working group.

By publishing this working prototype in HTML5 Labs, we hope to:

• Clarify the CU-RTC-Web proposal with interoperable working code so others can understand exactly how the API could be used to solve real-world use cases .
• Show what level of usability is possible for Web developers who don't have deep knowledge of the underlying networking protocols and interface formats.
• Encourage others to show working example code that shows exactly how their proposals could be used by developers to solve use cases in an interoperable way.
• Seek developer feedback on how the CU-RTC-Web addresses interoperability challenges in Real Time Communications.
• Provide a source of ideas for how to resolve open issues with the current draft API as the CU-RTC-Web proposal is cleaner and simpler.

Please download the prototype and let us know what you think. We look forward to receiving your feedback!

Only three months after its creation, the W3C Pointer Events Working Group has announced that Pointer Events has reached "Last Call Working Draft" status and is considered feature complete by the Working Group. The W3C Pointer Events Working Group has been hard at work over the last few months to standardize a single device input model - mouse, pen and touch - across multiple browsers. Congratulations to the W3C Pointer Events Working Group!

Microsoft Open Technologies, Inc. (MS Open Tech) and the Microsoft Corp. Internet Explorer teams have been working with our colleagues across the industry, engaging developers to test and provide feedback on the specification, and incorporating all the received feedback into this Last Call Working Draft.

To demonstrate cross-browser interoperability for Pointer Events, MS Open Tech developed a Pointer Events prototype for WebKit on HTML5 Labs and submitted the patch to the WebKit community. On 2/20/13, we posted an updated version of the patch on HTML5Labs and on the WebKit issue tracker, incorporating community feedback received on the previous version.  MS Open Tech will continue updating this prototype to match latest draft of the specification.

Go ahead and download the latest version of the patch!

How is this helping developers?

With the Device Orientation API, developers can explore new input mechanisms for games, new gestures for apps (such as "shake to clear the screen" or "tilt to zoom")or even augmented reality experiences. The prototype's installation includes a sample game to get you started in understanding the API.

How does this work?

The Device Orientation API exposes two different types of sensor data: orientation and motion.

When the physical orientation of the device is changed (e.g. the user tilts or rotates it), the deviceorientation event is fired at the window and supplies the alpha, beta, and gamma angles of rotation (expressed in deg/s):

<div id="directions"></div>
<script>
   window.addEventListener("deviceorientation", findNorth);
   function findNorth(evt) {
      var directions = document.getElementById("directions");
      if (evt.alpha < 5 || evt.alpha >355) {
         directions.innerHTML = "North!";
      } else if (evt.alpha < 180) {
         directions.innerHTML = "Turn Left";
      } else {
         directions.innerHTML = "Turn Right";
      }
   }
</script>

When a device is being moved or rotated (more accurately, accelerated), the devicemotion event is fired at the window and provides acceleration (both with and without the effects of gravitational acceleration on the device, expressed in m/s²) in the x, y, and z axis as well as the rate of change in the alpha, beta, and gamma rotation angles (expressed in deg/s²):

<div id="status"></div>
<script>
   window.addEventListener("devicemotion", detectShake);
   function detectShake(evt) {
      var status = document.getElementById("status");
      var accl = evt.acceleration;
      if (accl.x > 1.5 || accl.y > 1.5 || accl.z > 1.5) {
         status.innerHTML = "EARTHQUAKE!!!";
      } else {
         status.innerHTML = "All systems go!";
      }
   }
</script>

Trying out the prototype

The prototype can be found on the download tab. This prototype requires Internet Explorer 10 running on devices with accelerometer sensors supported by Windows 8. The prototype works as an extension to Internet Explorer on the desktop, where developers can get a first-hand look at the APIs. To get started building your own pages with the prototype, all you need to do is install the prototype and then include a reference to the DeviceOrientation.js script file included with the demo game:

<script type="text/javascript" src="DeviceOrientation.js"></script>

We want your feedback

We want to hear from developers on this prototype implementation of the W3C Device Orientation Event Specification, so please let us know what you think by sending us a message.

Important Note: This prototype has been developed as a proof of concept to demonstrate how Scalable Vector Graphics can be made even more flexible for web designers in HTML5. While the prototype is working and we would like developers to download, test it and provide feedback, it is not intended for production quality developments.

SVG, or Scalable Vector Graphics, is a family of specifications of an XML-based file format for 2-dimensional vector graphics, both static and dynamic. The SVG specification is an open standard that has been under development by W3C since 1999. In addition to being vector-based, the big advantage of SVG graphics is that images are defined in XML text files, and therefore can be searched, indexed, scripted and compressed. All the major web browsers have some degree of support and can render SVG markup directly. 

SVG can be animated with SMIL (Synchronized Multimedia Integration Language) or with a scripting language such as JavaScript. You can see examples of this on MSDN. Using these methods to render animated graphics usually works well but when it comes to making modifications or applying different styles, they usually require considerable development efforts.

This is where the CSS3 capabilities come into play. Cascading Style Sheet has been designed to enable the separation between the document content and its presentation. Using CSS you can style your web pages and easily and conveniently adapt the look and feel and the ergonomics of your Web site or application. 

When applied to SVG values that are currently exposed as properties, the CSS animations and transitions styling provide flexibility and ease of use to developers.

In his blog post [insert link to blog post], Patrick Dengler, Senior Program Manager in the Internet Explorer Graphics team explains how this would like concretely and provides concrete examples for animating objects, applying transitions on their attributes and manipulate filters in CSS.

The prototype works on Internet Explorer 10 and Webkit-based browsers. You can see a video below and read the transcript of a demonstration that highlights some of the scenarios made possible when applying CSS animations and transitions styling to SVG.

In this demo we explain how to use the prototype to apply simple styling to different SVG objects attributes such as position, color or SVG filters.

You can download the prototype and create your own web site project to reproduce this demo.

To download the prototype, go to the following page and extract the content of the zip file to the location of your choice.

In Visual Studio, create a new C# Web project of type "ASP.NET Empty Web Application"

Add 2 new files in the project, an html one and a CSS one.

To do so, right-click on the project name in the Solution Explorer and select "Add->New Item" then select the right file type (HTML and Style sheet) and name the files:

Create a new folder in the project named "scripts". To do so, right click on the project name and select "Add->New Folder…"

From the prototype extracted folder, drag and drop the following files into the newly created folder in the Solution explorer:

• Jquery.min.js
• Svgadmin.js

Open the index.html file, delete all content and paste the code from this file.

Open the style.CSS file, delete all content and paste the the code from this file.

Switch the view back to the index.html file and strike F5 to start debugging. You will be able to see the final result of the demo.