From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27965 invoked from network); 12 Mar 2021 01:15:05 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 12 Mar 2021 01:15:05 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 15E6D9C653; Fri, 12 Mar 2021 11:15:03 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id ABAEC9B615; Fri, 12 Mar 2021 11:14:23 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=mhorton-net.20150623.gappssmtp.com header.i=@mhorton-net.20150623.gappssmtp.com header.b="JYZx94Kj"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 68D359B615; Fri, 12 Mar 2021 11:14:20 +1000 (AEST) Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com [209.85.210.181]) by minnie.tuhs.org (Postfix) with ESMTPS id 6EFF995074 for ; Fri, 12 Mar 2021 11:14:19 +1000 (AEST) Received: by mail-pf1-f181.google.com with SMTP id b23so734085pfo.8 for ; Thu, 11 Mar 2021 17:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mhorton-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=yk8TS0stqzt9A4mNL1hUcFzs8os4/oiBxcXlrvIahr8=; b=JYZx94KjTo2m5cvZ7EG2kKO5moUY+K/asACME2E/Zf24fZWd+UznpnENyF7mIm5Gr2 Gx6m1at/tRyvsLY6NifJJMy8wSB8hS9NJhVNE1thF+tIJcEN9VXd2JcOnUuF1jVRC4uG LVsWcMiy5qqpJFeAFrG7tBG6WxOv2hdxYPBKiL9fXXFa9flrVn+axJsq8sExJunl9J9k iirzwsN0SPGuGTkPBkeoX63kSsASqXEuUN+GR756XQhGVsxu0aAtLGvvNTTxb2sX7Ora IEUW9LuHhZSLyejeCpQedmod9gnk4PiUDy2WSbgkxwpR/QSZMN99NrOwkYgqkt9iH6iK l7Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=yk8TS0stqzt9A4mNL1hUcFzs8os4/oiBxcXlrvIahr8=; b=h0xNLyDIuNbRpwMuHhY8HoR+l13SAlrbJpniaZbY7xxgwYsD+RD2R6Wg+UiCkfr8Hd ule3p/tBgrZJrGPVF2e4GcxHc1aCIL5B46b+5NdH4hzNh3REchKYh+Wb2Ksy8/PqGWtO jtBci+RD/i60X1i3MQemz9Id92Ys0nq3kSL3HY9pzZ1NBzIX2VkULxjAG/sJNeZIM5rJ 4YS8RhMhB+L35cPlQ+WXVn1qq+5Y1r/9WjeLvB7LIWIuGwzvYWBLbD9+j5vS/ILICmDK Nu3UQ8lQHstMOw6QW0gz6ks/B5s9gZTaueJIeL76qyNa76mX8IrRDB330qAgiuf8jUEE 1XWw== X-Gm-Message-State: AOAM531c6Ns18HU2w9MOm7aihsCCkzBTw1EgYIadwos9WxzoznotHvLL /fxCJt+8uqHYIcL86iUZ0ApcTOpKcaCDFw== X-Google-Smtp-Source: ABdhPJwyFG1zuWTzM5H4t8/Vwceto3hMDsKa8S3MK7IZSKdHYSmctpN/EffjjrYeLObVTRISB7sb+Q== X-Received: by 2002:aa7:808b:0:b029:1ce:8a32:f5e8 with SMTP id v11-20020aa7808b0000b02901ce8a32f5e8mr9988395pff.34.1615511658443; Thu, 11 Mar 2021 17:14:18 -0800 (PST) Received: from [192.168.1.12] (ip72-197-247-231.sd.sd.cox.net. [72.197.247.231]) by smtp.gmail.com with ESMTPSA id n5sm3430188pfq.44.2021.03.11.17.14.17 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Mar 2021 17:14:17 -0800 (PST) To: tuhs@minnie.tuhs.org References: <02d10a8e-2f39-4f88-f4c9-ecb295e0f01e@spamtrap.tnetconsulting.net> <555F9514-DD67-41F1-8151-480F0D9D0EAC@iitbombay.org> From: Mary Ann Horton Message-ID: <446e7c8d-01d6-6f86-3078-02e795b85ee8@mhorton.net> Date: Thu, 11 Mar 2021 17:14:16 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------83E35A2FE9DF88729C40367F" Content-Language: en-US Subject: Re: [TUHS] [COFF] Pondering the hosts file X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This is a multi-part message in MIME format. --------------83E35A2FE9DF88729C40367F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 3com.com was indeed illegal initially. We (the UUCP Zone) went to register it with the NIC and were told leading zeros weren't allowed, because some code might think a leading digit meant an IP address. I pushed back, they relented, and it was registered without a problem. On 3/11/21 1:08 PM, Ron Natalie wrote: > The "name" in this context the host/network/gateway name such as > SRI-NIC.ARPA.    3COM.COM would not have been legal back then. > Nowhere does it imply that any of the other fields are so restricted. > > ------ Original Message ------ > From: "Bakul Shah" > > To: "Ron Natalie" > > Cc: "The Unix Heritage Society" >; "Internet History" > > > Sent: 3/11/2021 4:02:50 PM > Subject: Re: [TUHS] [COFF] Pondering the hosts file > >> On Mar 11, 2021, at 12:32 PM, Ron Natalie > > wrote: >>> >>> Amusingly one day we got an Imagen ethernet-connected laser >>> printer.    Mike Muuss decided the thing should be named BRL-ZAP and >>> since I didn't know what to put down as the machine type, and it did >>> have a 68000 in it, I had Jake put 68000 in the entry in the host table. >>> >>> The next day I got all kinds of hate mail from other BSD sites who >>> assumed I had intentionally sabotaged the host table.  Apparently, >>> the BSD systems used a YACC grammar to parse the NIC table into the >>> Berkeley one.   The only problem is they got the grammar wrong and >>> assumed the CPU type always began with a letter.    There parse blew >>> up on my "ZAP" host and they assumed that was the desired effect. >> >> This is understandable as >> a) All the "official machine names" in various assigned numbers RFCs >> start with a letter. >> b) the BNF syntax for the "host table specification" entries in RFC >> 952 or 810 are not precise enough. >> >> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc. >> >> NOTE: See "Assigned Numbers" for specific options and acronyms >> for machine types, operating systems, and protocol/services. >> >> for machine types, operating systems, and protocol/services. >> >> c) 68000 was not an official name! >> :-) :-) :-) >> >>> I countered back that using a YACC grammar for this was rediculous. >>>  There was already a real popular file on UNIX that had a bunch of >>> fields separated by colons and commas (/etc/passwd anybody) that it >>> was never necessary to use YACC to parse. >> >> Can't argue with that! Though that doesn't mean a handwritten parser >> wouldn't have complained about 68000. >> --------------83E35A2FE9DF88729C40367F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

