ward@cfa.harvard.EDU (Steve Ward) (06/11/87)
Help needed from TCP/IP, Telnet protocol experts!!!!!!!!
I have Bridge terminal servers talking to DEC MicroVAXes running VMS with
Excelan TCP/IP protocol/Ethernet interface boards.
Here is my most serious problem: In order to run CAD/CAE graphics and other
applications, the Telnet session must be in binary mode. The Excelan board
defaults to 7-bit(ASCII) mode. The Excelan board is designed to expect the
remote client to request binary mode through some Telnet command/request
mechanism. The Bridge Terminal Servers can easily be tailored by a user
to operate in binary mode, but have no user or system method to be made to
request binary mode on the part of a host. This means there is no way for
the Excelan board to operate in binary mode when a Bridge terminal server
is used to interface the terminal or other remote client.
All that is needed is for the Excelan board to provide some host-based
method for configuring binary mode, or the Bridge terminal server must
implement some method for requesting binary mode from the host. NOW FOR
THE REAL PROBLEM:
Bridge says that they used to implement client request for host
binary mode, but it caused havoc with SUN workstations, so they
took out the command/request mechanism for host binary mode.
Bridge further stated that the protocol specs are somewhat
ambiguous on whether the client or host is responsible for requesting
or implementing methods to enter binary mode, but at this point they feel
the host is burdened with this function, though they admit they felt
the opposite was true at an earlier point in time. Bridge sympathizes
with my problem, but declines to do anything to fix it since their
position is that they are conforming to the TCP/IP/Telnet specs.
Excelan takes the same position, saying that per the specs it is clear
that the Bridge terminal servers must issue the appropriate request
for host binary mode, and their board will respond properly to the
request. Now it is clear that one of these two products is broken, but
which one??? Bridge and Excelan sympathize, but in essence are saying
"nothing wrong with us or our stuff, go away kid, don't bother me."
What is disturbing is that neither outfit is interested in researching
and resolving the problem. I would think that both companies would
be interested in helping clarify the situation, even perhaps indulging in
a three way conversation, but this interest was not shown.
I do not have RPC's or specs of any kind. What I ask is that you network
protocol wizards out there discuss this issue and let's see if their is a
concensus as to whether Bridge or Excelan has a broken product in this case.
If the specs turn out to be truly ambiguous, can we initiate a clarification
to eliminate the confusion?
Excelan, Bridge, are you listening? I would appreciate a higher
level of concern and support whether you think your product
is broken or not. This problem will cause malfunctions with most,
if not all graphics terminals connected to Bridge terminal servers talking
to the Excelan TCP/IP board. Are there other TCP/IP protocol boards out
there that assume that the terminal server or other client must request
binary mode? If so, then using the Bridge terminal server is not wise
since it won't request the binary mode. If the host must provide a
method for entering binary mode, then clearly the Excelan product is
broken and these problems could be encountered using the Excelan board
with any terminal server or other client. This should concern all
present and potential customers for these two product lines.
Bridge and Excelan, if you are listening, replies to myself or Roger
Hauck should be e-mailed to me at: {seismo|ihnp4}!harvard!cfa!ward
or ward@cfa.harvard.EDU (ARPA)
This topic should be of broad interest and concern, so replies to the
net are also appropriate, in my view.
Steven Ward, Harvard-Smithsonian Astrophysical Observatory
{seismo|ihnp4}!harvard!cfa!wardmckenzie@J.BBN.COM.UUCP (06/12/87)
Steve, The Telnet protocol was specifically designed to be symmetric; EITHER party to a Telnet connection is permitted to suggest a shift to binary mode, although both parties must agree before the shift takes place. On the other hand, Telnet is a specification of the PROTOCOL which takes place between two systems; it is NOT a spec of the interface to the user of Telnet on either system. What you are asking for is provision, in the local interface, for one Telnet user (the terminal user on the Bridge box, or the program on the uVAX) to ask the local Telnet to suggest the use of binary mode, and for the other user to agree that this is acceptable. I do not think you will find anything in the Telnet specs on which to base a claim that either interface MUST supply this functionality. In fact, binary mode is a Telnet OPTION, and by definition is not required. So in my opinion, neither of the Telnet implementations is "broken" in the sense you suggest. [I do believe Excelan is wrong if they told you the spec forbids them from suggesting binary mode, but that's not, I think, the main point.] Rather, the user community needs to convince one or both of these manufacturers that their implementation would be much more useful if it provided the additional functionality. One way to do this is to switch from purchases of the less useful product to a more useful product, although this may not be feasible in your case. Another way is to just keep up the pressure on the manufacturer. Regards, Alex McKenzie