This article is a response to a paper from Tom Worthington regarding MHP and Internet convergence published at the Communications Research Forum in September 2001 . This paper has been available for a while, but I still see references to it in the logs for my web site, and so I thought that it was time to publish my comments on his paper. Convergence is an area of interest to a lot of people, after all, and I think that there's some areas that are missed in the paper or which I believe need some clarification.

Although this document clarifies and rebuts a lot of the content of Tom's paper, this is not intended as a dismissal of that document. Instead, it's a view from the other side of the wall, the TV side, and fills in some of the holes that an audience unfamiliar with MHP may stumble on.

Any quotes in italics are from Tom's original paper. To make them easier to find, they are followed by the heading of the section containing the quote (also in italics). Links used as references below will open the content in a new window.

Disclaimer: I am not associated with DVB in any way, shape or form and so this is not an official response. At the same time, I'm one of the architects of several of the MHP APIs, and author of some of the standard itself. While this gives me an insight into elements of the standard that other people may not have, it probably introduces some biases as well. You have been warned.

I will apologize in advance for any places I've misinterpreted Tom's paper. I will be more than happy to correct any misinterpretations. If you have any feedback regarding this paper, please email me at webmaster@mhp-interactive.org

An overview of MHP

The first of the items that needs to be addressed is the purpose of the MHP standard. There seems to be a misunderstanding about what MHP sets out to achieve: The Multimedia Home Platform (MHP) attempts to adapt existing Internet and web standards for to digital Television (DTV). The aim is to provide interactive digital content that can be viewed on set top boxes and multimedia PCs. (What is the Multimedia Home Platform (MHP)?).

MHP is much more than that. It's an attempt to define an open middleware standard for interactive TV. It doesn't care about multimedia PCs. It doesn't care about the web. It cares about TV. Anything else is a distraction, and is outside the scope of DVB as an organization.

A similar statement is made elsewhere in the document: MHP attempts to merge European DVB standards with those of the Internet (An overview of the main points of the MHP standard).

It uses some Internet standards, in the same way that it uses MPEG and other DVB standards. It's not a serious attempt to merge them. Instead, it's an attempt to build on top of existing standards where appropriate and avoid re-inventing the wheel. Please note that the previous sentence says "where appropriate": if the wheel in question is actually a square with an offset axle, then it got re-invented. Some internet standards can and should be adopted. Some should not. A lot depends on how suitable they are for the technology of a television system and the interaction model of TV viewing.

Individual DVB members may have particular biases in this area (yes, I do mean Microsoft and Intel), but adapting Internet and web standards is only a small part of this work. That's why the sections referring to Internet and web standards are only 10% of the document, and weren't added until version 1.1, about a year after the final standard.

While I'm dealing with this section of the document, let's kill a couple more inaccuracies:

June 28, 2001 First MHP applications for digital TV
First MHP applications for digital TV The first MHP (Multimedia Home Platform) applications for digital TV are now available. Watch a streaming video demonstrating the use of a browser in digital TV. The video was made by recording the video output of a MHP capable set-top-box.
From: Sonera Plaza MediaLab 2001

This is a quotation from a press release, and not actually part of the text that Tom wrote. It's nice marketing, but not actually very accurate. I was personally demonstrating some of the first MHP applications (along with Philips, Sony, Nokia, Panasonic and others) back in 1999 at events like IFA and IBC, and some of those applications were also shown at JavaOne starting in 2000. Ho hum, Sonera are only about two years late with their claim.

By the way, the first MHP applications didn't have any HTML at all, because it wasn't even part of the standard then. Most applications still don't, because DVB-HTML is not very mature and real implementations have had limited interoperability testing.

The relevance of the Internet to MHP

Next, let's move on to the importance of Internet and Web standards to MHP. The paper complains more than once that the standard is published in an Internet-unfriendly way:

The standard is difficult to use, due to it being published as one large PDF file. The use of PDF, is at odds with the stated aim of the standard to use Internet and web standards. Reading the standard is a cumbersome process and lowers its credibility as a guide to efficient electronic communication. This contrasts with successful Internet and web standards, available in Internet and web formats which are simple and quick to download, translate or copy. This, and the poor quality of the design of the MHP web site, may prove a major impediment to use of the standard.. (Where can I get the standard?)

A similar complaint is made in the conclusion. This is partially true, but there are reasons for this:

