Re: API
Paul Tsuchiya <tsuchiya@thumper.bellcore.com> Tue, 09 February 1993 00:28 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa20469; 8 Feb 93 19:28 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa20463; 8 Feb 93 19:28 EST
Received: from babyoil.ftp.com by CNRI.Reston.VA.US id aa27075; 8 Feb 93 19:29 EST
Received: from thumper.bellcore.com by ftp.com with SMTP id AA20482; Mon, 8 Feb 93 19:25:43 -0500
Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id <AA26825> for criteria@ftp.com; Mon, 8 Feb 93 19:25:25 EST
Received: by chiya.bellcore.com (4.1/4.7) id <AA25513> for ericf@ftp.com; Mon, 8 Feb 93 19:25:25 EST
Date: Mon, 08 Feb 1993 19:25:25 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Tsuchiya <tsuchiya@thumper.bellcore.com>
Message-Id: <9302090025.AA25513@chiya.bellcore.com>
To: criteria@ftp.com, ericf@atc.boeing.com
Subject: Re: API
Cc: ericf@ftp.com
Status: O
> > I would like to propose yet another IPvN Selection Criteria. This > criteria is that the IPvN solutions be able to use the existing TCP/IP > Transport Layer APIs unchanged. I suggest that each IPvN solution > should be able to run under Berkeley Sockets, TLI, the Revised XTI API, > and the eXTI (i.e., the API submitted by IBM to X/Open under the title > of "MPTN") in as transparent a fashion as possible. > Our implementation of Pip is currently working with unchanged applications and TCP--on sunOS. The limitation is that applications that embed IP addresses in them can only work within what we call an "IP-unique" domain. That set of systems that are have unique IP addresses.... I haven't looked into these other. Is there any reason we couldn't make it work on the others if we can make it work on sunOS? Also, I agree with your criteria...... PX