3. 拟议的 Telnet 约定
3A.
服务方站点在初始时应假定回显由用户站点的进程执行, 直至被明确指示改变。如果用户站点能够逐字符发送, 那么在连接和登录建立之后, 用户可以向服务方站点发出命令切换到服务方站点回显 (server-site-echo), 然后再命令 (对服务方站点不可见) 其本地 Telnet 一并更改回显模式。
3B.
服务方进程应假定它接收到的字符集, 与"直接"连接到它的终端所能产生的字符集相同。(我们建议至少支持 128 字符的 ASCII。) 用户的 Telnet 可能必须识别双字符序列, 才能既产生大写和小写代码, 也产生控制代码。我们建议, 对于单一大小的终端, 用户能够设置大写或小写作为默认大小, 并能够指定一个大小切换字符 (case shift character)。用户还应能指定一个字符, 用来指示紧随其后敲击的字符要转换为相应的控制字符代码。后一项约定使终端直接产生的控制代码能够被用户系统识别, 从而实现向用户系统的转义。建立一项约定, 允许所有控制代码进入网络, 并允许网络的输出在进入服务方进程之前先送入服务方监视器, 这为向许多现有系统的转义提供了一种简单的机制。(对某些系统而言, 问题比这更复杂, 我们在下文进一步讨论。)
3C.
我们建议为 HT、VT 和 FF 的本地回显含义建立网络标准, 或者建立一项约定, 把这些字符的含义发送给服务方进程。例如, NLS(NIC) 需要跟踪打印头的位置, 在缺乏此类约定的情况下, 它会把这些字符代码转换为空格和换行。这意味着输出页面的呈现可能与输入时的呈现不同。如果输出时的页面能够按照输入时的样子排版, 将对用户有所帮助。
3D.
LF 字符的处理方式, 应与用户敲击"直接"连接到服务方系统的终端上的换行键所产生的效果一致。
3E.
回车符 (CR) 可能是造成相当多困难的根源。例如, 在输入时, 不同的系统、以及同一系统在不同时刻, 可能向终端和用户进程回显并传输不同的代码。一些监视器系统什么也不回显、只回显 CR、或回显 CRLF。一些系统向用户进程传输 CR、CRLF 或行结束码 (end of line, EOL)。用户进程可以控制回显或对其加以补充。考虑到网络连接每一端之间可能存在的各种组合, 以及它们彼此之间的关系, 若不采纳 2A 的定义和 2E 的实现约定, 混乱便可能出现。这些假设意味着: 敲击 CR 时, 网络上传送的就是一个 CR。如果用户监视器系统或终端控制硬件把 CR 转换为 CRLF 或 EOL, 那么 Telnet 程序必须把它转换回 CR。当 CR 到达服务方监视器时, 监视器会为服务方进程妥善处理它。
当回显由服务方系统处理时, 会被回显的是正确的代码。用户 Telnet 在接收到 CRLF 时, 可以用适当的空字符 (null) 填充, 以处理特定终端的回车移动时序。
当回显由用户系统处理时, 理想情况是用户的 Telnet 或系统采用与服务方系统相同的回显约定。这意味着, Telnet 要么必须为它可以连接的各种系统维护一张回显约定表, 要么能够从服务方系统或进程获取该信息, 或者反过来由服务方获取。
对于一个初始的 Telnet 协议而言, 这可能并无必要。用户系统可以采用默认做法: 每接收到一个 CR 就回显一个 CRLF。对于我们熟悉的所有情形以及 NIC 来说, 这个默认做法应当是令人满意的。
3F.
为了与逐字符系统和逐行系统通信, Telnet 进程可能需要识别一个字符 (由用户指定), 我们称之为流结束 (end of stream, EOS)。该字符应具备下文讨论所定义的功能。关键在于把流结束 (end-of-stream) 作为一种网络功能, 与作为用户或服务方系统功能的行结束 (end-of-line) 区分开来。首先考虑逐行系统。我们对逐行系统的经验不多, 因此下文还需要进一步研究和澄清。据我们理解, 逐行系统识别某个字符 (例如 CR 或断开信号) 作为唤醒用户进程并把一行文本传送给它的代码。从 NLS(NIC) 的角度出发, 重要的一点是: 用户既能在适当的时候输入以 CR 结尾的文本行, 又能在其他时候输入不以 CR 结尾的文本。(NLS(NIC) 的一条语句是长度"任意"的字符串, 其中不必含有 CR; 输出时, 行会在用户的 (用户可定义的) 页面边界处折行。)
举一个说明需求的例子: 假设用户系统把 CR 识别为行结束。此时, Telnet 会在接收到 CR 时被唤醒。我们建议, 在这种情况下, CR 代码应原样写入 Telnet 输出缓冲区。如果 CR 前面有一个 EOS 字符, 那么 CR 就不应放入 Telnet 输出缓冲区。通过网络传输可以在接收到 EOS 时进行, 也可以在 Telnet 输出缓冲区填满时自动进行。从逐行系统向逐字符系统传输时, 可能需要别扭地敲击三个键才能把一个字符送过网络。
现在考虑从逐字符系统向作为逐行系统的服务方传输。类似的问题也存在于逐行系统之间。有了与 CR 不同的 EOS 字符定义, 就可以把一行内容缓冲起来, 直到接收到 EOS 再发送, 且不发送 EOS。服务方系统如何知道已经发送了一行? 一种办法是让服务方 NCP 识别报文边界。这一约定会违背一项设计目标。另一种办法是让用户 Telnet 请求其 NCP 发送一条 INS 命令。发送 INS 类型的控制命令可能在网络中引入竞态条件 (race conditions), 在确定将其用于 Telnet 进程之前应当先行研究。由于我们所知的一些逐行系统具有识别行结束信号的专用硬件, 我们需要找到某种借助软件控制信号与这类硬件兼容的办法。我们把这个问题留给 NWG 子小组进一步研究。
3G.
现在回到在远程服务方系统中中断或转义的问题。对于在输出进行期间不锁定输入键盘的系统, 上述机制和约定似乎已经足够, 除非转义信号是一个特殊的断开信号 (break signal)。后一种情况需要更多研究。对于在输出发生期间不允许输入的系统, 人们可能不得不接受这种终端使用方式的后果, 并准备好等待输出停止之后才能发送转义代码。如果键盘已被锁定, 而又能向用户系统发送转义断开信号, 那么它可以阻止输出到达终端, 但必须准备好继续从服务方站点接收输出, 直到用户能够通知其 Telnet 进程向服务方站点发送中断或转义信号为止。这同样是一个有待进一步研究的问题。
网络信息中心的在线系统 (Online System) 运行在逐字符的监视器系统上, 本文确立的约定足以支持对它的访问。这些约定总结在附录 A 中。