要約

  • RFC 1041 は専用の 3270-REGIME optionを提案したが、RFC 1576 は実装した開発者とvendorが非常に少なかったと記す。実運用では Terminal-Type、Binary、EOR の三つが regime を構成した。
  • 三つの合意は emulation、8 bit data、block境界を扱えた。一方、特定device/LUの指定、SNA BIND、処理結果の応答、ATTN/SYSREQの一貫した意味は提供しなかった。
  • TN3270E は device-name、BIND-IMAGE、RESPONSES を個別に交渉できるようにした。TN3270Eという名称だけでは、それらの採用、認証、最終結果は証明されない。

専用optionより既存の組合せが残った

3270 data stream は NVT ASCII の文字列ではない。EBCDIC を使い、一つのcommandとdataをblockとして扱う。したがって TCP/Telnet 上で再現するには、terminal model、binary octet、blockの終わりを双方が共有しなければならない。

RFC 1041 は1988年、そのための Telnet option 29 3270-REGIME を定義した。clientが希望順にregimeを列挙し、serverが共通の一つを選ぶ。3270を選べばbinaryとIAC EORを含む意味になり、空のlistを選べばNVT ASCIIへ戻る。

興味深いのはmode切替の時点である。交渉中はclientがuser dataを受け付けず、serverも可能な限りdata送信を止める。serverは未送信dataを出し終えてから新regimeを通知し、それを送った時点でparserを切り替える。clientは通知を受信した時点で切り替える。必要なら双方がbufferをflushする。同じoctetを古いgrammarと新しいgrammarが別々に読む危険を、仕様は正面から扱った。

しかし、整ったoptionが広く採用されたわけではなかった。RFC 1576 は RFC 1041 を実装したdeveloperとvendorが「very few」だったと述べる。公式記録では1994年1月のInformational RFCである。これは全実装の調査ではなく、zero adoptionの証明でもない。実際に共有されていた方法を文書化する根拠である。

三つの状態で表示regimeを作った

traditional TN3270 は Telnet本体の上で、Terminal-Type、Binary Transmission、End of Record を別々に交渉した。Terminal-Typeはclientのemulationを伝え、Binaryは8 bit dataを許し、EORはIAC EORでblockを区切る。

どれか一つがTN3270を宣言したわけではない。三状態の組合せが de facto standard だった。RFC 1576 では交渉順序は問われない。適切なtype、Binary、EORがそろった後に3270 blockを交換する。serverがBinaryまたはEORを撤回すれば、clientは以後をNVT ASCIIとして処理する。

この構成は狭いから有用だった。Binaryはoctetの扱い、EORはmessage境界、Terminal-Typeは表示方式を扱う。serverがSNA経由でhost applicationへ接続したか、別の方法を使ったかはclientから隠れたままである。

terminal type は LU name ではない

Terminal-Typeの主導権はserver側にある。serverが問い合わせ、clientが候補を順に返す。clientはtypeを送る際にemulationを切り替える場合があるが、serverは受信直後に処理を変える義務を持たない。

たとえば3278系の名前とscreen sizeはpresentationの宣言である。実機、user、host側resourceのidentityではない。structured fields対応を示す-E suffixも、extended attributesまで含むと読むserverとそうでないserverがあり、完全なcapability証明ではなかった。

SNAでは通常、terminalはapplicationとのsessionとSSCPとのsessionを持つ。TN3270 clientの前には一つのTelnet connectionしかない。clientは特定の3270 device-nameを要求できず、SNA側で割り当てられたLU nameを知る標準手段もなかった。

RFC 1576 はclient IP addressを、TN3270環境でLU nameに最も近いものと表現する。しかしIP addressはTCP endpointを指し、LU nameはhost applicationが区別するlogical resourceを指す。近似は同一性ではない。

EORの後にも未確定が残る

traditional TN3270 のcommand blockには外側のlengthがないため、EORは必要だった。receiverはIAC EORによって「ここまでが一つのcommand」と知る。これはframing receiptであり、processing receiptではない。

RFC 1576は欠落項目としてSNA positive/negative responseを挙げる。positive responseは直前のdata処理完了を示し、negative responseは不正commandやclient側のmechanical errorなどを知らせ得る。traditional TN3270ではdataは処理されたか無視されたものとして扱われ、その結果を共通に返さなかった。

TCP受信、binary復元、EOR到着、command解釈、screen描画、printer動作、applicationの次状態、人の確認は別々である。NOPやTiming Markによるpresence testも、client processがまだ到達可能かを探るだけで、applicationやuserの状態を保証しない。

ATTNとSYSREQの意味はgatewayが決めた

ATTNはcurrent processをinterruptする意図を持ち、多くのclientはTelnet BREAKへ写した。serverがそれをSNA側の適切なsignalへ翻訳する。non-SNA serverはBREAKを無視できた。

SYSREQにはさらに複数のpracticeがあった。Telnet Interrupt Processを使うserverも、3270 Test Requestを使うserverもある。SNAではapplication sessionとSSCP sessionの切替に関わるが、SSCP dataをtraditional TN3270でそのままclientへ渡せない。serverが吸収、変換、または非対応を選ぶ。

key press、Telnet command、gateway translation、SNA event、application outcomeを一つの「sent」にまとめることはできない。

TN3270Eは不足分を別々に交渉した

RFC 1646とRFC 1647を経て、1998年のRFC 2355がTN3270EをStandards Trackでまとめた。その位置は公式記録で確認できる。

TN3270Eでは、まずdevice-typeと任意のresource/device-nameを交渉する。serverは割り当てたdevice-nameを返すか、unknown、in use、type mismatchなどのreasonで拒否する。その後、FUNCTIONS listを合意する。

BIND-IMAGEはSNA host application sessionの開始と終了をclientへ伝える。RESPONSESはrequest policyとsequence numberをheaderに置き、positive/negative resultを対応するdata blockへ結びつける。SYSREQやprinter controlも独立functionである。listは空でもよく、それがbasic TN3270Eだった。

従って沈黙には文法がある。no response、error-only、always responseがあり、RESPONSESを合意しなければsequence numberは証拠にならない。BIND-IMAGEがなければBINDも届かない。TN3270Eを拒否したpeerとはtraditional TN3270へfallbackできる。

RFC 2355はTN3270Eが通常のTelnet以上のsecurityを提供しないとも明記する。device-nameの技術的割当と、それをuserが利用してよいかというauthorizationは別の判断である。

running codeにも証明できない範囲がある

RFC 1041はpaper上の明確さ、traditional TN3270はinstalled compatibility、TN3270Eは追加receiptを示す。どれか一つを絶対化する必要はない。

Heng Luのrunning-code primacyは実際に動くsystemを観察対象にする。minimum specificationとlocal decisionは小さな共通層の価値を説明し、reality layerはpresentation、session、identity、resultの混同を止める。これは後世のeditorial lensであり、RFC著者の意図を代弁するものではない。

端末画面が成立しても、sessionの名前と処理結果はまだ開いている。RFC 1576の価値は、動いたものを記録すると同時に、その外側を空白のまま残したことにある。

出典