Carl Malamud: Internet Talk Radio, flame of the Internet.

Malamud: This is Geek of the Week. We’re talk­ing to David Crocker, who’s a mem­ber of the tech­ni­cal staff at Silicon Graphics. You may know David as the author of the famous Request For Comment 822, which defined elec­tron­ic mail as we know it today. Welcome to Geek of the Week, David.

David Crocker: Thank you.

Malamud: Well, why don’t you tell us about 822. Why did we need to write down the for­mat of a mail mes­sage? I mean, these things all look dif­fer­ent. do we need to stan­dard­ize this?

Crocker: Well, that effort in fact was the first RFC that declared itself to be a stan­dard. And so it is an exam­ple of your ques­tion in the gen­er­al form, why do we need stan­dards. And the answer is ini­tial­ly we had­n’t had one. There was a for­mat that Bolt Beranek and Newman was using, and even­tu­al­ly some­body asked them doc­u­ment it and they wrote that in an RFC. And then peo­ple start­ed play­ing with it; they start­ed mak­ing changes. And as always hap­pens when you have inde­pen­dent efforts, they made incom­pat­i­ble changes. And so by about 19…early 1977, it was clear that we had some com­mon­al­i­ty of phi­los­o­phy but no com­mon­al­i­ty of detail. And sev­er­al of us were com­mis­sioned to go work on that, and RFC 733, which was the pre­de­ces­sor of 822, came out at the very first Internet—well, back then ARPANET—doc­u­ment that declared itself to be a stan­dard, much to the cha­grin of many of the ARPANET people.

Malamud: Was that con­sid­ered bad, to be me mak­ing stan­dards and telling peo­ple what to do?

Crocker: Telling peo­ple what to do was the key point. It was­n’t that it was pop­u­lar. It was that it declared itself to be a rule that every­one had to fol­low. Back then, there was a much more anar­chis­tic view, much more demo­c­ra­t­ic view, which was that if you wrote some­thing that was good then I’d choose to use it. And if the next guy chose to use it that was fine, too. But nobody was going to tell me that I had to use it.

Malamud: Well what’s wrong with that approach? I mean if every­one’ll kind of con­verge on a sin­gle way and things’ll either work or they won’t. Why do we need offi­cial standards?

Crocker: I think that…it’s a way of help­ing peo­ple to know what they should do. Because the real­i­ty is no one ever has to adopt a stan­dard just because it declares itself to be a stan­dard. And we have lots of exam­ples of things declared to be stan­dards that don’t get suc­cess­ful. So I think in fact it’s real ben­e­fit is a way of show­ing a con­sen­sus about a thing rather than real­ly mandating. 

Malamud: Now, RFC 822 is a fair­ly sim­ple thing as stan­dards go. Where do we go on the slip­pery slope between RFC 822 and X.400? Where do we stop in the middle?

Crocker: Boy, isn’t that a treat? Because back when we did 822, we very care­ful­ly kept it triv­ial. I mean the text body…I mean nobody would have ever viewed that as being a long-term solu­tion. And all of us expect­ed X.400 to be the one that took off. And so it was fas­ci­nat­ing to watch MIME, which start­ed as just a very focused effort to add a small upgrade to 822, end up being some­thing which has fea­tures that are in many ways as good, in some ways per­haps bet­ter, as X.400.

I don’t know how you know ahead of time whether you’re bit­ing off some­thing that’s too com­pli­cat­ed or too sim­ple. The Internet phi­los­o­phy has been to do things that are real­ly very imme­di­ate and look too triv­ial, they look too sim­ple, and end up instead being things that last a very long time. 

Malamud: Now, how has MIME moved beyond the orig­i­nal elec­tron­ic mail, and how will we move beyond MIME? I mean, what has been the pro­gres­sion of mes­sag­ing that you see?

Crocker: Well MIME…in a way, from com­put­er sci­ence and design stand­point, MIME is…offen­sive. I mean, it does mul­ti­me­dia encod­ing using text. I mean nobody would do that. 

Malamud: So you take a bina­ry file and you turn it in to ASCII for pur­pos­es of trans­fer, and to turn it back into bina­ry, is that what you mean?

Crocker: Right. Right. And the struc­ture infor­ma­tion, what you might think of as the envelop­ing or the way of dis­tin­guish­ing the dif­fer­ent parts of the mes­sage, is all done in text. And that’s not very effi­cient from a the­o­ret­i­cal stand­point, but it’s very effi­cient if you’re try­ing to get through lots of email gate­ways, many of which don’t like bina­ry data at all.

