Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SLCS.SLB.COM!7thSon
From: 7thSon@SLCS.SLB.COM (Chris Garrigues)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  HINFO
Message-ID: <19890411182849.3.7THSON@GLOWWORM.LispM.SLCS.SLB.COM>
Date: 11 Apr 89 18:28:00 GMT
References: <8904102034.AA05495@hogg.cc.uoregon.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 66


    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.