Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!lupine!infopiz!athertn!hpda!motcsd!apple!usc!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ANDREW.CMU.EDU!tjh+
From: Ravinder.Chandhok@CS.CMU.EDU (Rob Chandhok)
Newsgroups: comp.protocols.appletalk
Subject: Re: Encapsulated LocalTalk in IP Packets (query)
Message-ID: <538.620312688@GNOME.CS.CMU.EDU>
Date: 28 Aug 89 13:04:48 GMT
Sender: Ravinder.Chandhok@GNOME.CS.CMU.EDU
Organization: The Internet
Lines: 25
To: BMUG <agate!garnet.berkeley.edu!bmug@ucbvax.berkeley.edu>
Cc: info-appletalk@ANDREW.CMU.EDU
In-Reply-To: Your message of 26 Aug 89 00:41:23 +0000. <1989Aug26.004123.29350@agate.uucp>

I broached this subject a while ago on info-appletalk, and the only
people
(company) that seems to be interested is Kinetics, a division of
someone, a
wholly owned subsidary of someone else.  If you can get past their name,
the
people there are quite knowlegable about the implications of a software
based "IPTalk" driver for the Mac.  Problems arise when you consider
using
MacTCP, however, since you have to listen to 256 UDP ports.  It would be
a
lot easier if Apple would let you open listeners for a range of ports,
since
MacTCP currently has a limit of 64 ports.

In addition, I think the actual specs of "IPTalk" should be committed to
RFC
form, so that the KBOX can talk to IPTalk can talk to CAP, without
arguing
whose hack is the right hack.  I'll help do it, if I get enough committe
members.  That's the way we did the NIC assigned port numbers for
"IPTalk"
(the dreaded 200 range).

Rob Chandhok