组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：&nbsp;&nbsp;&nbsp;（&nbsp;&nbsp;）<br />
译文发布时间：2001-10-23<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;Postel<br />
Request&nbsp;for&nbsp;Comments:&nbsp;855&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;J.&nbsp;Reynolds<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISI<br />
Obsoletes:&nbsp;NIC&nbsp;18640&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;May&nbsp;1983<br />
<br />
<br />
TELNET选项规范<br />
（RFC855——TELNET&nbsp;OPTION&nbsp;SPECIFICATIONS）<br />
<br />
<br />
本RFC指定了一个ARPA互联网社区的标准。在ARPA互联网上的主机应该采纳与实<br />
现该标准。<br />
<br />
给TELNET协议提供一些选项的目的是，使相互通信的主机在解决不同设备之间的通<br />
信问题时获得比由网络虚拟终端（NVT）提供的可能框架更好的方案。它可以让主机自由地<br />
创建，测试或者丢弃某些选项。当然，可以想象，那些普遍有用的选项最终大部分的主机都<br />
应该支持。因此，应该仔细地设计这些选项的文档，并且尽可能地公布它们。另外，确保不<br />
在不同的选项中使用相同的选项代码也是必要的。<br />
<br />
本文档指定了一个选项代码的分配和选项的文档标准方面的方法。在进行试验时，可能<br />
只需要选项代码分配而不需要完整的文档，不过一般来说，在分配选项代码之前都需要一个<br />
文档。我们通过把一个选项的文档作为一个RFC文档来发布，从而发布该选项。当然，选<br />
项的创建者也可以用其他的方式发布选项。<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;选项代码由下面人员分配：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Jonathan&nbsp;B。&nbsp;Postel<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;University&nbsp;of&nbsp;Southern&nbsp;California<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Information&nbsp;Sciences&nbsp;Institute&nbsp;(USC-ISI)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4676&nbsp;Admiralty&nbsp;Way<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Marina&nbsp;Del&nbsp;Rey,&nbsp;California&nbsp;90291<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(213)&nbsp;822-1511<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mailbox&nbsp;=&nbsp;POSTEL@USC-ISIF<br />
<br />
选项的文档至少要包含下面几个小节：<br />
<br />
第1节&nbsp;-&nbsp;-&nbsp;命令的名称和选项的代码<br />
<br />
第2节&nbsp;-&nbsp;-&nbsp;命令的意义<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;应该描述同该选项相关的每一个TELNET命令的意义。需要注意的是，对于复杂的选<br />
项，“子谈判”是必需的，因此可能有许多相关的命令。“子谈判”的原理在下面有更详细的<br />
描述。<br />
<br />
第3节&nbsp;-&nbsp;缺省的规范<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;对那些没有实现，或者没有使用该选项的主机，必须描述这些选项在这些主机中的缺省<br />
假定值。<br />
<br />
第4节&nbsp;-&nbsp;动机<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;对创建一个特殊的选项，或者对某种选项选择一种特殊的格式的动机进行详细的描述，<br />
对那些还没有碰到（或者虽然已经碰到，但没有认识到）该选项被设计来解决什么的问题的<br />
人，是非常有用的。<br />
<br />
第5节&nbsp;-&nbsp;描述（或者实现规则）<br />
<br />
为了确保一个命令的两个不同实现相互之间能够通讯，仅仅定义命令的意义和对该命令的意<br />
图进行说明有时候是远远不够的。因此，在许多情况下，我们需要给一个命令提供一个完整<br />
的描述。这个描述可以用文本来表示，也可以是一个示例性的实现，或者是实现的线索等等。<br />
<br />
对“子谈判”的解释<br />
<br />
在主机之间传递选项时，除了一个选项编码外可能还需要更多其他信息。例如，要求一个参<br />
数的那些选项就属于这种情况。在主机之间传递除了选项代码外的其他信息的策略包含两个<br />
步骤：双方都同意去”商讨“该参数，第二，对参数进行”商讨“。<br />
<br />
在第一步中，同意去商讨参数以一种普通的方式来进行。一方通过发送一个带有选项代码的<br />
DO(或WILL)命令来建议使用选项，另一方发送一个带有选项代码的DO(或WILL)命令来表<br />
示接受这个建议。一旦双方都同意使用这选项，通过在SB命令的后面跟上相应的选项代码，<br />
参数和命令SE来开始子谈判。每一方都被假设为能够解析该参数。因为在最初通过交换<br />
WILL和DO命令，双方都表明可以支持该选项。另外，即使接收方不能解析该参数，接收<br />
方也可以通过搜索SE命令（如字符串IAC&nbsp;SE）来定位参数字符串的结束位置。当然，在<br />
任何时候，任何一方都可以给另一方发送WON'T或DON'T来拒绝继续进行进一步的子谈<br />
判。<br />
<br />
因此，对需要进行子谈判的选项“ABC”来说，TELNET的格式为：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IAC&nbsp;WILL&nbsp;ABC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;提议使用选项ABC（或者赞成另一方使用该选项的请求）<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IAC&nbsp;DO&nbsp;ABC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;要求另一方去使用选项ABC（或者赞成另一方使用该选项的提议）<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IAC&nbsp;SB&nbsp;ABC&nbsp;&nbsp;IAC&nbsp;SE<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;子谈判的一步，双方都要使用<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;设计那些需要进行“子谈判”的选项的设计者必须小心避免子谈判过程中的无穷尽的<br />
循环。比如，<br />
&nbsp;&nbsp;&nbsp;&nbsp;如果每一方都可以接受一个参数的任何值，而每一方都给该参数提出一个不同的值，那<br />
么一方可能将进入无穷的“应答”过程中（因为每一个接收者都认为只要应答另一方的提议）。<br />
最后，如果在一个“子谈判”中的参数包含一个值为255的字节，对应于TELNET的通用<br />
规则，必须把该值加倍。<br />
<br />
<br />
RFC855——TELNET&nbsp;OPTION&nbsp;SPECIFICATIONS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TELNET选项规范<br />
<br />
<br />
3<br />
RFC文档中文翻译计划<br />