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

This is Geek of the Week. We’re talk­ing to Bob Bob Kummerfeld, for­mer chair­man of the com­put­er sci­ence depart­ment at the University of Sydney, and one of the code­vel­op­er of a suite of mes­sag­ing pro­to­cols known alter­na­tive­ly as ACSnet, SUN3, SUN4, MHSnet. This sounds like the pro­to­col of many names. Welcome to Geek of the Week, Robert.

Bob Kummerfeld: Thanks Carl.

Malamud: What is ACSnet, or SUN3, and I guess I can see why you would­n’t call it SUN3.

Kummerfeld: Well, let me go back. We start­ed this devel­op­ment a long while ago in about 1979, 1980. And at that stage we want­ed to build a sys­tem to send mes­sages between our machines and machines of oth­er uni­ver­si­ties. And we called it the Sydney University Network. And it went through ver­sion 1, 2, 3. But unfor­tu­nate­ly anoth­er com­pa­ny start­ed up with a sim­i­lar acronym for their name, and so we had to change it from SUN to some­thing else. And more recent­ly it’s become MHSnet. The pack­age is a mes­sag­ing thing. It allows you to send bina­ry mes­sages of any size. And on top of that we built email, file trans­fer, and any message-oriented sort of service.

Malamud: Now, this sounds like a mix between many of the things that we know and love. UUCP[crosstalk]you know, the dif­fer­ent mes­sag­ing protocols. 

Kummerfeld: Mm hm. Yeah. Sure.

Malamud: How does this dif­fer let’s say from the Usenet mod­el which evolved around the same time?

Kummerfeld: Yep. Well, in fact UUCP was released in about 19— Well. Sorry, it escaped from Bell Labs in about 1979. And we looked at that and thought well, that’s real­ly ad hoc, maybe could do some­thing bet­ter. And that began the devel­op­ment. And it was real­ly a research project. But once again that sort of escaped out of our depart­ment and became much more wide­ly used. The sort of things that dis­tin­guish it from oth­er sys­tems are that it can send any bina­ry mes­sage of any size, over any sort of vir­tu­al cir­cuit. It has— 

Malamud: Any vir­tu­al cir­cuit. Do you build on top of exist­ing net­works, or vir­tu­al cir­cuit” do you mean under­ly­ing telex lines, for example?

Kummerfeld: Could be, yes. Anything that can get bits across. In fact the low-level pro­to­col adapts to the under­ly­ing cir­cuit, whether it be vir­tu­al or real. It can run over dialup lines, it can run over X.25, it can run over IP and TCP connections.

Malamud: This is very sim­i­lar to UUCP which can be run on top of TCP/IP

Kummerfeld: That’s right

Malamud: —on top of a tele­phone line—

Kummerfeld: Sure

Malamud: —on top of X.25.

Kummerfeld: Yep. 

Malamud: Okay.

Kummerfeld: But you know if— The low-level pro­to­col that we have does things like full duplex trans­mis­sion, which the orig­i­nal UUCP did­n’t do. It adapts to the under­ly­ing cir­cuit so that if you’ve got a noisy tele­phone line, it will increase the size of the pack­et and give bet­ter— Sorry, if you’ve got a clean tele­phone line it’ll increase the size of the pack­et, and you get high­er through­put. If you’ve got a noisy tele­phone line it will decrease the size and so get bet­ter through­put that way.

Malamud: And these are fea­tures that you had in the in the ear­ly 80s [crosstalk] or are these things that you just added last year.

Kummerfeld: Sure. Oh no no, these are things that were in in the ear­ly 80s. 

Malamud: Now what was built on top of this basic infra­struc­ture for mov­ing data?

Kummerfeld: Okay. Well, the low­est lev­el then is the node-to-node or machine-to-machine thing that runs above the vir­tu­al cir­cuit. But above that, we have a rout­ing lay­er, which decides the best store-and-forward path. Essentially it’s a store-and-forward net­work, just like UUCP. But above the node-to-node pro­to­col we have a rout­ing archi­tec­ture which will pick the best route through the net­work, and…then above that, you put your mes­sag­ing pro­to­col. And we used it, and still use it, for things like elec­tron­ic mail, for sender-initiated file trans­fer. So just as I can send you elec­tron­ic mail, I can also send you a file.

