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