As per Relevance of the word appendix, we have this rfc below:
Network Working Group David
Request for Comments: 716 Joel
NIC #35534 May 24, 1976
Interim Revision to Appendix F of BBN Report 1822
Over the past few months we have become aware that there has
some confusion as to how to operate a Host connected to an IMP as
Very Distant Host (or VDH). Therefore, next time BBN Report 1822
("Specifications for the Interconnection of a Host and an IMP")
revised, we will include additional information on how the IMP
of a VDH connection works and how the Host side may operate
efficiently. As an interim measure, we are distributing this
which takes the form of a (logical) update to Appendix F of
Report 1822.
On page F-6 on Appendix F, delete the second footnote
On page F-7, find the phrase "... and the odd/even bit is complemented."
on line 17 of the page. Delete the rest of the page and insert
following text
In a standard Host to IMP interface, messages are delivered in
specific order and received in the same order. A Very Distant
interface operates similarly in that messages are passed,
example, from the IMP to its RTP in order; the Host's RTP
delivers them to its receiving process in the same order. It
important to note, however, that between these two
interfaces there is nothing said about ordering. In particular,
the special interface detects an error in a packet, for example
the receiving RTP will discard the packet. The next packet
arrive on another logical channel before the sending
retransmits the discarded and unacknowledged packet, and
receiver should be prepared to accept this packet out of order
The protocol described above explicitly permits such out-of-
behavior between the RTPs, requiring only that the transmit
of the RTP fill its channels in sequence (one to channel zero,
to channel one, one to channel zero, etc.), and that the
portion of the RTP empty its channels in sequence. In addition,
insure correct sequencing, the first channel filled or
after initialization must be channel zero. Null packets
neither a channel nor a channel number when sent and are
acknowledged when received
When packets must be retransmitted until acknowledged,
and transmission delay may cause acknowledgement to be delayed
more than one transmission time. Unnecessary retransmission
interfere with new transmissions, as well as placing an
-1-
burden on both receiver and transmitter. Therefore, we recommend
program delay before deciding to retransmit an
packet. This amount of delay should be adjustable, but
recommend a trial value of 100 msec. Additional efficiency may
gained if the RTP can notice that the next packet has
acknowledged while the previous one has not: in this case, it
clear that the first packet was not correctly received and it
be retransmitted immediately without waiting for the
delay to expire. This option has not, however, been implemented
the IMP at this time
-2-
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
