科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网网络频道Comments on the new Telnet specifications(2)

Comments on the new Telnet specifications(2)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

Protocol Specification and TELNET Option Specification. In general I feel the new TELNET protocol is far superior to the previous version.

作者:论坛整理 来源:ZDNet网络安全 2007年12月26日

关键字: telnet命令 opentelnet linux telnet telnet入侵 telnet telnet端口

  • 评论
  • 分享微博
  • 分享邮件

    A more positive solution could be had by defining a "synch response" (SR) TELNET command. The SR command would be sent when the INS and DM had both been processed (ie, when the "synch" had been completely received). If a process should ever receive an SR when it has an option request outstanding, the request has been discarded and must be repeated. User processes which carry on option negotiations would be the generators of any "synch's" so they can handle discarded option requests as desired. Note that this assumes that the TELNET process itself will never generate a spontaneous "synch"; comments are solicited on this. Another possible solution would be to define a "TIMING-MARK" TELNET command (see "TELNET Timing Mark Option", NIC # 16238), which would be sent immediately following the DM of a "synch".

  The response to the TIMING-MARK (also to be defined) would mean the same as the proposed SR command.

  The final non-editorial comment concerns the need for some means of specifying horizontal tab positions and use. This is quite a nuisance when dealing with systems which normally handle tabs for local terminals. Perhaps this issue can be best handled with an appropriate option; comments are solicited.

  The only editorial comments are on the TELNET Protocol document, which I reference below by page number.

  On page 8 the parenthetical comment "(i.e., when a process at one end of a TELNET connection is 'blocked on input')" should either be removed or rewritten to avoid the (to me) incomprehensible phrase "blocked on input." If additional discussion is felt to be necessary, I would propose "i.e., when a process at one end of a TELNET connection cannot proceed without additional input)." If examples are felt necessary, I would propose "(e.g., in the state characterized by the Multics term 'blocked on input')." The parallel could also be drawn between the GA and the concept of a "read command" being issued to request more input.

  On page 10 I feel that there needs to be some more discussion of the Abort Output (AO) command, particularly the statement that it "allows a process... to run to completion... but without sending the output to the user's terminal." The problem is that nothing is said about when output is to resume (presumably at the next system prompt character). I realized that the AO is meant only to invoke this function on systems which already provide it, but it would seem to be more useful if more fully specified.

  On page 11 I do not understand what the example "(e.g., an over-strike)" is trying to say. Speaking of an overstrike on output would imply to me that both characters are to be printed in the same print position, reducing the EC to a backspace. Some more discussion should also be added as to what EC (and EL) mean on output (if anything).

  On page 11 I would like to see the word "promptly" (which is in quotation marks) either eliminated or defined, as per my earlier aside comment. The phrase "if necessary" in the last line also seems unnecessary.

  On page 12 my proposed redefinition of "interesting" signals would remove the middle paragraph entirely and would modify the third paragraph substantially. The line "discard all characters which would have had an effect on the NVT printer" should be changed, however, as it seems BELL's should also be discarded.

  On page 14 I see no reason why the sequence "CR NUL" is required to generate a "CR" only, and also object to "and the CR character must be avoided in other contexts." Either some supporting discussion should be added or this restriction should be removed.

  [ This RFCwas put into machine readable form for entry ]

  [ into the online RFCarchives by Alex McKenzie with ]

  [ support from GTE, formerly BBN Corp. 9/99 ] 

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章