Browse Prior Art Database

Comments on the Meyer Proposal (RFC0050)

IP.com Disclosure Number: IPCOM000003636D
Original Publication Date: 1970-Apr-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 2 page(s) / 3K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

E. Harslen: AUTHOR [+1]

Related Documents

10.17487/RFC0050: DOI

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

E. Harslen J. Heafner Network Working Group RANL Request for Comments: 50 4/30/70

Comments on the Meyer Proposal ------------------------------

We find the Meyer proposal (Note #46) to be the most acceptable to dare, for exactly the reasons that he enumerates; viz., simple, suffices for most planned uses of the Network, easy to implement, can be extended. It does not encompass everything that has been suggested recently, however, we do agree with the items that are proposed and we feel that the missing features are probably not worth doing battle over and thus delaying the specification.

We make the following comments on the seven issues rasied in Note #47.

1) We agree with Steve that dynamic reconnection will later be required for more sophisticated uses of the Network. We also agree with the Project MAC people that it unnecessary initially. A better job can be done of dynamic reconnection given some Network experience and the specific needs of its use.

2) INT is easy to implement and serves a useful purpose.

3) We favor including a sub-field for instance tag identifier. We see the need for both cases; a) where multiple processes should appear indistinguishable, and b) where a given user owning multiple processes must distinguish among them. Those program parts that should not distinguish among processes should simply ignore the instance tag. Tom’s suggestion to use part of the user number sub-field merely reduces the combined length of sub-fields from 32 bits to 24 bits; the problem remains.

4) We disagree with both Steve and MAC in that no special structure should be imposed on the data transmitted. We prefer the "message data type" mentioned by E. I. Ancona, Note #42, page 1. An example of its use was cited in Note #39, page 2, transmit vs broadcast.

[Page 1]

With regard to a standard character set, we strongly support adopting one in the beginning, and in particular ASCII. We have observed that most sites have previously suggested ASCII. Is there anyone who objects?

5) Word boundary alignment is more attractive than double padding.

6)...

Processing...
Loading...