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

Malamud: This is Geek of the Week, and we’re talk­ing with Steve Kille, who’s President and CEO of the ISODE Consortium, which is—ISODE of course is the ISO Development Environment. Welcome to Geek of the Week, Steve.

Steve Kille: Thank you Carl.

Malamud: Why don’t you start and tell us what the ISODE Consortium is?

Kille: Well per­haps the first thing I should do is to talk a lit­tle bit about ISODE and what that is, and where it came from, and then I’ll talk about the con­sor­tium and what exact­ly it’s doing with ISODE. 

ISODE is a pack­age of soft­ware which is tar­get­ed par­tic­u­lar­ly at OSI appli­ca­tions, X.400, X.500, and was ini­tial­ly a research com­mu­ni­ty activ­i­ty to exam­ine OSI and to see if it was viable. There was con­tri­bu­tions from a wide range of envi­ron­ments. From Marshall Rose in par­tic­u­lar, who did a lot of the FTAM and the stacks asso­ci­at­ed with that. There were var­i­ous groups in the UK—my own group of University College London, and a group at Nottingham University who pro­duced the X.400 and the X.500. And became very much the widest-spread OSI imple­men­ta­tion. It’s been used a lot in the research com­mu­ni­ty. And it was becom­ing suc­cess­ful on the research side, and there was also quite a bit of inter­est on the com­mer­cial side. But there were firms that were inter­est­ed to use this tech­nol­o­gy as a basis for prod­ucts. In fact sev­er­al of them did. 

But in gen­er­al, being a research project and a research activ­i­ty it real­ly was­n’t posi­tioned right for that sort of devel­op­ment. And so the real moti­va­tion behind con­sor­tium was to take this research devel­op­ment and put it in a posi­tion where it was appro­pri­ate that prod­ucts and ser­vices based on this tech­nol­o­gy could appear. And there was a real frus­tra­tion among sev­er­al of the peo­ple doing this that we had some tech­nol­o­gy that was excit­ing and inter­est­ing and in many sens­es bet­ter than any­thing that was avail­able com­mer­cial­ly, but yet we weren’t real­ly able to sell strong­ly in the com­mer­cial environment.

Malamud: So the code was there but it was­n’t bul­let­proofed, it was­n’t pro­duc­tion qual­i­ty code. Was that the problem?

Kille: The bul­let­proof­ing and issues of pro­duc­tion qual­i­ty were ini­tial­ly I think to an extent that… There’s always an image of research code. And in fact ISODE in many aspects was a very good indeed, although there are some that could do with a lot of improve­ment. I think that the more sig­nif­i­cant thing is that if you’re going to build a prod­uct, you want to have some­thing that’s going to be there in five years’ time, in ten years’ time. You don’t want to be tying your­self to piece of tech­nol­o­gy that’s a research project that’s going to van­ish. You won’t have an orga­ni­za­tion there that’s going to be able to back it, pro­vide the sup­port you need as a devel­op­ment orga­ni­za­tion. But also it’s going to be there, it’s going to add in the func­tion­al­i­ty to track the stan­dards, and to put in all the new things that as a ven­dor of OSI prod­ucts you want to have.

Malamud: So did you take ISODE out of the pub­lic domain and you’re sell­ing it now?

Kille: We… The tech­nol­o­gy that we’re tak­ing is no longer pub­lic domain. But our release is avail­able under license to com­mer­cial orga­ni­za­tions. The mech­a­nism by doing that is that you join the con­sor­tium to buy access to the tech­nol­o­gy. And then as an OSI ven­dor you would pay an addi­tion­al roy­al­ty to the consortium—not a large roy­al­ty, but suf­fi­cient to give the con­sor­tium a con­tin­ued exis­tence and so we can put the resources that are need­ed to make this tech­nol­o­gy happen.

The rea­son that we chose the con­sor­tium approach rather than the more con­ven­tion­al com­mer­cial struc­ture was that I think ISODE has become quite a spe­cial imple­men­ta­tion in the research world. And it would have been unfor­tu­nate I think to do a straight com­mer­cial­iza­tion and in some sense let the pub­lic domain tree rot because there are a lot of peo­ple in the research com­mu­ni­ty that’re using and are run­ning ser­vices on ISODE. And in very many ways it’s that usage in the research com­mu­ni­ty that’s ISODE’s real strength rather than just being a stack that’s been test­ed in the lab and has been bench­marked against all var­i­ous con­for­mance tests and has lots of good ticks asso­ci­at­ed with it, it’s some­thing which has been demon­strat­ed in the real world, it’s been field test­ed, and peo­ple are using it for their day-to-day work. And so from a com­mer­cial point of view it’s impor­tant, because you see this as sort of a mar­ket­ing pub­lic­i­ty, you get field test­ing, and some­thing which none of the oth­er OSI vendors—the Retixes and the [Marvins?] and so on—they real­ly can’t offer that. It give the via­bil­i­ty, it gives a user ori­en­ta­tion for the technology.

