tcp-ip@ucbvax.ARPA (06/15/85)
From: Mike Muuss <mike@BRL.ARPA> [In responding to MRC's comments, I am reducing the distribution back down to the TCP-IP@NIC list] I don't believe that I implied that the TOPS-20 systems were doing anything wrong; it's just that they were where we ran into the problems. Yes, what BRL's mail systems are doing right now is perhaps somewhat distasteful, but rather than expending effort on improving the current table-driven software, I have directed that all implementation effort be focused on the transition to domain-based naming using domain servers & resolvers. We have a version of MMDF which operates with the domain server system currently in testing, and hope to begin using it in production fairly soon (at least against our own local domain server). Interestingly, in the current state of affairs, the nicname.ARPA syntax really isn't expected to be valid (because it is not in the table), but in the domain-server view of the world, this is a perfectly correct syntax. Our intention was to make it possible for our users to enter the new syntax as soon as possible, so that they could begin to get accustomed to it; this has been true for many months now. However, implementing this meant that we had to "infer" the valid set of nicnames for each host in the .ARPA domain by munging the table. The code that built our internal tables "KNEW" the format of the NIC tables, and thus our problem. At such time as the NIC reorders the tables to have the full (new) domain name of the host FIRST, our table-builder will break again, but hopefully we will have transitioned to using the domain servers by then, and have rid ourselves of our .ARPA tables all together! -Mike
tcp-ip@ucbvax.ARPA (06/16/85)
From: Rudy.Nedved@CMU-CS-A.ARPA Mike, You would have had more problems at least with CMU sites if it was not for the policy of being "liberal" with the garbage we get. Our mail receivers "correct" or "improve" return paths. In the case of BRL, we are always adding the canonical host name of the connecting host to the return path under the assumption BRL is yet another mail relay forgetting to add its name to the relayed mail it is handling... It should not be case that nickname.ARPA is a valid name and it is a unintentional side effect that nickname.ARPA works under the domain system...you will run into problems with places like CMU that will 1) flush all existing nikcnames, 2) have NIC point current canoncial names like CMU-CS-A.ARPA to have CNAME records to A.CS.CMU.EDU and 3) and change our official names to A.CS.CMU.EDU. For some reason, it really sounds like BRL went in and hacked there host table so nickname.ARPA would exist because there software simply appends .ARPA to the end of a user supplied name before looking it up. If this is the case and you are hoping that the domain system will further this hack...you are going to be in a big mess soon....look at Symbolics, CMU, Rochester, Berkeley, Rice, Purdue, CSNET..... -Rudy
tcp-ip@ucbvax.ARPA (06/16/85)
From: Joe Weening <JJW@SU-AI.ARPA>
From: HOSTMASTER@SRI-NIC
... version (#458) reverted the name field to the following format:
... :domain name (if any), official name.arpa, official name, nickname: ...
From: Mike Muuss <mike@BRL.ARPA>
At such time as the NIC reorders the tables to have the full (new) domain
name of the host FIRST, our table-builder will break again, but hopefully we
will have transitioned to using the domain servers by then, and have rid
ourselves of our .ARPA tables all together!
Consider yourselves broken. (Look at the PURDUE.EDU entries in table #458.)
The fix to use the NIC table correctly is absolutely trivial on most systems:
just make sure "." is a legal character in host names, use the first name in
the NIC table as the official name, and allow others as nicknames. It is
even easier than the kludge method, because no special handling of the
string ".ARPA" is needed. Most of us did this back in late 1983 when we
were asked to.
On the issue of nicknames in the ARPA domain: if you use the host table,
there are (almost) none, not counting the non-domain nicknames, but if you
query the official servers it appears that all of the non-domain nicknames
have been turned into nickname.ARPA forms. This is unfortunate; it would
be better to have the table and the name servers agree as long as the ARPA
domain remains. (Which might be a while, since Milnet hosts still need to
set a date for their conversion.) Presumably the nickname.ARPA forms have
not been added to the table because that would increase its size too much,
so I think they should be removed from the name server database as well.
Joetcp-ip@ucbvax.ARPA (06/18/85)
From: Mike Muuss <mike@BRL.ARPA> Actually, if you look carefully, you will notice that BRL is already registered as a second-level domain (BRL.MIL), and we are hard at work trying to do the *right thing* in the new context. This does not prevent us from having to continue to exist in the current environment for a few more weeks until we transition to the new version of our software. The real problem was not that the MMDF software itself didn't handle domains properly (it seems to), but instead that one lousy program which converted the NIC table into some internal tables (used in lieu of a domain server) was (and still is) somewhat demented. Looking forward to newer forms of suffering (but at higher levels) with domain servers... -Mike
tcp-ip@ucbvax.ARPA (06/18/85)
From: Ron Natalie <ron@BRL.ARPA> Jeez, end of subject please. Yes, the program at BRL was doing the wrong thing. You get screwed when you make shortcuts like this. Same thing happened to nearly every 4.2 site when the host BRL-ZAP was added. They wrote grammer rules to parse the table that were wrong, and the entry for that host was legal in the table spec, but caused the program to blow up. Guess who got all the complaints? Right, BRL and the NIC. The code probably never did get fixed at most sites as BRL modified their entry to complied with the 4.2 pinhead view on what the table looked like. Let's just move along to implementing the next specification (domains, such as they are), regarding this as a lesson to be learned. -Ron