給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的通用
規則，必須把該值加倍。