This sounds complex (and details are!), but it is just same as person on Rock n Roll knowing to wait until they heard "over and out" before calling Jazz, and saying "over" at end of each sentence. If no one followed these protocols channel would have been chaos, everyone trying to talk over everyone else. In same way, if your computer and other computers on internet did not follow specifications, fact that your computer sends out some numbers over your phone line would be as useless as it sounds in first place! ... but, if rules are followed, it works.

I am not going to go into actual details of these specifications, but you have probably seen acronyms; TCP/IP and DNS (and a heap more!)

--* HTTP *--

Lets say that someone on Rock n Roll knows there is a football almanac onboard Jazz which will confirm score of a particular game and settle an argument onboard Rock n Roll. When Rock n Roll hears Jazz say "this is Jazz, go ahead, over" they know they have a connection to Jazz and can start a conversation. Rock n Roll might say "Jazz can you get me score of 1987 Superbowl, over", and Jazz comes back with answer finishing with an "over". Rock n Roll might ask for another score, or might ask for list of players, or might just say "thanks, over" and which point Jazz would say, "See ya, over and out".

--* http://Jazz/SuperbowlScore1987 *--

That is really what HTTP is doing. The connection has been made at lower separate layers which are handling numbers traveling out of your computer and moving them to computer you are connecting to. HTTP is a fairly simple specification that allows one computer to ask another for some information (by naming it), and for that information to be returned. It doesn't say anything about where that information comes from; as far as HTTP specification is concerned, somebody could be sitting at other computer typing in response. However, usually information that is asked for is name of a file, which is a bunch of numbers on hard drive. Those numbers get moved from hard drive into memory into modem and back to your computer.

Thats it! That is essence of HTTP.

The point is, to see why a geek can think something like HTTP is simple you need to think in layers like a geek. Thinking in layers is not some kind of zen like discipline for them, they probably do it without even being aware of it as that is what their tools and languages encourage. If a programmer was writing an HTTP program they may write something like:

LowerLayer connectTo: "Jazz". LowerLayer send: "GET SuperbowlScore1987". LowerLayer out.

The programmer who writes this is not thinking about details of how connection is established or how message is sent. They may have no idea! When they are working with HTTP they just assume lower layer works. If they, or you, do want to understand lower layer, then put HTTP out of your mind and read up on TCP/IP and DNS layers and specifications (have fun, and have a good supply of coffee ready).

Similarly, they are not trying to understand how information that is received is displayed so nicely in your browser. That is a higher layer and yet another specification (HTML).

I hope you enjoyed reading this article, it has taken an unusual perspective of HTTP! If you want to read up on details there are a number of good articles on web and HTTP specification itself.

However, here is where DRM currently falls down. The distribution and licensing can only be enforced in theory because in order to work, content has to be viewed / played on a device or with software that supports particular flavour of DRM that you wish to apply. For example, as soon as you allow a file to be burnt to a standard CD, you have lost all control of it and limitless copies can again be made.

We arrive at a strange Catch 22 situation, whereby DRM is useless unless everybody adopts same system, but people won’t start to adopt a system that restricts their use so severely in first instance.

The lack of widely available, reliable DRM is given by record industry as a main reason for not launching online distribution channels themselves. But DRM won’t become widely available until music industry adopts it for online distribution.

As more and more intellectual property and copyright is distributed through email and web, there is a greater need for a way of controlling this content. Slowly but surely, DRM technologies will become embedded into more and more software applications and hardware devices. As a recent example, Apple iTunes is an online music store which embeds DRM into songs downloaded. Microsoft Office 2003 also embeds DRM enabling technologies, as does Windows Media Player.

An overly restrictive DRM solution will scare consumers away from protected content; but if content can be distributed freely with no reimbursement for creator, then innovation and development and sharing of new and exciting ideas will be stifled.

In end, answer to issues surrounding DRM will have to be a delicate balancing act between consumers on one hand, and copyright owners and intellectual property creators on other.

This article is copyright Fire Without Smoke Software Ltd 2003. You may reproduce with appropriate credits intact.