Telnet远程登录 相关协议 RFC.docx
《Telnet远程登录 相关协议 RFC.docx》由会员分享，可在线阅读，更多相关《Telnet远程登录 相关协议 RFC.docx（21页珍藏版）》请在冰点文库上搜索。
Telnet远程登录相关协议RFC
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
（）
译文发布时间：
2001-10-23
版权：
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。
NetworkWorkingGroupJ.Postel
RequestforComments:
855J.Reynolds
ISI
Obsoletes:
NIC18640May1983
TELNET选项规范
（RFC855——TELNETOPTIONSPECIFICATIONS）
本RFC指定了一个ARPA互联网社区的标准。
在ARPA互联网上的主机应该采纳与实
现该标准。
给TELNET协议提供一些选项的目的是，使相互通信的主机在解决不同设备之间的通
信问题时获得比由网络虚拟终端（NVT）提供的可能框架更好的方案。
它可以让主机自由地
创建，测试或者丢弃某些选项。
当然，可以想象，那些普遍有用的选项最终大部分的主机都
应该支持。
因此，应该仔细地设计这些选项的文档，并且尽可能地公布它们。
另外，确保不
在不同的选项中使用相同的选项代码也是必要的。
本文档指定了一个选项代码的分配和选项的文档标准方面的方法。
在进行试验时，可能
只需要选项代码分配而不需要完整的文档，不过一般来说，在分配选项代码之前都需要一个
文档。
我们通过把一个选项的文档作为一个RFC文档来发布，从而发布该选项。
当然，选
项的创建者也可以用其他的方式发布选项。
选项代码由下面人员分配：
JonathanB。
Postel
UniversityofSouthernCalifornia
InformationSciencesInstitute（USC-ISI）
4676AdmiraltyWay
MarinaDelRey,California90291
（213）822-1511
Mailbox=POSTEL@USC-ISIF
选项的文档至少要包含下面几个小节：
第1节--命令的名称和选项的代码
第2节--命令的意义
应该描述同该选项相关的每一个TELNET命令的意义。
需要注意的是，对于复杂的选
项，“子谈判”是必需的，因此可能有许多相关的命令。
“子谈判”的原理在下面有更详细的
描述。
第3节-缺省的规范
对那些没有实现，或者没有使用该选项的主机，必须描述这些选项在这些主机中的缺省
假定值。
第4节-动机
对创建一个特殊的选项，或者对某种选项选择一种特殊的格式的动机进行详细的描述，
对那些还没有碰到（或者虽然已经碰到，但没有认识到）该选项被设计来解决什么的问题的
人，是非常有用的。
第5节-描述（或者实现规则）
为了确保一个命令的两个不同实现相互之间能够通讯，仅仅定义命令的意义和对该命令的意
图进行说明有时候是远远不够的。
因此，在许多情况下，我们需要给一个命令提供一个完整
的描述。
这个描述可以用文本来表示，也可以是一个示例性的实现，或者是实现的线索等等。
对“子谈判”的解释
在主机之间传递选项时，除了一个选项编码外可能还需要更多其他信息。
例如，要求一个参
数的那些选项就属于这种情况。
在主机之间传递除了选项代码外的其他信息的策略包含两个
步骤：
双方都同意去”商讨“该参数，第二，对参数进行”商讨“。
在第一步中，同意去商讨参数以一种普通的方式来进行。
一方通过发送一个带有选项代码的
DO（或WILL）命令来建议使用选项，另一方发送一个带有选项代码的DO（或WILL）命令来表
示接受这个建议。
一旦双方都同意使用这选项，通过在SB命令的后面跟上相应的选项代码，
参数和命令SE来开始子谈判。
每一方都被假设为能够解析该参数。
因为在最初通过交换
WILL和DO命令，双方都表明可以支持该选项。
另外，即使接收方不能解析该参数，接收
方也可以通过搜索SE命令（如字符串IACSE）来定位参数字符串的结束位置。
当然，在
任何时候，任何一方都可以给另一方发送WON'T或DON'T来拒绝继续进行进一步的子谈
判。
因此，对需要进行子谈判的选项“ABC”来说，TELNET的格式为：
IACWILLABC
提议使用选项ABC（或者赞成另一方使用该选项的请求）
IACDOABC
要求另一方去使用选项ABC（或者赞成另一方使用该选项的提议）
IACSBABCIACSE
子谈判的一步，双方都要使用
设计那些需要进行“子谈判”的选项的设计者必须小心避免子谈判过程中的无穷尽的
循环。
比如，
如果每一方都可以接受一个参数的任何值，而每一方都给该参数提出一个不同的值，那
么一方可能将进入无穷的“应答”过程中（因为每一个接收者都认为只要应答另一方的提议）。
最后，如果在一个“子谈判”中的参数包含一个值为255的字节，对应于TELNET的通用
规则，必须把该值加倍。
RFC855——TELNETOPTIONSPECIFICATIONSTELNET选项规范
3
RFC文档中文翻译计划
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
顾国飞（ggfeiggfei@）
译文发布时间：
2001-4-2
版权：
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
NetworkWorkingGroupJ.Postel
RequestforComments:
856J.Reynolds
ISI
Obsoletes:
NIC15389May1983
RFC856TELNET二进制传输
（RFC856--TELNETBINARYTRANSMISSION）
本RFC规范了一个ARPAInternetcommunity上的标准。
在ARPAInternet上的所有主机应当采用和实现这个标准。
目录
1.命令和代码1
2.命令意义1
3.默认情况2
4.选项出现的原因2
5.选项描述2
6.实现问题3
1.命令和代码
TRANSMIT-BINARY0
2.命令意义
*IACWILLTRANSMIT-BINARY
这个命令请求的发送方请求开始传输，或确定现在要传输的数据在接收方会以八位二进制方式解释。
*IACWON'TTRANSMIT-BINARY
如果连接已在二进制方式下，发送此命令要求接收方恢复原来标准的NVTASCII方式解释数据。
如果现在还未在二进制方式下，发送方拒绝传输将被接受者解释为二进制数据的字符（也就是说，数据传输者要求继续按现在方式进行传输）。
只有当双方均同意的情况下才有可能进行二进制传输。
*IACDOTRANSMIT-BINARY
发送者要求传输数据，或确定数据将要被传输，这些数据均被解释为8位二进制的。
*IACDON'TTRANSMIT-BINARY
如果现在处于二进制状态下，命令发送方要求数据发送方进行标准的NTVASCII的传输。
如果连接未在二进制状态下，发出命令者要求数据发送方按现在的状态发送数据。
只有当双方均同意的情况下才有可能进行二进制传输。
3.默认情况
默认情况为：
WON'TTRANSMIT-BINARY和DON'TTRANSMIT-BINARY，连接未在二进制状态下。
4.选项出现的原因
有时候利用telnet上的二进制传输会更有效率，这就是出现的根本原因吧。
而双方只要把对数据的解释方式加以改变就可以完成这一选项，因此也比较方便。
5.选项描述
开始二进制传输后，接收方对没有IAC开始的数据以二进制进行解释。
IAC后面的是标准的TELNET命令。
如果IAC后面的命令不可识别，它和IACNOP命令的效果一样。
6.实现问题
实现二进制传输则不能进行其它模式的传输，这是可以预见的。
然而，如果双方能够理解它们同处于二进制传输模式或者例如它们同处于Echo模式，如果他们对此进行了协商，则不会出现什么问题。
我们看到上面的命令意义解释可以注意到WON'T和DON'T的意义要看现在是不是处于二进制传输模式下，假设现在处于EBCDIC模式下，而且一方也不知道任何二进制传输的命令，如果它接收到DOTRANSMIT-BINARY，它根本不知道这是什么，因此返回WON'TTRANSMIT-BINARY，如果对于WON'TTRANSMIT-BINARY的默认值是NVTASCII，发送DOTRANSMIT-BINARY可能希望接收方转到NVTASCII，但接收DOTRANSMIT-BINARY的一方有可能不这么做。
因此，我们有这样一条规则：
当连接不处于二进制状态时，默认值（也就是说，对WON'T和DON'T的解释）是维持现状，无论是在在NVTASCII,EBCDIC或者是其他状态。
然而，当连接处于二进制状态时，这规则就不顶用了。
这就要求连接双方维持一个保存所有可用的连接状态的栈，这样才能正确解释WON'T和DON'T。
在二进制状态下，WON'T和DON'T会使状态返回NVTASCII。
因为telnet是一个双向的通道，因此必须保证双向的数据流都是二进制的。
在实现时遵守防止循环的规则，这一规则在telnet协议中有描述。
下面我们看看从一个进程和终端开始或接收二进制传输的情况：
a.从终端开始二进制传输
实现者应该考虑在二进制状态下如何产生8位有效数据，其中不带什么校验位之类的东西。
b.二进制传输到进程
实现者应该考虑在二进制状态下进行如何接收所有的二进制数据。
例如TOPS-20会在终端级解释一些特定字符（例如，ETX,中断control-C），而不把它们传送到进程。
c.从进程开始的二进制传输
实现者应该考虑传输的字符如何不对对方的终端解释为其它的字符。
例如TOPS-20会将非打印字符转为一个箭头和一个可打印字符。
d.二进制传输到终端
实现者应该考虑接收到的数据如何传送到本地终端。
包括本地应该加入的一些字符，校验运算或字符转换。
RFC856TELNETBINARYTRANSMISSIONRFC856TELNET二进制传输
1
3
ＲＦＣ文档中文翻译计划
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
顾国飞（ggfeiggfei@）
译文发布时间：
2001-4-2
版权：
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
NetworkWorkingGroupJ.Postel
RequestforComments:
857J.Reynolds
ISI
Obsoletes:
NIC15390May1983
RFC857TELNETECHO选项
（RFC857-TELNETECHOOPTION）
本RFC规范了一个ARPAInternetcommunity上的标准。
在ARPAInternet上的所有主机应当采用和实现这个标准。
目录
1.命令和代码1
2.命令意义2
3.默认值2
4.选项产生的原因2
5.选项描述2
6.例子4
1.命令和代码
ECHO1
2.命令意义
*IACWILLECHO
命令发送者请求开始或确定将要开始回复接发送者发出的数据字符。
*IACWON'TECHO
命令发送者要求停止或拒绝开始回复接收到的数据字符。
*IACDOECHO
命令发送者要求接收方开始回复或确定接收方要回复收到的数据字符。
*IACDON'TECHO
命令发送者要求此命令的接收者不要开始或停止回复收到的数据字符。
3.默认值
WON'TECHO，DON'TECHO是默认值，也即不进行回复。
4.选项产生的原因
NVT有一个显示设备的键盘，在通常情况下，键盘的输入会直接显示到显示设备上，在交互比较多的时候，对于要将字符到去进行控制的远程进程这是合适的方法。
我们可以设想一下聊天室里的情况加以理解，在这种情况就需要用这个选项，看起来象一个键盘控制两个显示设备。
5.选项描述
当此选项有效时，端终端需要将接收到的字符返回给发送者。
此选项并不要求返回的和接收的完全一样。
当未在echo选项状态时，接收者不返回数据给发送者，当然这不是说接收者就要给接收到的数据不加理会。
通常的连接是双向的，在一个方向上的数据流与另一个方面上的数据流没有什么关系。
下面是五种可能出现的情况：
此选项提供了决定一端是否对另一端数据进行返回。
如果不对另一端进行返回，那对自己进行不进行返回。
如果两端的主机都进行了echo状态，那会在连接上出现无限循环的状态，因此实现者在实现时要注意这种情况，一端返回的数据，另一端不要再返回了。
双方在建立连接的时候的默认状态时非echo状态。
如果一方决定要返回对方发出的数据，或希望对方这样做，由它发出相应的命令，并等待响应。
如果响应被拒绝，则仍然保持非echo状态；如果对方接受了请求，则连接进入echo状态，处于这样的状态下时，任何一方都可以解除echo状态，因为连接是双向的，因此不同方面的echo状态应该分别解除。
在实现时要遵守telnet协议中的循环防止规则。
因为在不同状态下的开关有时候会意义不清，因此要特别注意相应开关所在的状态。
例如一方以WILLECHO响应了DOECHO，则在DOECHO之后的所有字符均被返回，这一条无论是接收方还是发送方都应该牢记。
光是echo选项还不足以让远程计算机理解是在终端上输入的字符，因此要使用SUPPRESS-GOAHEAD选项进行相应的处理。
6.例子
下面是一个称为UHOST的简单实现。
其中用于非echo的值小于用于表示echo的值。
对于每个用户终端，UHOST保留三个状态位，是否对自己进行echo，用户是否希望在echo状态下工作，终端连接到服务器上时是否处于echo状态下，这三位我们称为P（物理），D（希望）和A（实际）位。
当终端拨号时，设置P位和D位，而A位设置为非echo，P位和D位可以通过相应的命令进行人为设置。
当UHOST和服务器的连接打开时，如果P位和D位的最小值小于A位，那就向服务器发出DOECHO命令，如果收到WON'TECHO或WILLECHO响应，UHOST会设置A位为接收到以下三值的最小值：
接收到的值，P位值，D位值。
如果需要改变A位当前的状态，UHOST要发出相应的确定信息，如果不改变A位当前的状态，则返回拒绝，表示自己不需要进行改变。
如果在连接打开时，UHOST终端改变了P位或D位的值，UHOST会重复上面的测试。
连接关闭时，UHOST会恢复A位值。
因为UHOST在连接打开时或用户显式改变ECHO状态时未涉及使用DOECHO和DON'TECHO命令，大型主机会频繁地进行这样的状态切换。
例如，当line-at-a-time系统运行时，服务器会试图通过WON'TECHO命令将用户设置为本地ECHO状态；但是当character-at-a-time系统运行时，服务器需要通过WILLECHO命令启动用户的远程ECHO。
而且，因为UHOST不会发出WILLECHO命令，只会发出WON'TECHO命令，服务器主机会频繁发出WILL和WON'T命令。
RFC857-TELNETECHOOPTIONRFC857TELNETECHO选项
1
1
ＲＦＣ文档中文翻译计划
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
顾国飞（ggfeiggfei@）
译文发布时间：
2001-4-2
版权：
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
NetworkWorkingGroupJ.Postel
RequestforComments:
859J.Reynolds
ISI
Obsoletes:
RFC651（NIC31154）May1983
RFC859TELNET的STATUS选项
（RFC859TELNETSTATUSOPTION）
本RFC规范了一个ARPAInternetcommunity上的标准。
在ARPAInternet上的所有主机应当采用和实现这个标准。
目录
1.命令和代码2
2.命令意义2
3.默认值2
4.选项产生的原因2
5.具体内容2
1.命令sss和代码
STATUS5
2.命令意义
此选项不同方便的数据流上使用。
*IACDON'TSTATUS
发送者拒绝进行就现在的状态选项提供进一步的信息。
*IACWON'TSTATUS
发送者拒绝进行就现在的状态选项提供进一步的信息。
*IACSBSTATUSSENDIACSE
发送者要求接收者返回它的当前选项状态。
*IACSBSTATUSIS...IACSE
发送者说明自己的选项状态。
3.默认值
DON'TSTATUS和WON'TSTATUS是默认值。
4.选项产生的原因
此选项使用户/进程可以远程查看telnet选项。
5.具体内容
WILL和DO仅用于获得对未来协商的许可。
而实际的状态信息则由下面的子命令进行传送。
一旦两主机交换了WILL和DO，WILLSTATUS的发送者就可以传送状态信息或对DO进行响应。
最差时会传送两次状态信息。
只有DO的传送者可以发出请求，只有WILL的发出者可以传送状态信息。
IS有子命令WILL，DO和SB，它们用于telent选项实际协商过程中，其中SB中以SE结尾，而不是IACSE。
传送SE时，象平常的数据字节一样，传送两次（SESE）。
如果选项未说明，则认为它们处于默认状态。
下面是使用选项的例子：
Host1:
IACDOSTATUS
Host2:
IACWILLSTATUS（此时HOST2可以发送状态信息了，最差时就发两次就行了）
Host1（perhaps）:
IACSBSTATUSSENDIACSE
Host2（下面的信息分为多行是为了阅读方便）
IACSBSTATUSIS
WILLECHO
DOSUPPRESS-GO-AHEAD
WILLSTATUS
DOSTATUS
IACSE
对Host2理解的解释：
回送（ECHOBACK）从TELNET连接中收到的数据字符是合理的；它不会送Go-Ahead信号，它将发送和请求Status信息.
RFC859TELNETSTATUSOPTIONRFC859TELNET的STATUS选项
1
2
ＲＦＣ文档中文翻译计划
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
顾国飞（ggfeiggfei@）
译文发布时间：
2001-4-2
版权：
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
NetworkWorkingGroupJ.Postel
RequestforComments:
860J.Reynolds
ISI
Obsoletes:
NIC16238May1983
RFC860TELNETTIMINGMARK选项
（RFC860TELNETTIMINGMARKOPTION）
本RFC规范了一个ARPAInternetcommunity上的标准。
在ARPAInternet上的所有主机应当采用和实现这个标准。
目录
1.命令名和代码2
2.命令意义2
3.默认值2
4.选项产生原因2
5.具体描述3
1.命令名和代码
TIMING-MARK6
2.命令意义
*IACDOTIMING-MARK
命令发出者要求接收者在数据流的适当位置返回一个WILLTIMING-MARK，具体位置在文章的后面加以说明。
*IACWILLTIMING-MARK
命令发出者确认接收者乐意进行同步，发出了DOTIMING-MARKING。
*IACWON'TTIMING-MARK
命令发出者拒绝在数据流中加上确定同步的命令。
*IACDON'TTIMING-MARK
命令发出者通过命令接收者原来收到的WILLTIMING-MARK被忽略了。
3.默认值
WON'TTIMING-MARK，DON'TTIMING-MARK，也就是说默认情况下不对telnet两端的活动进行同步。
4.选项产生原因
有时用户需要知道TELNET另一端已经将传输过去的数据处理完毕，这个选项此时就比较有用了，即使被拒绝进行同步，返回的拒绝代码也表示原来发出的数据都接收到了。
下面是一个例子，可以想象一个全双工服务器它允许用户在处理用户输入之前预先输入一些命令。
假设双方同意SuppressGoAhead选项，而且服务器同意提供回显。
现在服务器抛弃了一条不可知的命令，这条命令可能是用户的输入错误，服务器可能将用户所有预先输入的命令抛弃，并向用户发出一条错误命令，并且在用户看到错误信息后开始处理用户的新命令。
如果用户是本地的，系统可以抛弃缓冲的输入，但是用户输入可能在用户主机或其它地方缓冲。
因此服务器必须发出DOTIMING-MARK，并希望从在数据流的合适地方得到WILLTIMING-MARK。
这个合适的地方就是用户看到错误信息后输入的第一个字符。
在上例中，如果用户已经意识到自己输入错误，而希望在服务器做出反应前就纠正这个错误并回到预先输入状态。
它可以让自己的系统发出WILLTIMING-MARK给服务器，然后再次开始预先输入。
在这种情况下，合适的位置是由用户自己定义的。
在上面二例中，系统负责传输DOTIMING-MAR
升级会员 