Malamud: Wouldn’t it make more sense just to tell the gate­ways to begin sup­port­ing mod­ern data types like bina­ry data?

Crocker: That would make a lot of sense. The trou­ble is going back to the ear­li­er point, you don’t get to tell these peo­ple. You can try to seduce them. And so MIME rep­re­sents an approach of seduc­tion. And in fact we went and— I was not one of the orig­i­nal advo­cates of this, but I think for the long term it’s the right idea. We went and we did upgrade the email pro­to­col SMTP so that it could sup­port bina­ry, but on an option­al basis. 

But you asked about MIME going beyond email, and I’m not sure peo­ple in gen­er­al under­stand that it’s com­ing to be more than email. It was orig­i­nal­ly done as a way of upgrad­ing the email body from a triv­ial text into this mul­ti­me­dia hier­ar­chi­cal won­der­ful thing. And instead what’s happening—not instead but in addi­tion what’s hap­pen­ing, is that it’s get­ting used for oth­er data trans­fer envi­ron­ments. It’s becom­ing a stan­dard way—and this is by de fac­to, nobody’s impos­ing it—a stan­dard way of encod­ing these kinds of objects in oth­er sit­u­a­tions. And so, peo­ple like the Gopher and World Wide Web ser­vices are tend­ing to adopt it.

Malamud: Okay. So we’ve tak­en mime and defined a series of body parts—

Crocker: Mm hm.

Malamud: —and ways of label­ing those body parts.

Crocker: Right.

Malamud: And you’re telling me that’s not being used just for elec­tron­ic mail, it’s also being used in menu-based resource dis­cov­ery, it’s being used in hyper­text markup languages—

Crocker: Right.

Malamud: —like the Web?

Crocker: Right. Right. My guess about where things are going, and I haven’t talked about this with a lot of peo­ple, is that MIME is in the process—and we’re very ear­ly days, so I could eas­i­ly be wrong on this. But I think MIME is going to become the real glob­al stan­dard for attach­ing things to each oth­er that are oth­er­wise rel­a­tive­ly inde­pen­dent. Whereas it sure looks like SGML​’s becom­ing the way to com­pos­ite objects, putting togeth­er a bunch of small­er things to make one inte­grat­ed whole, like a doc­u­ment. Whereas MIME is a way of attach­ing col­lec­tions of documents. 

Malamud: David Crocker, we’ve been talk­ing about MIME and mul­ti­me­dia mes­sages. We’ve been look­ing at the SGML stan­dard for mark­ing up text. We’ve been look­ing at the MIME stan­dard for label­ing the dif­fer­ent body parts. This sounds like a lot more than my father’s email mes­sage. Does elec­tron­ic mail look like it’s going to be the basis for let’s say doing busi­ness trans­ac­tions on the Internet?

Crocker: Well, that’s my view. And it’s the sub­ject of some very intense debate right now. I’ve got­ten involved in the most applied-focused aspect of using the Internet for com­merce, called Electronic Data Interchange, which is a col­lec­tion of busi­ness stan­dards. It has noth­ing to do with the Internet. It was devel­oped out of in fact the MIS depart­ments of the world rather than the dat­a­com depart­ments. And they are cur­rent­ly using a vari­ety of data com­mu­ni­ca­tion ser­vices, and there are some peo­ple in the EDI com­mu­ni­ty look­ing at using the Internet. 

My view is…and I’m not alone in this, that using email is the eas­i­est entrée to the Internet, because it is so used to get­ting through lots of incom­pat­i­ble some­times, mis­be­hav­ing gate­ways, both email gate­ways and oth­er kinds. But there are oth­er peo­ple who want to use file trans­fer, and in fact there are some peo­ple talk­ing about build­ing their own EDI pro­to­cols direct­ly to run on top of TCP.

Malamud: I’ve nev­er under­stood this. EDI has been out there for years. And I’ve nev­er under­stood why it’s so com­pli­cat­ed to put togeth­er a few stan­dard labels and say ​“This is a pur­chase order. It’s to this per­son, it’s from this per­son, it’s for this much. Here’s the date.” Slap it in a mail mes­sage, and off it goes. What’s the big issue with EDI?

Crocker: And the answer—my answer to your ques­tion is I don’t know. I’m try­ing to learn. I am…confused, as you’ve just said, about the com­plex­i­ty. I under­stand some of the phi­los­o­phy of why it’s com­pli­cat­ed, and then because busi­ness­es con­duct them­selves in dif­fer­ent ways, and my busi­ness which might be the same— I might be a com­peti­tor of yours, but I run it dif­fer­ent­ly, and there­fore need cer­tain kinds of infor­ma­tion that’s dif­fer­ent from yours. 

