As per Relevance of the word extensible, we have this rfc below:
RFC 730 20 May 77
Extensible Field
Network Working Group Jon
Request for Comments: 730 USC-
NIC: 40400 20 May 1977
Extensible Field
This memo discusses the need for and advantages of the expression
addresses in a network environment as a set of fields. The
is that as the network grows the address can be extended by
techniques: adding fields on the left, adding fields on the right,
increasing the size of individual fields. Carl Sunshine has
this type of addressing in a paper on source routing [1].
Change in the Host-IMP
The revised Host-IMP interface provides for a larger address space
hosts and IMPs [2]. The old inteface allowed for a 2 bit host field
a 6 bit IMP field. The new interface allows a 8 bit host field and a 16
bit IMP field. In using the old interface it was common practice
treat the two fields as a single eight bit quantity. When it
necessary to refer to a host by number a decimal number was often used
For example host 1 on IMP 1 was called host 65. Doug Wells has
out some of problems associated with attempting to continue such
as the new interface comes into use [3]. If a per field notation
been used no problems would arise
Some examples of old and new host numbers are
Host Name Host IMP old # new #
--------------------------------------
SRI-ARC 0 2 2 2
UCLA-CCN 1 1 65 65537
ISIA 1 22 86 65558
ARPA-TIP 2 28 156 131100
BBNA 3 5 197 196613
Multinetwork
The prospect of interconnections of networks to form a
multinetwork system poses additional addressing problems. The
Host-IMP interface specification has reserved fields in the leader
Postel [page 1]
RFC 730 20 May 77
Extensible Field
carry network addresses [2]. There is experimental work in progress
interconnecting networks [4, 5, 6]. We should be prepared for
extensions to the address space
The addressing scheme should be expandable to increase in scope
interconnections are made between complex systems
Multiprocessor
There may be configurations of hardware that could be interfaced to
network as a single host that in fact contain multiple processors
Tasks could be associated with processors such that it is desirable
dispatch network messages associated with certain sockets or message-
to certain processors. For example it might be desirable to service
Telnet use from one processor and all FTP use from a
processor
The addressing scheme should be expandable to explicitly address
fine structure within a host when that is desirable
Some examples where such fine structure addressing would have
useful in the ARPANET are
At ISI, we have the capability of emulating computers using the
system [7]. For many applications it is desirable to add the
host to the network. Since the emulation is carried out under
of a program operating under Tenex, we have a host within a host
Extensible addressing of hosts would provide the necessary handle
SCRL once had a PDP-11 connected by VDH to an IMP at UCSB. It
necessary to add a second PDP-11 to the network. The two PDP-11s
already physically connected and it would have been a simple matter
have the first serve as a multiplexor for both. However, because
the limitations in the network addressing structure, there was no
to identify the two hosts to other sites on the network. A new
had to be installed
In many other cases, it is desirable to have two hosts share the
front end to the network. With the current limitation, one IMP
must be consumed for each host
Postel [page 2]
RFC 730 20 May 77
Extensible Field
The necessary solution to the problem posed by the change in
Host-IMP inteface is to always represent the address by fields.
solution provides for a natural growth into an internetwork environment
and allows explicit addressing of the fine structure within a host
that is desirable
The fields should be written in a natural way, and i believe that
that the most general field should come first with additional
specifying more and more details of the address. In the current
this would lead to the following fields
Network / IMP / Host / Message-
A problem with simple field addressing is the desire to specify only
fields that are necessary given the local context. A
interpreting the address is then unsure what the first field represents
Some clues are needed in the address specification for correct
to be possible. Dave Crocker has described a syntax for a
problem in network access of data [8].
Specific
Specifically i suggest that we adopt a field based extensible
scheme where each field is separated from its neighbors by a
character and each field has a name. When an address is specified
name of the most general field must also be indicated
Definitions
::= ":"
::= "NET" | "IMP" | "HOST" | "MESSAGE-ID
::= | "/"
::= a decimal
Examples
NET:1/3/5/7 names message-id 7 at host 5 on imp 3 in network 1.
HOST:6 names host 6 on whatever imp this message originates on
Postel [page 3]
RFC 730 20 May 77
Extensible Field
One might ask: What is all the fuss about, isn't this a non-problem?,
The answer is: Almost. There are very few places where any
difficulties arise, but we have to change the way we think about
addresses. The places where there is a problem are typically
used, except one. The place where humans will see a difficulty is
the TIP "open" command [9], and to a lesser extent the user Telnet
user FTP "connect" commands. Other places are in the MAIL
field, the FTP "sock" command [10], the Telnet reconnection option [11],
and in the NIC maintained list of official host names [12].
The suggestion is that we adopt field based extensible addressing
provide for growth in three ways
(1) growth of the number of hosts and IMPs by allowing these fields
grow in size independently of each other
(2) growth in scope by the addition of fields on the left to
for multinetwork systems
(3) growth in fine structure by addition of fields on the right for
implementation of hosts as mininetworks
Postel [page 4]
RFC 730 20 May 77
Extensible Field
[1] Sunshine, C. "Source Routing and Computer Networks,"
Communication Review, Vol. 7, Number 1, ACM Special
Group on Communications (SIGCOMM), January 1977.
circulated as INWG General Note number 133.
[2] BBN, "The Interconnection of a Host and an IMP," Report 1822,
Bolt Beranek and Newman, Revised January 1976.
[3] Wells, D., "Impact of New IMP Leaders on Higher-
Protocols," ARPA Network
[MIT-Multics]1.2.BBBJGbHZPXdDjl, MIT, 19 May 1977.
[4] Beeler, et.al. "Gateway Design for a Computer
Interconnection," PRTN 156, February 1976.
[5] Cerf, V., Y. Dalal, and C. Sunshine. "Specification of
Internet Transmission Control Program," INWG General 72,
675, Revised December 1974.
[6] Cerf, V. "Specification of TCP version 2," March 1977.
[7] Britt, B. et.al. "PRIM System: Overview," ISI/RR-77-58,
Information Sciences Institute, University of
California, March 1977.
[8] Crocker, D., "Network Standard Data Specification Syntax,"
645, Network Information Center Catalog Number 30899, 27
1974.
[9] Malman, J., "User's Guide to the Terminal IMP," Report 2138,
Bolt Beranek and Newman, Network Information Center
Number 10916, Revised March 1976.
[10] Neigus, N., "File Transfer Protocol," RFC 542,
Information Center Catalog Number 17759, 12 August 1973.
Contained in "ARPANET Protocol Handbook," Network
Center Catalog Number 7104, Revised 1 April 1976.
[11] Thomas, R., "Telnet Reconnection Option," Network
Center Catalog Number 15391, August 1973. Contained in "
Protocol Handbook," Network Information Center Catalog
7104, Revised 1 April 1976.
[12] [Offfice-1]HOSTS.
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