Malamud: Is this good?

Kummerfeld: I think this is a real­ly great thing to have. Because how do I send you a file if I don’t have this? What do I do? I have to encode it into say a MIME mes­sage… Not very con­ve­nient. Also, you end up with a huge elec­tron­ic mail mes­sage if it’s a bina­ry file. Or maybe I can use FTP but then I’ve got­ta put it in some anony­mous incom­ing” direc­to­ry some­where. Security might be a prob­lem there. Or I’ve got­ta have an account on your machine, so I can dump it into a direc­to­ry. It’s just not very con­ve­nient where­as with our sys­tem we say Send you the file.” 

Malamud: So as the orig­i­na­tor of Geek of the Week I can on an unso­licit­ed basis send every user a thirty-megabyte file—

Kummerfeld: Absolutely.

Malamud: Are they gonna be hap­py with this?

Kummerfeld: No, but I can send you a thirty-megabyte mail mes­sage… Well, maybe I can’t but I mean you know, you can send unso­licit­ed files—or mes­sages already, using oth­er mech­a­nisms. We just make it easier.

Malamud: Um, and what oth­er fea­tures are in the mail and mes­sag­ing part of the suite?

Kummerfeld: Well the mail is just RFC 822. Or now these days you can send MIME or what­ev­er. Because once it leaves our sys­tem it’s passed up to what­ev­er deliv­ery sys­tem you’ve got. Or to inject it into the the ser­vice, you can use what­ev­er user agent you have.

Malamud: So it’s stan­dard Internet mail, built on top of a dif­fer­ent…[crosstalk] transport.

Kummerfeld: Yeah. Different trans­port. A dif­fer­ent mes­sage trans­port, and I guess we don’t use SMTP. We use our sys­tem to do it.

Malamud: And does that still exist? Are there peo­ple in Australia [crosstalk] that actu­al­ly use this?

Kummerfeld: Oh yes. Yes. This fact went through…four revi­sions, the final one appear­ing in about 1988. And at that stage we still did­n’t have Internet in Australia. And at that time there were about 1,000 sites. Mainly in uni­ver­si­ties, but quite a few com­mer­cial ones as well. As the Internet has come on, of course, the ones in uni­ver­si­ties have gone away. Now there are still a few. Many peo­ple run it still because it’s so con­ve­nient to be able to send files around. But in fact the net­work is still grow­ing. Because there are now com­mer­cial sites that’re out there dialup lines. They can’t afford the IP con­nec­tion. It’s very expen­sive in Australia. And so there are still a lot of peo­ple using it.

Also, um…

Malamud: If you’re just doing mes­sag­ing, what is the lev­el of over­head of using the MHSnet pro­to­col as a way of send­ing mails ver­sus for exam­ple a typ­i­cal TCP/IP SLIP con­nec­tion? Have you mea­sured the dif­fer­ence in overhead?

Kummerfeld: We haven’t mea­sured the dif­fer­ence in over­head but what we’ve mea­sured is the per­for­mance dif­fer­ence. And in fact we do about 10% bet­ter com­pared to FTP on trans­fer­ring a file, in terms of throughput.

Malamud: And peo­ple are using it and you’re gate­way­ing it into the so-called core of the Internet, TCP/IP world. 

Kummerfeld: Sure.

Malamud: What are the issues in putting those gate­ways togeth­er? Do you lose any­thing on either side? 

Kummerfeld: Well, of course if you’ve got RFC 822 mail, then you don’t lose any­thing because it’s…it’s just that mes­sage no mat­ter what sys­tem it’s in. If it’s say, FTP, then it’s a lit­tle dif­fer­ent because, how do I gate­way to FTP for send­ing? In fact we have anoth­er mes­sage ser­vice built on top of this which allows you to fetch files. You can send out a small mes­sage which says Give me that file over there,” and it will send it back to you using the oth­er pro­to­col. And we built gate­ways with that to anony­mous FTP. And I tend to use that in pref­er­ence to anony­mous FTP because anony­mous FTP is inter­ac­tive, where­as what we have allows me to say, Get that file,” and then go on and do oth­er things. A lit­tle while lat­er a mes­sage pops up say­ing The file’s here,” and I go—you know, I’ve got it.

