I could see Varouj's presentation directly in Antwerp. The presentation was good, and solution was very likely good enough for many potential customers. Anyway, I think the presented solution might be too expensive under some circumstances.
As a programmer from Supply Chain business, I dare to comment the presented solution.

It is clear, currently one of the most important telnet application is an interaction between wireless (RF) barcode scanners and some central logistic server application.

If one wants to develop a J2EE based solution for such an interaction, he/she should consider:

• Depots can be located at any place of the globe; the only possible connection could be normal Internet connection and firewalls/proxies can play an important role. This might imply deploying of Telnet server on a number of places in the world e.g. we could need an instance of telnet server in each depot communicating with central WEB app over HTTP. Though it is possible to deploy JCA based telnet server on e.g. free JBoss app servers installed in those depots, this solution is likely not as a cheap and elegant solution like we need.
• Supply chain business can live with RF scanners providing simulation of command line console with barcode scanning capabilities i.e. the business can live without the rich user interface based on JSF. In fact, RF scanners might be supporting something else in future (WAP) and it is not probably too much worthy to heavily improve telnet based solutions nowadays.
• A connection between RF scanner and telnet server is not very reliable i.e. we can't limit the number of telnet clients and the number of JCA connections can easily be several times higher than expected

Conclusion:
It is feasible to implement telnet server as a simple java application that can be launched using Java Web Start in any depot in any town in any country if needed. The app can be a simple request/response proxy based on telnetd library and use HTTP protocol (+HTTP session, +HTTP authentication for telnet login for "free") to forward user's input to central app server. There should be one telnet servlet deployed and we can use HTTP sessions to mirror telnet sessions for free. The telnet servlet (in central app) should use a management of persistable telnet sessions (identified by HTTP sessions id) and the servlet has to be also able to dispatch telnet requests to right telnet handlers (typically one handler can manage one use case having a state attached to a telnet session) and fill the answer to HTTP response.
This solution can be relatively easily implemented and it can serve SPL business perfectly. The number of light telnet servers can balance the load coming from RF scanners easily. The command line based solution can buffer single input character directly on light telnet servers (in depots) and we don't need to transmit single characters from RF scanner to central app. This likely improves the performance much - comparing the original solution presented by Varouj Chitilian.

I have to admit, the solution presented by Varouj Chitilian can be also adopted to requirements presented above and moreover it provides a mean for building a rich user interfaces on telnet enabled devices. In fact, it is definitely more complete solution, but it can be more expensive than simpler but also sufficient solution. That was the point of my comment.