But I think also on the research side you know, we have the research her­itage. And I think it’s impor­tant that we have, as the con­sor­tium, a higher-level mis­sion in terms of pro­mot­ing this tech­nol­o­gy and to make it avail­able. And for that rea­son I think that the link­age with the research com­mu­ni­ty is impor­tant. So we allow research orga­ni­za­tions to join our con­sor­tium, and the mem­ber­ship is a some­what low­er costs than would be for a com­mer­cial orga­ni­za­tion that’s going to base prod­ucts on the technology. 

We’re also going to pro­vide a zero-cost dis­tri­b­u­tion for two research orga­ni­za­tions. And we’ll be doing an online dis­tri­b­u­tion that’ll be encrypted-source. And all that a uni­ver­si­ty or a research insti­tu­tion needs to do is send us a fax sign­ing that they will take good care of the code, and then we’ll return a key and they’ll be able to use the tech­nol­o­gy from the ISODE consortium.

Malamud: Do they have to give you any enhance­ments they make to the code so you can use them for your distribution?

Kille: No, there’s no such require­ment. There are con­di­tions about what is done with the code. We in par­tic­u­lar want­ed to pro­tect against a sit­u­a­tion where a com­pa­ny makes use of a uni­ver­si­ty to do its soft­ware devel­op­ment. I don’t think that’s an appro­pri­ate thing to do. But in gen­er­al the com­pa­nies or orga­ni­za­tions are encour­aged to do what they like to do with the code. They can keep things for their own inter­nal usage. 

Universities in par­tic­u­lar are also able to put things they do rel­a­tive to the con­sor­tium released into the pub­lic domain. And I think that for advanced devel­op­ment that’s a more appro­pri­ate way to han­dle them than for the tech­nol­o­gy just to try to be put back. So we’re not try­ing to squir­rel things back into the con­sor­tium, we’re try­ing to facil­i­tate research activ­i­ties and advanced developments.

I think in very many ways the con­sor­tium is a tech­nol­o­gy trans­fer orga­ni­za­tion. We’re tak­ing this base tech­nol­o­gy for the X.400 and the X.500 in par­tic­u­lar from the research side and we’re putting it over as an appro­pri­ate prod­uct base. And we’ll con­tin­ue to take a flow of tech­nol­o­gy. I mean in par­tic­u­lar the X.509 secu­ri­ty activ­i­ties that’re going on from var­i­ous research ini­tia­tives at the moment, we’ll like­ly take from those and then we’ll make them avail­able com­mer­cial­ly. And I see that as an ongo­ing mod­el for the work­ing of the ISODE consortium.

Malamud: You men­tioned peo­ple using ISODE in their day-to-day work. Can you give me some exam­ples of that? Do you use it, for example?

Kille: Yes, absolutely.

Malamud: Do you have an X.400 address when I send you mail?

Kille: I do not use X.400 address­ing. I use X.500 to look up infor­ma­tion. I use a mail­er which has X.400 sup­port. And so I use an RFC 822 mail­box for my for my day-to-day work. But I use X.400 gate­way­ing capa­bil­i­ties of our MTA to access cer­tain X.400 ser­vices and that means com­mer­cial peo­ple who’re work­ing with X.400, and it means researchers, in par­tic­u­lar in Europe, who’re start­ing to move from RFC 800 back­bone onto an X.400 back­bone service.

Malamud: Is it fair to say that the vast major­i­ty of the uses of ISODE are X.400 and X.500? Are there many FTAM users, for example.

Kille: The major­i­ty of usage is X.400 and X.500. There are cas­es where the FTAM is used. I think par­tic­u­lar­ly some of the European coun­tries have found that the FTAM pro­vides access into cer­tain archives which they come get at using FTP. But that’s more an issue of the lower-level con­nec­tiv­i­ty than the par­tic­u­lar ser­vices often offered by the FTAM.

