The W3C (World Wide Web Consortium, w3.org) is responsible for defining standards around HTML. One of the most prominent current developments is HTML 5.

HTML 5 is not just about the HTML "mark-up" language. The standard includes extensive extensions to Javascript APIs around geolocation, storage, media access and other features.

In addition, HTML is defined by the "WHATWG" (Web Hypertext Application Technology Working Group), an organization not associated with W3C. The WHATWG was created by Apple, Opera and Mozilla after the companies felt that the W3C's HTML Working Group (HTMLWG) didn't move fast enough.

These days, the HTMLWG and the WHATWG are working together, but they are taking a different approach to the future development of HTML. The WHATWG is defining HTML as a constantly developing, "living" standard. The HTMLWG is taking various snapshots of the WHATWG standard, and defining them as an HTML version.

Here are some of the more recent notable additions to HTML, which are usually kept under the umbrella of "HTML 5":

- Access to hardware sensors: Most browsers already support GPS geolocation, or access to other geolocation APIs of the hosts (e.g. via WiFi). But sensors like accelerometers commonly found in mobile devices are supported as well. Recently, support for the access to cameras and microphones emerged but support is still spotty.

- Extended storage options: Traditionally, web applications had to store data in cookies. Cookies are rather limited in size, and wouldn't scale to a larger size as they are sent with each request. With HTML 5, web applications can store up to 20 MB on the browser, and if that's not enough, they can ask the user for permission to store more data.

- Offline applications: An application may provide a manifest listing all files (HTML, Javascript) that are required to run an application offline

- Video/Audio codecs: the <video> and <audio> tags allow for the playback of audio without the help of plugins like Flash or Java. However, not all browsers support the same codecs.

- Client input validation: Many web applications use javascript to validate user input on the client. In HTML 5, this can be done within the "input" tag by specifying a regular expression. Just like the javascript client validation, this should never be used for security purposes, but can make an application more usable.

There are many more features that are part of the most recent HTML specs, and browsers are starting to implement them. Which features you will find depends on the browser you are using.

But with great power comes great responsibility. All these features need to be implemented correctly in order to avoid security vulnerabilities in the browser. The browser is also very exposed constantly downloading code and executing it from various sites. The fundamental problem in HTML is that data (HTML) and code (Javascript) isn't well separated from each other. This missing separation opens the door to issues like XSS.

There is also no good way to "sign" a piece of javascript like you would sign a desktop application. The best you can do is to protect the transit via SSL.

Introduction

There are several new protocols that are on their way to being adopted in some form or another. In the previous article we covered how different standards bodies can cover and sometimes govern similar protocols and standards. Here we will discuss two emerging data center orriented standards and how they compete.

TRILL

First, I would like to draw your attention to a protocol called TRILL or TRansparnet Interconnection of Lots of Links. [1] There are several good sources for a technical overview so I will be brief. In short TRILL is a method of Routing Bridges or RBRidges [4] to exchange link state and does so with another protocol called IS-IS [2] or Intermediate System to Intermediate System.

Before we get lost in our first example of too many cooks making the soup, lets be clear on TRILL using IS-IS that are both published by the IETF as RFC6327 and RFC 1142. RFC1142 is a republication of an ISO Standards body routing protocol publication. So, RFC6327 uses a standard that that was actually published by the ISO body but republ… You see where I am going.

SUPER OVER Simplification (TRILL)

TRILL is desinged to run at Layer 2 in the OSI model and allows for each TRILL switch to exchange link state information. You get enough information shared between TRILL Switches that they can make route discisions for optimized pathing. Here is a great write up http://en.wikipedia.org/wiki/TRILL_(computing) on Wikipedia. So basically build a tree of L2 States, trade them, and help them to talk, REALLY Fast… Well that's the goal anyways.

Why are we talking about this new Data Center Protocol by the IETF and through republication the ISO?

SPB

Enter Protocol number 2, this protocol is brought to you by the good ole folks at the IEEE. If we remember our breakdown from my last diary, we will know they govern things like 802.1 [5] and 802.11 [6]. Why is this relevant? Enter contender number two for datacenter bridging protocols. SPB or Shortest Path Bridging. [7] [8]

SUPER OVER Simplification (SPB)

Use IS-IS (<------seeing a trend?) to exchange a tree information to compute shortest path for packets. There is, of course, a lot more to it than the above but hopefully my point is made. Another great write up: http://en.wikipedia.org/wiki/IEEE_802.1aq

Conclusion

So, to recap, the IETF and the IEEE are working on similar protocols to accomplish similar goals. We will see who "Markets" the best to gain acceptance but It might be important to understand how many standards bodies have influence on the widgets and tools we implement. With SDN [9] or Software Defined Networking being the new "Cloud" word, it is good to understand who is shaping the SDN protocols. We can now start to see that many standards bodies go into making the "Internet" go....

And most of all, awareness of this is good as we are the ones that have to secure it