What I don’t under­stand is why in the paper world we can do just what you said. I could call you up on the phone and say, ​“Do you have a widget?”

And you say, ​“Yes, send me a pur­chase order.”

I send you a pur­chase order. And you send me back the wid­get with an invoice. And I pay you back. In paper we do very lit­tle nego­ti­at­ing about the details of what goes on my pur­chase order or your invoice. And yet for EDI they’re in the stage which seems to require nego­ti­at­ing a lot of the details. I’m very very new to this, and it’s clear there’s a great deal of work that’s been going on. There is in the US a stan­dards body called X12 that’s been work­ing on this stuff for about fif­teen years—

Malamud: Well maybe it’s time for them to quit and hand it over?

Crocker: Uh…

Malamud: I don’t want to be harsh here, but would it take fif­teen years to— Because I don’t see EDI out there a lot. I mean, I know there are some cor­po­ra­tions using it. But it’s not a general-purpose tool used in the busi­ness world.

Crocker: Oh, they think it is. And there’s enough of them— The Internet stan­dards process has grown from about a hun­dred peo­ple in 1989 to 600 now. And we hold three-time-a-year meet­ings. It turns out X12 holds three-times-a-year meet­ings, and they have a thou­sand peo­ple show up. So, in fact they’re quite large. There’s a lot of mon­ey involved, both in a lit­er­al sense of what’s trans­ferred back and forth and then the soft­ware costs and ser­vice costs because there’s providers for EDI gate­way­ing; value-added net­works do that. And start­ing to think about putting things over the Internet may impact that.

Malamud: Now I could see a cou­ple issues that might require some­thing besides just general-purpose mail. Obviously Internet mail is not secure. 

Crocker: Mm hm.

Malamud: At all.

Crocker: Mm hm.

Malamud: And it’s not guar­an­teed delivery.

Crocker: Right.

Malamud: Aaand, if you don’t define the inside of the pack­age, what the EDI pur­chase order looks like, you’re not going to be able to machine process that incom­ing mes­sage, at least not nec­es­sar­i­ly. Are those areas that the Internet is going to ever be able to address? Secure, reli­able deliv­ery of well-formatted information?

Crocker: Well, you’re list­ing just the right issues. Security is the top of the hit list. And a guar­an­teed deliv­ery is not as crit­i­cal because it’s a data com­mu­ni­ca­tions pro­to­col and they have acknowl­edg­ments and retrans­mis­sion. They care about reli­a­bil­i­ty on the net, but I don’t think it’s as crit­i­cal. Authentication and pri­va­cy and non-repudiation, or sig­na­tures, are absolute­ly the stop­ping point right now.

Malamud: How are we gonna solve those prob­lems? Do we have tech­ni­cal solu­tions to those problems?

Crocker: The line of think­ing that I’ve been try­ing to offer is that rather than go and invent the solu­tion for EDI, we should observe that for Internet email there’s already been a great deal of effort in that area, where Privacy-Enhanced Mail, PEM, is the stan­dards process approach to doing that. There are non-standards-process approach­es, such as PGP, Pretty Good Privacy, which uses almost the same tech­nol­o­gy but uses it in a slight­ly dif­fer­ent way.

Malamud: It does­n’t have a license.

Crocker: For exam­ple. There’s— 

Malamud: Now that’s an impor­tant point, though, because the tech­nol­o­gy you’re talk­ing about, Privacy-Enhanced Mail, is based on the RSA technology—

Crocker: And DES.

Malamud: —licensed by Public Key Partners.

Crocker: Right. And it’s also based on using DES. And the rea­son I’m men­tion­ing that is DES has been around, it’s well-accepted, but it’s sub­ject to export con­trols. And to the extent that the US wants to be com­pet­i­tive in our newly-aware glob­al envi­ron­ment, the fed­er­al gov­ern­ment pol­i­cy on export con­trols is very much get­ting in the way. 

Malamud: So DES is the Data Encryption Standard used for actu­al­ly encrypt­ing the data.

Crocker: Right.

Malamud: The pub­lic key tech­nol­o­gy is used in a very scal­able solu­tion exchang­ing authen­ti­ca­tion information.

Crocker: Right. There’s

Malamud: So one tech­nol­o­gy’s export-controlled, and the oth­er one is owned by a pri­vate cor­po­ra­tion. Is this real­ly some­thing we want to base a glob­al infra­struc­ture on? Does this make sense?

