Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ucbvax!BU-CS.BU.EDU!bzs
From: bzs@BU-CS.BU.EDU (Barry Shein)
Newsgroups: mod.protocols.tcp-ip
Subject: Do we need another protocol?
Message-ID: <8610011740.AA28707@bu-cs.bu.edu>
Date: Wed, 1-Oct-86 13:40:45 EDT
Article-I.D.: bu-cs.8610011740.AA28707
Posted: Wed Oct  1 13:40:45 1986
Date-Received: Fri, 3-Oct-86 09:17:18 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 55
Approved: tcp-ip@sri-nic.arpa


Re: record-level access in TCP

This has come up before as being seriously lacking in other contexts.

It may be a can of worms due to the nature of heterogeneous networks,
usually the person calling for it is thinking of just THEIR record
level access (eg. VMS/RMS.) My usual reaction is that this problem has
not been adequately solved for magnetic tapes across heterogeneous
systems so I suspect there is a nut there to crack, it's not like tape
users never thought of it.

Even if OpenNet gets you this service to another OpenNet/Intel310
host, I doubt it helps you much with a PDS file on the MVS system
down the hall. It just solves the easy, short term problem.

I would suggest the community start looking hard at how far NFS/RPC/XDR
from SUN (and, as we all know, being adopted as a layered protocol on
TCP/UDP/IP by almost every major computer vendor) can be used to solve
the problem. It's not really 'record' level access, the question is better
put as:

	"How in general can I create a network I/O stream
	 which, rather than bytes, uses an arbitrary structured
	 data type, with a file offset calculation, as a unit of
	 transfer?"

Perhaps just semantics but I think it brings one a little closer to
understanding why something like XDR/RPC already addresses this
problem to a large extent and working from that base, where weaknesses
are perceived, might be the most profitable route to a solution (lord I
sound pedantic, sorry...)

Essentially (for those who haven't looked at the SUN protocols) one
sits down (they have already) and defines a network representation
for various primitive types (eg. byte order and format of integers).
Then a method for constructing arbitrary data types out of those as
n-tuples. Then a protocol for exchanging what you have in mind (as
a trivial example exchanging a fortran format string would be close)
and finally a remote procedure call protocol for specifying various
remote operations.

To stave off the flood of "XYZ system has been doing that for years",
yes, we know, but XYZ system is not licensable on our machines, is it?
The XDR/RPC protocols (protocols != code) are in the public domain.

And yes, I don't think it would be a good idea to put this into FTP
until this layer is defined. At some later date it might be clear
how these mechanisms can best be utilized in an extension to FTP for
some subset, but I doubt FTP is designed to support such generality.

	-Barry Shein, Boston University

P.S. I have no economic interests in any of this, if I did I'd probably
be rich and out spending my money instead of typing this stuff in...