P85025%BARILAN.BITNET@WISCVM.ARPA (Doron Shikmoni) (11/18/85)
(This should reply Ken Rossman's and Jon Solomon's recent notes). Before we go on with this issue, the distribution of this Mail exchange is getting a bit out of hand (and I guess some of you are already getting more than one copy of each...). I'd suggest to move it all to one list, and I think Header-People is the right forum - please correct me if I'm wrong and somewhere else is more appropriate. I'll accept anything as long as it's ONE LIST... Ken Rossman: I'll use your invitation for further debate.. RFC920-style addresses have all the properties you're pointing at. Yes. But it seems there's one thing you keep forgetting: Bitnet does not comply with DARPA RFC's (at least not for now). "Domain-style name has nothing specifically to do with specific networks or networking protocol (TCP/IP or ARPA)" (Ken Rossman) - this is only partialy correct. I'd agree it has nothing to do with TCP/IP and these layers of the networking machanism protocols. But you simply CAN'T say it's "network independent". It is such only as far as a network accepts and handles "things" like RFC920 (or RFC822, or anything). You wouldn't claim, I guess, that the RFC920-style addresses "should" be recognized and handled correctly by ANY arbitrary electronic Mail network. For one thing, the addresses you generate may even be *invalid* in "another" network. Gateway-ing Mail into a Mail exchange system X requires that you send in Mail that agrees with system X's internal rules and capabilities (at least pack it in an envelope). That's part of a gateway function - not just moving Mail files from TCP/IP system (or whatever) to RSCS/NJE system (or whatever). You simply can't jump in and say "you must follow MY rules". Domain names are NOT a standard rule in Bitnet. Yes, a host may have several addresses, dependent on the NETWORKING ENVIRONMENT. My host name is "Barilan" in Bitnet, yet some "Barilan.Bitnet@Wiscvm.Wisc.Edu" in the Internet. And this is NATURAL. And here we get to an important point: YES it would have been nice if Bitnet would support RFC920 (fully). YES it would be good and effective if we had a nice hierarchy of domain servers. YES it would be great if our mail software could handle these things properly. BUT ALL THESE ARE NOT TRUE. Not for the moment, and (if I'm guessing right) not in the near future. It may be right to follow DARPA community's footsteps in planning the future of Bitnet (and then, it may not..); but that's well beyond the scope of our discussions. Having a one-network "image" with cross-network addressing conventions is SF, yet. What we are dealing with is current Mail transfer. And the point raised was exchanging Mail between a domain-driven system (I guess you can now call CCnet this) and another system which does not support or use domains. Using domains in Bitnet is an old issue, discussed in a few Bitnet forums. Yet FACTS are that most Bitnet hosts today will not even recognize the ".Bitnet" pseudo-domain name, suggested for use a long time ago (please don't attack me on THAT one; I know ".Bitnet" contradicts the "independency" path taken by RFC920). FACT is that although a few Bitnet Mail software packages can recognize top-most domain names and make some (primitive) decisions - this is more a sort of a hack, with hardcoded tables and very little "intelligence". So you're coming now, saying "I KNOW I'm using the right philosophy" (which is probably correct), and changing a working environment into a non-working one. The net result of this, is that Bitnet users have lost the capability to use the addresses they receive to reply. They have to know (Jon Solomon), that when they see "user@CU20A.COLUMBIA.EDU", they have to send replies to "user@CU20A" (utilizing another system hack - since CU20A is also not a Bitnet site..). Some of the Bitnet Mail software packages can fairly easily be further hacked, to contain a list of ALL Columbia sites, with their "new" names and the Columbia Bitnet-CCnet gateway address (CUVMA). Some others will require a lot of effort for this hack. Is that "correct"? of course not. By the way: the ".Bitnet" pseudo domain name is used today in many places to relay Mail from Internet into Bitnet. Should this stop too ? NOW ? "it should work - NOW". I think that's a good guideline. Sure, you must be prepared for the future with a full scheme of implementation phases. Yet I think it's not to anyone's interests to bring working Mail exchange to a halt due to a "GOOD" addressing approach. But I'm repeating myself already (sorry - it's getting late..). Doesn't all this sound surprizingly similar to the fight that took place recently between (mainly) Berkeley and the military branch of DARPA about RFC920 implementation? the research community said "but it's good for us". The military side said "yeah - but it doesn't work TODAY, and I can't sit down NOW and rework my mail software". I guess that's enuf for now. But I'd appreciate if we could all think in a constructive direction and find out how this can be solved - to WORK, not just to be academically "proper". Columbia absorbed some fire for going first; it happens... Solutions, however, should be general. (I'm certainly not interested in "flaming" for its own - I really have better things to do...). Thank you for your time and patience Doron.
JSOL%BUCS20%bostonu.csnet@CSNET-RELAY.ARPA (Jon Solomon) (11/19/85)
No matter what direction is taken, significant rewriting of some parts of BITNET software will be required. That's life. Maybe we can set you on a direction that has proven useful for us. Conceptually the gateway responsibility issue is not new. Most of us have lived with the use of a % hack for years. My header is officially sepearated into "jsol%bucs20%bostonu.csnet"@"csnet-relay.arpa", abstractly: local-part@network-part. What is in the "network-part" must conform to the network standards, and what is in the "local-part" is open to negotiation (on a host by host basis). It is within the scope of the gateway to modify the headers to conform to each networks' protocols. The gateway adds or removes its name from the address and changes the last % to an @ (or removes the first @ leaving only one). This is considered messy, because it requires the gateway to parse the headers, nonetheless it is practical for the present. This will require changing the mail software not to use % as an indicator that the address should go to WISCVM. The software will have to parse the line and send the mail to the host indicated. Strictly speaking, this is probably the best you can do until someone comes along with a brilliant idea for a centralized name protocol (i.e. domains or something). Note: If using % is too complicated, you can use some other character(?) as the indicator for CCNET. Didn't mean to scorch you. Sorry. --JSol