Malamud: There’s a com­mon wis­dom that says we’re all con­verg­ing on a com­mon set of pro­to­cols. Now there’s no common…feeling of what that pro­to­col is but we’re see­ing BITNET appear­ing to be going away—

Kummerfeld: Oh yeah. 

Malamud: —and the Internet core protocols. 

Kummerfeld: Sure.

Malamud: Do you think we’re gonna live in a world of a sin­gle com­mon set of pro­to­cols, or do you think—

Kummerfeld: No…no, I think there’s be a place for these sorts of things for a long while to come. And there’ll be new things which will pop up, and all things will go away. You know, we’ll have a mixed envi­ron­ment for…forever. That’s my opinion.

The MHSnet pack­age has gone. That has been com­mer­cial­ized and is now being used by the Australian gov­ern­ment to send mes­sages between its embassies and posts around the world. And the rea­son they chose it is because it will run over things like 55 baud tele­graph cir­cuits, which appar­ent­ly is all you can get into Mogadishu or some­where. And so there’s a place for oth­er such pro­to­cols, you know. IP and SMTP does­n’t work very well over 55 baud tele­graph cir­cuits. So I think there’s going to be quite a wide range of pro­to­cols and sys­tems around for a long while to come.

Of course, you know, we’ve moved on from this and— I should say before I go on that to give cred­it where cred­it’s due a lot of this devel­op­ment was done by my cowork­er Piers Lauder, and we’re con­tin­u­ing to work on pro­to­cols and net­works. This work real­ly fin­ished up in 1988. We haven’t done too much to it since then.

Malamud: Bob Kummerfeld, you’re the author of MHSnet and you pret­ty much com­plet­ed your work in 1988. But you’ve con­tin­ued work­ing on mes­sag­ing sys­tems. And I pre­sume that means you’ve been doing X.400 development. 

Kummerfeld: Ha. You’re jok­ing. Well in fact, in the ear­ly days I was quite attract­ed to the X.400 idea, and looked at it very care­ful­ly and con­tem­plat­ed doing some imple­men­ta­tion work. But then after look­ing at it in more detail I real­ized it was a very complex…just overkill…thing. And I dropped the idea entire­ly. And in fact I think the whole OSI mod­el has being now dis­cred­it­ed and is slow­ly going away. I think there are much sim­pler things to do. Much sim­pler ways of solv­ing the same problems.

Malamud: For example.

Kummerfeld: Well, we did it with the MHSnet. We could have branched off in the mid-80s and gone on the X.400 path. But I could see that it was just too com­plex, and so we end­ed up with three lay­ers rather than sev­en. And we end­ed up with very sim­ple mes­sage for­mats rather than a very complex—you know, P1P2.

Malamud: Is there any­thing good that we can get out of X.400, or is the fact that it’s all bun­dled togeth­er make the total effort a loss?

Kummerfeld: Um, I think actu­al­ly the total effort is prob­a­bly a loss. I’m sad to say, but I think…you know, there are things that just sound so obvi­ous these days. Things like the store-and-forward mod­el in gen­er­al. And the idea of admin­is­tra­tive domains and so on. I think those ideas are falling out in oth­er areas. And maybe we got that out of it, I’m not sure. 

Malamud: But things like the feature-rich con­ver­sion, and return receipts, and all the func­tion­al­i­ty. Isn’t this some­thing peo­ple want in their mes­sag­ing service?

Kummerfeld: Oh yes, sure. And those things are appear­ing in things like MIME…email in the Internet. There is now an effort to pro­vide the sort of receipts that peo­ple want, using MIME types. I think we’re going to get to the same func­tion­al­i­ty through a dif­fer­ent path.

Malamud: Um, are we going to see an explo­sion in store-and-forward ser­vices, or is this a par­a­digm who’s done and [crosstalk] we’re gonna go real-time and do phone calls?

