Comments on IMP/Host Protocol changes (RFCs 687 and 690)
A proposal to keep revised IMP and Host leaders at a workable combined length.
Wolfe, S.M., "Comments on IMP/Host Protocol changes (RFCs 687 and 690)", RFC 692, DOI 10.17487/RFC0692, June 1975, <https://www.rfc-editor.org/info/rfc692>.
@misc{rfc692,
series = {Request for Comments},
number = 692,
howpublished = {RFC 692},
publisher = {RFC Editor},
doi = {10.17487/RFC0692},
url = {https://www.rfc-editor.org/info/rfc692},
author = {S.M. Wolfe},
title = {{Comments on IMP/Host Protocol changes (RFCs 687 and 690)}},
pagetotal = 2,
year = 1975,
month = jun,
} RFC text
Network Working Group Stephen Wolfe
RFC # 692 UCLA CCN
NIC # 32734 June 20, 1975
COMMENTS ON IMP/HOST PROTOCOL CHANGES, (RFCS 687 AND 690)
Basically, the proposed set of changes in RFC 687 seems reasonable, as
are the comments in RFC 690.
The major problem, as pointed out by Postel, is the change in the
combined length of the IMP and Host leaders to a total of 120 bits,
which is not a multiple of both 8 and 36 bits.
The suggested solution is to increase the length of the host to host
protocol leader by 24 bits, creating a total length of 144 bits. The
problem, however, is that the only way of compatibly changing this
length would be to have the IMP either insert or delete the extra 24
bits when converting to/from the old format leader. The problems with
this solution are obvious.
The better solution is to change the length of the new proposed IMP
leader. I suggest 104 bits instead of 80 bits. The complaint that 104
is not a multiple of an IMP word is valid, but it should not be that
difficult if the following rules are observed.
1. The last 8 bits are never used to convey information.
2. The network is not required to pass them from source to
destination, or to return them to the source.
3. When sending messages of types other than zero, (irregular
messages), the IMP is allowed to send either 96, 104 or 112 bits
of data, the choice being at the IMP's convenience.
4. Also, if desired, either 96 or 112 could be used as the new
leader length for irregular messages.
It must be faster (and cheaper) to just change the IMP program to handle
a 104 bit leader, than to force additional changes in all hosts using
the standard protocol.
Another suggested extension to the protocol would add a new type of IMP
to Host message. This message has a table of Host names (people type
character strings) and Host network addresses. Send this message(s) to
the Host after each interface reset, or alternatively, it could be a
response to a new Host to IMP request for this information.
[ 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. 10/99 ]
ISO Plain Language
On this page
§1The Combined Leader Length
Wolfe considers the changes in RFC 687 and the comments in RFC 690 broadly reasonable. He identifies a problem in the combined IMP and Host leaders: their proposed total length of 120 bits is not a multiple of both 8 and 36 bits.
One suggested fix was to add 24 bits to the Host leader, making the combined length 144 bits. Wolfe says this would require the IMP to insert or remove those bits when translating between old and new formats.
The proposed headers add up to a length that does not fit both systems' data units. Making the Host header longer would force the IMP to change the header when translating it.
§2A Different IMP Leader Length
Wolfe prefers an IMP leader of 104 bits instead of 80. Although 104 is not a multiple of an IMP word, he says it can work if the last 8 bits carry no information and the network is not required to preserve or return them.
For messages other than type zero, which the RFC calls irregular messages, the IMP may send 96, 104 or 112 bits of data at its convenience. The RFC also says either 96 or 112 bits could be used as the new leader length for irregular messages. Wolfe argues that changing the IMP program would be faster and cheaper than requiring changes in all hosts.
The proposal changes the IMP header and treats its last 8 bits as unused. For certain messages, the IMP can choose among three data lengths.
§3A Message for Host Names and Addresses
Wolfe also proposes a new IMP-to-Host message containing a table of host names and network addresses. The network could send the table after each interface reset, or send it in response to a new request from a host.
The proposal is an additional suggestion in this comment on protocol changes. It does not specify the full message format or define a complete implementation procedure.
The proposed message would give a computer a list matching host names to network addresses. The network could send it after a reset or when the computer asks.