Malamud: ISODE start­ed out as an exper­i­ment. And basi­cal­ly the idea was ​“Let’s take the upper lay­ers of OSI with all that rich func­tion­al­i­ty and build it on the low­er lay­ers of TCP/IP.” And so we’ve kind of ripped out the low­er lay­ers of OSI, and we we’ve got a cou­ple appli­ca­tions on the top, but we’ve got these fair­ly com­plex, fair­ly large set of code that’s in ISODE. Is all that over­head worth it? Is this an effi­cient way to be doing these appli­ca­tions of direc­to­ries and messaging?

Kille: That’s an inter­est­ing ques­tion. And I think that there are cas­es where the answers is yes and there’s cas­es where the answer is no. I think par­tic­u­lar­ly for the X.400, the per­for­mance over­head of the lay­ers is not an issue. That you’re estab­lish­ing a con­nec­tion, and you can imple­ment the code very straight­for­ward­ly and effi­cient­ly. And rather than argue about well we could tune it, we could do some­thing a lit­tle bit sim­pler that was doing the same job, it real­ly isn’t that sig­nif­i­cant an issue when we have the stan­dards and the spec­i­fi­ca­tions there, there’s an agree­ment so we might as well use them.

The X.500, I think there are some envi­ron­ments where it is fine. I think par­tic­u­lar­ly for DSA/DSA inter­con­nec­tion where DSAs will very often main­tain permanently-open con­nec­tions, the over­heads are accept­able. I think for DUA to DSA com­mu­ni­ca­tion, par­tic­u­lar­ly where DUAs are going to be run­ning on small machines, or are going to be inte­grat­ed into oth­er appli­ca­tions to use the X.500 sup­port, the over­heads of the full stack X.500 are too high. And and I think the mod­el which the con­sor­tium is pro­mot­ing for that, and which is gain­ing increas­ing com­mer­cial accep­tance is using a pro­to­col called LDAP, the Lightweight Directory Access Protocol, which pro­vides a much sim­pler pro­to­col imple­men­ta­tion but gives access to almost all of the X.500 ser­vices. And so you can build a sim­ple user agent on a Mac or on a PC, and you can con­cen­trate on pro­vid­ing sort of a good graph­i­cal and inter­ac­tion, rather than build­ing a pro­to­col engine.

Similarly, if you want to inte­grate X.500 into an appli­ca­tion so you can do some name lookup and some basic search­es in the con­text of anoth­er appli­ca­tion you can link in a rel­a­tive­ly small LDAP library. And that will give you access into an X.500 DSA, and then beyond that the X.500 infra­struc­ture will work in the wide area to give you the ser­vices that you need. And you have the con­sen­sus of the inter­na­tion­al stan­dards for access out­side of the research community.

Malamud: You talk a lot about X.500. And X.500 if you look at the inter­na­tion­al stan­dards is the direc­to­ry. It’s the glob­al direc­to­ry, start­ing with a route which is actu­al­ly run at your for­mer home, University College London and goes down from there to the rest of the world. Some peo­ple that look at resource discovery—Professor Michael Schwartz at University of Colorado for exam­ple, argues that is not a scal­able solu­tion and X.500 just won’t work in the long run. What do you think about the role of X.500? Is it going to be the directory?

Kille: I believe that X.500 and a frame­work based on X.500 will be the direc­to­ry. There’s an inter­est­ing dis­tinc­tion, though, between the direc­to­ry and the only tech­nique for doing resource dis­cov­ery. I think Professor Schwartz is doing some very inter­est­ing work at Colorado. And I see it as very much a com­ple­men­tary rather than as an alter­na­tive to X.500.

In many ways if you’re look­ing for things and you’re try­ing to do resource dis­cov­ery, you need to index to access things in a very wide and com­plex set of mech­a­nisms. And there isn’t going to be one right or one tech­nique to do that. That you’ll be using techniques—databases, index­ing, and approach­es which are going to be tai­lored to the prob­lem that you’re try­ing to solve, that’s going to give access to data­bas­es or to infor­ma­tion sources which are going to be help­ing you to solve your problems. 

