dwaitzma@bbn.com (David Waitzman) (12/20/88)
In article <11024@ulysses.homer.nj.att.com> Steven M. Bellovin writes: >The proposed window size option is good as far as it goes; perhaps, though, >that it should include the size in pixels (whatever they are) as well. >More and more terminals are bit-mapped; the information is probably >going to be needed. If the terminal doesn't support the concept, 0 can >be passed in those fields. Thank you for the comments on my RFC (RFC-1073). The option, as implemented at Carnegie-Mellon University, was a more general window information option, that included the display location (X specific), and the terminal size in pixels. For general use, the option was simplified. A very complex window/terminal information option, with lots of suboptions, could be difficult. It wasn't clear to me how to handle negotiation of suboptions without reimplementing the regular telnet option negotiation code. In the near future, we shouldn't use up the first level of telnet option numbers, so just creating new options, with the NIC's blessing, seems ok to me. One problem with a proliferation of options is the inability to negotiate a group of related options at once. Suppose there are three important telnet options relating to a particular windowing system, if one end of the connection accepts the first two, and declines the third option, the other end of the connection might be confused. This is why my telnet window size RFC passes the row and column sizes in one option- they are usually too tighly bound for either to be meaningful without the other. By allowing a 0 size to mean that the row or column size is not being sent, I accommodate strange cases. This is, perhaps, a fine line. Future telnet options might include (ordered from highest to lowest probability of definition): - pixel size, as you suggested; - user id's/password (I believe someone is working on this); - window location (X specific, and for other windowing systems); - sending of mouse position, and button pushing; - available display field types (bold, inverse, underlined), etc, along with a way to specify them; - available colors, along with a way to specify them; - " fonts """; - " voice/sound channels """. Basically, we might one day telnet to a host, and run a color WYSIWYG word processor on it through the telnet connection. Of course, this is re-inventing a networked window system. So, where do we draw the line for what telnet should do? In summary, if you want to pass pixel size, please write a new telnet option RFC. -david (617)873-4323, dwaitzman@bbn.com