3com.com was indeed illegal initially. We (the UUCP Zone) went to register it with the NIC and were told leading zeros weren't allowed, because some code might think a leading digit meant an IP address. I pushed back, they relented, and it was registered without a problem.

On 3/11/21 1:08 PM, Ron Natalie wrote:
The "name" in this context the host/network/gateway name such as SRI-NIC.ARPA.    3COM.COM would not have been legal back then.
Nowhere does it imply that any of the other fields are so restricted.

------ Original Message ------
From: "Bakul Shah" <bakul@iitbombay.org>
To: "Ron Natalie" <ron@ronnatalie.com>
Cc: "The Unix Heritage Society" <tuhs@minnie.tuhs.org>; "Internet History" <internet-history@postel.org>
Sent: 3/11/2021 4:02:50 PM
Subject: Re: [TUHS] [COFF] Pondering the hosts file

On Mar 11, 2021, at 12:32 PM, Ron Natalie <ron@ronnatalie.com> wrote:

Amusingly one day we got an Imagen ethernet-connected laser printer.    Mike Muuss decided the thing should be named BRL-ZAP and since I didn't know what to put down as the machine type, and it did have a 68000 in it, I had Jake put 68000 in the entry in the host table.

The next day I got all kinds of hate mail from other BSD sites who assumed I had intentionally sabotaged the host table.   Apparently, the BSD systems used a YACC grammar to parse the NIC table into the Berkeley one.   The only problem is they got the grammar wrong and assumed the CPU type always began with a letter.    There parse blew up on my "ZAP" host and they assumed that was the desired effect.

This is understandable as
a) All the "official machine names" in various assigned numbers RFCs start with a letter.
b) the BNF syntax for the "host table specification" entries in RFC 952 or 810 are not precise enough.
	<cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.

            

            

              
NOTE:  See "Assigned Numbers" for specific options and acronyms
         for machine types, operating systems, and protocol/services.


            

            

              
         for machine types, operating systems, and protocol/services.


            

          

          

            
c) 68000 was not an official name!
:-) :-) :-)

          

          


          

          

            

              

                
I countered back
                  that using a YACC grammar for this was rediculous. 
                   There was already a real popular file on UNIX that
                  had a bunch of fields separated by colons and commas
                  (/etc/passwd anybody) that it was never necessary to
                  use YACC to parse.

              

            

            

          

          
Can't argue with that! Though that doesn't mean a
            handwritten parser wouldn't have complained about 68000.

          

        

      

    

  


--------------83E35A2FE9DF88729C40367F--