• At 1400-plus pages, it's too long for a document format such as HTML to be practical. Trust me, having written drafts of parts of the standard, and seen the level of editing work that went into the finished article (as an author and reviewer of parts of the standard, I was frequently in contact with the editor of the standard during the time it was prepared), I know of what I speak. Internet standards are not this long, or this complex, and the idea of using something like HTML to make it even bigger and more complex to maintain is really not a good one.

  Reading the standard is a cumbersome process because it's 1400 pages long. Reading 1400 pages-worth of any document is tough. Reading that much HTML is tough. Even reviewing the material on this web site (around 150 pages when printed) is a painful job, when I have to review all of it. Would you guarantee that every browser, or even major versions of the big three browsers on all platforms, will display the entire document in a sensible way? I wouldn't.

• It's not an Internet standard, so why should it be distributed in the same was as Internet standards instead of in the same way as every other DVB standard?. This is an important point. Yes, MHP uses Internet standards. So what? Lots of other standards do as well - look at the number of places XML is used, for instance. The references to Internet standards are a fairly small part of the entire document (less than 10% of the MHP 1.1 specification) and are far outweighed by the references to DVB and MPEG standards.

• Successful Internet and web standards are ...available in Internet and web formats which are simple and quick to download, translate or copy. None of those is as big as MHP, and none of those has any kind of compatibility test suite that one must pass. In the case of an MHP receiver, to say it complies with the MHP standard it must pass a test suite. By distributing a PDF, no unauthorized alterations can be made in the text, no 'unofficial versions' of the standard can exist - just the PDF from DVB which is the canonical reference.

  As for translating the MHP specification, well...would you really want to trust a volunteer effort to translate a 1400-page specification with no guarantee that the translation is accurate? More to the point, is an unofficial translation with no guarantees of correctness actually better or worse than no translation, from an interoperability point of view and especially when you have to pass a test suite to legitimately call your MHP implementation an MHP implementation? The language used in standards is extremely precise, and translating this hard even without the copyright restrictions. Even writing it is hard.

  Let's also remember that unsuccessful Internet standards are also ...simple and quick to download, translate or copy. Big deal. What matters is the technical quality of the standard and how well it's supported by the industry. Those well known Internet standards IEEE 802.3 (Ethernet) and 802.11 (WiFi) are copyrighted and only published in paper or PDF form, and it hasn't harmed their adoption - you wouldn't be reading this article without them. The same also applies to the MPEG-2 standard. They're widely adopted not because they're freely available, or because it's easy to translate. It's widely adopted because it does what it's supposed to do in a way that most people think is a good approach.

I won't argue about the design of the MHP web site - it's awful, and the sooner it gets changed to something more usable, the better. But if ...the design of the web site...may prove to be an major impediment to use of the standard, why is Microsoft doing so well?

It might have been better if the standard had been developed as a set of documents, building up functionality, based on experience, rather than as one "big bang". The Internet has shown the benefits of incremental standards development. (An overview of the main points of the MHP standard)

MHP is largely built on existing standards - very few of the APIs in MHP are new, especially the main ones. Even some of those new APIs are built on older APIs, and modified based on the experiences of implementing and using those APIs. MHP includes work from the Digital Audio-Visual Council (DAVIC) and HAVi, as well as from existing closed APIs such as Sun's JMF. Many of the people involved in MHP were involved in other digital TV standards, and brought the lessons from those standards with them.

While this isn't quite the same as what Tom describes, there's a good reason for this: if a digital TV middleware solution doesn't have all the needed functionality, it's not useful. No-one will use middleware that only has half the functionality of other solutions.

The Internet is not TV

The Internet has a long history (well, in technology terms, anyway) and a lot of baggage that goes with that. You're reading some of that baggage now. Even though this page validates as HTML 4.01 (so do all the others on this site, and the stylesheets too), I still need to use some fairly ugly HTML tricks to support all the browsers.

The browser arms-race of the 90s is basically over, thankfully - now, it's about supporting standards. But there's a lot of content out there (and a lot of content developers) who still use the browsers and HTML that was produced during that arms race. Web site design is copying print media ever more closely (or using Flash), and people are trying to make HTML do things that it was never designed to do, with browsers that don't support the tools to help them achieve this.

How many sites have you seen recently that have turned you away or warned you, because you're not using Internet Explorer or because you're using an old version? I use Opera as my default browser, and I still get it sometimes on some fairly well-known sites. Can you imagine what would happen to this content on a TV?

