Browse Prior Art Database

Comments on a proffered official ICP: RFCs 123, 127 (RFC0151) Disclosure Number: IPCOM000002339D
Original Publication Date: 1971-May-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 2 page(s) / 3K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

A. Shoshani: AUTHOR

Related Documents

10.17487/RFC0151: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 61% of the total text.

NWG/RFC # 151 A. Shoshani SDC NIC #6755 May 10, 1971


Bob Long at SDC noticed that the order in which messages go out to the network depend on the local NCP. In particular commands may be given priority over data and therefore in the sequence specified for server in RFC 123 (top of Page 3), the last two INIT commands may go out before the data = S on socket = L is sent. (This is the case in the current implementation of SDC’s NCP.) The implication is that the user’s NCP should be prepared to keep the INIT’s it received from the server until the user process gets the data = S and issues two INITs in response.

This case is brought up now so that people will think about it before the Atlantic City meeting and comment whether their NCP can tolerate it. It may be necessary to make it explicit in the ICP that the two INITs sent by the server should go out only after the data = S is sent, or even after the user process acknowledges its receipt.

I have a more general remark about the ICP. This is a third level protocol and therefore should not alter or ignore procedures of the second level protocol (Host-Host protocol). In particular three remarks seem appropriate:

Kreznar [Page 1]

RFC 19 October 1969

1. In RFC 123 (bottom of Page 2) it is suggested that the byte size for the connection to the server socket L is 32. However, in the modifications to second level protocol (RDC 107) it is specified that it is up to the sending process to chose the byte size. According to the Host-Host protocol, NCPs should be prepared to accept messages in any byte size (1<= size <=255); therefore there is no need to impose a size of 32 in this case. Furthermore, since it is up to the sender to choose the byte size, some Hosts may choose a particular byte size (for simp...