RFC1576 日本語訳
1576 TN3270 Current Practices. J. Penner. January 1994. (Format: TXT=24477 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Penner Request for Comments: 1576 DCA, Inc. Category: Informational January 1994
コメントを求めるワーキンググループJ.ペネルの要求をネットワークでつないでください: 1576年のDCA Inc.カテゴリ: 情報の1994年1月
TN3270 Current Practices
TN3270現在の実務
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes the existing implementation of transferring 3270 display terminal data using currently available telnet capabilities. The name traditionally associated with this implementation is TN3270.
このドキュメントは、現在利用可能なtelnet能力を使用することで3270の移しているディスプレー装置データの既存の実装について説明します。 この実装に伝統的に関連している名前はTN3270です。
Information is provided to aid in the implementation of TN3270 servers as well as client terminal emulators.
クライアント端末エミュレータと同様にTN3270サーバの実装で支援するために情報を提供します。
The following areas pertaining to TN3270 implementations are covered in this document:
TN3270実装に関係する以下の領域が本書ではカバーされています:
1. the telnet options negotiated to transition from a NVT ASCII
state to a TN3270 state ready to process incoming 3270 data
stream commands
1. NVT ASCII状態から3270の入って来るデータ・ストリーム命令を処理する準備ができているTN3270状態までの変遷と交渉されたtelnetオプション
2. the method for sending and receiving 3270 data
2. 3270のデータを送って、受け取るためのメソッド
3. the method of handling some special keys known as SYSREQ and
ATTN using current available telnet commands
3. 取り扱いのSYSREQとして知られているいくつかの特別なキーとATTNが現在の利用可能なtelnetコマンドを使用するメソッド
4. the events that will transition a TN3270 session back to an NVT
session
4. TN3270セッションからNVTセッションを変遷に望んでいるイベント
Table of Contents
目次
1. Motivation . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . 2
3. Telnet Options and Commands Used . . . . . . . . 4
4. Connection Negotiation . . . . . . . . . . . . . 4
4.1 3270 Regime Option . . . . . . . . . . . . . . . 6
4.2 Suppress Go Ahead Option . . . . . . . . . . . . 6
4.3 Echo Option . . . . . . . . . . . . . . . . . . . 6
4.4 Timing Mark Option . . . . . . . . . . . . . . . 7
1. 動機. . . . . . . . . . . . . . . . . . . 2 2。 バックグラウンド. . . . . . . . . . . . . . . . . . . 2 3。 telnetオプションとコマンドは.4 4を使用しました。 接続交渉. . . . . . . . . . . . . 4 4.1 3270政権オプション. . . . . . . . . . . . . . . 6 4.2は先のオプション. . . . . . . . . . . . 6 4.3エコーオプション. . . . . . . . . . . . . . . . . . . 6 4.4タイミングがオプション. . . . . . . . . . . . . . . 7であるとマークする碁を抑圧します。
TN3270 Enhancements Working Group [Page 1] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[1ページ]RFC1576TN3270海流は1994年1月に練習されます。
5. Testing for session presence . . . . . . . . . . 7
6. Handling 3270 data . . . . . . . . . . . . . . . 7
7. 3270 Structured Fields . . . . . . . . . . . . . 8
8. The 3270 ATTN (Attention) Key . . . . . . . . . . 8
9. The 3270 SYSREQ Key . . . . . . . . . . . . . . . 9
10. Items not addressed by TN3270 . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . 11
13. Author's Note . . . . . . . . . . . . . . . . . . 11
14. Author's Address . . . . . . . . . . . . . . . . 12
5. セッション存在. . . . . . . . . . 7 6がないかどうかテストします。 3270のデータ. . . . . . . . . . . . . . . 7 7を扱います。 3270は分野. . . . . . . . . . . . . 8 8を構造化しました。 3270ATTN(注意)キー. . . . . . . . . . 8 9。 3270年のSYSREQキー. . . . . . . . . . . . . . . 9 10。 TN3270. . . . . . . . . . 10 11によって扱われなかった項目。 参照. . . . . . . . . . . . . . . . . . . 10 12。 セキュリティ問題. . . . . . . . . . . . . 11 13。 著者注. . . . . . . . . . . . . . . . . . 11 14。 作者のアドレス. . . . . . . . . . . . . . . . 12
1. Motivation
1. 動機
3270 display terminal data differs from traditional display terminal data in that it is block mode and uses EBCDIC instead of ASCII character representation. These two differences are the primary reason for the differentiation of TN3270 from standard Telnet in this document.
3270のディスプレー装置データが、それがブロックモードであるという点において伝統的なディスプレー装置データと異なっていて、ASCII文字表示の代わりにEBCDICを使用します。 これらの2つの違いが本書では標準のTelnetからのTN3270の分化のプライマリ理由です。
2. Background
2. バックグラウンド
Existing complex IBM 3270 display terminal networks are not easily integrated with the increasing number of multi-platform networking environments, specifically TCP/IP. These complex networks include terminals attached to a 3270 host using SNA (Systems Network Architecture) and non-SNA connections. To address the issue of easily connecting display terminals to 3270 hosts using IP networks, several vendors have introduced telnet servers that provide TCP/IP users a connection to existing IBM mainframes by supporting display terminal emulation using a subset of the existing telnet protocol. Telnet servers may exist on the host itself, or be connected to the host using SNA or non-SNA methods.
既存の複雑なIBM3270ディスプレー装置ネットワークは容易にマルチプラットフォームネットワーク環境(明確にTCP/IP)の増加する数と統合されません。 これらの複雑なネットワークは、SNA(システム・ネットワーク・アーキテクチャ)と非SNA接続を使用することで3270年のホストに愛着している端末を含んでいます。 IPネットワークを使用することで容易に接続ディスプレー装置の問題を3270人のホストに扱うために、ディスプレイが端末のエミュレーションであると既存のtelnetプロトコルの部分集合を使用することでサポートすることによって、いくつかのベンダーがTCP/IPユーザに接続を提供するtelnetサーバを既存のIBMメインフレームに取り入れました。 telnetサーバは、ホスト自身の上に存在しているか、またはSNAか非SNAメソッドを使用しているホストに接されるかもしれません。
IBM terminals are generically referred to as 3270's which includes a broad range of terminals and devices, not all of which actually begin with the numbers 327x.
IBM端末は一般的に広範囲な端末を含んで、すべてではなく、それのデバイスが実際に数の327xで始まる3270年代と呼ばれます。
3270 terminals in the IBM SNA network environment have two sessions with the host computer application. One is used for communicating with the host application, the other is used for communicating with the SSCP (System Services Control Point) that links the terminal with the appropriate host computer. For the purposes of TN3270, this distinction is not apparent or relevant since there is actually only a single telnet session with the host computer or server. On an IBM SNA network, the 3270 terminal has a special key that toggles between the two sessions (SYSREQ). A brief discussion on how some telnet servers deal with this is included.
IBM SNAネットワーク環境における3270台の端末には、ホストコンピュータアプリケーションとの2つのセッションがあります。 1つがホストアプリケーションとコミュニケートするのに使用されると適切なホストコンピュータに端末をリンクするSSCP(システムServices Control Point)と伝えますもう片方が使用されている。 TN3270の目的のために、ホストコンピュータかサーバとのただ一つのtelnetセッションしか実際にないので、この区別は、明らかでなく、また関連していません。IBM SNAネットワークでは、3270年の端末は2つのセッション(SYSREQ)の間で切り換えられる特別なキーを持っています。 いくつかのtelnetサーバがどうこれに対処するかについての簡潔な議論は含まれています。
TN3270 Enhancements Working Group [Page 2] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[2ページ]RFC1576TN3270海流は1994年1月に練習されます。
In an SNA environment, a client session is identified by a Logical Unit (LU) name. In a non-SNA environment, there is not a LU name associated with a client session. The closest thing to a LU name in the TN3270 environment is the client's IP address. Although some telnet servers are connected to the host using SNA, TN3270 clients using these servers have no defined way to determine the LU name associated with the session.
SNA環境で、クライアントセッションはLogical Unit(LU)名によって特定されます。 非SNA環境には、クライアントセッションに関連しているLU名がありません。 TN3270環境におけるLU名への最も近いものはクライアントのIPアドレスです。 いくつかのtelnetサーバがSNAを使用しているホストに接されますが、これらのサーバを使用しているTN3270クライアントがセッションに関連しているLU名を決定する定義された方法を全く持っていません。
Telnet servers that exist in non-SNA environments do not have to be concerned about providing TN3270 clients with support for the SNA functions described in this document.
非SNA環境で存在するtelnetサーバは本書では説明されたSNA機能のサポートをTN3270クライアントに提供することに関して心配する必要はありません。
TN3270 does not support typical SNA responses and is classified as a non-SNA protocol. A TN3270 emulator is not aware or concerned about how the telnet server is connected to a 3270 host application.
TN3270は典型的なSNA応答をサポートしないで、非SNAプロトコルとして分類されます。 TN3270エミュレータは、意識しないで、またtelnetサーバがどう3270年のホストアプリケーションに接続されるかに関して心配していません。
NOTE: Except where otherwise stated, this document does not distinguish between telnet servers that represent SNA devices and those that represent non-SNA 3270 devices.
以下に注意してください。 別の方法で述べられているところ以外に、このドキュメントはSNAデバイスを表すtelnetサーバと非SNA3270台のデバイスを表すものを見分けません。
Some typical "SNA" functions such as the SYSREQ and ATTN keys have been mapped to existing telnet commands and are supported by some telnet server implementations.
SYSREQやATTNキーなどのいくつかの典型的な「SNA」機能が、既存のtelnetコマンドに写像されて、いくつかのtelnetサーバ実装によってサポートされます。
Currently, support for 3270 terminal emulation over Telnet is accomplished by the de facto standard of negotiating three separate Telnet Options - Terminal-Type [2], Binary Transmission [3], and End of Record [4]. This negotiation and the resulting data flow will be described below.
現在、Telnetの上の3270年のターミナルエミュレーションのサポートは3別々のTelnet Optionsを交渉するデファクトスタンダードによって実行されます--端末のタイプの[2]、Binary Transmission[3]、およびEndのRecord[4]。 この交渉と結果として起こるデータフローは以下で説明されるでしょう。
RFC 1041 [1] attempted to standardize the method of negotiating 3270 terminal support by defining the 3270 Regime Telnet Option. Historically, very few developers and vendors ever implemented RFC 1041.
RFC1041[1]は、3270Regime Telnet Optionを定義することによって3270年の端末のサポートを交渉するメソッドを標準化するのを試みました。 歴史的に、ほんのわずかな開発者とベンダーは、今までに、RFCが1041であると実装しました。
All references in this document to the 3270 datastream, SNA versus non-SNA operation, 3270 datastream commands, orders, structured fields and the like rely on [6].
本書では3270datastreamのすべての参照、SNA、対非SNA操作、3270のdatastreamコマンド、注文、構造化された分野、および同様のものは[6]を当てにします。
References to SNA Request and Response Units rely on [7]. References to SNA and SSCP rely on [12].
SNA RequestとResponse Unitsの参照は[7]を当てにします。 SNAとSSCPの参照は[12]を当てにします。
TN3270 Enhancements Working Group [Page 3] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[3ページ]RFC1576TN3270海流は1994年1月に練習されます。
3. Telnet Options and Commands Used
3. オプションとコマンドが使用したtelnet
TN3270 makes use of existing Telnet options and does not define any additional options or commands.
TN3270は既存のTelnetオプションを利用して、少しの追加オプションやコマンドも定義しません。
Telnet option Value (decimal)
------------- ---------------
BINARY 0
TERMINAL-TYPE 24
EOR 25
telnetオプションValue(小数)------------- --------------- 2進の0端末のタイプ24EOR25
Additional options may be used during a TN3270 session and are interpreted as per their respective RFCs. These are [1] 3270-REGIME, [8] SUPPRESS-GO-AHEAD, [9] ECHO and [10] TIMING-MARK. Other options should be rejected unless they are specifically handled by the client for NVT mode.
追加オプションは、TN3270セッションの間、使用されるかもしれなくて、それらのそれぞれのRFCs単位で解釈されます。 これらは、[1] 3270-REGIMEと、[8] SUPPRESS-GO-AHEADと、[9] ECHOと[10]TIMING-マークです。 それらがNVTモードのためにクライアントによって明確に扱われない場合、別の選択肢は拒絶されるべきです。
Commands that may be encountered during a TN3270 session and are described in RFC 854 [11] include NOP, BREAK and Interrupt Process.
TN3270セッションの間、遭遇するかもしれなくて、RFC854[11]で説明されるコマンドはNOP、BREAK、およびInterrupt Processを含んでいます。
4. Connection Negotiation
4. 接続交渉
The following example shows a TN3270-capable server and a TN3270 client establishing a connection:
以下の例は、TN3270できるサーバとTN3270クライアントが取引関係を築くのを示します:
The TCP/IP port used to connect with is 23 (Telnet).
接続するポートが使用したTCP/IPは23(telnet)です。
At any place before and during the TN3270 connection negotiation process, other telnet commands and data may be transferred and will be interpreted under the existing telnet state. Some existing TN3270 servers start a client connection using an NVT telnet dialog to establish parameters needed to complete the TN3270 connection to the desired host.
プロセスの前とTN3270接続交渉プロセスの間のどんな場所でも、他のtelnetコマンドとデータは、移されるかもしれなくて、既存のtelnet状態の下で解釈されるでしょう。 いくつかの既存のTN3270サーバが、TN3270接続を必要なホストに終了するのに必要であるパラメタを証明するのにNVT telnet対話を使用することでクライアント接続を始めます。
The order of negotiating terminal type, EOR and BINARY is not significant, this example shows a typical TN3270 connection.
この例は、端末のタイプ、EOR、およびBINARYを交渉する注文が重要でないことを典型的なTN3270接続を示しています。
Server: IAC DO TERMINAL-TYPE
サーバ: IACは端末でタイプします。
Client: IAC WILL TERMINAL-TYPE
クライアント: IACは端末でタイプするでしょう。
Server: IAC SB TERMINAL-TYPE SEND IAC SE
サーバ: IAC SBの端末のタイプはIAC SEを送ります。
Client: IAC SB TERMINAL-TYPE IS <terminal type>IAC SE
クライアント: IAC SBの端末のタイプは<の端末のタイプ>IAC SEです。
where <terminal type> is a string consisting of terminal model,
type and support of enhanced attribute bytes; an example is IBM-
3278-2. The acceptable values are listed in RFC 1340, Assigned
高められた属性バイトの<の端末のタイプ>はどこの端末モデルから成るストリングであるか、そして、タイプとサポート。 例はIBM3278-2です。 Assigned、許容値はRFC1340に記載されています。
TN3270 Enhancements Working Group [Page 4] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[4ページ]RFC1576TN3270海流は1994年1月に練習されます。
Numbers [5]. Other values are in use that do not exist in [5].
数[5]。 他の値が[5]に存在しない使用であります。
The -2 following 3278 designates the alternate screen size. 3270
terminals have the ability to switch between the standard (24x80)
screen size and an alternate screen size. Model -2 is 24x80 which
is the same as the standard size. Model -3 is 32x80, model -4 is
43x80 and model -5 is 27x132.
3278に続くと補欠が任命される-2はサイズを上映します。 3270台の端末には、標準の(24×80)画面サイズと代替の画面サイズを切り換える能力があります。 モデル-2は標準のサイズと同じ24×80です。 モデル-3は32×80です、そして、モデル-4は43×80です、そして、モデル-5は27×132です。
Appending the two character string "-E" to the end of the terminal
type signifies that the terminal is capable of handling 3270
extended data stream. This is interpreted to mean that the
terminal is able to handle structured fields, which are described
below. Some telnet server implementations also interpret this to
mean that the terminal is capable of handling extended attributes
(highlighting, field validation, character set, outlining, etc.)
[6].
2キャラクタストリング"-E"を端末のタイプの終わりに追加するのは、端末が3270年の拡張データ・ストリームを扱うことができるのを意味します。 これは、端末が以下で説明される構造化された分野を扱うことができることを意味するために解釈されます。 また、いくつかのtelnetサーバ実装が、端末が拡張属性(ハイライト、分野合法化、文字集合、概説など)を扱うことができることを意味するためにこれを解釈します。 [6].
The 3279 series of terminals is capable of extended attributes
while the 3278 series is not.
3278年のシリーズはできませんが、3279年の端末のシリーズは拡張属性ができます。
Server: IAC DO EOR IAC WILL EOR
Client: IAC WILL EOR IAC DO EOR
Server: IAC DO BINARY IAC WILL BINARY
Client: IAC WILL BINARY IAC DO BINARY
Server: <3270 data stream> IAC EOR
Client: <3270 data stream> IAC EOR
. .
. .
サーバ: IACはEOR IACウィルEORクライアントをします: IACウィルEOR IACはEORサーバをします: IACは2進のIACウィルに2進のクライアントをします: IACウィルBINARY IACは2進のサーバをします: 3270年の<データ・ストリーム>IAC EOR Client: <3270データは>IAC EORを流します…
To terminate the connection the socket is closed by one of the session partners. Typically, when the user logs off of the host, the telnet server closes the connection.
接続を終えるために、ソケットはセッションパートナーのひとりによって閉じられます。 ホストからのユーザログであるときに、通常、telnetサーバは接続を終えます。
If the telnet server wishes to go back to NVT mode, it may issue the following telnet options:
telnetサーバがNVTモードに戻りたいなら、以下のtelnetオプションを発行するかもしれません:
Server: IAC WONT BINARY
Client: IAC DONT BINARY
サーバ: IACの習慣2進のクライアント: IACドントBINARY
or
または
Server: IAC WONT EOR
Client: IAC DONT EOR
サーバ: IAC習慣EORクライアント: IACドントEOR
Either one of the above two cases causes the connection to not satisfy the requirements for a valid TN3270 session. The telnet client would then process data from the server as though it were NVT ASCII data.
上のどちらの2つのケースでも、接続は有効なTN3270セッションのための要件を満たしません。 そして、telnetクライアントはまるでそれがNVT ASCIIデータであるかのようにサーバからデータを処理するでしょう。
TN3270 Enhancements Working Group [Page 5] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[5ページ]RFC1576TN3270海流は1994年1月に練習されます。
The following examples show how a TN3270 client handles the 3270- REGIME, SUPPRESS-GO-AHEAD, ECHO and TM options.
以下の例はTN3270クライアントがどう3270REGIME、SUPPRESS-GO-AHEAD、ECHO、およびTMオプションを扱うかを示しています。
4.1 3270 Regime Option
4.1 3270年の政権オプション
Very few servers support the 3270 Regime Telnet Option. If the client does not support this option and responds negatively as shown in the following example, the server will proceed on to the more typical example shown above.
ほんのわずかなサーバは3270Regime Telnet Optionをサポートします。 クライアントがこのオプションをサポートしないで、以下の例に示されるように否定的に応じると、サーバは上に示されたより典型的な例に続くでしょう。
Server: IAC DO 3270-REGIME
Client: IAC WONT 3270-REGIME
Normal negotiation:
Server: IAC DO TERMINAL-TYPE
... (see above)
サーバ: IACは3270政権にクライアントをします: IAC WONT 3270-REGIME Normal交渉: サーバ: IACは端末でタイプします… (上を見ます)
4.2 Suppress Go Ahead Option
4.2が先で碁を抑圧する、オプション
The Suppress Go Ahead option [8] is requested by some servers. The Suppress Go Ahead option RFC lists the default as being go aheads are transmitted to signal the receiver to begin transmitting. Since TN3270 negotiates binary and end-of-record and is a block mode protocol, the telnet go ahead character is not sent. Most servers do not negotiate this option even though they do not use the telnet go ahead character.
Suppress Go Aheadオプション[8]はいくつかのサーバによって要求されます。 前に進むことであることが伝わり始めるように受信機に合図するために伝えられるようにSuppress Go AheadオプションRFCはデフォルトを記載します。 プロトコル、telnetは、TN3270がバイナリーと記録の終わりを交渉して、ブロックモードであることで前に進んでいます。キャラクタは送られません。 先で順調なtelnetを使用しませんが、ほとんどのサーバはこのオプションを交渉しません。キャラクタ。
Server: IAC DO SUPPRESS-GO-AHEAD
Client: IAC WILL SUPPESS-GO-AHEAD
サーバ: IACは開始許可を抑圧しているクライアントをします: IACウィルSUPPESS-GO-AHEAD
4.3 Echo Option
4.3 エコーオプション
The Echo option [9] is negotiated by those servers that make use of the telnet NVT mode to allow the user to enter information prior to negotiating the options necessary for TN3270. This information includes but is not limited to user identification, password and destination 3270 host. Some servers accept the default for this option which is for the client to not do a local echo of characters the user enters at the keyboard. This allows the server to decide if it should echo characters back to the client (or not in the case of password). Echoing characters back to the client causes slow response time since every character is typically echoed individually. Because of this, some servers negotiate for the client to do it's own local echoing (except for passwords). The following example illustrates this case.
Echoオプション[9]はTN3270に必要なオプションを交渉する前にユーザが情報を入力するのを許可するのにtelnet NVTモードを利用するそれらのサーバによって交渉されます。 ユーザ登録名、パスワード、および目的地3270ホストにとって、含んでいますが、この情報は限られていません。 いくつかのサーバがクライアントがユーザがキーボードで入るキャラクタのローカルエコーをすることになっていないこのオプションのためのデフォルトを受け入れます。 これで、サーバは、それがクライアント(または、パスワードの場合では、どんなそうしない)にキャラクタをecho backであるべきであるかどうか決めることができます。 クライアントにキャラクタをecho backであると、すべてのキャラクタが通常個別に言葉を繰り返されるので、遅い応答時間は引き起こされます。 これのために、いくつかのサーバが、クライアントがそれの自己のローカル・エコーイング(パスワードを除いた)をするのを交渉します。 以下の例は本件を例証します。
TN3270 Enhancements Working Group [Page 6] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[6ページ]RFC1576TN3270海流は1994年1月に練習されます。
Server: IAC DO ECHO
Client: IAC WILL ECHO
(Client does local display of all characters)
Server: IAC WONT ECHO
Client: IAC DONT ECHO
(Client enters password - not locally displayed or remotely
echoed)
Server: IAC DO ECHO
Client: IAC WILL ECHO
(Client resumes local display of all characters)
サーバ: IACはクライアントの言葉を繰り返します: IAC WILL ECHO(クライアントはすべてのキャラクタの地方のディスプレイをする)サーバ: IAC習慣エコークライアント: IAC DONT ECHO(クライアントはパスワードを入力します--局所的に表示しないか、または離れて反響しない)サーバ: IACはクライアントの言葉を繰り返します: IACは反響するでしょう。(クライアントはすべてのキャラクタの地方のディスプレイを再開します)
4.4 Timing Mark Option
4.4 タイミング・マークオプション
The Timing Mark option [10] is used by some servers to test for the continued presence of a TN3270 client. The following example will assure the server the client is still alive.
Timingマークのオプション[10]はいくつかのサーバによって使用されて、TN3270クライアントの継続的な存在がないかどうかテストします。 以下の例は、クライアントがまだ生きていることをサーバに保証するでしょう。
Server: IAC DO TIMING-MARK
Client: IAC WONT TIMING-MARK
サーバ: IACはタイミング・マーククライアントをします: IAC習慣タイミング・マーク
5. Testing for session presence
5. セッション存在がないかどうかテストすること。
The NOP command (hexadecimal F1) [11] is used by some servers to test for the continued presence of a TN3270 client. If a client has terminated abnormally, TCP/IP send errors will occur. The Timing Mark option, described above, is also used to test for presence.
NOPコマンド(16進F1)[11]はいくつかのサーバによって使用されて、TN3270クライアントの継続的な存在がないかどうかテストします。 クライアントが異常に終わったなら、TCP/IP送信エラーは起こるでしょう。 また、上で説明されたTimingマークのオプションは、存在がないかどうかテストするのに使用されます。
Server: IAC NOP
Client: <ignore / no response>
サーバ: IAC NOPクライアント: <は応答の/ノー>を無視します。
6. Handling 3270 data
6. 取り扱3270いデータ
The 3270 data stream consists of a command and its associated data. Commands include but are not limited to erase screen, erase and write to screen and read current screen; see [6] for a complete description of 3270 commands and parameters.
3270年のデータ・ストリームはコマンドとその関連データから成ります。 コマンドは、スクリーンに含みますが、抹消スクリーン、抹消に制限されないで、書いて、現在のスクリーンを読み込みます。 3270のコマンドとパラメタの完全な記述のための[6]を見てください。
The reason for negotiating the EOR telnet option [4] is to provide a method for separating these commands since no length information is specified. 3270 commands are interpreted by the telnet client in their entirety. Each 3270 command and possible data is terminated with the IAC EOR sequence.
EOR telnetオプション[4]を交渉する理由は長さの情報が全く指定されないのでこれらのコマンドを切り離すためのメソッドを提供することです。 3270のコマンドがtelnetクライアントによって全体として解釈されます。 それぞれの3270年のコマンドと可能なデータはIAC EOR系列で終えられます。
The Binary option [3] is also required since 3270 data may contain the FF (hexadecimal) or IAC character. When this character is encountered during a TN3270 connection it is handled as per the Binary RFC [3].
また、3270のデータがFF(16進)かIACキャラクタを含むかもしれないので、Binaryオプション[3]が必要です。 このキャラクタがTN3270接続の間遭遇するとき、それはBinary RFC[3]に従って扱われます。
TN3270 Enhancements Working Group [Page 7] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[7ページ]RFC1576TN3270海流は1994年1月に練習されます。
7. 3270 Structured Fields
7. 3270は分野を構造化しました。
3270 structured fields provide a much wider range of features than "old-style" 3270 data, such as support for graphics, partitions and IPDS printer datastreams. A structured field is a 3270 data type that allows non 3270 data to be embedded within 3270 data. Briefly, a structured field consists of the structured field command followed by one or more data blocks. Each data block has a length and a structured field identifier, followed optionally by additional data.
3270の構造化された分野が「古いスタイル」3270のデータよりはるかに広い範囲の特徴を提供します、グラフィックスのサポートや、パーティションやIPDSプリンタdatastreamsなどのように。構造化された分野は非3270データが3270のデータの中で埋め込まれているのを許容する3270年のデータ型です。 簡潔に、構造化された分野は1データ・ブロック以上が支えた構造化された分野コマンドから成ります。 各データ・ブロックには、長さと構造化された分野識別子があります、続いて、任意に追加データを持っています。
Not every TN3270 client can be expected to support all structured field functions. There must be a mechanism by which those clients that are capable of supporting some or all structured field functions can indicate their wishes. This is typically done by adding "-E" to the end of the terminal type string. That is, when the terminal identifies itself as being able to handle extended attributes, it also is capable of being able to send and receive structured fields.
すべてのTN3270クライアントが、すべての構造化された分野が機能であるとサポートすると予想できるというわけではありません。 それらのいくつかをサポートしているか、またはすべて構造化された分野機能ができるクライアントが彼らの願望を示すことができるメカニズムがあるに違いありません。 通常端末のタイプストリングの端に"-E"を加えることによって、これをします。 また、すなわち、端末は拡張属性を扱うことであることができると名乗るとき、構造化された野原を送って、受けるのはできることができます。
The design of 3270 structured fields provides a convenient means to convey the level of support (including no support) for the various structured field functions. This mechanism is the Read Partition Query command, which is sent from the host application to the client. The client responds with a Query Reply, listing which, if any, structured field functions it supports.
3270の構造化された分野のデザインは様々な構造化された分野機能のために、サポート水準(サポートを全く含んでいない)を伝える便利な手段を提供します。 このメカニズムはRead Partition Queryコマンドです。(そのコマンドはホストアプリケーションからクライアントに送られます)。 それがサポートするそれのもしあれば構造化された分野機能を記載して、クライアントはQuery Replyと共に応じます。
A TN3270 client that supports structured fields will respond to a Read Partition Query command with the appropriate reply. The sequence of events when a client receives a Read Partition Query and does not support structured fields is left up to the client implementation. Typically clients can identify at least this structured field and reply with a null set.
構造化された分野をサポートするTN3270クライアントは適切な回答でRead Partition Queryコマンドに応じるでしょう。 クライアントがRead Partition Queryを受け取って、構造化された分野をサポートしないとき、イベントの系列はクライアント実装に任せられます。 通常、クライアントは少なくともこの構造化された分野と回答を零集合と同一視できます。
8. The 3270 ATTN (Attention) Key
8. 3270ATTN(注意)キー
The 3270 ATTN key is interpreted by many host applications in an SNA environment as an indication that the user wishes to interrupt the execution of the current process. A majority of the telnet servers currently accept the telnet IAC BREAK (code 243) [11] sequence to signal this event.
3270年のATTNキーはユーザが現在のプロセスの実行を中断したがっているという指示としてSNA環境における多くのホストアプリケーションで解釈されます。 telnetサーバの大部分が、現在、このイベントに合図するためにtelnet IAC BREAK(コード243)[11]系列を受け入れます。
Use of this key requires two things:
このキーの使用は2つのものを必要とします:
- The TN3270 clients provide as part of their keyboard
mapping a single key or a combination of keys that map to
the 3270 ATTN key. When the user presses this key(s), the
client transmits a Telnet BREAK command to the server.
- TN3270クライアントは彼らのキー割当一覧の一部としてATTNを3270に主要な状態で写像するキーの単一のキーか組み合わせを提供します。 ユーザがこのキーを押すと、クライアントはTelnet BREAKコマンドをサーバに伝えます。
TN3270 Enhancements Working Group [Page 8] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[8ページ]RFC1576TN3270海流は1994年1月に練習されます。
- The TN3270 servers translate the BREAK command received from
a TN3270 client into the appropriate form and pass it along
to the host application as an ATTN key. In other words, the
server representing an SLU in an SNA session would send
a SIGNAL RU to the host application.
- TN3270サーバは、TN3270クライアントから受け取られたBREAKコマンドを適切なフォームに翻訳して、ATTNキーとしてホストアプリケーションにそれを回します。 言い換えれば、SNAセッションのときにSLUを表すサーバはホストアプリケーションにSIGNAL RUを送るでしょう。
The ATTN key is not supported in a non-SNA environment; therefore, a TN3270 server representing non-SNA 3270 devices ignores any Telnet BREAK commands it receives from a client.
ATTNキーは非SNA環境で支えられません。 したがって、非SNA3270台のデバイスを表すTN3270サーバはそれがクライアントから受け取るどんなTelnet BREAKコマンドも無視します。
9. The 3270 SYSREQ Key
9. 3270年のSYSREQキー
The 3270 SYSREQ key is useful in an environment where the telnet server is attached to the host using SNA. The SYSREQ key is useful in this environment when the host application becomes locked or the user wishes to terminate the session without closing the Telnet connection.
3270年のSYSREQキーはtelnetサーバがSNAを使用しているホストに愛着しているところで環境で役に立ちます。 ホストアプリケーションがロックされるようになるか、またはユーザがTelnet接続を終えないでセッションを終えたがっているとき、SYSREQキーはこの環境で役に立ちます。
The Telnet Interrupt Process (IP) command [11] is interpreted by some telnet servers as a SYSREQ key. Other servers recognize the 3270 Test Request key as a SYSREQ key. In an SNA environment, pressing this key toggles the terminal between the host application session and the SSCP session. Usually the user will enter LOGOFF once this key has been pressed to terminate the application session and then select a new host to connect to. Sometimes, if SYSREQ is pressed again, the host application will become unlocked and normal activities may then proceed.
Telnet Interrupt Process(IP)コマンド[11]はSYSREQキーとしていくつかのtelnetサーバによって解釈されます。 他のサーバは、3270年のTest RequestキーがSYSREQキーであると認めます。 SNA環境で、このキーを押すと、ホストアプリケーションセッションとSSCPセッションの間の端末は切り換えられます。 通常、アプリケーションセッションを終えて、次に、このキーが接する新しいホストを選ぶようにいったん押されると、ユーザはLOGOFFに入るでしょう。 SYSREQが再び押されるなら、時々、ホストアプリケーションはアンロックされるようになるでしょう、そして、次に、正常な活動は続くかもしれません。
It is entirely up to the telnet server to interpret this command and send the appropriate commands to the host as well as format the resulting host data for display on the telnet client. The data format during the SSCP session is in a slightly different format than normal 3270 data. Since the telnet server has no way to pass this data directly to the telnet client, it must either handle it entirely and ignore SYSREQ events or convert it to 3270 data to present to the client.
このコマンドを解釈して、適切なコマンドをホストに送って、telnetクライアントの上でディスプレイのための結果として起こるホストデータをフォーマットするのは完全にtelnetサーバまで達しています。 わずかに正常な3270のデータと異なった形式にはSSCPセッションの間のデータの形式があります。 telnetサーバには直接telnetクライアントにこのデータを渡す方法が全くないので、それは、クライアントに提示する3270のデータにそれを完全に扱って、SYSREQイベントを無視しなければならないか、またはそれを変換しなければなりません。
To implement SYSREQ key support, TN3270 clients provide a key (or combination of keys) that is identified as mapping to the 3270 SYSREQ key. When the user presses this key(s), the client would either transmit a Telnet IP command or Test Request key to the server, depending on the server implementation.
SYSREQが主要なサポートであると実装するために、TN3270クライアントはSYSREQを3270に写像するとして主要な状態で特定されるキー(または、一組の鍵)を提供します。 ユーザがこのキーを押すと、クライアントはサーバに主要なTelnet IPコマンドかTest Requestを伝えるでしょう、サーバ実装によって。
TN3270 servers representing non-SNA 3270 terminals may ignore any Telnet IP commands or Test Request keys they receive from a client.
非SNA3270台の端末を表すTN3270サーバは彼らがクライアントから受け取るどんなTelnet IPコマンドやTest Requestキーも無視するかもしれません。
TN3270 Enhancements Working Group [Page 9] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[9ページ]RFC1576TN3270海流は1994年1月に練習されます。
10. Items not addressed by TN3270
10. TN3270によって扱われなかった項目
There are several items that are not supported by current TN3270 implementations; among them are the following:
現在のTN3270実装によって支えられない数個の項目があります。 それらの中に、以下があります:
- TN3270 provides no capability for clients to emulate the 328x
class of printers.
- TN3270はクライアントがプリンタの328xのクラスを見習う能力を全く提供しません。
- There is no mechanism by which a Telnet client can request that
a connection be associated with a given 3270 device-name. This
can be of importance when a terminal session is being
established, since many host applications behave differently
depending on the network name of the terminal.
- Telnetクライアントが接続が3270年の与えられた装置名に関連しているよう要求できるメカニズムが全くありません。 ターミナルセションが設立されているとき、これは重要であることができます、端末のネットワーク名に異なってよって、多くのホストアプリケーションが振る舞うので。
- The 3270 ATTN and SYSREQ keys are not universally supported.
- 3270ATTNとSYSREQキーは一般に支えられません。
- There is no support for the SNA positive/negative response
process. All data that is sent is assumed to either be handled
or ignored. The lack of SNA response processing in TN3270 is
part of what makes TN3270 efficient.
A negative response indicates some sort of error at the client
while processing the previously received data; this could be
caused by the host application building a 3270 datastream that
contains an invalid command, or by a mechanical error at the
client side, among other things.
Positive responses indicate processing of the previously received
data has completed.
- SNAの肯定しているか否定している応答プロセスのサポートが全くありません。 扱われるか、または送られるすべてのデータが無視されると思われます。 TN3270のSNA応答処理の不足はTN3270を効率的にすることに関する部分です。 否定応答は以前に受信されたデータを処理している間、クライアントにおけるある種の誤りを示します。 これは無効のコマンドを含む3270datastreamを造るホストアプリケーション、または特にクライアント側の機械的な誤りで引き起こされる場合がありました。 積極的な応答は、以前に受信されたデータの処理が完成したのを示します。
- There is no mechanism by which the client can access the SNA
BIND information. The BIND image in a SNA environment
contains a detailed description of the session between the
telnet server and the host application.
- クライアントがSNA BIND情報にアクセスできるメカニズムが全くありません。 SNA環境におけるBINDイメージはtelnetサーバとホストアプリケーションとのセッションの詳述を含んでいます。
- The connection negotiation does not make it clear whether
clients should support 3270 structured fields.
- 接続交渉で、それはクライアントが3270をサポートするべきであるかどうかが分野を構造化したのが明確になりません。
11. References
11. 参照
[1] Rekhter, Y., "Telnet 3270 Regime Option", RFC 1041, IBM
Corporation, January 1988.
[1]Rekhter、Y.、「telnet3270政権オプション」、RFC1041、IBM社、1988年1月。
[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
Software, Inc., February 1989.
[2]VanBokkelen、J.、「telnet端末のタイプオプション」、RFC1091、FTPソフトウェアInc.、1989年2月。
[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD
27, RFC 856, USC/Information Sciences Institute, May 1983.
[3] ポステル、J.、およびJ.レイノルズ、「telnetバイナリー送信」、STD27、RFC856(科学が設けるUSC/情報)は1983がそうするかもしれません。
TN3270 Enhancements Working Group [Page 10] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[10ページ]RFC1576TN3270海流は1994年1月に練習されます。
[4] Postel, J., "Telnet End of Record Option", RFC 885,
USC/Information Sciences Institute, December 1983.
[4] ポステル、J.、「記録的なオプションのtelnet終わり」、RFC885、科学が1983年12月に設けるUSC/情報。
[5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[5] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[6] "3270 Information Display System - Data Stream Programmer's
Reference", publication number GA23-0059, IBM Corporation.
[6] 「3270年の情報はシステムを表示します--データはプログラマの参照を流す」公表番号GA23-0059、IBM社。
[7] "Systems Network Architecture - Formats", publication number
GA27-3136, IBM Corporation.
[7] 公表は、「システム・ネットワーク体系--形式」に付番します。GA27-3136、IBM社。
[8] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option",
STD 29, RFC 858, USC/Information Sciences Institute, May 1983.
[8] ポステル、J.、およびJ.レイノルズ、「telnetが先で碁を抑圧する、オプション、」、STD29(RFC858、科学が設けるUSC/情報)は1983にそうするかもしれません。
[9] Postel, J., and J. Reynolds, "Telnet Echo Option", STD 28, RFC
857, USC/Information Sciences Institute, May 1983.
[9] ポステル、J.、およびJ.レイノルズ、「telnetエコーオプション」、STD28、RFC857(科学が設けるUSC/情報)は1983がそうするかもしれません。
[10] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31,
RFC 860, USC/Information Sciences Institute, May 1983.
[10] ポステル、J.、およびJ.レイノルズ、「telnetタイミング・マークオプション」、STD31、RFC860(科学が設けるUSC/情報)は1983がそうするかもしれません。
[11] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD
8, RFC 854, USC/Information Sciences Institute, May 1983.
[11] ポステル、J.、およびJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854(科学が設けるUSC/情報)は1983がそうするかもしれません。
[12] "Systems Network Architecture - Concepts and Products",
publication number GC30-3072, IBM Corporation.
[12]、「システム・ネットワーク体系--概念、製品、」、公表番号GC30-3072、IBM社。
12. Security Considerations
12. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
13. Author's Note
13. 著者注
Portions of this document were drawn from the following sources:
以下のソースからこのドキュメントの一部を得ました:
- A White Paper written by Owen Reddecliffe, WRQ Corporation,
October 1991.
- 1991年10月のオーエンReddecliffe、WRQ社によって書かれたホワイトPaper。
- Experimental work on the part of Cleve Graves and Michelle
Angel, OpenConnect Systems, 1992 - 1993.
- クリーブ・グラーブとミシェルAngel、OpenConnect Systems、1992--1993側の実験研究。
- Discussions at the March 1993 IETF meeting and TN3270 BOF at
Interop August 1993.
- 1993年3月のIETFミーティングにおける議論とInterop1993年8月におけるTN3270 BOF。
- Discussions on the "TN3270E" list, 1993.
- "TN3270E"リスト、1993についての議論。
TN3270 Enhancements Working Group [Page 11] RFC 1576 TN3270 Current Practices January 1994
TN3270増進作業部会[11ページ]RFC1576TN3270海流は1994年1月に練習されます。
14. Author's Address
14. 作者のアドレス
Jon Penner DCA, Inc. 2800 Oakmont Drive Austin, TX 78664
ジョンペネルDCA Inc.2800Oakmont Driveオースチン、テキサス 78664
Phone: (512) 388-7090 FAX
EMail: jjp@bscs.com
or dca/g=Jon/s=Penner/ou=DCAAUS@mhs.attmail.com
以下に電話をしてください。 (512) 388-7090 ファックスで、メールを送ってください: jjp@bscs.com かdca/g=ジョン/sはペネル/ou= DCAAUS@mhs.attmail.com と等しいです。
TN3270 Enhancements Working Group [Page 12]
TN3270増進作業部会[12ページ]
一覧
スポンサーリンク
