General Considerations (一般性考虑)

TELNET连接 (TELNET Connection) 是一个传输控制协议 (TCP, Transmission Control Protocol) 连接，用于传输数据并穿插TELNET控制信息 (Control Information)。

TELNET协议基于三个主要思想构建: 首先是"网络虚拟终端" (Network Virtual Terminal) 的概念; 其次是协商选项 (Negotiated Options) 的原则; 第三是终端和进程的对称视图 (Symmetric View)。

当TELNET连接首次建立时，假定每一端都起源并终止于一个"网络虚拟终端" (Network Virtual Terminal, NVT)。NVT是一个虚拟设备 (Imaginary Device)，它提供了一个标准的、网络范围的、规范终端 (Canonical Terminal) 的中间表示 (Intermediate Representation)。这消除了"服务器" (Server) 和"用户" (User) 主机需要保留彼此终端特性和终端处理约定信息的需求。所有主机，无论是用户还是服务器，都映射其本地设备特性和约定，使其看起来像是在网络上与NVT打交道，并且每个主机都可以假设对方也进行了类似的映射。NVT旨在在过度受限 (不为主机提供足够丰富的词汇表来映射到其本地字符集) 和过度包容 (使具有简单终端的用户受到惩罚) 之间取得平衡。

注意: "用户"主机是物理终端通常连接到的主机，"服务器"主机是通常提供某种服务的主机。作为另一种观点，即使在终端到终端或进程到进程的通信中也适用，"用户"主机是发起通信的主机。
协商选项的原则认识到这样一个事实: 许多主机将希望在NVT可用的服务之外提供额外的服务，而许多用户将拥有复杂的终端，并希望拥有优雅而非最小的服务。独立于但结构化于TELNET协议内的是各种"选项" (Options)，这些选项将被认可，并可与"DO, DON'T, WILL, WON'T"结构 (下文讨论) 一起使用，以允许用户和服务器同意为其TELNET连接使用更精细 (或可能只是不同) 的约定集。此类选项可能包括更改字符集 (Character Set)、回显模式 (Echo Mode) 等。

建立选项使用的基本策略是让任一方 (或双方) 发起请求，要求某个选项生效。另一方可以接受或拒绝该请求。如果请求被接受，该选项立即生效; 如果被拒绝，连接的相关方面保持为NVT所指定的状态。显然，一方总是可以拒绝启用的请求，并且必须永远不拒绝禁用某个选项的请求，因为所有各方都必须准备支持NVT。

选项协商的语法已经建立，以便如果双方同时请求一个选项，每一方都会将对方的请求视为对自己请求的肯定确认。
协商语法的对称性可能会导致不终止的确认循环 (Nonterminating Acknowledgment Loops) -- 每一方都将传入的命令视为新的请求而不是确认，这些请求必须被确认。为了防止此类循环，以下规则占主导地位:

a. 各方只能请求选项状态的变化; 即，一方不能仅仅为了宣布其所处的模式而发出"请求"。

b. 如果一方收到似乎是进入其已经处于的某种模式的请求，则不应确认该请求。这种非响应对于防止协商中的无限循环至关重要。要求对模式更改请求发送响应 -- 即使模式未更改。

c. 每当一方向第二方发送选项命令时，无论是作为请求还是确认，如果该选项的使用将对从第一方发送到第二方的数据处理产生任何影响，则该命令必须插入到数据流中期望其生效的位置。(应当注意，从请求的传输到收到确认之间将经过一些时间，该确认可能是否定的。因此，主机可能希望在请求选项后缓冲数据，直到它得知请求是被接受还是被拒绝，以便向用户隐藏"不确定期" (Uncertainty Period)。)

当TELNET连接首次建立时，选项请求可能会来回激增，因为每一方都试图从另一方获得最佳可能的服务。然而，除此之外，选项可用于动态修改连接的特性以适应不断变化的本地条件。例如，NVT (如后面将解释的) 使用一种传输规则，非常适合许多"逐行" (Line at a Time) 应用程序 (如BASIC)，但不太适合许多"逐字符" (Character at a Time) 应用程序 (如NLS)。当适合本地进程时，服务器可能会选择投入"逐字符"规则所需的额外处理器开销，并协商适当的选项。然而，它可以在不再需要详细控制时切换 (即协商) 回NVT，而不是永久承担额外的处理开销。

如果进程通过简单地重新请求选项来响应拒绝，则进程发起的请求可能会刺激不终止的请求循环。为了防止发生此类循环，在某些事情发生变化之前不应重复被拒绝的请求。在操作上，这可能意味着进程正在运行不同的程序，或者用户已给出另一个命令，或者在给定进程和给定选项的上下文中有意义的任何内容。一个好的经验法则是，重新请求应仅作为来自连接另一端的后续信息的结果或在本地人工干预要求时发生。

选项设计者不应感到受到选项协商可用的某种有限语法的约束。简单语法的意图是使拥有选项变得容易 -- 因为相应地易于宣称对它们的无知。如果某个特定选项需要比"DO, DON'T, WILL, WON'T"内可能的更丰富的协商结构，正确的做法是使用"DO, DON'T, WILL, WON'T"来确立双方都理解该选项，一旦完成此操作，就可以自由使用更复杂的语法。例如，一方可能发送请求以改变 (建立) 行长度 (Line Length)。如果被接受，则可以使用不同的语法来实际协商行长度 -- 这种"子协商" (Sub-Negotiation) 可能包括最小允许、最大允许和期望行长度的字段。重要的概念是，这种扩展的协商永远不应该开始，直到某个先前的 (标准) 协商已经确立双方都能够解析扩展的语法。

总之，任一方发送WILL XXX以指示该方希望 (提议, Offer) 开始执行选项XXX，DO XXX和DON'T XXX是其肯定和否定确认; 类似地，发送DO XXX以指示希望 (请求, Request) 另一方 (即DO的接收者) 开始执行选项XXX，WILL XXX和WON'T XXX是肯定和否定确认。由于NVT是未启用任何选项时剩下的内容，因此DON'T和WON'T响应可以保证将连接保持在双方都可以处理的状态。因此，所有主机都可以实现其TELNET进程完全不知道不支持的选项，只需对无法理解的任何选项请求返回拒绝 (即拒绝)。

TELNET协议已尽可能地实现服务器-用户对称，以便它轻松自然地涵盖用户-用户 (链接, Linking) 和服务器-服务器 (协作进程, Cooperating Processes) 情况。希望但不是绝对要求选项进一步实现这一意图。无论如何，明确承认对称性是一个操作原则而不是铁律。

应查阅伴随文档"TELNET选项规范" (TELNET Option Specifications) 以获取有关建立新选项的过程的信息。