Movatterモバイル変換

Netork Working Group                                     L. Peter DeutschRequest For Comments: 606                                       PARC-MAXC                                                            December 1973Host Names On-lineNow that we finally have an official list of host names, it seemsabout time to put an end to the absurd situation where each siteon the network must maintain a different, generally out-of-date,host list for the use of its own operating system or userprograms.For example, each of the TENEX sites to which I have access( SRI-ARC, BBN-TENEX, USC-ISI, and PARC-MAXC) has a slightlydifferent mapping between host names and host addresses: noneis complete, and I believe each one differs in some way fromthe official List.Since the NIC has responsibility for maintaining the officiallist, lt seems appropriate for them to maintain an on-line file,accessible to anyone, which Lists names and host addresses ( andcertain other information which I will suggest in a moment) in aneasily machine-readable form.This rules out, in my opinion, providing this information onlyin the form of an NLS structured file, since there are nofacilities for accessing such files from the network and sincemany sites would not want to accommodate themselves to thisstructure even if there were.The file I have in mind would be devoted principally to thatinformation needed by programs, as opposed to people, since the ;former want their information in compact, easily parsed form,whereas the latter appreciate more verbose expression and moresophisticated facilities for browsing or querying. Therefore, Ipropose that the following information be included in such a file:Of course, the official name and host address for each host.This would be the primary content of each entry.Some information about the options of the various protocolssupported by the host, including ( for FTP ) the preferred bytesize and ( for TELNET) the preferred duplex mode. The formercan have an enormous effect on the efficiency of filetransfers. Since the new TELNET allows negotiation of options,the list need not be complete or accurate.The function o f the host vis-a-vis the network ( user, server,TIP, etc.). This may aid NCPs in deciding whether to poll thehost or give useful information for statistical purposes ( e.g.I would like to make my NCP collect statistics on traffic withTIPs vs. other hosts).Since the file will be generated centrally by a single program,but used widely by a variety of programs, it follows that itsformat should be organized for ease of interrogation at theexpense of ease of construction. I feel a reasonable way toachieve this is to store it as an ASCII text file with the logicalstructure of a "property list".                                   -1-

In other words, aside from the two basic facts in each entry( name and address), the information will be expressed in theform of <attribute, value> pairs rather than having theattribute be recognized by format, position, etc.l don't believe it matters a great deal exactly how this file isformatted, so I will make a suggestion in the hope that no onecares enough to protest it. ( This has never worked before in thehistory of the network, but it' s still worth a try ) Thefollowing is the proposed syntax of the file.<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>This leaves the following terms undefined:<end-of-line>: I don't know what end-of-line indication is infavor in the network community these days. I personally favorcarriage-return followed by line-feed. TENEX tends to use thesingle character octal 37, which is totally non-standard andinappropriate for this application.<host-name>: an official host name as specified in the recentRFC 597 (NIC 20826) by NJN and JAKE. It is my understandingthat these names are restricted to letters, digits, hyphens,and parentheses ( including the network name).<host-address>: a decimal host address, relative to its ownnetwork ( I would assume). There has been no general discussionof multi-network addressing -- although there is apparently anunpublicized Internetworking Protocol experiment in progress --and some other convention may be more desirable.<attribute-name>: an arbitrary name containing only letters,digits, and hyphens. We will have to agree on some names likeBEST-FTP-BYTE-SIZE (?), but I am willing to let the NIC pickthem.<attribute-value>: an arbitrary string not containing<end--of-line>, whose interpretation depends in general on theattribute. For example, there might be an attribute SERVERSwhose value was a list of the servers customarily run by thesite.The following are some specific attributes that I think would beworthwhile:NICKNAMES -- value is a list of acceptable nicknames for thehost. Any system that provides name-to-address translation isencouraged ( although of course not required) to accept thesenames as alternatives to the official host name.                                     -2-

FTP-BYTE-SIZES -- value is a list of the byte sizes supportedby the FTP server. The first byte size is the one which leadsto the least computational overhead ( e.g. 36 for PDP-1O's, 32for 36O's).ECHOING -- value is L or R depending on whether the hostexpects the terminal to echo ( Remote) or expects to do its ownechoing (Local).Note that no attribute is actually required and that the valuesunder a given attribute need not be complete. In other words,this list is meant not to replace option negotiation,word-of-mouth, or any other means bo which one host discoversthe properties of another, but merely to provide an alternatesource of information which can be accessed in a simple anduniform way.I realize that there is a time-honored pitfall associated withsuggestions such as the present one: it represents a specificsolution to a specific problem, and as such may not be compatiblewith or form a reasonable basis for more general solutions to moregeneral problems. However, ( 1) this particular problem has beenirking me and others I have spoken to for well over a year, and itis really absurd that it should have gone unsolved this Long; (2)no one seems particularly interested in solving any more generalproblem.Except the Datacomputer: PLEASE, if there is an easy way toaccomplish the same function through the Datacomputer, someonewrite un RFC specifying it.                                       -3-