给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的通用
规则，必须把该值加倍。