Crocker: I share your dis­com­fort about the privately-owned part. But it hap­pens that this is very spe­cial­ized tech­nol­o­gy to which there is no real com­pe­ti­tion. And so for asym­met­ric keys, which is what pub­lic keys allows so that I can keep a hold of my decod­ing part but give you some pub­lic han­dle to know that it’s real­ly my key, there’s no solu­tion oth­er than the RSA cat­e­go­ry approach, that I know of. And where­as much of the com­mu­ni­ty is uncom­fort­able with hav­ing to rely on that, oth­er peo­ple observe that Ethernet is anoth­er exam­ple of some­thing that was a pri­vate solu­tion that was used pub­licly quite successfully.

Malamud: So this is real­ly no dif­fer­ent than the Ethernet situation.

Crocker: I sus­pect the amount of mon­ey involved will be dif­fer­ent. But from a philo­soph­i­cal stand­point I think not.

Malamud: So what is stop­ping, then, from hav­ing secu­ri­ty? It’s obvi­ous­ly a road­block to doing com­merce on the Internet. What is stop­ping this train from mov­ing forward?

Crocker: The oper­a­tional aspects of doing general-purpose casu­al security—casual in the sense of with­out pri­or key exchange, with­out pri­or arrangement—

Malamud: Anybody knocks on my com­put­er and I know who they are.

Crocker: Right. —is real­ly tough. And it does­n’t look like, it does­n’t appear that it’s tough inher­ent­ly from a the­o­ret­i­cal stand­point. It’s tough from an admin­is­tra­tive stand­point. And get­ting in place a pub­lic sys­tem that allows send­ing these keys around is some­thing that has pro­gressed very very slow­ly. And in gen­er­al the use of secu­ri­ty tech­nol­o­gy seems to involve admin­is­tra­tive over­head that peo­ple aren’t usu­al­ly very expe­ri­enced with and there’s a lot of resis­tance to. So I think what it’s going to take in order to break through and get this as a general-purpose, reg­u­lar option in our data com­mu­ni­ca­tions exchanges is both changes in fed­er­al pol­i­cy, and a lot more oper­a­tional expe­ri­ence. And at the moment it does­n’t look like it actu­al­ly needs changes to the under­ly­ing technology.

Malamud: What kind of changes in fed­er­al policy?

Crocker: The chang­ing of the export con­trols, for which increas­ing­ly the secu­ri­ty com­mu­ni­ty, the body of peo­ple who spend their lives deal­ing with this tech­nol­o­gy, have been knock­ing on the fed­er­al gov­ern­men­t’s door try­ing to get that changed. And oh by the way also so has busi­ness. And in addi­tion to which the fed­er­al gov­ern­ment has just been pur­su­ing a pol­i­cy through some tech­nol­o­gy which is pub­licly referred to as ​“Clipper,” which is essen­tial­ly com­pet­i­tive as a dig­i­tal signature-based technology.

Malamud: It’s the hardware-based secu­ri­ty scheme that has the back­door in it so the fed­er­al gov­ern­ment with prop­er court orders can go in and look at data exchanges.

Crocker: Right. And this has been in devel­op­ment by the gov­ern­ment for quite a few years. I heard about it in ​’86. And it’s come to fruition from a tech­ni­cal stand­point. The fed­er­al gov­ern­ment has decid­ed to pur­sue it as a fed­er­al stan­dard and there­by require that those doing busi­ness with the fed­er­al gov­ern­ment sup­port this option. They are not trying—

Malamud: Now wait a minute. I remem­ber some stan­dards called GOSIP which said if you’re gonna do busi­ness with the fed­er­al gov­ern­ment you’ve got­ta have OSI, and that did­n’t go very far. Is Clipper gonna go any farther?

Crocker: Gosh I hope so. No, I mean I hope you’re right that it won’t go any far­ther. Because it— While I’m sym­pa­thet­ic to the con­cerns the fed­er­al gov­ern­ment is rais­ing about con­trol over var­i­ous odi­ous peo­ple, the real­i­ty is that the rest of the world, the com­mer­cial world in the US and all of the inter­na­tion­al world, are using oth­er tech­nol­o­gy, and it’s all in place. It has­n’t grown very large yet, but it’s all in place. And the fed­er­al gov­ern­ment is cre­at­ing an island with just itself.