Kummerfeld: No, no. Oh, no. I dis­agree with that entire­ly. I think there’s still a big future in mes­sag­ing. And in fact I think there’s a lot of hype these days about things like video on demand. I think that that will be avail­able, but only in a very lim­it­ed way. You’ve just got­ta think about the amount of band­width that’s required for these sort of on-demand, inter­ac­tive ser­vices. You just can’t deliv­er enough to ser­vice all the tele­vi­sion sets in America. Or even all the tele­vi­sion sets in a small town. There’s just not enough band­width. Instead we’re gonna have a mix of things, and I think mes­sag­ing will play a big part in that. You know, I would like to be able to have the equiv­a­lent of the video shop, so that I can say, Right, I want that par­tic­u­lar movie,” and gets deliv­ered, maybe not…immediately, but it will turn up on my home sys­tem in the next hour or so, or maybe tomor­row, or maybe next week depend­ing on how much I’m will­ing to pay. And I think that’s where mes­sag­ing and store-and-forward is going to be very impor­tant in the future.

Malamud: So deliv­ery of MPEG movies as mail messages.

Kummerfeld: Absolutely. Yes.

Malamud: What else do you think we’re gonna make our mes­sag­ing pro­to­cols do? MIME gives us a few hints, I think. There’s point­ers to exter­nal infor­ma­tion. There’s dif­fer­ent body parts that can be played simul­ta­ne­ous­ly, or can be played one after the oth­er. What are some of the oth­er things we can expect out of our mes­sag­ing pro­to­cols over the next few years?

Kummerfeld: Hm. Well…

Malamud: Obviously, if you knew all of that you’d be off imple­ment­ing it and mak­ing a for­tune, but give us some guess­es. What’s tomor­row’s email look like?

Kummerfeld: Um, well I think you prob­a­bly said it all just there, that things will become more com­plex, more struc­tured. You will be able to have, as we now have in MIME, var­i­ous media types—you know, audio, still pictures…

Malamud: What about EDI? Is that some­thing that we’re wait­ing on some break­through in order to be able to do elec­tron­ic data inter­changes in a mail message?

Kummerfeld: Yeah… Mmm, no I think that all the infor­ma­tion is there. There are oth­er var­i­ous pro­to­cols now around. We looked at EDIFACT, for exam­ple. There’s an effort in the IETF to come up with a way of encap­su­lat­ing EDIFACT mes­sages inside MIME-format email. I think all of the tech­nol­o­gy is there to be able to do EDI right now. 

Malamud: EDI has been a long time in com­ing. There’s over a thou­sand peo­ple involved in the ANSI X12 com­mit­tee, more than attend the IETF. It’s been—

Kummerfeld: Sure but this isn’t real­ly a tech­ni­cal issue and I think. I think it’s more of a busi­ness and a polit­i­cal and a legal issue. I think the tech­nol­o­gy is there and is not a prob­lem. I think it com­ing up with agree­ments that the lawyers can approve. I think that’s where the prob­lems are.

Malamud: Is the prob­lem the struc­ture of the pur­chase order, or is the prob­lem the secu­ri­ty and the reliability…

Kummerfeld: Security, reli­a­bil­i­ty, yes all those things. 

Malamud: That’s often been solved by build­ing a cus­tom value-added net­work specif­i­cal­ly for an EDI appli­ca­tion. Is Internet ready to begin deliv­er­ing this kind of work?

Kummerfeld: No, I don’t think so. But there is some won­der­ful efforts going on in the IETF to move it in that direc­tion. Thing like the Integrated Services Group just form­ing, and many oth­er groups—the secu­ri­ty groups, qual­i­ty of ser­vice, and all this sort of thing. I think the Internet will…even­tu­al­ly be able to pro­vide the sort of ser­vice guar­an­tees that peo­ple want. But at the moment it can’t. I think that’s obvi­ous. Anyone who uses the Internet on a reg­u­lar basis knows that from day to day per­for­mance can vary enor­mous­ly, that secu­ri­ty is a real issue. It’s okay 99% of the time, but I don’t my cred­it card to fall into some­one’s hands in that oth­er 1%.

Malamud: Well you know, in the real world my cred­it card 1% of the time falls in the wrong hand. And when I send a pack­age by Federal Express, it almost always makes it but some­times it doesn’t.

Kummerfeld: Yeah, that’s true.

Malamud: Are we expect­ing too much out of the Internet?

Kummerfeld: Well, I think what we’re doing is we’re com­par­ing to the tele­phone sys­tem. And how many times have you picked up the phone and not got dial tone? Very rarely—if ever. How many times have you dialed a num­ber and had a mes­sage back say­ing, Sorry, con­ges­tion in the net­work. I can’t put that call through?” [crosstalk] Very—

