Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!HOGG.CC.UOREGON.EDU!jqj
From: jqj@HOGG.CC.UOREGON.EDU
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  HINFO
Message-ID: <8904102034.AA05495@hogg.cc.uoregon.edu>
Date: 10 Apr 89 20:34:46 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38

>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.