What exactly is the difference between a “standard” and a “tech mandate”? There was some confusion today at the House hearing on the FCC’s efforts to promote a more competitive market in home video devices. (Here’s Harold’s written testimony from the hearing.)
There are a lot of kinds of “standards” out there—think auto emissions standards or weights and measures—so I’m not trying to come up with a comprehensive overview. In high tech industries, though, a “standard” is usually a method that helps different products interoperate. A standard might be an interconnection interface or a communications protocol. Standards might be required by the government, or they might be industry or de facto standards.
The AllVid adapter would serve as a point of interconnection between proprietary pay TV (MVPD) networks and home devices. Interconnection specifications are a typical kind of standard. Power adapters and phone jacks are standard points of interconnection. The Phillips head is one, too, allowing screws and screwdrivers to “interconnect.” Standard railway gauges allow trains to be used on a variety of different track systems. Communications protocols like the IEEE 802.11 suite, Internet Protocol, and Signaling System No. 7 (heck, maybe stdin and stdout) are standards, too.
A “tech mandate” is a much broader concept than a standard. A tech mandate goes further than a standard, and doesn’t just detail an interconnection point or communications protocol, but describes how the standard is going to be implemented. HTTP is a standard, and Apache is an implementation. If the FCC were to require that Apache be used instead of nginx or IIS, that would be a tech mandate. When the FCC tried to tell device manufacturers how their devices had to treat recorded content, that was a tech mandate, and not a standard. It had nothing to do with how video devices interconnected with the outside world.
The dividing line isn’t always totally clear. You might define an interconnection standard so precisely that there’s only one way to implement it. And after all, industry “standards” can be quite comprehensive. For instance, people who make Blu-ray players will soon be forbidden from including analog outputs in their players (the “analog sunset”). This won’t make players read Blu-ray discs better, or help them connect to TVs. It’s a tech mandate imposed on device manufacturers by the Blu-ray Disc Association.
While there might be edge cases, the output side of the AllVid adapter is clearly a standard and not a tech mandate. (The output will be standard and any third-party device can interoperate with it, but there can be plenty of nonstandard, proprietary and weird technology inside any given AllVid adapter, if that’s what’s needed to make it work with a particular MVPD. There will be no “one” AllVid adapter just as there’s no “one” kind of broadband modem; they will differ from MVPD to MVPD.) The AllVid adapter will be no more complex than necessary to allow third-party devices to communicate with MVPDs. Given that MVPDs differ significantly, it needs to be more complex than a phone or power jack, but the idea is the same. We keep using the broadband modem analogy, because it works: DSL, cable, and satellite broadband is all made available to home computers in a standard way. Your home PC doesn’t need to know about how the Internet gets to the home, because the broadband modem translates it into a protocol it already understands. This is what the AllVid adapter will do, but with MVPDs. It creates a point of demarcation between the home and the MVPD, and defines an interconnection standard. It doesn’t dictate the internal design or functionality of the devices that attach to it, or of MVPDs.
Sometimes the market arrives at interconnection standards by itself, and sometimes it doesn’t. It’s especially important that communications technologies, like MVPDs, be standardized. The FCC has been taking the right steps to get us there.