TELNET終端類型選項

轉：http://www.cnpaf.net/Class/Telnet/200408/5.html

 

1． 命令名稱及編號
TERMINAL-TYPE24
2．命令含義
IACWILLTERMINAL-TYPE
發送者但願在接下來的子選項協商中發送終端類型信息。
IACWON'TTERMINAL-TYPE
發送者拒絕發送終端類型信息。
IACDOTERMINAL-TYPE
發送者但願在接下來的子選項協商中接收終端類型信息。
IACDON'TREMINAL-TYPE
發送者拒絕接受終端類型信息。
IACSBTERMINAL-TYPESENDIACSE
服務器要求客戶方傳送它的（客戶方的）下一個終端類型，並切換到仿真模式（若是它支持多個終端類型）。SEND的編碼爲1。（見下面）
IACSBTERMINAL-TYPEIS...IACSE
客戶方聲明本身當前的(或僅有的)終端類型。
4．使用選項的緣由
在大部分機器的位圖顯示器上（如PC機和圖形工做站），客戶方終端仿真程序被用來模擬傳統的ASCII終端。這些程序大部分都有多種仿真模式，一般特徵也多種多樣。同時，如今的主機系統軟件和應用能處理不少終端類型。所以，須要有一種方法：客戶向服務器提交一系列可用的終端仿真模式，服務器從中選出一個合適的模式（不管何種緣由）。另外,還須要一種機制:可以在會話過程當中，多是根據應用程序的須要,去改變仿真模式。Telnet中現有的終端類型傳送機制在設計時沒有考慮多仿真模式。雖然容許多個名字是，但它們被看做同義詞。仿真模式的變化沒有定義，而且全部的模式只能被檢查一次。

本文檔定義了對現存機制的簡單擴充，它知足上面的標準。假定執行動做按之前的標
準編碼，目的是得到充分的向後兼容性。
5．選項描述
在Telnet中，規定經過傳統的Telnet選項協商來自動交換終端類型信息。WILL和DO僅被用請求和受權許可，來爲後面的協商作準備。真正的狀態信息交換是在後面的子選項協商命令中進行的（IACSBTERMINAL—TYPE...）.一旦兩臺主機交換過WILL和DO後，發送DOTREMINAL-TYPE命令的主機（服務器）能夠任意的詢問終端類型信息。只有服務器可以發送詢問命令（IACSBTERMINAL-TYPESENDSE）也只有客戶方可以傳送真正的類型信息（用IACSETERMINAL-TYPEIS...IACSE命令）。終端類型信息不能自發的被傳送，只能是爲了響應請求而被髮出。終端類型信息是一個NVTASCII字符串。在這個字符串中,不區分大小寫。全部有效的終端類型名都夠在最新的「數字分配標識」RFC文檔中找到。當Telnet客戶爲響應服務器的詢問傳送終端類型信息時，就意味着客戶必須同步地改變仿真模式，除非傳送的終端類型是前一個類型的同義詞，或者進入新的模式有其它的先決條件（例如已約定Telnet的二進制選項）。在收到請求信息時，並不表示服務器會當即改變它的處理過程。可是，這種信息可能被傳遞給一個進程。此進程能夠調整發送的數據以適應不一樣終端的不一樣特色。例如，某些操做系統有一個終端驅動器，它能經過接收一些代碼從而指示出哪一種終端類型正在被驅動。在這樣的系統中，經過使用TERMINALTYPE和BINARY選項，Telnet服務程序可以安排終端的驅動過程（包括一些標準網絡虛擬終端不具備的特殊功能），就像它們被直接鏈接在一塊兒。
注意，這個規範是特地不對稱的。它假定服務方操做系統和應用不能在一個鏈接的任意點改變終端類型。所以，只有在服務器要求時，客戶方纔能發送新的終端類型（並潛在的改變仿真模式）。
6．執行問題
「終端類型」信息能夠是任意的NVTASCII字符串。只要字符串對協商的兩端都有意義。在數字分配標識文檔的終端類型列表中，試圖將因爲終端類型寫法的可選擇性而引發的混餚降到最小。例如，當一方將一個終端稱做「IBM3278-2」，而另外一方稱它爲「IBM-3278/2」時，就會出現混餚。對於一個不能識別的終端類型不會有否認的確認，可是當沒有指定一個有效的終端類型名時，有些選項（例如切換到BINARY模式）可能會被拒絕。在一些狀況下，或者某些特殊的終端可能有不止一個名字，例若有一個特殊的類型和幾個普通的類型，或者客戶方是一個帶有複合式顯示器的工做站，它能仿真多種終端模式。在這種狀況下，發送TERMNINAL-TYPEIS命令的一方應該用不一樣的名字來響應接下來的TERMINAL-TYPESEND命令。用這種方法，當不能解釋第一次響應的類型時，Telnet服務器可以提示進行選擇。若是客戶方支持多種不一樣的終端仿真，除非某些特殊的仿真須要其餘的Telnet選項（如BINARY）做爲先決條件（在這種條件下，當先決條件被執行後，仿真模式將轉換到最後發送的類型），不然必須將仿真模式轉換到最後的類型。當類型名是同義詞時，它們應該按從細節最多的名字到細節最少的順序被髮送。當服務器（收到TERMINAL-TYPEIS的一方）在連續的時間收到相同的類型時，這說明此爲有效類型列表的末尾。一樣，客戶端應該經過重複發送最後一個類型以表示它已經傳送了全部有效的類型名。若是客戶端收到一個額外的請求，它表示服務方（發送IS的一方）但願返回到有效類型列表的頂部（可能但願選擇最小的Nevils）。之前的標準規定，當在兩個連續的時間收到相同的響應時，服務器將中止發送
TERMINAL-TYPESEND命令，並將根據原來的標準工做。假定客戶方的執行將照之前的標準去發送列表中的最後一個類型，以響應第三次請求（和第二次）。新式的服務器必須能識別這一點而且再也不發送更多的請求。當終端類型是未知的或是一方不能識別時，將使用「未知」類型。最新的所有終端類型名列表被保存在「數字分配標識」中。一個終端類型名的最大長度是40字節。
7．用戶接口
符合此規範的Telnet客戶和服務器應該在它們的用戶接口中提供如下的功能：支持多仿真模式的客戶應該容許用戶可以在鏈接創建之前指定首選的模式（即哪一個名字首先被髮送）。當協商開始後，發送類型的順序就不能再更改。當服務器不支持TERMIANL
TYPE時，這種模式也將成爲它的默認模式。服務器應該用某種方式存儲當前的終端類型名和有效的名字列表。只有這樣，它才能
得到所須要的用戶（經過鍵盤命令）和任何應用程序的信息。另外，也須要一種相應的機制（經過創建一系列的SEND/IS子協商）去請求改變終端類型。
8．例子
在這個例子中，服務器查找第一個可接受的類型。
Server:IACDOTERMINAL-TYPE

