When I first got back into the world of the TI-99/4a I found lots of old FAQ's about 'getting on the internet' which described using the TI as a terminal. In my original web page I described the method as "about as useful and exciting as a wet brick..." One can use such a terminal to connect to surviving bulletin boards or ISP shell accounts, but I think that having a Unix command line 'terminal' from which to run Pine or Gopher as a remote program on that other system doesn't make it, at least not for me.
Yet, as I write in 2008, I have to modify my view somewhat. I do have a connection between one of my TI systems and one of my Debian linux systems, and although I cannot FTP a file between the two systems, I can certainly run Xmodem. So one of things I used to say, that being connected as a terminal doesn't really communicate to the TI, isn't exactly true any more. I can theoretically connect to my linux box, FTP a file from anywhere to the linux box, and then Xmodem the same file back to my TI. Nevertheless, even in that scenario, the TI is not the IP host, my linux box is, and the two-step file transfer process is, well, two steps. [And I know of no Xmodem implementation in linux-land that understands or implements TIFILES headers.) So with that caveat, I would still argue that calling this method 'getting on the internet' is an illusion: serving as a 'dumb terminal' to a competent IP host is not the same thing as being an IP host.
The TI-99/4a was designed close to the same time the OSI 7-layer architecture was conceived, but the TI doesn't follow it exactly. The TI featured a proprietary version of BASIC as its native environment. Access to internals, and all I/O, were achieved by CALL statements to routines which were either built into the operating environment, or custom written and loaded as extensions. In the underlying operating system, access to all peripherals was made through a software layer called a 'Device Service Routine.' The DSR in turn would rely on intelligence and low-level routines built into the device, essentially using designated software addresses to send and receive bits and bytes and some rudimentary signals.
Calls to the DSR, either from BASIC or in native assembly language, tend to be discrete events. There are interrupt routines, of course, and the 9900 is pretty versatile in this regard. but still there's not much space in those interrupt service routines for anything like a protocol stack. So in this environment there's no provision for a clean separation between application, presentation and session layers, and down at the bottom, no clean way of implementing a data link layer, much less run a 'stack' of protocols against that data link.
Nevertheless, there is a persistent dream/hope/wish for a way for hobbyists to integrate their old TI's into the modern world by means of ethernet and tcp/ip. Primitive (and incomplete) C compliers do exist in the TI environment, and of course tcp/ip source code in C is readily available. Some people think that one could compile a miniature IP stack and squeeze it into an Interrupt Service Routine, or somewhere, but within the overall TI architecture it's hard to visualize how an API into that stack would actually work.
Perhaps someone will start completely from scratch, by-passing the firmware in the system ROM and devising a new operating architecture around the TMS9900 and the ancient bus. If by some miracle it all worked, would it still be a TI-994/a?
Even the dreamers in the TI community recognize that the challenges of a true networking implementation are daunting, so their discussions tend to spin on about how to design an ethernet interface board that would have bus compatibility with the TI's expansion port, but with the IP software all off-loaded onto the mythical board. Maybe that could be done, but then you end up back with scenario #1, the TI as a terminal to the internal device, and, well, who cares?