I see the X.500 infra­struc­ture as some­thing rather more low-level from that. But despite being lower-level it’s prob­a­bly a more impor­tant part of the basic infra­struc­ture for build­ing net­work ser­vices. The rea­son why I think you’ll want to have a sin­gle glob­al direc­to­ry is exact­ly the same rea­son that you want to have a sin­gle tele­phone ser­vice. I mean if you imag­ined try­ing to find a tele­phone num­ber via resource dis­cov­ery, that you ahd to some­how know which tele­phone ser­vice some­body’s using and it’s a pre­req­ui­site to be able to call them, it would be quite hope­less. You basi­cal­ly need to have a scheme where there’s effec­tive­ly a sin­gle glob­al num­ber space which defines all the tele­phones in the world so you can pick up a tele­phone with a lit­tle bit of infor­ma­tion on how you get the local access, but beyond that you can basi­cal­ly take some­body’s local tele­phone num­ber and you can call them.

And I think you need exact­ly the same basic nam­ing frame­work for com­put­er resources so that a per­son or a com­put­er can be labeled in a glob­al frame­work. I mean, the Internet com­mu­ni­ty does sim­i­lar things with the DNS scheme. It’s used in the research and oth­er aspect of the Internet world for label­ing resources, but I think that the X.500, because of its posi­tion­ing and because of the addi­tion­al func­tion­al­i­ty is going to be the cor­rect direc­to­ry ser­vice for the broad­er com­mer­cial world.

Malamud: Will X.500 replace the Domain Name System?

Kille: I believe in the long term, yes it will. I think that there will be a long coex­is­tence, and I think that there are cer­tain aspects of the DNS par­tic­u­lar­ly in the short term and par­tic­u­lar­ly with­out the Lightweight access pro­to­cols where it would not be appro­pri­ate to use X.500 as a plug replace­ment. But I think in the long term, as the size of the world grows and you try to encom­pass a large num­ber of peo­ple, that the frame­work and the polit­i­cal accep­tance of X.500 will cause it to suc­ceed. I think you can think of the DNS as sort of anal­o­gous to a com­pa­ny phone sys­tem which has got nice short num­bers because the com­pa­ny is small­er and it’s con­ve­nient to use. But in the long term you’re going to move to a nationally-defined tele­phone service.

Malamud: How long’s it gonna take to get that glob­al infra­struc­ture in place, where we can actu­al­ly use X.500 as a way of find­ing names, or pub­lic keys, or things of that sort? Is this a five-year rollout?

Kille: It’s prob­a­bly longer than that. But…it isn’t a tech­nol­o­gy prob­lem. In the tech­nol­o­gy, we can under­stand how to build direc­to­ry servers today. I think it will be exact­ly the same sorts of prob­lems, and in many ways much worse than build­ing the ini­tial tele­phone sys­tem of get­ting the col­lab­o­ra­tions and con­nect­ing things togeth­er. There are a lot of very seri­ous prob­lems with build­ing a direct­ly ser­vice, and one is the issue of mul­ti­ple ser­vice providers and that it isn’t pos­si­ble for direc­to­ry to be run by one per­son. You’ve got to allow com­pet­ing orga­ni­za­tions to share in the pro­vi­sion of those ser­vices. And so they have to be both com­pet­i­tive in the sense that they can com­pete with each oth­er and bring in dif­fer­ent cus­tomers, but there also has to be a mea­sure of col­lab­o­ra­tion so that over­all, as with the tele­phone ser­vice you have a sort of sin­gle num­ber space which can be referred to.

Then per­haps a much more stronger prob­lem, you have to define nam­ing struc­tures that, you have to have a reg­is­tra­tion ser­vices where orga­ni­za­tions can get names which will either be new allo­ca­tion mech­a­nisms or as is being pro­posed by the North American Directory Forum is basi­cal­ly lever­age off a civ­il infra­struc­ture to get name allo­ca­tion from names that have been assigned already. And then you have to plug in, you have to take data which is in what­ev­er exist­ing sources and to coerce it into this infor­ma­tion frame­work that’s pro­vid­ed by X.500. And the infor­ma­tion frame­work is one of the strengths and one of the weak­ness­es of X.500. In fact it’s going to be a prob­lem that’s going to occur with any rea­son­ably rigidly-defined direc­to­ry ser­vice. The strength is that when you have it in place, a user of the direc­to­ry ser­vice has this very clear mod­el of the data that’s in there so it can pro­vide a qual­i­ty and uni­form and a very sophis­ti­cat­ed access to this because the infor­ma­tion is [typed?], so it can access dif­fer­ent types infor­ma­tion, it can present them in dif­fer­ent ways.

