hascall@cs.iastate.edu (John Hascall) (08/11/90)
Greetings again from water-logged Iowa: (As you may recall from a previous message) I added the option XDISPLOC to our Telnet (passes your DISPLAY environment variable to the remote machine) which is all fine and dandy except that you have to do an "xhost +remote.machine.foo.bar" before you telnet so the other end can draw on your local display (bummer!). What I was thinking of doing was passing the magic-cookie to the remote-end through another Telnet option. Has anyone else thought about/done this (I didn't find a RFC)? Does any one have any comments on the good/badness of this? On a possibly related note (if this turns out to be `a good thing') what is the process for writing a RFC? As always, many thanks, John Hascall / Project Vincent / Iowa State University / Ames IA john@iastate.edu / hascall@atanasoff.cs.iastate.edu
gs26@prism.gatech.EDU (Glenn R. Stone) (08/12/90)
In <2432@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: > What I was thinking of doing was passing the magic-cookie [DISPLAY variable] >to the remote-end through another Telnet option. Has anyone else thought >about/done this (I didn't find a RFC)? Does any one have any comments >on the good/badness of this? This smells more like what rlogin does... Telnet doesn't need to be passing environment variables, since I might (and do, occasionally) be telnetting to a VMS machine, or (angels and ministers of grace defend us) a CYBER... Rlogin's Bugs section in TFM already says it should propogate more of the environment... how much more is open to debate, but it already says that rows and columns are supported on some systems.... hmmm.. p'raps there is a need for xrlogin, to propogate such neat things as color, stty settings, etc? I don't think all this info needs to be in the standard package, simply because the vast majority of what's going on out there is still being done on damn-3a's and Real PC's with a serial port out the back. (you wouldn't believe the number of old 4.77mHz boxes still being pounded on every day on this campus... but I digress.) If the env-variable passing is already there, it shouldn't be too hard to extend rlogin into xrlogin, and drop One More File into ..../contrib... -- Glenn R. Stone gs26@prism.gatech.edu
bob@MorningStar.Com (Bob Sutterfield) (08/13/90)
In article <12461@hydra.gatech.EDU> gs26@prism.gatech.EDU (Glenn R. Stone) writes: In <2432@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: What I was thinking of doing was passing the magic-cookie [DISPLAY variable] to the remote-end through another Telnet option. Has anyone else thought about/done this (I didn't find a RFC)? This smells more like what rlogin does... Telnet doesn't need to be passing environment variables, since I might be telnetting to a VMS machine, or a CYBER... Please don't use rlogin, which is a BSD-centric UNIXism, as a basis for anything. Instead, look at RFC1091 terminal type negotiation. The client might look at the environment to decide how to negotiate, but it shouldn't assume that the server knows or cares what an environment is. Clients on "environment"less machines should know other ways to find out what terminal types they're to claim to support.
henry@zoo.toronto.edu (Henry Spencer) (08/14/90)
In article <12461@hydra.gatech.EDU> gs26@prism.gatech.EDU (Glenn R. Stone) writes: >> What I was thinking of doing was passing the magic-cookie [DISPLAY variable] >>to the remote-end through another Telnet option... > >This smells more like what rlogin does... Telnet doesn't need to be passing >environment variables, since I might (and do, occasionally) be telnetting >to a VMS machine, or (angels and ministers of grace defend us) a CYBER... This is why Telnet options are --> options <--, so that systems which don't understand a particular option can reject it. Modern telnet can do everything rlogin can, and better, and it's a documented standard. -- It is not possible to both understand | Henry Spencer at U of Toronto Zoology and appreciate Intel CPUs. -D.Wolfskill| henry@zoo.toronto.edu utzoo!henry
gumby@Cygnus.COM (David Vinayak Wallace) (08/14/90)
Date: 13 Aug 90 13:22:51 GMT From: bob@MorningStar.Com (Bob Sutterfield) Please don't use rlogin, which is a BSD-centric UNIXism, as a basis for anything. Instead, look at RFC1091 terminal type negotiation. Or better, look at protocols like SUPDUP, which gets away from terminal NAMES and just talks about terminal CAPABILITIES. It amazed me that when Unix finally got a window system, the first thing implemented was an emulator for a specific kind of terminal!
moore@DALE.FAC.CS.CMU.EDU (Dale Moore) (08/17/90)
In article <12461@hydra.gatech.EDU>, gs26@prism.gatech.EDU (Glenn R. Stone) writes: |> In <2432@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: |> |> > What I was thinking of doing was passing the magic-cookie [DISPLAY variable] |> >to the remote-end through another Telnet option. Has anyone else thought |> >about/done this (I didn't find a RFC)? Does any one have any comments |> >on the good/badness of this? |> |> This smells more like what rlogin does... Telnet doesn't need to be passing |> environment variables, since I might (and do, occasionally) be telnetting |> to a VMS machine, or (angels and ministers of grace defend us) a CYBER... |> See RFC 1096 for one way to pass the DISPLAY environment variable from telnet client to telnet server. Dale Moore Senior Research Systems Programmer School of Computer Science Carnegie Mellon University