Malamud: It sounds like this phi­los­o­phy of…“let it go a lit­tle bit lat­er” is the same phi­los­o­phy that the mul­ti­cast back­bone folks are using mov­ing audio and video over the net in a non-guaranteed, non-real-time envi­ron­ment. Does this kind of very sim­ple packet-switching paradigm…I mean is this kind of the big dif­fer­ence between us and the tele­phone company?

Crocker: Sure. By the same token, they have a long his­to­ry of mak­ing sure that real-time data gets deliv­ered in real time. And we turn out to be doing bet­ter at that than we have any right to expect. But we don’t have any expe­ri­ence actu­al­ly mak­ing guar­an­tees. That’s what the work on flows for exam­ple is try­ing to solve. 

Malamud: Is the tele­phone com­pa­ny and the Internet, are these dif­fer­ent infra­struc­tures? Is it the same thing? Are we fight­ing the tele­phone com­pa­ny? Are we dif­fer­ent lay­ers? Are we…becoming the tele­phone company?

Crocker: Given their size and giv­en ours I hope we’re not fight­ing. There are cer­tain­ly dif­fer­ent philoso­phies of tech­ni­cal devel­op­ment and dif­fer­ent philoso­phies of oper­a­tion that are at base. But as we see phone com­pa­nies start­ing to offer Internet ser­vice, I think that there will be some kind of convergence.

Malamud: Convergence, now who is gonna run this con­verged super­high­way? I mean, you work for Silicon Graphics. Presumably you’re try­ing to build the ulti­mate set-top box. On the oth­er hand I would assume that Microsoft is doing the same thing. But I would­n’t be sur­prised if Walt Disney Studios is try­ing to build a set-top box, or pro­gram it. What’s this new indus­try going to look like?

Crocker: It is I hope going to be a high­ly com­pet­i­tive indus­try as opposed to a highly-regulated one. And it is one in which I hope that the con­sumer has a wide range of options rather than hav­ing things dic­tat­ed by a local monop­oly or by the government.

Malamud: How do we ensure that?

Crocker: Well the Internet has proved to be I think a good exam­ple of how to do that. And I hope that that les­son isn’t lost. But your ques­tion goes more into the realm of busi­ness pol­i­cy and fed­er­al pol­i­cy that I have real lim­it­ed expe­ri­ence on, and so I become just anoth­er hall­way con­ver­sa­tion opportunity.

Malamud: Are you look­ing for…standard inter­faces? We’ve been hear­ing a lot about that from Congressman Markey, for exam­ple. Are we back to stan­dards again?

Crocker: That brings it back to a tech­ni­cal top­ic, and the answer is you’re absolute­ly right. That we fig­ure out where the points of exchange need to be, and we define—openly define—interfaces which spec­i­fy the ser­vice that cross­es that inter­face; in both direc­tions. And then we let who­ev­er wants to be on one side of the inter­face pro­vide ser­vice there, and who­ev­er wants to be on the oth­er side of the inter­face be a con­sumer of the service.

Malamud: So for exam­ple the set-top box and the under­ly­ing cable TV provider might be a point of interface.

Crocker: My per­son­al opin­ion is that long-term that will be what will hap­pen. I know that many of the cable providers are expect­ing that the set-top will be pret­ty much their cap­tive piece of tech­nol­o­gy, because it tends to—certainly in the ear­ly days now, it tends to be inte­grat­ed so deeply into their ser­vice offer­ing that there’s no way that they can decou­ple it in an open way. [crosstalk] My guess is long—

Malamud: Do you think it could be decoupled? 

Crocker: I’d guess long-term it will. And I know a lot of oth­er peo­ple do too.

Malamud: We’ve been talk­ing to David Crocker. This has been Geek of the Week.

Malamud: You’ve been lis­ten­ing to Geek of the Week, a pro­duc­tion of the Internet Multicasting Service. To pur­chase an audio cas­sette of this pro­gram, send mail to audio@​ora.​com. You may copy this file and change the encod­ing for­mat, but may not resell the con­tent or make a deriv­a­tive work. 

Support for Geek of the Week comes from Sun Microsystems. Sun, mak­ers of open sys­tem solu­tions for open minds. Support for Geek of the Week also comes from O’Reilly & Associates. O’Reilly & Associates, pub­lish­ers of the Global Network Navigator. Send mail to info@​gnn.​com for more infor­ma­tion. Additional sup­port is pro­vid­ed by HarperCollins and Pearsall. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by UUNET Technologies, and MFS DataNet.

Geek of the Week is pro­duced by Martin Lucas, and fea­tures Tungsten Macaque, our house band. This is Carl Malamud for the Internet Multicasting Service, flame of the Internet.