Malamud: Well I’ve lived in some coun­tries where that has hap­pened, but in the United States we cer­tain­ly don’t expect that, and Australia you don’t, obviously. 

Kummerfeld: No, no. Except on Mother’s Day or…well, any­way. So, I think that’s what we’re com­par­ing it to. We’re com­par­ing it to a net­work which is vast­ly overengi­neered in order to give you the guar­an­teed band­width at any time of the day or night. Whereas—

Malamud: Should the Internet be the same thing? I mean, phone calls are rea­son­able cost as a gen­er­al rule.

Kummerfeld: That’s because it’s an almost ubiq­ui­tous ser­vice, that every­body has one and every­body con­tributes a lit­tle, and so there’s a prof­it mar­gin there for some­one to wire the entire coun­try. And maybe when the Internet gets to that stage, and I think it will, then we’ll be able to engi­neer it to the extent that the phone sys­tem is.

Malamud: So is this a ques­tion of our pol­i­cy­mak­ers encour­ag­ing a pol­i­cy of uni­ver­sal ser­vice? Should we give this to one com­pa­ny so they’re able to give us uni­ver­sal service?

Kummerfeld: You mean the monop­oly sit­u­a­tion. Well, I’m not sure about that either. You know, I’ve seen the monopolies…both gov­ern­ment monop­o­lies and com­mer­cial ones. And unless they have some vision­ar­ies behind them, they tend to take the eas­i­est path to prof­its. And at the moment I’m not sure the Internet is the best path. I think what will dri­ve in that direc­tion is enter­tain­ment, con­ver­gence of the cable indus­try, telecom­mu­ni­ca­tions, tele­phone, and the com­put­er indus­try. HDTV, all of that. I think that’s what’s going to bring wide­spread net­work services—you know, the net­work ser­vice into every home. And then we’ll see the sort of overengi­neered, highly-reliable, large band­width at a low cost.

Malamud: And how does the Internet as we know it fit into this world of cable providers and HDTV, and some video on demand from your local neigh­bor­hood cable com­pa­ny? What’s the role of an inter­net­work in this con­verged world?

Kummerfeld: Well, it’s to car­ry every­thing as bits, rather than ana­log. And to car­ry pro­grams either in real-time or as mes­sages. So we’re send­ing video, we’re send­ing audio, and so on. But also to car­ry data, to car­ry text, to car­ry that sort of infor­ma­tion. So that we can do oth­er things. We can do the…what’s usu­al­ly quot­ed? The home shop­ping. We can type on our key­board and order some­thing we don’t real­ly want but…we’re attract­ed to it. That’s the rea­son for the inte­grat­ed ser­vices. That’s the rea­son for an Internet-style net­work into the home.

Malamud: The net­work can be a closed com­mu­ni­ty, what I call the sub­urbs of the Internet like CompuServe in which what you do is what’s on there—which is good; some peo­ple live in the sub­urbs for reasons. 

Kummerfeld: Mm, but they still get— You know, they still have the abil­i­ty to com­mute to oth­er areas. And unfor­tu­nate­ly with things like CompuServe… I’m not famil­iar with CompuServe but I under­stand that there’s a very lim­it­ed Internet con­nec­tiv­i­ty from CompuServe, per­haps only email. And I think that that is a real mistake. 

Malamud: How do we fix that mis­take? Do we hope peo­ple migrate into, or use mar­ket pres­sure to force our provider to do that?—

Kummerfeld: Yes.

Malamud: Do we pass laws and say if you’re going to pro­vide a net­work you must con­nect to oth­er networks?

Kummerfeld: Well, I’m not famil­iar with the his­to­ry of how the tele­phone sys­tem was built in the US

Malamud: What about Australia?

Kummerfeld: Well, Australia it was a gov­ern­ment monop­oly right from the begin­ning. And that had good and bad effects. One of the bad effects was that they were very con­ser­v­a­tive and are still con­ser­v­a­tive to some extent. They only pro­vid­ed ser­vices that were sort of site. But, they were able to wire the entire coun­try at a rea­son­able price. In the US I under­stand there were many many small phone com­pa­nies to begin with, and mis­match of stan­dards and there a need for reg­u­la­tion and gov­ern­ment, leg­is­la­tion, to get these peo­ple to con­nect up. So per­haps we need a sort of mix­ture of approach­es. We need some­thing like the fabled infor­ma­tion super­high­way that’s going act as the back­bone, and maybe that might be government-controlled, government-provided. And then we need all the small phone com­pa­nies out on the edges, pro­vid­ing local con­nec­tiv­i­ty like the cable com­pa­nies and so on. We need a mix­ture of things.

