組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：boniter（boniter@etang.com）
譯文發布時間：2001-11-24
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。

Network Working Group                                          D. Borman
Request for Comments: 1571                           Cray Research, Inc.
Updates: 1408                                               January 1994
Category: Informational

TELNET環境選項互用性問題
（RFC1571——Telnet Environment Option Interoperability Issues）

本備忘錄的狀態
    本備忘錄向Internet社會提供了信息。本備忘錄并不詳細說明任何一種Internet標準。
此備忘錄的發布是無限的。
目錄
1、總觀點	1
2、客戶端Telnet：解析SEND	2
3、服務器Telnet:解析IS或INFO	2
4、客戶端總結	3
5、服務器總結	3
參考書目	4
安全考慮	4
作者地址	4

1、總觀點
    RFC 1408 [1],Telnet環境選項的規范書，詳細說明了與Telnet環境選項中BSD執行
相反的VAR和VALUE。因為BSD是RFC對于文檔假想的參考執行，并以許多已存在的執行為
基礎，所以在帶有定義沖突的VAR和VALUE的執行之間就存在互用性問題。
    這片文檔描述了一個方法，它允許執行者確定它們的環境選項的執行能與盡可能多的執
行共同操作，這是通過提供一種啟發式的機制來實現的，而這種機制能用來幫助識別連接另
一端正在使用的VAR和VALUE定義。

2、客戶端Telnet：解析SEND
SEND潛在選項應該只包含VAR和USERVAR命令。它應該不包含VALUE。如果在解析SEND
潛在選項時遇見了VALUE，客戶端可以假定服務器已經顛倒了VAR和VALUE的值，在客
戶的觀點應該翻轉那些值，同樣在解析剩下的SEND潛在選項和產生IS和INFO潛在選
項時。如果VALUE和VAR命令都被遇見，SEND命令就不能很好的成形，并且它被執行依
賴于將要發生什么。
    如果在SEND潛在選項中沒有VAR和VALUE命令，那么客戶端就不知道服務器所期
望的VAR和VALUE的值。在這種情況下，只需假定服務器有正確的定義，并使用VAR和
VALUE的正確的值。

3、服務器Telnet:解析IS或INFO
在潛在選項中的IS或INFO只能被VAR或USERVAR合法地跟隨。如果IS或INFO立即跟
隨了VAR，那么可以假定客戶端有正確的VAR和VALUE定義。如果IS或INFO立即跟隨
了VALUE，那么可以假定客戶端顛倒了VAR和VALUE的定義，在服務器的觀點應該假定
VALUE和VAR的定義被顛倒了。
    如果IS或INFO立即跟隨了USERVAR，進一步的啟發必須被應用來確定什么是客戶
端對于VAR和VALUE的定義。這是因為只有跟隨VAR或VALUE的USERVAR才是合法的。
USERVAR后的VALUE給定了USERVAR的值。USERVAR后的VAR意味著USERVAR未被定義。
    接下來要做的就是掃描全部的潛在選項，尋找兩個VAR或VALUE連貫的情況，或是
VAR或VALUE為空的情況。一個潛在選項包含兩個并不介于VAR或USERVAR之間的值，
這被認為是不合法的，同樣的，一個潛在選項包含一個空VAR也是被認為是不合法。因
此，如果兩個連貫的VAR或是空的VAR被發現，就可以假定產生潛在選項的客戶端使用
了正確的VAR和VALUE定義。如果兩個連貫的VALUE或是空的VAR被發現，就可以假定
產生潛在選項的客戶端顛倒了VAR和VALUE的定義，從服務器的觀點應該假定VAR和
VALUE的定義被顛倒了。
    如果仍然有所疑問的話，接下來的測試可以被應用來把接收到多少VAR,USERVAR和
VALUE加起來。（并不介于VALUE或VAR之間的連貫的USERVAR被加時應該只能算作一
個。）因為一個VALUE只能跟隨一個VAR或者一個USERVAR，而且如果所有的VAR和
USERVAR都有值，那么將有與VAR和USERVAR同樣多的VALUE是正確的。如果VAR和
USERVAR的數量與VALUE的總數量相同，那么客戶端對于VAR和VALUE有正確的定義。
如果VAR和USERVAR的數量與VAR的總數量相同，那么客戶端對于VAR和VALUE的定義
顛倒了。
    如果VALUE的數量比VAR和USERVAR的總和還要多，就可以假定客戶端已經顛倒了
VAR和VALUE的定義，并且如果有比USERVAR和VALUE更多的VAR，那么可以假定客戶
端對于VAR和VALUE有正確的定義。盡管如此，為了達到這一步，已經確定了沒有連貫
的VAR和VALUE。一些小的數學運算可以展示這意味著VALUE的數量將永遠不會超過VAR
和USERVAR的總和，而且VAR的數量也永遠不會超過VALUE和USERVAR的總和。從此，
這種核查就變成多余的，可以被跳過。
    如果還是有疑惑的話，VAR命令的值能被用來檢驗他們確實定義了眾所周知的變量。
如果他們中任何人這樣做了，那么客戶端大概正在使用對于VAR和VALUE的正確定義。
否則的話，如果任何VALUE包含了眾所周知的變量名，那么客戶端也許已經顛倒了對于
VAR和VALUE的定義。
    如果以上所有的啟發失敗了，那么服務器已經做了所有的來確定客戶端的類型，并
且它應該只須假定客戶端正在使用VAR和VALUE的正確定義。

4、客戶端總結
只包含VAR和USERVAR命令的SEND潛在選項。
      服務器正常。
包含VALUE命令的SEND潛在選項。
      服務器被顛倒。
找不到VAR或VALUE命令。
      假定服務器正常。

5、服務器總結
    IS/INFO被VAR跟隨。
         客戶端正常。
    IS/INFO被VALUE跟隨。
       客戶端被顛倒。
    有連續兩個VAR。
       客戶端正常。
    有連續的VALUE。
       客戶端被顛倒。
    有空的VALUE。
       客戶端正常。
    有空的VAR。
       客戶端被顛倒。
    USERVAR和VAR的數量與VALUE的數量相同。
       假定客戶端正常。
    USERVAR和VALUE的數量與VAR的數量相同。
       假定客戶端被顛倒。
    有包含眾所周知的名稱的VAR。
       假定客戶端正常。
    有包含眾所周知的名稱的VALUE。
       假定客戶端被顛倒。
    其他
       假定客戶端正常。

參考書目
[1] Borman, D., Editor, "Telnet Environment Option", RFC 1408, Cray
       Research, Inc., January 1993.

安全考慮
    安全問題在此備忘錄中不討論。

作者地址
David A. Borman
    Cray Research, Inc.
    655F Lone Oak Drive
    Eagan, MN 55123

    Phone: (612) 452-6650
    EMail: dab@CRAY.COM

    Telnet Working Group Mailing List: telnet-ietf@CRAY.COM

RFC1571——Telnet Environment Option Interoperability Issues             TELNET環境選項互用性問題


1
RFC文檔中文翻譯計劃