Mly@AI.AI.MIT.EDU (Richard Mlynarik) (04/10/89)
Date: 9 Apr 89 22:00:01 GMT
From: mailrus!shadooby!accuvax.nwu.edu!nucsrl!gore@bbn.com (Jacob Gore)
Is there any particular reason why we have to enumerate every piece of
computer hardware in the world?
For instance, the domain application wants host type and OS type for the
hosts on which the domain's nameservers run. What on Earth for?
Re host type:
How else does my machine I determine what pathname syntax to use for the
host's filesystem?
How else can my machine determine how to interpret the idiosyncratic
results returned by such semi-standard things as FTP LIST?
How else can my machine attempt to try to compensate in advance for
well-known (but never repaired) bugs in implementations of
specific network protocols under specific operating systems?
TCP interconnectivity is increasingly a "least common denominator"
effort at the level of what various broken (usually unix)
implementations -implement-, rather than what the specifications
-specify-.jqj@HOGG.CC.UOREGON.EDU (04/11/89)
>How else does my machine I determine what pathname syntax to use for the >host's filesystem? >How else can my machine attempt to try to compensate in advance for >well-known (but never repaired) bugs in implementations I don't believe that very many existing implementations in fact use HINFO for this (or any other) purpose. In fact, I know of none; can someone correct me (maybe LispMachines?)? If what you care about is implementation bugs, then HINFO is the wrong level of analysis -- you don't care that a system is a MICROVAX-II running VMS, but that it is a VAX running VMS with Wollongong version 5.0SMP or whatever. The best way to find out about version-specific bugs in a particular instance of a service is to query the service on that host. For example, the herald when you connect to the SMTP socket on a host usually contains version information about the particular SMTP implementation: 220 hogg.cc.uoregon.edu Sendmail 4.0/SMI-4.0.1 ready at Mon, 10 Apr 89 12:59:35 PDT HINFO seems to me to be a holdover from late-1970s perceived needs as realized in HOSTS.TXT. In the present era it makes very little sense, and in fact many domain administrators are quite careless about keeping it up to date or making sure that the values are chosen from the (always out of date) legal list in assigned numbers (What value should I choose for a Mac-IICX running NCSA Telnet? No "Mac" value appears in RFC1010, but Macs are rapidly becoming the most common IP-speaking machine on our network). The proposal to delete HINFO makes good sense to me. On the other hand, it is often useful to humans (particularly people debugging the network) to be able to learn something about a foreign machine. I frequently find myself looking for the HINFO data about a misbehaving remote machine, then (when I find that there is no HINFO data, and perhaps not even a domain entry for the machine) I telnet to the machine to see what the telnet herald reports. If we really care about this data, the place to put it is in a new IP self-description service that a machine could offer; the machine, after all, is the most likely place for up to date data to be available! If it must be in the domain database, then making it a longer descriptive string rather than a forced-choice keyword would make it much more useful.
7thSon@SLCS.SLB.COM (Chris Garrigues) (04/12/89)
Date: Mon, 10 Apr 89 13:34:46 PDT
From: jqj@hogg.cc.uoregon.edu
>How else does my machine I determine what pathname syntax to use for the
>host's filesystem?
>How else can my machine attempt to try to compensate in advance for
>well-known (but never repaired) bugs in implementations
I don't believe that very many existing implementations in fact use
HINFO for this (or any other) purpose. In fact, I know of none; can
someone correct me (maybe LispMachines?)?
Yes, they do.
The best
way to find out about version-specific bugs in a particular instance of
a service is to query the service on that host. For example, the
herald when you connect to the SMTP socket on a host usually contains
version information about the particular SMTP implementation:
220 hogg.cc.uoregon.edu Sendmail 4.0/SMI-4.0.1 ready at Mon, 10 Apr 89 12:59:35 PDT
Basically true, but it isn't in a standardized machine readable form, so
my software can't automatically deal with it.
HINFO seems to me to be a holdover from late-1970s perceived needs as
realized in HOSTS.TXT.
HINFO and WKS are both useful pieces of data for systems which are
willing to make use of them. The Lisp Machine "Copy File" command uses
HINFO to figure out the pathname of the host it's dealing with and WKS
to figure out what file transfer protocol to use to get to the host.
This means that as a user I use the same command and don't have to care
if the system actually uses FTP, TFTP, NFS, NFILE, QFILE, PUP, or
whatever.
In the present era it makes very little sense,
and in fact many domain administrators are quite careless about keeping
it up to date
This is true, but is it an argument against the idea?
or making sure that the values are chosen from the
(always out of date) legal list in assigned numbers (What value should
I choose for a Mac-IICX running NCSA Telnet? No "Mac" value appears in
RFC1010, but Macs are rapidly becoming the most common IP-speaking
machine on our network). The proposal to delete HINFO makes good sense
to me.
Is your argument that your software doesn't make use of this data, so
therefore it shouldn't be available for those systems which do? What
ever happened to the philosophy of "Be liberal in what you accept and
conservative in what you generate"? This implication is that everybody
*should* provide as much info as possible, but nobody should be required
to ask for the info.
On the other hand, it is often useful to humans (particularly people
debugging the network) to be able to learn something about a foreign
machine. I frequently find myself looking for the HINFO data about a
misbehaving remote machine, then (when I find that there is no HINFO
data, and perhaps not even a domain entry for the machine) I telnet to
the machine to see what the telnet herald reports.
Fine for human debugging, but as users get more naive, this becomes less
desirable. Naive users shouldn't ever need to find out this
information. As it is, they call me to say they have a problem. I'd
prefer that their software handle it so I don't have to.
If we really care
about this data, the place to put it is in a new IP self-description
service that a machine could offer;
This idea, I like.
the machine, after all, is the most
likely place for up to date data to be available! If it must be in the
domain database, then making it a longer descriptive string rather than
a forced-choice keyword would make it much more useful.amanda@lts.UUCP (Amanda Walker) (04/12/89)
Hmm. You can look at a domain name server in two ways. The first is that it replaces the /etc/hosts file under UNIX, that is to say it provides the mapping between ASCII host names and IP addresses. This is currently its primary use most of the time, I admit. However, you can also look at it as a way to determine the attributes of hosts and domains, with the IP address being just one of the attributes. This is how I see it, and from my reading of the RFC, is how it was intended. There are often good reasons for needing to know more than just the IP address of another machine, and in some cases you need to know this even if the machine in question is down (MX records, in particular). A more general host information protocol (HIP? :-)) would be useful, but I still think that it wouldn't replace HINFO and MX records. Maybe we shouldn't need them (in some sense of ``should''), but the fact is that we often do, DNS as it stands does a pretty good job of solving the problem, and extensions such as Hesiod do the same thing for users, mailboxes, and so on. I don't mean to be flippant, but if you know a better way to do it, by all means implement it and write up an RFC... -- Amanda Walker <amanda@lts.UUCP> InterCon Systems Corporation -- "A keyboard ... how quaint!" -- Scotty, Star Trek IV: The Voyage Home