But the flip side of that is you have to take your exist­ing infor­ma­tion, you have to coerce it into this for­mat. And as I’ve said, real infor­ma­tion is very much a mess. It’s not neat­ly laid out and struc­tured. It’s all over the place. And to take it and to bring it into this for­mat is ini­tial­ly very much a lot of work. And then to be there in a way that it will be main­tained and updat­ed. And it’s not going to be as sort of an ad hoc effort, some­body does it one evening and it stays there. It’s some­thing that’s got to become a part of the process of oper­at­ing the direc­to­ry ser­vices and oper­at­ing the busi­ness, so that when you make changes to…somebody arrives on the staff or some­body moves offices, that as a part of the man­age­ment pro­ce­dure the infor­ma­tion gets changed and the direc­to­ry gets changed as a con­se­quence of that.

Malamud: Well, what are the chances of that actu­al­ly hap­pen­ing on a con­sis­tent basis? Of peo­ple real­ly main­tain­ing their data, and of this glob­al set of coop­er­at­ing direc­to­ries actu­al­ly being put in place? It’s obvi­ous­ly a desir­able goal, but is it some­thing we can realize?

Kille: You will real­ize it because as the usage of it grows, and as more data gets put into the direc­to­ry, that the ben­e­fits of main­tain­ing it and keep­ing it up to date become very much stronger. And you’ve seen this on a small­er scale at the uni­ver­si­ty where I was at. And when I arrived in the in the depart­ment ini­tial­ly, that the mail sys­tem was very much an ad hoc approach, and there were some peo­ple who were in there and some peo­ple weren’t. And the data was basi­cal­ly main­tained by some­body inde­pen­dent of the depart­ment. And over that peri­od we’ve moved to a much more sys­tem­at­ic approach. When some­body arrives they get put into the data­base, and that as a con­se­quence cre­ates them an account and cre­ates them in the mail­ing entry sys­tem. So it basi­cal­ly becomes a part of the way the sys­tem oper­ates. And that’s impor­tant, because the mail infra­struc­ture is a part of the way peo­ple do busi­ness. You can’t actu­al­ly work effec­tive­ly in the depart­ment with­out hav­ing mail. 

Malamud: But you also had an insti­tu­tion and peo­ple that were will­ing to go through that process. Is it fair to think that oth­er insti­tu­tions will be sim­i­lar­ly con­sci­en­tious in keep­ing their data up to speed in the database?

Kille: I think… The anal­o­gy, and the impor­tant one, is it’s when there is suf­fi­cient ben­e­fit to be gained from it. That if it’s only…the only rea­son that you try to keep the data up to date is to main­tain the X.500 direc­to­ry it’s not going to hap­pen. That in itself is not a goal. But when it becomes part of the way of doing busi­ness; that you find that the direc­to­ry infra­struc­ture is being used for rout­ing and deliv­er­ing mail which are rely­ing on it; it’s used to the fax­es; it’s part of the man­age­ment infra­struc­ture; it becomes an essen­tial part of the busi­ness oper­a­tion that any­body in the depart­ment is cor­rect­ly reg­is­tered in the direc­to­ry because it’s not just an extra lookup of peo­ple in the depart­ment, it’s just part of the way that the depart­ment, the orga­ni­za­tion, does busi­ness. And at that stage it’s not that peo­ple want to do it, it just becomes part of the way of oper­a­tion. And that’s the way that the direc­to­ry will oper­ate effectively.

Malamud: I’ve heard two the­o­ries. One is that the rea­son X.400 isn’t more wide­ly deployed is because we’re wait­ing on X.500 to be there as a sup­port basis. And what I just heard you say is that X.500 will be more wide­ly deployed when X.400 is used more. Is that a bit of a cir­cu­lar argu­ment there?

Kille: I did­n’t think that I ever intro­duced X.400 in there. I said mail ser­vices and infra­struc­ture. I used mail as an exam­ple of the rea­son why this sort of tech­nol­o­gy is going to become impor­tant and to per­me­ate. But the real dri­ving thing behind the X.500 is not mail per se but things that need a direc­to­ry infra­struc­ture in order to oper­ate. And that’s going to be an increas­ing num­ber of office applications.

Malamud: Public key cryp­tog­ra­phy, for exam­ple, is based on cer­tifi­cates being stored in some form of a direc­to­ry. Is that an exam­ple of a basic ser­vice that needs X.500?

Kille: That’s a very good exam­ple, yes.

Malamud: And do you think maybe pub­lic key cryp­tog­ra­phy and Privacy-Enhanced Mail will be the thing that will spark X.500 usage? Because obvi­ous­ly cer­tifi­cates do you no good unless you have some­place to get them from.

