As per Relevance of the word structure, we have this rfc below:
Netork Working Group L. Peter
Request For Comments: 606 PARC-
December 1973
Host Names On-
Now that we finally have an official list of host names, it
about time to put an end to the absurd situation where each
on the network must maintain a different, generally out-of-date
host list for the use of its own operating system or
programs
For example, each of the TENEX sites to which I have
( SRI-ARC, BBN-TENEX, USC-ISI, and PARC-MAXC) has a
different mapping between host names and host addresses:
is complete, and I believe each one differs in some way
the official List
Since the NIC has responsibility for maintaining the
list, lt seems appropriate for them to maintain an on-line file
accessible to anyone, which Lists names and host addresses (
certain other information which I will suggest in a moment) in
easily machine-readable form
This rules out, in my opinion, providing this information
in the form of an NLS structured file, since there are
facilities for accessing such files from the network and
many sites would not want to accommodate themselves to
structure even if there were
The file I have in mind would be devoted principally to
information 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
sophisticated facilities for browsing or querying. Therefore,
propose 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
supported by the host, including ( for FTP ) the preferred
size and ( for TELNET) the preferred duplex mode. The
can have an enormous effect on the efficiency of
transfers. 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
host or give useful information for statistical purposes ( e.g
I would like to make my NCP collect statistics on traffic
TIPs 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
format should be organized for ease of interrogation at
expense of ease of construction. I feel a reasonable way
achieve this is to store it as an ASCII text file with the
structure of a "property list".
-1-
In other words, aside from the two basic facts in each
( name and address), the information will be expressed in
form of <attribute, value> pairs rather than having
attribute be recognized by format, position, etc
l don't believe it matters a great deal exactly how this file
formatted, so I will make a suggestion in the hope that no
cares enough to protest it. ( This has never worked before in
history of the network, but it' s still worth a try )
following is the proposed syntax of the file
::= |
::=
Note that this produces a blank line after the .
::= | <attribute-item
::= ,
<attribute-item> ::= <attribute-name> = <attribute-value
This leaves the following terms undefined
: I don't know what end-of-line indication is
favor in the network community these days. I personally
carriage-return followed by line-feed. TENEX tends to use
single character octal 37, which is totally non-standard
inappropriate for this application
: an official host name as specified in the
RFC 597 (NIC 20826) by NJN and JAKE. It is my
that these names are restricted to letters, digits, hyphens
and parentheses ( including the network name).
: a decimal host address, relative to its
network ( I would assume). There has been no general
of multi-network addressing -- although there is apparently
unpublicized 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
BEST-FTP-BYTE-SIZE (?), but I am willing to let the NIC
them
<attribute-value>: an arbitrary string not
, whose interpretation depends in general on
attribute. For example, there might be an attribute
whose value was a list of the servers customarily run by
site
The following are some specific attributes that I think would
worthwhile
NICKNAMES -- value is a list of acceptable nicknames for
host. Any system that provides name-to-address translation
encouraged ( although of course not required) to accept
names as alternatives to the official host name
-2-
FTP-BYTE-SIZES -- value is a list of the byte sizes
by the FTP server. The first byte size is the one which
to the least computational overhead ( e.g. 36 for PDP-1O's, 32
for 36O's).
ECHOING -- value is L or R depending on whether the
expects the terminal to echo ( Remote) or expects to do its
echoing (Local).
Note that no attribute is actually required and that the
under 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
the properties of another, but merely to provide an
source of information which can be accessed in a simple
uniform way
I realize that there is a time-honored pitfall associated
suggestions such as the present one: it represents a
solution to a specific problem, and as such may not be
with or form a reasonable basis for more general solutions to
general problems. However, ( 1) this particular problem has
irking me and others I have spoken to for well over a year, and
is really absurd that it should have gone unsolved this Long; (2)
no one seems particularly interested in solving any more
problem
Except the Datacomputer: PLEASE, if there is an easy way
accomplish the same function through the Datacomputer,
write un RFC specifying it
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
