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.


Help Support Open Transcripts

If you found this useful or interesting, please consider supporting the project monthly at Patreon or once via Cash App, or even just sharing the link. Thanks.