Kille: I think that Privacy-Enhanced Mail will not be deploy­able until X.500 has been deployed. But I think the means that they’ve defined at the moment, they use all the X.509 cer­tifi­cate infra­struc­ture and the way that X.500 says how do you do secu­ri­ty, but it shies away from using the full X.500 direc­to­ry. But that means that you can do the mech­a­nisms of PEM with­out X.500. But in fact to deploy it, if you want to find some­one’s cer­tifi­cate in a sys­tem­at­ic way, I think there’s going to be a lot of prob­lems. And so…you know, it’s a good exam­ple of an appli­ca­tion that would be facil­i­tat­ed by the pres­ence of an X.500 directory. 

I guess I don’t believe, unlike some peo­ple, that there is some sin­gle course what’s going to mean that X.500 will be deployed. And the real ben­e­fits of X.500 is it’s some­thing that can— It’s a very gen­er­al and flex­i­ble direc­to­ry ser­vice, and it can be used to solve a broad range of prob­lems. And it’s going to be the sum rather than the indi­vid­ual that real­ly is the strength in the long run. That it’s been com­ment­ed if you want just to do white pages lookup, you would­n’t use X.500 because you could do some­thing tar­get­ed at that par­tic­u­lar prob­lem pret­ty much…much much sim­pler. But if you are going to build an infra­struc­ture with X.500, you solve this, and then sud­den­ly you have a frame­work where­by you can solve an increas­ing range of dif­fer­ent problems. 

And at the OSI DS work­ing group on Monday this week, we were look­ing at the use of X.500 for solv­ing a whole range of reg­is­tra­tion and man­age­ment prob­lems. And I think if you had some­thing which had been tar­get­ed at white pages you would­n’t be able to talk about that sim­ply because you did­n’t have a frame­work that was well-enough defined and exten­si­ble to be able to go down that path. And I think it’s going to be as we start to build X.500 infra­struc­ture we’re going to be able to lever­age off a whole range of addi­tion­al services. 

Malamud: You care­ful­ly sep­a­rat­ed X.500 from X.400. And you very care­ful­ly talked about the glob­al direc­to­ry. Are we gonna have the glob­al mes­sag­ing sys­tem based on X.400, or are we gonna see mul­ti­ple mes­sag­ing pro­to­cols, con­nect­ed with gateways?

Kille: I think that we’re going to see both. Gateways—

Malamud: Global and local.

Kille: Gateways are a real fact of mes­sag­ing life. And… As I’ve seen mes­sag­ing evolve, peo­ple run wide ranges of dif­fer­ent pro­to­cols. And the only thing I can see that’s going to mit­i­gate against that is that when­ev­er you run a gate­way you get prob­lems. You get man­age­ment issues with the gate­way. You get loss of func­tion­al­i­ty across the gate­way. And so there is a lot of oper­a­tional ben­e­fit from work­ing in a homo­ge­neous rather than a het­ero­ge­neous envi­ron­ment. Although, the real­i­ties of doing that are very dif­fi­cult at the moment. 

I think that X.400 is def­i­nite­ly going to become the glob­al mes­sag­ing back­bone. I think the rea­sons for that is it’s polit­i­cal­ly posi­tioned right. It is a rich ser­vice, and by offer­ing a back­bone ser­vice which has got rich fea­tures you’re going to allow any­thing else to con­nect onto it effec­tive­ly. It has an address­ing struc­ture which although awk­ward deals quite effec­tive­ly with the prob­lems of mul­ti­ple ser­vice providers. And in a com­mer­cial world, if we’re going to move away from a mod­el where you basi­cal­ly have a net­work infra­struc­ture and the mail just runs over it with­out any real mail ser­vice sup­port— And that mod­el works fine for research orga­ni­za­tions and for peo­ple that are tech­ni­cal­ly aware, I think it works much less well for peop—for orga­ni­za­tions which are not so tech­ni­cal­ly aware. I think that the ben­e­fits of doing your remote inter­con­nect through a mail ser­vice provider and hav­ing some­body look­ing after your mail ser­vices rather than just oper­at­ing SMTP over the net­work are quite sub­stan­tial. And for that, you have to have mail ser­vice providers and you have to have com­pe­ti­tion and mul­ti­ple ser­vice providers.