Client:IACWILLTERMINAL-TYPE

(如今，服務器可在任意時刻請求終端類型。)

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISIBM-3278-2IACSE

在這個例子中，服務器請求額外的終端類型，並接受響應的第二種類型（列表中的最後
一個）
Server:IACDOTERMINAL-TYPE

Client:IACWILLTERMINAL-TYPE

(如今，服務器可在任意時刻請求終端類型)

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISZENITH-H19IACSE

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISUNKNOWNIACSE

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISUNKNOWNIACSE
在這個例子中，服務器請求額外的終端類型，並超出了類型列表的末尾。它選擇客戶
提供的第一種類型（新型的客戶和服務器）。

Server:IACDOTERMINAL-TYPE

Client:IACWILLTERMINAL-TYPE

(如今，服務器可在任意時刻請求終端類型。)

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISDEC-VT220IACSE

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISDEC-VT100IACSE

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISDEC-VT52IACSE

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISDEC-VT52IACSE

Server:IACSBTERMINAL-TYPESENDIACSE

Client:IACSBTERMINAL-TYPEISDEC-VT220IACSE

9.References:

[1]Postel,J.,andJ.Reynolds,"TelnetProtocolSpecification",
RFC854,USCInformationSciencesInstitute,May1983.

[2]Postel,J.,andJ.Reynolds,"TelnetOptionSpecification",
RFC855,USCInformationSciencesInstitute,May1983.

[3]Solomon,M.,andE.Wimmers,"TelnetTerminalTypeOption",
RFC930,UniversityofWisconsin-Madison,January1985.

[4]Reynolds,J.,andJ.Postel,"AssignedNumbers",RFC1010,
USCInformationSciencesInstitute,May1987.


Reviser'snote:

IowemuchofthistexttoRFCs884and930,byMarvinSolomonand
EdwardWimmersoftheUniversityofWisconsin-Madison,andIowe
theideaoftheextensiontodiscussionsonthe"tn3270"mailinglist
intheSummerof1987.

Author'sAddress

JamesVanBokkelen
FTPSoftware,Inc.
26PrincessStreet
Wakefield,MA01880-3004

Phone:(617)246-0900

Email:jbvb@ftp.com