The product lifecycles of the television industry and the PC industry are very, very different. In the TV industry, you have a product with fairly long life - up to 10 years. For the Internet, two years means the technology is virtually obsolete. Mixing these two industries is very hard, and even though the standards track one another for now, in a couple of years the TV industry will be well behind the web in terms of technology adoption.

People don't upgrade their TVs as often as they change their PCs (set-top boxes are a different story, but even there you have the barrier of not being able to download new hardware). The basic TV standards have been around a long time, simply because upgrading them is so difficult. Look at the time it's taken to upgrade to digital.

TV is not the Internet, either

There are a number of reasons why HTML is not more prominent in MHP. As I've already mentioned, Internet standards are a moving target. So many web pages and web developers use stupid HTML tricks, non-compliant HTML or stuff that simply isn't HTML to achieve their ends. On a PC this is fine - you've probably got enough bandwidth and processing power (as well as screen real-estate) to display these pages. You may even have a browser that handles it. But take a look at how much memory your browser is using.

Once you start trying to handle all of the HTML-related standards that MHP specifies (which aren't even in most mainstream PC browsers yet), you need a lot of memory and processing power. Memory and processing power that STBs simply don't have, and that customers won't pay for in the current markets. Don't forget that most markets are currently vertical markets, and so it's the network operator that bears the cost of the box. They're not going to add to their box cost just for the ability to use HTML. If they did, you'd see this already happening.

HTML support was added to MHP mainly at the behest of the PC industry. STB makers don't care about it that much. Neither do content developers. They're already using middleware that supports Java or C development, and the switch to MHP is simply another middleware API to learn. The clamor for an MHP 1.1 implementation that includes DVB-HTML has hardly been deafening. I've worked for two companies developing MHP implementations, and in both cases, MHP 1.1 is off in the distance, to be provided sometime when MHP 1.0 takes off.

Let's not forget either that all the other stuff in MHP 1.1 must be included for any DVB-HTML implementation to meet the MHP standard. You don't get to pick and choose. Any device which doesn't implement all the other parts of MHP 1.1 besides DVB-HTML is non-standard. That's a lot of overhead to support when you can do it in much less memory using Java, and that's why DVB-HTML support has been weak. Adding a web browser means more RAM, more flash memory and a faster CPU. Since the consumer isn't willing to pay for any of those at the moment, it's no wonder that adoption has been slow.

To illustrate the gulf between the philosophies of interactive TV and the Internet, I'd like to address some of Tom's comments about timing and synchronization:

• A major limitation of the MHP standard is that it does not define referencing of video segments of finite duration. MHP is not a true multimedia format, in the style of the Synchronized Multimedia Integration Language (SMIL). (DVB-HTML)

  Actually, it does. A DVB locator can refer to a DVB event - a specific show or piece of content that will be of finite duration. This may not be very useful in most cases, but the reason for that is because the TV world doesn't have many short video segments. An event is as short as it gets, in most cases. When people are thinking about TV, they are usually thinking about a specific channel or a specific show. Anything else would be an unnecessary addition to MHP, trying to support something that there's no need for.

  The comparison to SMIL is not really fair. SMIL is designed to bring together content contained in files (or that can be streamed on demand) and play it in a specific context and in a specific order. That's not the case with MHP. MHP was never designed to play short video clips of finite duration (streamed on demand or loaded from a file) because that model simply doesn't work very well in a broadcast environment. And MHP is, after all, a broadcast standard.

• MHP provides "triggers": small messages with a time code and action sent in a broadcast, which can start a particular video, audio or action. The synchronization features are similar to SMIL and it is not clear why the SMIL module of XHTML was not used. (Synchronization)

  Again, the comparison to SMIL. In practise, the synchronization features are quite different and are based mainly around external events (DSM-CC stream events) rather than synchronizing to other content elements in the same presentation. Before anyone says anything, the broadcast video is not really part of the same presentation, when considered from the SMIL perspective. Since the application can be started at any point in the broadcast stream, considering the service to be part of the application is not a valid way of thinking about it.

  These synchronization features provide a way of synchronizing with external media (the broadcast service, in this case) and not with other components of a presentation. SMIL was not used because it was not appropriate and would only have complicated things.

Tom also has some comments about the graphics model: The MHP standard contains a detailed section on the graphics reference model used. It is not clear if this is needed as it duplicates much of the work of CSS. CSS may be inadequate for this application, but producing an enhancement to that standard might be better than create a new separate standard. (Graphics reference model)

For a TV-centric application, which has to take into account existing TV-centric hardware, 'enhancing' an existing web standard is almost certainly not a good idea. The TV graphics model is very specific, and very different from the computer industry model. The model in MHP is based around the hardware support offered by chipset vendors. This is a model that everyone in the industry is familiar with, that has all the functionality needed in a TV environment and which offers significant benefits and few major problems. So why change?

As I have said above, when the wheel in question is a square with an offset axle, MHP makes no hesitation in re-inventing the wheel. While CSS is generally a reasonably good standard for web use, the baggage that comes with it and the differences from a traditional DTV display model is too much.

I also have some detailed comments on his remarks about content formats:

• On image support: However, the standard takes the dangerous approach of requiring any pixel scaling, colour space or gamma settings in an image file to be ignored. This could result in distortion of some images and may be illegal under moral rights provisions of copyright law. (Static formats)

  Is this a dangerous approach? Not really. Instead, it saves valuable space inside the receiver by not implementing features that aren't needed. Developers know that these features can't be relied on, so they make allowances for it. A much bigger problem for distorting images is the presentation of content with a 4:3 aspect ratio on a 16:9 TV, and there is no way of dealing with this. Again, developers and broadcasters have to cope. And they do. It's a different industry, with different expectations from the PC world and different issues to solve. Content developers and broadcasters (i.e. people who care about image reproduction quality) were involved in developing the standard, and had no problem with these features.

• On MPEG-2 video 'drips': an unnecessary and complex addition to the standard. (Static formats)

  Well, the content developers don't think so. This option was added at the request of one of the middleware manufacturers who support a similar feature in their middleware, and has been well-received by all parties. Yes, the learning curve is a little high, if you don't know MPEG. However, if you're a content developer for interactive TV, you should know MPEG, dammit, at least to this level. Any feature that saves precious bandwidth in a way that's easy for content developers to understand is likely to be well-received. Yes, it's an unusual content format for the Internet world. That's because there's no need for this kind of content format in the Internet world.

• On subtitles: ...program access to Teletext data packets is not permitted. This is presumably to try to prevent unauthorized use of Teletext content. However, it may prevent useful services, such as searching and indexing multimedia content based on the text of subtitles. MHP supports Teletext for subtitles, not as an alternative to web-style content. (Broadcast streaming formats)

  Well, access to Teletext data isn't supported by an MHP API, but that's because we didn't see a need for it. This is not the same as it not being permitted. Teletext is separate from an MHP application, and if a broadcaster wants to use Teletext, that's fine.

  These 'useful services' are services for the head-end or for a PVR-style box, and these advanced features aren't going to be common in products for a while yet. Even when they are, this may not be the best approach for doing this (see the TVAnytime activity for an example of the work in this area).

  Teletext isn't a real alternative to web-style content, because we can use MHP applications if we want web-style content. Many of the teletext services offered on MHP platforms are written using HTML and a web browser, simply because of the flexibility it provides.

• On fonts: Note that the default ("body") font size of 26 points is approximately the same as 18 TV lines. While these font sizes are suitable for TV display they are much larger than fonts used in web computer applications. (Resident fonts)

  Yes, they are larger, and there's a good reason for it, as I'm sure Tom already knows. Small fonts look terrible on a TV. Again, the differences between a TV display and a PC display raise their ugly head. Small fonts flicker because of the interlacing on a TV, and are difficult to read because the number of pixels used to represent them is too small.

• On colour representation: A detailed mathematical explanation [of the RGB colour space] is provided in the standard, but while important for TV applications this appears excessive for a web application. (Colour representation)

  Since the standard is aimed at the TV industry and not the web, this is not surprising. That explanation is included precisely because it's important to TV, and since the standard doesn't care about the web, this is not a big deal. Unless you're developing HTML content for display on a TV, in which case, you'd better care if you don't want your image to look terrible.

This brings us to an important point, which is why I chose to end this section addressing it. The display models of a computer and a TV are very, very different. What displays well on a PC can look terrible on a TV, after colour space conversion and interlacing. Integrating the requirements of designing content for the Internet and for a TV will be one of the biggest challenges facing any content developer that tries it. Doing a good job on this content will be an even bigger challenge. It may not be impossible, but it's tough.

It's extremely unlikely that exactly the same content will be shared between the PC world and the TV world, because the technical differences between the two are so big. When we get progressive-scan, high-definition displays that are good enough to display current web content as it's supposed to look (the PC industry (and the web) will have advanced technically. Transcoding and content adaptation are a possible way round this, but that introduces yet more issues that must be considered.

Internet compatibility

However, MHP is designed to provide Internet-like TV broadcast services, in much the same way WAP was designed to provide web-like services on a mobile telephone. The result is a closed business model very different from the Internet. WAP developers envisaged that WAP content providers would provide a rich range of services for which consumer would be prepared to pay. (Compatibility with the Internet)

However, MHP is designed to do nothing of the sort. MHP is designed to provide an open alternative to existing middleware solutions. This has many implications for the industry, but Internet-like TV broadcast services isn't one of them, let alone a conscious effort in the design process. WAP failed because accessing web-like content over a slow connection and small screen wasn't very popular, so no-one developed for it. Take a look at I-Mode for a counterexample. Trying to emulate the web too closely in a foreign environment is what killed WAP.

The TV business is very different from the Internet world in terms of philosophy and business models. People are still working out the business models for interactive TV, just as they're trying to work out business models for the Internet. Some of those business models will probably be the same, and some will be different. All this proves is that they're different environments. A closed business model makes sense in the TV world, because the TV world is itself closed - you can't just set up a digital head-end and expect that anyone who wants to see your content can do so, unlike a web site. MHP isn't designed to be related to Internet standards at the core technology level, because it was recognised that these environments were different.

However, expanding existing DVB set-top boxes to handle MHP will prove a challenge, even without allowing for Internet access as well. Entry level set-top boxes do not contain a hard disk and so can have only limited software. Digital video recorders, such as the TiVo, may provide the early platform for MHP. (Compatibility with the Internet)

High-end devices such as digital video recorders are unlikely to be the early platform for MHP, because the current business model doesn't allow it. A vertical market, where the network operator buys the STB and rents it to the customer, usually result in extremely high price pressure on the STB. That means that digital video recorders are out, at least in the current business climate. I was involved in responding to requests for proposals at one of my previous jobs, and cost was always a major factor. Advanced features were something that were nice if they were free.

This statement is partially based on an incorrect assumption: that MHP receivers need more power and storage than their non-MHP counterparts. To be honest, this is a fairly common assumption, but it doesn't have to be true. I've seen (and demonstrated) MHP solutions running on STMicroelectronics 5518 CPUs, which are a fairly common low-end chipset, with 24MB of RAM. While 24MB may sound a lot, 16MB is now common and 24 is not much more expensive. No hard disk, no upgrades over a standard STB for a real customer except some added RAM. MHP doesn't have to be expensive, and some of the major players in MHP predict that MHP-equipped receivers will be cheaper than their non-MHP counterparts by the end of 2003.

Tom's description of how the MHP supports referencing DVB services & content on the web. That is clicking on a link to DVB content will launch the DVB service (such as video). However, there appears to be an attempt to keep MHP self contained and not blended with web content. (Internet access clients).

This is correct, as far as it goes. There is not attempt to blend MHP with web content because it doesn't belong. Most web browsers will never support MHP content such as links to DVB services, because it's not sensible for them to do so - most PCs will not be capable of receiving DVB services. DVB-HTML is part of a digital TV standard, and so applying it to general web content is impractical. The use of links to DVB services in DVB-HTML provides the same functionality as the JMF or JavaTV service selection APIs in DVB-J applications. It's not intended to allow general web content to refer to DVB services, because DVB is not the place to standardise this. That is the job of the IETF.

While we're discussing compatibility with the Internet, I'd like to remind those of you who are reading this that unless the MHP implementation implements the (optional) DVB-HTML support in MHP 1.1, or provides an implementation of the full Internet Access profile from MHP 1.1, there is no support for Internet standards in MHP (Java is not an Internet standard any more than Perl is).

Will convergence happen?

I hope not; at least not anytime soon. The Internet and TV are two very different media, with different backgrounds, different technologies and different interaction models. There is a place for Internet standards in the TV world, no doubt about it. HTML can be a very useful way of developing certain types of application, but the overheads of a web browser mean that for many tasks it's unsuitable.

To look at this from another perspective, let's examine the world of closed middleware. Do they use Internet standards? Well, sort of. You can usually get a browser for a middleware stack (for instance, OpenTV Core provides it as an extension that you have to pay for, and you can get HTML support for MediaHighway). However, if you're developing content for that middleware, you'll use Java or C/C++, rather than HTML

HTML hasn't taken off in the digital TV field in Europe and Asia (I say this because I'm referring to markets I know personally - I can't make this judgment about other markets). Two of the reasons for that are compatibility and size. A decent HTML parser and renderer that follows current standards is big - take a look at Opera or Phoenix (the cut-down version of Mozilla) if you don't believe me. One of the reasons for this is that they have to support all of the stupid HTML tricks that people pull, and even worse, all of the not-quite-HTML that gets used on web pages. The TV world has to be more strict, more interoperable and more reliable - if you crash someone's TV, they won't be happy with you.

I'm not claiming that Java is perfect, or that anyone who uses DVB-HTML is a fool who's making life hard for themselves, but broadcast content can (and must) be more reliable than any other type of content.

The strict use of XHTML would limit the use of some legacy HTML features. One explicitly mentioned in the standard is that the id attribute has replaced the name attribute in specifying a target frame. The result could be that links to target frames will not work, if they use the name attribute. (DVB-HTML)

Strict is good. So is limiting legacy HTML code. Designers need to make sure that their code is reliable, and works well on the platform, and that means targeting the platform in question very carefully.

This is a major difference between web development and interactive TV development. I've been involved with deploying real interactive TV applications, and they often get tested for at least a month in the service operator's lab (in addition to any prior testing by the developers) before they're allowed anywhere near a real network. This happens for a reason.

With HTML content, it's extremely difficult to predict how an application will perform on several different platforms due to the (sometimes intentional) unspecified elements in the specification. HTML is NOT about providing absolute control over appearance, and attempts to make it do this only lead to trouble and the use of browser-specific tricks. Trying to maintain a common look and feel across platforms is impossible. If you don't believe how hard it is to maintain compatibility while still getting the right look and feel, take a look at the following sites:

• Globe Technology - All browsers are not created equal
• CSS bugs in IE (from the CSS Pointers page)
• CSS bugs in Opera (from the CSS Pointers page)
• Browser support for CSS from webreview.com (does not feature the latest versions of the browsers)

At the current stage in their development, digital TV and the Internet are too far apart in terms of philosophy and technology to integrate well. They may come closer in the future, but for now Internet-TV convergence is still a long way off and DVB-HTML won't do a lot to bring them closer.

To finish, I'd like to address a couple of final quotes: However, it is difficult to envisage practical applications which do not use DVB-HTML (Hypertext).

Actually, it's remarkably easy to envisage practical applications that do not use DVB-HTML. Take a look at the DVB booth in most major broadcasting exhibitions and you'll see them. Take a look at many other booths in a major exhibition and you'll see the same thing. The UK, which is probably the most advanced market for interactive TV right now, uses no HTML at all, except for TV-based web browsing: no application is written in any flavour of HTML.

You probably won't see any DVB-HTML applications, because most of the content developers and people looking at MHP are not looking at DVB-HTML. I've seen interactive advertisements, EPGs, enhanced sports broadcasts, VOD, online gambling, email, T-commence, online banking and many others, all implemented without a trace of DVB-HTML. I've written several of these myself. It's not just possible, but easier, because most of these applications need enough local processing that doing it in ECMAScript is harder than using Java for everything. If you find it ...difficult to envisage practical applications which do not use DVB-HTML, you need to take a harder look at the DTV industry.

However, the technical details of MHP may prove less relevant to its success that identifying a business model for multimedia content. Do people really want extensive interactive services, or just sit back and watch TV? Integrated PC/TVs have not been marketing successes in the past. (Conclusion)

Now this is somewhere that there will be no argument. A standard is only as successful as the number of people who use it. Without business models, the whole area of interactive TV is in jeopardy and not just one standard. Integrated PC/TVs can provide a valuable lesson to the industry: convergence will only be successful if both industries are moving in the same direction at the same rate. Mixing PC and CE equipment is risky because of the different rates of technology adoption. While software convergence is less risky than hardware convergence, both sides have to be aware of the risks and ask very carefully what is to be gained from it.

As Tom says in his conclusion, common tools may be used. Some content may also be shared. But a world where the web and the TV integrate seamlessly is a long way off. There are opportunities that we've not thought of yet, but there are also risks to Internet-TV convergence.