RFC 608

Host names on-line

πŸ“… published January 1974, from ietf

HOST NAMES ON-LINE πŸ’–

Okay bestie, first the basics πŸŽ€ This is RFC 608 (NIC # 21256), from the Network Working Group, written by M.D. Kudlick of SRI-ARC and dated January 10, 1974. The header doesn't list anything it obsoletes or updates ✨


The Tea β˜•

The NIC is on board with Peter Deutsch's idea from RFC# 606 / NIC# 21246 to keep an online ASCII text file of Host names, addresses, and attributes πŸ¦‹ Vint Cerf had basically the same idea recently, and ARPA/IPT clearly supports it. It's giving teamwork 🫢

Our Source Data 🌸

Jake Feinler at the NIC already designed and maintains a source file in NLS format, and it can be used to generate the ASCII file Peter described. A program to build an up-to-date version of the ASCII file still needs to be written at the NIC and run periodically (weekly, or as the situation warrants). Honestly, this is so smart, because we'd keep one source of data and use it for this and other purposes too πŸ’…

Right now our data includes the official Host name, Host address, Host status (user, server, TIP), and some other stuff like Technical Liaison, Host computer, operating system, etc. πŸ“‹

There are provisions for Peter's kind of attributes (like FTP byte size, TELNET duplex mode, echoing mode, and nicknames) πŸ™ˆ but that data is currently NOT in our source file. Not yet, anyway!

The Plan πŸ‘‘

To get things moving, we're doing these things:

  1. We shall write a program to generate the ASCII file in the syntax described in RFC# 606, namely:
<host-name-file> ::= <entry> / <host-name-file> <entry>

<entry> ::= <data-part> <end-of-line>

    Note that this produces a blank line after the <data-part>.

<data-part> ::= <basic-part> / <data-part> <attribute-item>

<basic-part> ::= <host-name> , <host-address> <end-of-line>

<attribute-item> ::= <attribute-name> = <attribute-value> <end-
of-line>
  1. We shall initially include only these items in each <entry> 🧚

a) <basic-part>: the <host-address> will be a decimal host address, relative to the Host's own Network. The <host-name> will be the official Host Name, a string negotiated between the Host and the NIC, with these constraints:

  • up to 48 characters drawn from the alphabet (A-Z), digits (0-9), and the minus sign (-) ... specifically, no blank or space characters allowed
  • no distinction between upper and lower case letters
  • the first character is a letter
  • the last character is NOT a minus sign
  • no other restrictions on content or syntax

Note: the Host Name may be prefixed with an Official Network Name of up to 24 characters enclosed in parentheses (). The Network Name designates the Network in which the Host resides.

(The characters used in the Network Name are drawn from the same character set as those in the Host Name, with the same constraints [except the length] as listed above.)

The ASCII text file will only contain the Official Network Name for Hosts NOT on the ARPANET. For ARPANET Hosts there will be no Network Name prefix 🌈

b) <attribute-item>: the <attribute-name> will initially have the single possible value STATUS. The matching <attribute-value> for STATUS will be one of these:

SERVER
USER
TIP
UNKNOWN

c) <end-of-line>: this is a carriage return followed by a line feed (octal 015 followed by octal 12) πŸ’€

  1. Attributes other than STATUS will be added in the same format at a later date (to be announced), as the data becomes available to us πŸŽ€

We agree with Peter that the attribute list should NOT be treated as replacing option negotiation or any other way one Host finds out about another Host's properties. It's just an alternative source of info that's simple, easy to access, and machine-readable 🫢

Suggestions for attributes worth including in the ASCII file are welcome! Send your ideas and/or data to Jake Feinler at FEINLER @ SRI-ARC, or by NIC Ident: NIC Ident = JAKE ✨

For Completeness πŸ“š

We're recording the attribute suggestions from RFC# 606 here too:

  • NICKNAMES: the value is a list of acceptable nicknames for the host. Any system that provides name-to-address translation is encouraged (although of course not required) to accept these names as alternatives to the official host name.
  • FTP-BYTE-SIZES: the value is a list of the byte sizes supported by the FTP server. The first byte size is the one which leads to the least computational overhead (e.g. 36 for PDP-10's, 32 for 360's).
  • ECHOING: the value is L or R, depending on whether the host expects the terminal to echo (Remote) or expects to do its own echoing (Local).

Where To Find It 🧚

The ASCII file generated by the NIC will live at Host OFFICE-1 (Host Address = 43 decimal), with the pathname:

<NETINFO>HOSTS.TXT

Using this pathname with an FTP process lets anyone grab the file for use at any Network Host 🌸 The login details are:

login username: GUEST
password: ARPA
account: 1

The file will be in alphanumeric sequence by Host Name. The date it becomes available at OFFICE-l will be announced via RFC as soon as the file is ready ⭐

Comments & Thanks πŸ’œ

We welcome comments on this RFC, on RFC# 606, or on any other aspect of this problem! And we want to thank Vint Cerf, Peter Deutsch, Jake Feinler, and Nancy Neigus for helping get the Official Host Name list going 🫢🌈

[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Alex McKenzie with    ]
[ support from GTE, formerly BBN Corp.            11/99 ]
πŸ“¦ where this page comes from