From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc608.txt | 227 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc608.txt (limited to 'doc/rfc/rfc608.txt') diff --git a/doc/rfc/rfc608.txt b/doc/rfc/rfc608.txt new file mode 100644 index 0000000..4285a8c --- /dev/null +++ b/doc/rfc/rfc608.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group M.D. Kudlick +RFC # 608 SRI-ARC +NIC # 21256 January 10, 1974 + + + HOST NAMES ON-LINE + + +We at the NIC agree with Peter Deutsch's suggestion (in RFC# 606 / NIC# +21246) that the NIC maintain an online ASCII text file of Host names, +addresses, and attributes. That suggestion corresponds to one made by +Vint Cerf recently, and evidently receives ARPA/IPT support. + +Jake Feinler at the NIC designed and maintains a source file, in NLS +format, that can be used to generate the ASCII file Peter outlined. A +program to generate an up to date version of the ASCII file needs to be +written at the NIC, and run periodically (weekly, or as the situation +warrants). Such a mechanism would allow us, of course, to maintain one +source of data and use it for this and other purposes. + +Our present data includes official Host name, Host address, Host status +(user, server, TIP) and certain other information like Technical +Liaison, Host computer, operating system, etc. + +Provisions exist for including attributes of the type Peter suggested +(for example FTP byte size, TELNET duplex mode, echoing mode, and +nicknames), but these data are currently NOT in our source file. + + +To get things moving, therefore, we propose to do the following things: + + 1) We shall write a program to generate the ASCII file in the + syntax described in RFC# 606, namely: + + ::= / + + ::= + + Note that this produces a blank line after the . + + ::= / + + ::= , + + ::= = + + + + + +Kudlick [Page 1] + +RFC 608 Host Names On-Line January 1974 + + + 2) We shall initially include only the following items in each + : + + a) + + in which will be a decimal host address, + relative to the Host's own Network, and + + in which will be the official Host Name, a + string obtained through negotiation between the Host and the + NIC, governed by 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) + + in which initially will have the single + possible value STATUS, and the corresponding value of + for STATUS will be one of these: + + SERVER + USER + TIP + UNKNOWN + + + +Kudlick [Page 2] + +RFC 608 Host Names On-Line January 1974 + + + c) + + this will be carriage return followed by line feed (octal + 015 followed by octal 12). + + 3) Attributes other than those for which is STATUS + will be added in the above 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 + construed as replacing option negotiation or any other means by + which one Host discovers the properties of another, but merely + as an alternative source of information that is simply and + easily accessible, in machine-readable form. + + Suggestions for attributes that are worthy of inclusion in the + ASCII file of Hostnames are welcome. Please send your + suggestions and/or data to Jake Feinler + FEINLER @ SRI-ARC, or NIC Ident = JAKE + + For completeness, we record here the attribute suggestions given + in RFC# 606: + + NICKNAMES -- 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 -- 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 -- value is L or R depending on whether the host + expects the terminal to echo (Remote) or expects to do its + own echoing (Local). + +The ASCII file generated by the NIC will reside at Host OFFICE-1 (Host +Address = 43 decimal), and will have the pathname + + HOSTS.TXT + +Using this pathname with an FTP process will enable anyone, of course, +to retrieve the file for use at any Network Host. + + The login username for FTP can be GUEST, + password ARPA, + account 1. + + + +Kudlick [Page 3] + +RFC 608 Host Names On-Line January 1974 + + +The file will be in alphanumeric sequence by Host Name. + +The date after which the file will be available at OFFICE-l will be +announced via RFC as soon as the file is ready. + + +We welcome comments on this RFC, on RFC# 606, or on any other aspect of +this problem. And we wish to acknowledge the contributions of Vint +Cerf, Peter Deutsch, Jake Feinler, and Nancy Neigus in getting the +Official Host Name list to happen. + + + + + + + + + + + [ 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 ] + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Kudlick [Page 4] + -- cgit v1.2.3