Malamud: Bob Kummerfeld, when we look at mes­sag­ing sys­tems, there is a com­mon wis­dom out there that says you have mes­sag­ing and you have direc­to­ries. This comes out of the once-proud OSI effort. But we hear that in many oth­er places. It’s com­mon in the trade press to say the Internet will only work when you can find some­body’s address. Are mes­sag­ing and direc­to­ries in fact cou­pled as [crosstalk] things that have to go together?

Kummerfeld: Oh yes. Well, they don’t have to go togeth­er but for exam­ple on our sys­tem we built a direc­to­ry ser­vice which was above the mes­sag­ing. You send off a mes­sage and it got poten­tial­ly mul­ti­cast out to var­i­ous servers that would then come back with an answer say­ing, Yes, this per­son lives out here,” or, I’ve got the infor­ma­tion.” [crosstalk] Very sim­ple system—

Malamud: Well, that would be helpful. 

Kummerfeld: It was a very sim­ple sys­tem. Part of the rout­ing archi­tec­ture of MHSnet allowed you to mul­ti­cast mes­sages. So you could send in an effi­cient way, a sin­gle mes­sage to many peo­ple. And so this allowed us to mul­ti­cast out to the—well, we called them whois servers but that’s a term which is already tak­en. But you could poten­tial­ly send it to mul­ti­ple places and ask for them to con­sult their data­base, which was just a flat file, and send back a result.

Malamud: Now why has­n’t what seems to be like such a sim­ple easy idea been moved into the Internet, for exam­ple on our whois data­bas­es? I have to man­u­al­ly go to each whois ser­vice and say­ing, Do you know about this per­son?” I can write a lit­tle shell script hack which search­es em, but it’s cer­tain­ly not a multicast-type application.

Kummerfeld: Well, it’s all to do with scale. And you know, we did­n’t push the idea any fur­ther. I think there cer­tain­ly is scope for build­ing these sort of dis­trib­uted data­bas­es in the Internet, using Internet-style technology—simple, straight­for­ward approach­es rather than com­plex ones.

Malamud: Is the Domain Name System what we should be using for our white pages ser­vice? Is that how we should find somebody?

Kummerfeld: No, I don’t think so. I think the Domain Name Service is built for a dif­fer­ent rea­son. You know, it’s built basi­cal­ly for address res­o­lu­tion. But some­thing like that…sure. And there are efforts here in the IETF to study this prob­lem and to come up with a uni­fied white pages ser­vice for the Internet. And per­haps it will involve using a mul­ti­cast, dis­trib­uted database.

Malamud: A uni­fied white pages ser­vice. Now does this mean a tree of direc­to­ries and chain­ing and those con­cepts from the X.500 world?

Kummerfeld: Mmm, yeah, I was going to say, it sounds like X.500. Possibly. Possibly.

Malamud: What’s anoth­er model?

Kummerfeld: Well, I’ll tell you, the prob­lem with X.500—and I don’t know what your expe­ri­ence is, but cer­tain­ly my expe­ri­ence is that when you ask for some­one’s address, you’re very often don’t find it because the serv­er, the leaf, in their orga­ni­za­tion is down. And that’s very com­mon in my expe­ri­ence. And so I think that push­ing all the infor­ma­tion right down to the end of the tree like that is prob­a­bly the wrong way to go. I think it would be bet­ter to have a small­er num­ber of large, well-maintained, reli­able servers that han­dle a real­ly large por­tion of the network.

Malamud: And do you allow…do you require the user to main­tain his or her own record, or you have some cen­tral reg­is­trar that does it for you?

Kummerfeld: Yes, now you’re get­ting to the nub of the prob­lem. I think the hard­est part of direc­to­ries ser­vices it keep­ing the direc­to­ries up to date. And peo­ple move and they for­get to change their entry. There are many prob­lems. Many many prob­lems in keep­ing the infor­ma­tion up to date. But, it can’t be run with a bunch of vol­un­teers. It has to be done pro­fes­sion­al­ly and with peo­ple who are ded­i­cat­ed to the task.