Malamud: There have been exten­sions to the SMTP base. There’s an SMTP exten­sion for bina­ry trans­fer. There’s the MIME def­i­n­i­tion of dif­fer­ent body parts and dif­fer­ent char­ac­ter sets. Doesn’t that address many of the issues of the feature-rich aspect of X.400?

Kille: In terms of pro­vi­sion of local ser­vice, absolute­ly it does. And I think some­body who goes and says you should use X.400 because it has fea­tures X is onto a los­er because if you’re oper­at­ing some oth­er pro­to­col, be it Microsoft Mail, be it SMTP, you could go and you could add that fea­ture. And because you have a much tighter envi­ron­ment you could prob­a­bly do it in a way that’s clean­er and sim­pler than the way it’s done with X.400.

The strength of X.400— It is feature-rich, and that means that what­ev­er you’re doing you have in it a way that you can gate­way it through. So you’ll be able to make use of the back­bone. You don’t have a prob­lem— If had got a low-feature back­bone, you would not be able to do that. 

And the sec­ond is the polit­i­cal posi­tion­ing of it. That it is a stan­dard that is rec­og­nized and will give a frame­work that the oper­a­tors and the inter­na­tion­al ser­vice pro­vides will rec­og­nize as pro­vid­ing the back­bone. And I’m just not con­vinced but in an inter­na­tion­al frame­work that orga­ni­za­tions are real­ly want­i­ng to rec­og­nize SMTP as the way of working.

Malamud: Why is that? What why is the—the stan­dards com­ing out of the IETF, why are those stan­dards not being rec­og­nized polit­i­cal­ly as being appro­pri­ate or fair, or some­how inter­na­tion­al and endorsed?

Kille: It will depend where you sit. I think if you are a gov­ern­ment orga­ni­za­tion in Europe it’s going to become issues of change con­trol, who your orga­ni­za­tion are, what they’re rep­re­sent­ing. And that then reflects onto orga­ni­za­tions— I mean, if I was a large chem­i­cal orga­ni­za­tion in Europe, I want to see things which— I’m not in the busi­ness of doing research or work­ing with the research com­mu­ni­ty, I want com­mer­cial ser­vice pro­vi­sion, and I want to look to the stan­dards that are going to be adopt­ed by the com­mer­cial ser­vice providers. And that’s why— 

Malamud: But does­n’t that mean we end up with a com­pro­mise stan­dard. Instead of get­ting the best we can, we’re try­ing to bring things down to a low­est com­mon denominator?

Kille: I think there is def­i­nite­ly a mea­sure of that. In any stan­dards process, be it an IETF one or an ISO one, there is always com­pro­mise. But there is a need with­in what­ev­er your con­stituen­cy is to achieve a com­pro­mise between the par­tic­i­pants. Research com­mu­ni­ty stan­dards have exact­ly the same prob­lem. It’s usu­al­ly their con­stituen­cy is some­what small­er so the mea­sure of com­pro­mise is not as large as usu­al­ly has to be gone through for inter­na­tion­al standards. 

So, I don’t think it’s an issue of per­fec­tion. No stan­dards are per­fect. They’re going to be the result of com­pro­mise, and it’s a ques­tion more of ade­qua­cy. Has the stan­dard got fun­da­men­tal tech­ni­cal rea­sons why it’s unac­cept­able? Or is it some­thing which is basi­cal­ly there and able to do the job. And I think both X.400 and X.500 amply sat­is­fy the cri­te­ri­on of meet­ing what’s need­ed to do the job. Sure, you could go and spec­i­fy some­thing that would do the job bet­ter. You could do improve­ments on it. But you’re look­ing at things where could change details here, we could clean out some of these fea­tures to make some­thing that was more focused and would tar­get bet­ter onto the prob­lems that I’m solv­ing. But you would­n’t come in and say there are such fun­da­men­tal defi­cien­cies here that we real­ly can’t use this stuff. There are very clear demon­stra­tions of both X.400 and X.500 that they’re per­fect­ly viable and man­age­able and usable solutions. 

Malamud: So by accept­ing those com­pro­mis­es, you’re see­ing the abil­i­ty to scale this out to a big­ger network.

Kille: Exactly.

Malamud: You see a trade­off there between the two.

Kille: Exactly. And over the last year I’m see­ing a lot of move­ment in com­mer­cial X.400. I think a lot of firms are talk­ing very seri­ous­ly about X.400 solu­tions. That they find that using things such as the cc:Mail, and the PC solu­tions, and it’s those rather than the Internet-based solu­tions that are the moment are the most seri­ous com­mer­cial com­pe­ti­tion to X.400.

The Internet has by large much less pen­e­tra­tion into orga­ni­za­tions. They see the polit­i­cal need for X.400 and we’re start­ing to see prod­ucts that are of accept­able qual­i­ty in terms of deploy­ment with­in orga­ni­za­tions. Most orga­ni­za­tions mov­ing down that are accept­ing that the X.400 and X.500 prod­ucts or not yet of the qual­i­ty that they are see­ing from their PC ven­dors but see the ben­e­fits of strate­gi­cal­ly set­ting that path and then push­ing on their sup­pli­ers to pro­vide the X.400 and the X.500 solutions.

Malamud: Is the Internet going to be the under­ly­ing infra­struc­ture that this X.400 back­bone runs on, or are we going to see anoth­er net­work of net­works form?

Kille: I think that’s that there will be a range of under­ly­ing tech­nolo­gies. But it’s my belief that the Internet TCP/IP is going to be the dom­i­nant inter­con­nect tech­nol­o­gy. I don’t think it’s going to be the dom­i­nant inter­con­nect in the way that the Internet researchers have want­ed and hoped that the pic­ture there would be this sin­gle con­nect­ed IP Internet with every­body in the world linked onto it. I think that it just isn’t like that and most com­mer­cial orga­ni­za­tions have far too much para­noia to allow some­thing at the pack­et lev­el to pen­e­trate into the orga­ni­za­tion. So we’re going to see com­mer­cial orga­ni­za­tions run­ning TCP/IP net­works but with­out exter­nal con­nec­tiv­i­ty. That the TCP/IP is an inter­nal solu­tion with appli­ca­tions that will gate­way to the exter­nal world. So inter­nal­ly you would X.400 and X.500 oper­at­ed over TCP/IP, and then con­nect­ed out over pub­lic providers.

Malamud: So you agree with Dave Clarke’s vision that with­out ade­quate secu­ri­ty, adequate—other improve­ments in the Internet we end up with a world of application-level gate­ways, and you see those being X.400-based?

Kille: I see those as being X.400-based, yes.

Malamud: Okay.

Kille: I also think that X.500 will for some orga­ni­za­tions at least be an accept­able entry because they will use it basi­cal­ly as a means of pre­sent­ing their vision of the world. It won’t be lists of all their employ­ees, but it will be the peo­ple they would want to pub­lish in a tele­phone book that they would allow peo­ple out­side the orga­ni­za­tion to see basi­cal­ly as a means of facil­i­tat­ing com­mu­ni­ca­tion with the orga­ni­za­tion, not as a means of pub­lish­ing the entire struc­ture and peo­ple in the organization. 

I think the secu­ri­ty thing at the net­work lev­el is not some­thing of detail. It’s actu­al­ly much more fun­da­men­tal. That before some­thing as low as a pack­et or an arbi­trary con­nec­tion pen­e­trat­ing from some­where out­side into the orga­ni­za­tion onto some work­sta­tion with­out the bound­ary of the orga­ni­za­tion hav­ing a very tight con­trol over what is going on, is just unac­cept­able. But mail is a much more con­strained thing. It’s basi­cal­ly like a pack­et arriv­ing at the door of the orga­ni­za­tion, and the orga­ni­za­tion accepts the con­tents of the pack­et. There’s no com­plex inter­ac­tion or pen­e­tra­tion of facil­i­ties. So that is real­ly is a much more accept­able means for most orga­ni­za­tions of how they operate.

Malamud: Thank you very much. We’ve been talk­ing to Steve Kille, and this has been Geek of the Week.

Malamud: This has been Geek of the Week, brought to you by Sun Microsystems, and by O’Reilly & Associates. To pur­chase an audio cas­sette or audio CD of this pro­gram, send elec­tron­ic mail to radio@​ora.​com.

Executive pro­duc­er for Geek of the Week is Martin Lucas. Our sys­tem admin­is­tra­tors are Curtis Generous and Rick Dunbar. Our pro­duc­tion man­ag­er is James Roland.

Geek of the Week is made pos­si­ble through the gen­er­ous sup­port of our spon­sors, includ­ing Sun Microsystems and O’Reilly & Associates. Network con­nec­tiv­i­ty for Geek of the Week is fur­nished by UUNET Technologies. This is Carl Malamud for the Internet Multicasting Service.

Internet Talk Radio, flame of the Internet.