Malamud: There’s a pro­to­col by Mike Schwartz known as Netfind and what Netfind does—it’s not a pro­to­col, it’s some soft­ware; it’s a serv­er. And it basi­cal­ly punts. It says, No, we don’t have a direc­to­ry but we’ve got all these lit­tle bit­ty sources of infor­ma­tion and I’ll kind of root around and maybe find that per­son for you and maybe not.”

Kummerfeld: Sure. Try fin­ger and all those oth­er things. Yeah.

Malamud: Is that a bet­ter way of doing things, [crosstalk] that dif­fer­ent mod­el of…can that coex­ist with the directories.

Kummerfeld: Well that’s… Well, okay, that’s more the intel­li­gent agent-type mod­el, where you send off a request and it says, Okay well I’ll try this, I’ll try that, I’ll try some­thing else.” And you know, it’s a lay­er above the oth­er ser­vices. And that’s a use­ful thing to have as well. You know, there’s Vint Cerf’s Knowbot ser­vice, same sort of idea. But I think there’s a huge future for intel­li­gent agents like this, of all types, in the net­work. You know, find­ing infor­ma­tion for me. Or—

Malamud: And are these agents that are stored inside of let’s say a mail mes­sage as a safe Perl script or a safe Tcl script?

Kummerfeld: Mm hm. Could be, could be. There’s an issue of pri­va­cy here, of course. If I want to send my pref­er­ences out say­ing what sort of movies I like, maybe I would­n’t like peo­ple to see that. And so maybe what we have to do is to split it up and send out some of that infor­ma­tion say­ing what I want, but then have the final fil­ter­ing done back at your own machine.

Malamud: And so agents come and vis­it my machine and I look at whose agent it is and decide whether or not to tell you what movies I’ve been watching.

Kummerfeld: That’s right. Yeah, I think so.

Malamud: Is this just a pipe dream or is this actu­al­ly some­thing that we’re were close to be able to do?

Kummerfeld: No, this is an area that I’ve been work­ing on just recent­ly. In fact my wife Judy Kaye is also a com­put­er sci­en­tist and her area is user mod­el­ing. And we’ve been col­lab­o­rat­ing on some of these things. I’ve been look­ing at the dis­trib­uted nature and the pro­to­cols nec­es­sary to pass around these sort of requests. And she’s been look­ing at the user mod­el­ing angle, that part of it.

Malamud: What’s user modeling?

Kummerfeld: Ah, well. [crosstalk] You’ll have to— 

Malamud: Are these uses that kind of stand up and twirl around on a walk­way or.

Kummerfeld: You’ll have to inter­view Judy on this. Well, it’s basi­cal­ly keep­ing some infor­ma­tion about you—your likes and dis­likes and your knowledge—trying to build a mod­el of the user, of what the user knows. So—

Malamud: So my mod­el might for exam­ple say I don’t like receiv­ing mail, and your intel­li­gent agent would walk in and see that and…go away because it’s a polite agent.

Kummerfeld: Something like that. 

Malamud: Well there you have it. This has been Geek of the Week. We’ve been talk­ing to Bob Kummerfeld from the University of Sydney. Thanks a lot.

Malamud: This is Internet Talk Radio, flame of the Internet. You’ve been lis­ten­ing to Geek of the Week. You may copy this pro­gram to any medi­um, and change the encod­ing, but may not alter the data or sell the con­tents. To pur­chase an audio cas­sette of this pro­gram, send mail to radio@​ora.​com.

Support for Geek of the Week comes from Sun Microsystems. Sun, the net­work is the com­put­er. Support for Geek of the Week also comes from O’Reilly & Associates, pub­lish­ers of the Global Network Navigator, your online hyper­text mag­a­zine. For more infor­ma­tion, send mail to info@​gnn.​com. Network con­nec­tiv­i­ty for the Internet Multicasting Service is pro­vid­ed by MFS DataNet and by UUNET Technologies.

Executive Producer for Geek of the Week is Martin Lucas. Production Manager is James Roland. Rick Dunbar and Curtis Generous are the sysad­mins. This is Carl Malamud for the Internet Multicasting Service, town crier to the glob­al village.