[要約] RFC 2355は、TN3270プロトコルの拡張に関する要約であり、目的はTN3270セッションの効率とセキュリティを向上させることです。
Network Working Group B. Kelly
Request for Comments: 2355 Auburn University
Obsoletes: 1647 June 1998
Category: Standards Track
TN3270 Enhancements
TN3270の機能強化
Status of this Memo
本文書の状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document describes a protocol that more fully supports 3270 devices than do traditional tn3270 practices. Specifically, it defines a method of emulating both the terminal and printer members of the 3270 family of devices via Telnet; it provides for the ability of a Telnet client to request that it be assigned a specific device-name (also referred to as "LU name" or "network name"); finally, it adds support for a variety of functions such as the ATTN key, the SYSREQ key, and SNA response handling.
このドキュメントでは、従来のtn3270プラクティスよりも3270デバイスを完全にサポートするプロトコルについて説明します。具体的には、Telnetを介して3270ファミリのデバイスのターミナルメンバーとプリンターメンバーの両方をエミュレートする方法を定義します。 Telnetクライアントが特定のデバイス名（「LU名」または「ネットワーク名」とも呼ばれる）を割り当てることを要求する機能を提供します。最後に、ATTNキー、SYSREQキー、SNA応答処理などのさまざまな機能のサポートを追加します。
This protocol is negotiated under the TN3270E Telnet Option, and is unrelated to the Telnet 3270 Regime Option as defined in RFC 1041 [1].
このプロトコルはTN3270E Telnetオプションでネゴシエートされ、RFC 1041 [1]で定義されているTelnet 3270レジームオプションとは無関係です。
TABLE OF CONTENTS
目次
1. Introduction ............................................... 2
1.1 Changes to RFC 1647 .................................... 4
2. TN3270E OVERVIEW ........................................... 5
3. COMMAND NAMES AND CODES .................................... 6
4. COMMAND MEANINGS ........................................... 7
5. DEFAULT SPECIFICATION ...................................... 9
6. MOTIVATION ................................................. 9
7. TN3270E SUB-NEGOTIATION RULES .............................. 9
7.1 DEVICE-TYPE Negotiation ................................ 9
7.1.1 Device Pools ...................................... 10
7.1.2 CONNECT Command ................................... 12
7.1.3 ASSOCIATE Command ................................. 12
7.1.4 Accepting a Request ............................... 13
7.1.5 REJECT Command .................................... 13
7.2 FUNCTIONS Negotiation .................................. 14
7.2.1 Commands .......................................... 14
7.2.2 List of TN3270E Functions ......................... 16
8. TN3270E DATA MESSAGES ...................................... 16
8.1 The TN3270E Message Header ............................. 18
8.1.1 DATA-TYPE Field ................................... 18
8.1.2 REQUEST-FLAG Field ................................ 19
8.1.3 RESPONSE-FLAG Field ............................... 19
8.1.4 SEQ-NUMBER Field .................................. 20
9. BASIC TN3270E .............................................. 20
9.1 3270 Mode and NVT Mode ................................. 21
10. DETAILS OF PROCESSING TN3270E FUNCTIONS .................... 22
10.1 The SCS-CTL-CODES Function ............................. 22
10.2 The DATA-STREAM-CTL Function ........................... 23
10.3 The BIND-IMAGE Function ................................ 24
10.4 The RESPONSES Function ................................. 25
10.4.1 Response Messages ................................. 26
10.5 The SYSREQ Function .................................... 28
10.5.1 Background ........................................ 28
10.5.2 TN3270E Implementation of SYSREQ .................. 29
11. THE 3270 ATTN KEY .......................................... 30
12. 3270 STRUCTURED FIELDS ..................................... 31
13. IMPLEMENTATION GUIDELINES .................................. 31
13.1 3270 Data Stream Notes ................................. 31
13.2 Negotiation of the TN3270E Telnet Option ............... 32
13.3 A "Keep-alive" Mechanism ............................... 32
13.4 Examples ............................................... 32
14. SECURITY CONSIDERATIONS .................................... 36
15. REFERENCES ................................................. 36
16. AUTHOR'S NOTE .............................................. 37
17. AUTHOR'S ADDRESS ........................................... 37
18. Full Copyright Statement ................................... 38
Traditionally, support for 3270 terminal emulation over Telnet has been accomplished by the de facto standard of negotiating three separate Telnet Options - Terminal-Type [2], Binary Transmission [3], and End of Record [4]. Note that there is no RFC that specifies this negotiation as a standard. RFC 1041 attempted to standardize the method of negotiating 3270 terminal support by defining the 3270 Regime Telnet Option. Very few developers and vendors ever implemented RFC 1041.
従来、Telnetを介した3270端末エミュレーションのサポートは、3つの個別のTelnetオプション（端末タイプ[2]、バイナリ転送[3]、およびレコードの終わり[4]）をネゴシエートするという事実上の標準によって実現されてきました。このネゴシエーションを標準として指定するRFCはないことに注意してください。 RFC 1041は、3270レジームTelnetオプションを定義することにより、3270端末サポートをネゴシエートする方法を標準化しようとしました。 RFC 1041を実装した開発者やベンダーはほとんどいません。
This document will refer to the existing practice of negotiating these three Telnet Options before exchanging the 3270 data stream as "traditional tn3270". Traditional tn3270 is documented in [10].
このドキュメントでは、3270データストリームを「従来のtn3270」として交換する前に、これら3つのTelnetオプションをネゴシエートする既存の方法を参照します。従来のtn3270は[10]に文書化されています。
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サーバーと非SNA 3270デバイスを表すTelnetサーバーを区別しません。
All references in this document to the 3270 data stream, 3270 data stream commands, orders, structured fields and the like rely on [5].
このドキュメントでの3270データストリーム、3270データストリームコマンド、オーダー、構造化フィールドなどへのすべての参照は、[5]に依存しています。
References to SNA Request and Response Units rely on [6]. References to SNA versus non-SNA operation rely on [7].
SNA要求および応答ユニットへの参照は、[6]に依存しています。 SNA操作と非SNA操作の参照は、[7]に依存しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119で説明されているように解釈されます。
There were several shortcomings in traditional tn3270; among them were the following:
従来のtn3270にはいくつかの欠点がありました。それらの中には次のものがあります：
- It provided no capability for Telnet clients to emulate the 328x class of printers.
- Telnetクライアントに328xクラスのプリンターをエミュレートする機能はありません。
- There was no mechanism by which a Telnet client could 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. In the case of printer emulation, this capability is an absolute necessity because a large number of host applications have some method of pre-defining printer destinations.
- Telnetクライアントが接続を特定の3270デバイス名に関連付けるよう要求できるメカニズムはありませんでした。多くのホストアプリケーションは端末のネットワーク名に応じて異なる動作をするため、これは端末セッションが確立されているときに重要になる可能性があります。プリンターエミュレーションの場合、多数のホストアプリケーションにプリンターの宛先を事前に定義する方法があるため、この機能は絶対に必要です。
- The 3270 ATTN and SYSREQ keys were not universally supported.
- 3270 ATTNおよびSYSREQキーは、普遍的にサポートされていませんでした。
- There was no support for the SNA positive/negative response process. This is particularly important if printer emulation is to function properly, but is also useful for some terminal applications. A positive response is used to indicate that the previously received data has been successfully processed. A negative response indicates some sort of error has occurred while processing the previously received data; this could be caused by the host application building a 3270 data stream that contains an invalid command, or by a mechanical error at the client side, among other things.
- SNAの正/負の応答プロセスに対するサポートはありませんでした。これは、プリンターエミュレーションが適切に機能する場合に特に重要ですが、一部の端末アプリケーションでも役立ちます。肯定応答は、以前に受信したデータが正常に処理されたことを示すために使用されます。否定応答は、以前に受信したデータの処理中に何らかのエラーが発生したことを示します。これは、とりわけ、無効なコマンドを含む3270データストリームを構築するホストアプリケーション、またはクライアント側の機械的エラーが原因である可能性があります。
- There was no mechanism by which the client could access the SNA Bind information. The Bind image contains a detailed description of the session between the Telnet server and the host application.
- クライアントがSNAバインド情報にアクセスできるメカニズムはありませんでした。バインドイメージには、Telnetサーバーとホストアプリケーション間のセッションの詳細な説明が含まれています。
- There was no mechanism by which the server could determine whether a client supported 3270 structured fields, or a client could request that it receive them.
- サーバーがクライアントが3270構造化フィールドをサポートしているかどうか、またはクライアントがフィールドの受信を要求できるかどうかをサーバーが判別できるメカニズムはありませんでした。
This document replaces RFC 1647; the following is a summary of the changes that have been incorporated:
このドキュメントはRFC 1647に代わるものです。以下は、組み込まれた変更の要約です。
- Reworded the Introduction to refer to traditional tn3270 in the past tense.
- はじめに、過去形の伝統的なtn3270を指すように書き換えました。
Affected sections: 1.
影響を受けるセクション：1。
- Added this section documenting changes to RFC 1647
- RFC 1647への変更を文書化したこのセクションを追加しました
Affected sections: 1.1
影響を受けるセクション：1.1
- Clarified the specification of numeric literals contained in the document.
- ドキュメントに含まれる数値リテラルの仕様を明確にしました。
Affected sections: 3. (first paragraph)
影響を受けるセクション：3.（最初の段落）
- Extensively revised several sections to
- いくつかのセクションを大幅に改訂し、
1) clarify the motivation behind and use of the ASSOCIATE command 2) remove restrictive wording regarding the organization and use of server maintained device pools 3) distinguish between device-names and resource-names in the TN3270E device-type negotiation, and define a maximum length for device-names and resource-names
1）ASSOCIATEコマンドの背後にある動機と明確化2）組織とサーバーが維持するデバイスプールの使用に関する制限的な表現を削除する3）TN3270Eデバイスタイプネゴシエーションでデバイス名とリソース名を区別し、最大値を定義するデバイス名とリソース名の長さ
Affected sections: 4. (DEVICE-TYPE REQUEST command) and 7.1.1 through 7.1.6
影響を受けるセクション：4.（DEVICE-TYPE REQUESTコマンド）および7.1.1〜7.1.6
- Corrected the erroneous specification of the format of the function-list sent during TN3270E functions negotiation.
- TN3270E機能のネゴシエーション中に送信される機能リストの形式の誤った指定を修正しました。
Affected sections: 7.2.1 (first paragraph)
影響を受けるセクション：7.2.1（最初の段落）
- Added a statement addressing what a client or server should do if an impasse is reached during TN3270E functions negotiation.
- TN3270E機能のネゴシエーション中に行き詰まりに達した場合にクライアントまたはサーバーが行うべきことを説明するステートメントを追加しました。
Affected sections: 7.2.1 (last paragraph)
影響を受けるセクション：7.2.1（最後の段落）
- Added a DATA-TYPE of PRINT-EOJ with a value of 0x08 to support the end-of-job indication for printers.
- プリンターのジョブ終了指示をサポートするために、0x08の値を持つPRINT-EOJのDATA-TYPEが追加されました。
Affected sections: 8.1.1, 10.1, 10.2
影響を受けるセクション：8.1.1、10.1、10.2
- Clarified the description of the SEQ-NUMBER Field to state that
- SEQ-NUMBERフィールドの説明を明確にして、
1) the field should be sent in network byte order (big endian) 2) either byte that contains a 0xff must be doubled to 0xffff before sending, and stripped back to 0xff after receipt.
1）フィールドはネットワークバイトオーダー（ビッグエンディアン）で送信する必要があります2）0xffを含むいずれかのバイトを送信前に2倍にして0xffffにし、受信後に0xffに戻す必要があります。
Affected sections: 8.1.4
影響を受けるセクション：8.1.4
- Defined the format and maximum length of the Bind image.
- バインドイメージの形式と最大長を定義しました。
Affected sections: 10.3 (fourth paragraph)
影響を受けるセクション：10.3（4番目の段落）
- Clarified the misleading wording regarding allowable DATA-TYPEs when BIND-IMAGE has been negotiated and a BIND has been sent.
- BIND-IMAGEがネゴシエートされ、BINDが送信された場合の、許容されるDATA-TYPEに関する誤解を招く表現を明確にしました。
Affected sections: 10.3 (last paragraph)
影響を受けるセクション：10.3（最後の段落）
- Clarified the use of the SEQ-NUMBER field in regards to when it should be reset to zero.
- ゼロにリセットする必要がある場合に関して、SEQ-NUMBERフィールドの使用を明確にしました。
Affected sections: 10.4 (last paragraph)
影響を受けるセクション：10.4（最後の段落）
- Clarified the format of the data when the DATA-TYPE field is SSCP-LU-DATA.
- DATA-TYPEフィールドがSSCP-LU-DATAの場合のデータの形式を明確にしました。
Affected sections: 10.5.2 (fourth paragraph)
影響を受けるセクション：10.5.2（4番目の段落）
- Reworded the Security section to refer to Kerberos.
- Kerberosを参照するようにセキュリティセクションを書き換えました。
Affected sections: 14.
影響を受けるセクション：14。
In order to address these issues, this document proposes a new Telnet Option - TN3270E. Telnet clients and servers would be free to negotiate support of the TN3270E option or not. If either side does not support TN3270E, traditional tn3270 can be used; otherwise, a sub-negotiation will occur to determine what subset of TN3270E will be used on the session. It is anticipated that a client or server capable of both types of 3270 emulation would attempt to negotiate TN3270E first, and only negotiate traditional tn3270 if the other side refuses TN3270E.
これらの問題に対処するために、このドキュメントでは新しいTelnetオプション-TN3270Eを提案しています。 Telnetクライアントとサーバーは、TN3270Eオプションのサポートを自由にネゴシエートできます。どちらかの側がTN3270Eをサポートしていない場合は、従来のtn3270を使用できます。そうでない場合、サブネゴシエーションが発生して、セッションで使用されるTN3270Eのサブセットが決定されます。両方のタイプの3270エミュレーションが可能なクライアントまたはサーバーは、最初にTN3270Eをネゴシエートしようとし、反対側がTN3270Eを拒否した場合にのみ従来のtn3270をネゴシエートすることが予想されます。
Once a client and server have agreed to use TN3270E, negotiation of the TN3270E suboptions can begin. The two major elements of TN3270E sub-negotiation are:
クライアントとサーバーがTN3270Eの使用に同意すると、TN3270Eサブオプションのネゴシエーションを開始できます。 TN3270Eサブネゴシエーションの2つの主要な要素は次のとおりです。
- a device-type negotiation that is similar to, but somewhat more complicated than, the existing Telnet Terminal-Type Option.
- 既存のTelnet Terminal-Type Optionに似ていますが、多少複雑なデバイスタイプネゴシエーション。
- the negotiation of a set of supported 3270 functions, such as printer data stream type (3270 data stream or SNA Character Stream), positive/negative response exchanges, device status information, and the passing of BIND information from server to client.
- プリンターデータストリームタイプ（3270データストリームまたはSNA文字ストリーム）、肯定/否定応答交換、デバイスステータス情報、サーバーからクライアントへのBIND情報の受け渡しなど、サポートされている一連の3270機能のネゴシエーション。
Successful negotiation of these two suboptions signals the beginning of 3270 data stream transmission. In order to support several of the new functions in TN3270E, each data message must be prefixed by a header. This header will contain flags and indicators that convey such things as positive and negative responses and what type of data follows the header (for example, 3270 data stream, SNA Character Stream, or device status information).
これら2つのサブオプションのネゴシエーションが成功すると、3270データストリームの送信が開始されます。 TN3270Eのいくつかの新しい機能をサポートするには、各データメッセージの先頭にヘッダーを付ける必要があります。このヘッダーには、肯定応答と否定応答、ヘッダーに続くデータのタイプ（3270データストリーム、SNA文字ストリーム、デバイスステータス情報など）などを伝えるフラグとインジケーターが含まれます。
Please note that all numeric literals in this document specify decimal values, unless they are preceded by "0x", in which case a hexadecimal value is represented.
このドキュメントのすべての数値リテラルは、「0x」が前に付いていない限り10進数値を指定することに注意してください。この場合、16進数値が表されます。
TN3270E 40 ASSOCIATE 00 CONNECT 01 DEVICE-TYPE 02 FUNCTIONS 03 IS 04 REASON 05 REJECT 06 REQUEST 07 SEND 08
TN3270E 40 ASSOCIATE 00 CONNECT 01 DEVICE-TYPE 02 FUNCTIONS 03 IS 04 REASON 05 REJECT 06 REQUEST 07 SEND 08
Reason-codes CONN-PARTNER 00 DEVICE-IN-USE 01 INV-ASSOCIATE 02 INV-NAME 03 INV-DEVICE-TYPE 04 TYPE-NAME-ERROR 05 UNKNOWN-ERROR 06 UNSUPPORTED-REQ 07
理由コードCONN-PARTNER 00 DEVICE-IN-USE 01 INV-ASSOCIATE 02 INV-NAME 03 INV-DEVICE-TYPE 04 TYPE-NAME-ERROR 05 UNKNOWN-ERROR 06 UNSUPPORTED-REQ 07
Function Names BIND-IMAGE 00 DATA-STREAM-CTL 01 RESPONSES 02 SCS-CTL-CODES 03 SYSREQ 04
関数名BIND-IMAGE 00 DATA-STREAM-CTL 01 RESPONSES 02 SCS-CTL-CODES 03 SYSREQ 04
Refer to the Telnet Protocol Specification [8] for the meaning of IAC, DO, WILL, etc.
IAC、DO、WILLなどの意味については、Telnetプロトコル仕様[8]を参照してください。
IAC WILL TN3270E
IACウィルTN3270E
The sender of this command is willing to send TN3270E information in subsequent sub-negotiations.
このコマンドの送信者は、後続のサブネゴシエーションでTN3270E情報を送信する用意があります。
IAC WON'T TN3270E
IAC WO N'T TN3270E
The sender of this command refuses to send TN3270E information.
このコマンドの送信者は、TN3270E情報の送信を拒否します。
IAC DO TN3270E
IAC DO TN3270E
The sender of this command is willing to receive TN3270E information in subsequent sub-negotiations.
このコマンドの送信者は、後続のサブネゴシエーションでTN3270E情報を受信する用意があります。
IAC DON'T TN3270E
IACしないTN3270E
The sender of this command refuses to receive TN3270E information.
このコマンドの送信者は、TN3270E情報の受信を拒否します。
Note that while they are not explicitly negotiated, the equivalent of the Telnet Binary Transmission Option [3] and the Telnet End of Record Option [4] is implied in the negotiation of the TN3270E Option. That is, a party to the negotiation that agrees to support TN3270E is automatically required to support bi-directional binary and EOR transmissions.
これらは明示的にネゴシエートされませんが、Telnet Binary Transmission Option [3]およびTelnet End of Recordオプション[4]に相当するものがTN3270Eオプションのネゴシエーションに含まれることに注意してください。つまり、TN3270Eのサポートに同意する交渉の当事者は、双方向のバイナリおよびEOR送信をサポートするように自動的に要求されます。
IAC SB TN3270E SEND DEVICE-TYPE IAC SE
IAC SB TN3270E SEND DEVICE-TYPE IAC SE
Only the server may send this command. This command is used to request that the client transmit a device-type and, optionally, device-name information.
サーバーのみがこのコマンドを送信できます。このコマンドは、クライアントがデバイスタイプおよびオプションでデバイス名情報を送信することを要求するために使用されます。
IAC SB TN3270E DEVICE-TYPE REQUEST <device-type>
[ [CONNECT <resource-name>] | [ASSOCIATE <device-name>] ] IAC SE
Only the client may send this command. It is used in response to the server's SEND DEVICE-TYPE command, as well as to suggest another device-type after the server has sent a DEVICE-TYPE REJECT command (see below). This command requests emulation of a specific 3270 device type and model. The REQUEST command may optionally include either the CONNECT or the ASSOCIATE command (but not both). If present, CONNECT must be followed by <resource-name> and ASSOCIATE must be followed by <device-name>. (See the section entitled "DEVICE-TYPE Negotiation" for more detailed information.)
クライアントのみがこのコマンドを送信できます。これは、サーバーのSEND DEVICE-TYPEコマンドへの応答として使用されるほか、サーバーがDEVICE-TYPE REJECTコマンドを送信した後に別のデバイスタイプを提案するためにも使用されます（以下を参照）。このコマンドは、特定の3270装置タイプおよびモデルのエミュレーションを要求します。 REQUESTコマンドには、オプションでCONNECTまたはASSOCIATEコマンドのいずれかを含めることができます（両方を含めることはできません）。存在する場合は、CONNECTの後に<resource-name>が続き、ASSOCIATEの後に<device-name>が必要です。 （詳細については、「DEVICE-TYPEネゴシエーション」というセクションを参照してください。）
IAC SB TN3270E DEVICE-TYPE IS <device-type> CONNECT
<device-name> IAC SE
Only the server may send this command. This command is used to accept a client's DEVICE-TYPE REQUEST command and to return the server-defined device-name.
サーバーのみがこのコマンドを送信できます。このコマンドは、クライアントのDEVICE-TYPE REQUESTコマンドを受け入れ、サーバー定義のデバイス名を返すために使用されます。
IAC SB TN3270E DEVICE-TYPE REJECT REASON <reason-code> IAC SE
IAC SB TN3270E DEVICE-TYPE REJECT REASON <reason-code> IAC SE
Only the server may send this command. This command is used to reject a client's DEVICE-TYPE REQUEST command.
サーバーのみがこのコマンドを送信できます。このコマンドは、クライアントのDEVICE-TYPE REQUESTコマンドを拒否するために使用されます。
IAC SB TN3270E FUNCTIONS REQUEST <function-list> IAC SE
IAC SB TN3270E機能要求<機能リスト> IAC SE
Either side may send this command. This command is used to suggest a set of 3270 functions that will be supported on this session. It is also sent as an implicit rejection of a previous FUNCTIONS REQUEST command sent by the other side (see the section entitled "FUNCTIONS Negotiation" for more information). Note that when used to reject a FUNCTIONS REQUEST command, the function-list must not be identical to that received in the previous REQUEST command.
どちらの側もこのコマンドを送信できます。このコマンドは、このセッションでサポートされる3270機能のセットを提案するために使用されます。また、相手側から送信された以前のFUNCTIONS REQUESTコマンドの暗黙の拒否としても送信されます（詳細については、「FUNCTIONSネゴシエーション」というセクションを参照してください）。 FUNCTIONS REQUESTコマンドを拒否するために使用する場合、function-listは前のREQUESTコマンドで受け取ったものと同一であってはならないことに注意してください。
IAC SB TN3270E FUNCTIONS IS <function-list> IAC SE
IAC SB TN3270E機能は<機能リスト> IAC SE
Either side may send this command. This command is sent as a response to a FUNCTIONS REQUEST command and implies acceptance of the set of functions sent to it in the REQUEST command. Note that the list of functions in the FUNCTIONS IS command must match the list that was received in the previous FUNCTIONS REQUEST command.
どちらの側もこのコマンドを送信できます。このコマンドはFUNCTIONS REQUESTコマンドへの応答として送信され、REQUESTコマンドで送信された一連の機能を受け入れることを意味します。 FUNCTIONS ISコマンドの関数のリストは、前のFUNCTIONS REQUESTコマンドで受け取ったリストと一致する必要があることに注意してください。
WON'T TN3270E
しないTN3270E
DON'T TN3270E
しないでくださいTN3270E
i.e., TN3270E will not be used.
つまり、TN3270Eは使用されません。
See the section entitled "Introduction".
「はじめに」というタイトルのセクションを参照してください。
Once it has been agreed that TN3270E will be supported, the first sub-negotiation must concern the DEVICE-TYPE (and possibly device-name) information. Only after that has been successfully negotiated can the client and server exchange FUNCTIONS information. Only after both DEVICE-TYPE and FUNCTIONS have been successfully negotiated can 3270 data stream transmission occur.
TN3270Eがサポートされることが合意されたら、最初のサブネゴシエーションはDEVICE-TYPE（およびおそらくデバイス名）情報に関係する必要があります。それが正常にネゴシエートされた後でのみ、クライアントとサーバーはFUNCTIONS情報を交換できます。 DEVICE-TYPEとFUNCTIONSの両方が正常にネゴシエートされた後でのみ、3270データストリームの送信が発生します。
Device-type names are NVT ASCII strings, all upper case.
デバイスタイプ名はNVT ASCII文字列で、すべて大文字です。
Device-type (and device-name) negotiation begins when the server transmits the DEVICE-TYPE SEND command to the client. The client responds with the DEVICE-TYPE REQUEST command, which must include a device-type and may include a resource-name or device-name request.
サーバーがクライアントにDEVICE-TYPE SENDコマンドを送信すると、デバイスタイプ（およびデバイス名）のネゴシエーションが始まります。クライアントはDEVICE-TYPE REQUESTコマンドで応答します。このコマンドには、デバイスタイプが含まれている必要があり、リソース名またはデバイス名の要求が含まれる場合があります。
Valid device-types are:
有効なデバイスタイプは次のとおりです。
erminals: IBM-3278-2 IBM-3278-2-E (24 row x 80 col display) IBM-3278-3 IBM-3278-3-E (32 row x 80 col display) IBM-3278-4 IBM-3278-4-E (43 row x 80 col display) IBM-3278-5 IBM-3278-5-E (27 row x 132 col display) IBM-DYNAMIC (no pre-defined display size)
ターミナル：IBM-3278-2 IBM-3278-2-E（24列x 80列ディスプレイ）IBM-3278-3 IBM-3278-3-E（32列x 80列ディスプレイ）IBM-3278-4 IBM-3278 -4-E（43列x 80列のディスプレイ）IBM-3278-5 IBM-3278-5-E（27列x 132列のディスプレイ）IBM-DYNAMIC（事前定義されたディスプレイサイズなし）
printers: IBM-3287-1
プリンター：IBM-3287-1
Note that the use of '3278' and '3287' is NOT intended to exclude any particular device capabilities; they are used here only because they are commonly known designations for a terminal and a printer member of the 3270 family of devices. The intention is to simplify the device-type negotiation (in comparison to traditional tn3270) by minimizing the number of possible device-types, and by breaking the association of a specific piece of IBM hardware with a related set of data stream capabilities. For example, negotiation of device-type IBM-3278-2-E does NOT in and of itself preclude the use of any of the functions associated with a physical 3279 model S2B. A client's ability to support the more advanced functions of the 3270 data stream will be indicated not by negotiation of an IBM device type and model number, but rather by the combination of Read Partition Query and Query Reply.
「3278」および「3287」の使用は、特定のデバイス機能を除外することを意図していないことに注意してください。これらは、3270ファミリーのデバイスの端末およびプリンターメンバーの一般的な既知の指定であるため、ここで使用されています。可能なデバイスタイプの数を最小限に抑え、IBMハードウェアの特定の部分と関連するデータストリーム機能のセットとの関連付けを解除することにより、デバイスタイプのネゴシエーションを（従来のtn3270と比較して）簡素化することを目的としています。たとえば、デバイスタイプIBM-3278-2-Eのネゴシエーション自体は、物理的な3279モデルS2Bに関連付けられた機能の使用を妨げるものではありません。 3270データストリームのより高度な機能をサポートするクライアントの機能は、IBMデバイスタイプとモデル番号のネゴシエーションではなく、読み取りパーティションクエリとクエリ応答の組み合わせによって示されます。
All of the terminal device-types support a "primary" display size of 24 rows by 80 columns. The "-3", "-4" and "-5" types each support an "alternate" display size as noted in the above list. The IBM-DYNAMIC device-type implies no pre-defined alternate display size; this value will be passed from the client to host applications as part of the Query Reply structured field, and it can represent any display size the client and the host application can support.
すべての端末デバイスタイプは、24行x 80列の「プライマリ」ディスプレイサイズをサポートします。上記のリストにあるように、「-3」、「-4」、「-5」タイプはそれぞれ「代替」ディスプレイサイズをサポートします。 IBM-DYNAMICデバイスタイプは、事前定義された代替ディスプレイサイズを意味しません。この値は、Query Reply構造化フィールドの一部としてクライアントからホストアプリケーションに渡され、クライアントとホストアプリケーションがサポートできる任意の表示サイズを表すことができます。
Terminal device-types with the "-E" suffix should only be negotiated by clients that are willing to support some subset of the 3270 "extended data stream". This usually includes at a minimum support for extended colors and highlighting, but may also include a number of other functions, such as graphics capability, alternate character sets, and partitions.
「-E」サフィックスが付いた端末デバイスタイプは、3270の「拡張データストリーム」のサブセットをサポートする用意があるクライアントによってのみネゴシエートされる必要があります。これには通常、拡張色と強調表示の最低限のサポートが含まれますが、グラフィックス機能、代替文字セット、パーティションなど、他の多くの機能が含まれる場合もあります。
Clients that negotiate a terminal device-type with the "-E" suffix or the DYNAMIC type, as well as those that negotiate a printer device-type, must be able to accept and respond to a Read Partition Query command (see the section entitled "3270 Structured Fields"). This allows the client to indicate to host applications which subsets of the 3270 extended data stream the client is willing to support.
「-E」サフィックスまたはDYNAMICタイプを使用して端末デバイスタイプをネゴシエートするクライアント、およびプリンターデバイスタイプをネゴシエートするクライアントは、Read Partition Queryコマンドを受け入れて応答できる必要があります（「 「3270構造化フィールド」）。これにより、クライアントは、クライアントがサポートしようとしている3270拡張データストリームのサブセットをホストアプリケーションに示すことができます。
In a VTAM/SNA environment, negotiation of IBM-DYNAMIC as the device-type should result in a Bind in which the Presentation Services Usage screen field (the eleventh byte in the logmode's PSERVIC field) is set to 0x03, indicating that the alternate screen size will be determined by the Query Reply (Usable Area).
VTAM / SNA環境では、デバイスタイプとしてIBM-DYNAMICをネゴシエーションすると、バインドが発生します。このバインドでは、Presentation Services Usage画面フィールド（ログモードのPSERVICフィールドの11番目のバイト）が0x03に設定され、代替画面であることを示します。サイズは、クエリ応答（使用可能領域）によって決定されます。
An explanation of the CONNECT and ASSOCIATE commands first requires a discussion of the organization of terminal and printer device pools that the server maintains and from which it selects device-names to assign to session requests. Definition of a few terms is also in order.
CONNECTおよびASSOCIATEコマンドの説明では、最初に、サーバーが維持し、セッション要求に割り当てるデバイス名を選択する端末およびプリンターデバイスプールの構成について説明する必要があります。いくつかの用語の定義も適切です。
The terms "device-name", "LU name" and "network name" can be considered interchangeable in this document. They refer to a specific terminal or printer device.
このドキュメントでは、「デバイス名」、「LU名」、および「ネットワーク名」という用語は互換性があると見なすことができます。これらは特定の端末またはプリンターデバイスを指します。
The term "resource-name" is less specific; it may refer to a device-name, but it may also be the name of a pool of printer or terminal devices. Such a named pool could serve to group devices with similar operational or administrative characteristics. In fact, this document places no restrictions on how a server makes use of resource-names, so long as the server can take a resource-name specified by the client and use it to come up with a device-name to assign to the session. Note, however, that servers must avoid allowing ambiguity; for example, they must not allow the definition of a device-name with the same name as that of a pool of devices.
「リソース名」という用語はそれほど具体的ではありません。デバイス名を参照することもできますが、プリンターまたは端末デバイスのプールの名前にすることもできます。このような名前付きプールは、同様の操作または管理特性を持つデバイスをグループ化するのに役立ちます。実際、このドキュメントでは、サーバーがクライアントによって指定されたリソース名を取得し、それを使用してセッションに割り当てるデバイス名を考え出すことができる限り、サーバーがリソース名を使用する方法に制限はありません。 。ただし、サーバーはあいまいさを許容しないようにする必要があることに注意してください。たとえば、デバイスのプールと同じ名前のデバイス名の定義を許可してはなりません。
Device-names and resource-names are specified as NVT ASCII strings in which upper and lower case are considered equivalent. The length of device-names and resource-names should not exceed 8 bytes.
デバイス名とリソース名は、大文字と小文字が同等と見なされるNVT ASCII文字列として指定されます。デバイス名とリソース名の長さは8バイトを超えてはなりません。
A "generic session request" is one which includes neither the CONNECT nor the ASSOCIATE command, while a "specific session request" is one that includes either the CONNECT or the ASSOCIATE command.
「一般的なセッション要求」は、CONNECTコマンドもASSOCIATEコマンドも含まない要求ですが、「特定のセッション要求」は、CONNECTコマンドまたはASSOCIATEコマンドのいずれかを含む要求です。
If a TN3270E server wishes to support traditional tn3270 clients, it must maintain a set of terminal device-names that can be used to satisfy requests from such clients for terminal sessions. This same pool could be used to satisfy generic requests for terminal sessions from TN3270E clients.
TN3270Eサーバーが従来のtn3270クライアントをサポートしたい場合は、そのようなクライアントからのターミナルセッションの要求を満たすために使用できる端末デバイス名のセットを維持する必要があります。これと同じプールを使用して、TN3270Eクライアントからのターミナルセッションに対する一般的な要求を満たすことができます。
The server may also maintain any number of other pools of device-names. For example, there could be a pool of terminal device-names reserved for a specific department within the organization, or a pool of terminal device-names that have access to certain applications on the host.
サーバーは、デバイス名の他のプールもいくつでも保持できます。たとえば、組織内の特定の部門用に予約された端末デバイス名のプール、またはホスト上の特定のアプリケーションにアクセスできる端末デバイス名のプールが存在する可能性があります。
For any of these terminal device pools, the TN3270E server may also have defined a "partner" or "paired" printer device for each terminal in the pool. There should be a unique, one-to-one mapping between a terminal and its associated printer. The reasoning behind such a configuration is to allow for those host applications that produce printed output bound for a printer whose device-name is determined by the device-name of the terminal that initiated the print request. These printer devices can only be assigned to specific printer session requests that use the ASSOCIATE command (see below).
これらの端末デバイスプールのいずれについても、TN3270Eサーバーは、プール内の各端末に対して「パートナー」または「ペア」のプリンターデバイスを定義している場合もあります。端末とそれに関連付けられたプリンタの間には、一意の1対1のマッピングが必要です。そのような構成の背後にある理由は、デバイス名が印刷要求を開始した端末のデバイス名によって決定されるプリンターにバインドされた印刷出力を生成するホストアプリケーションを許可するためです。これらのプリンターデバイスは、ASSOCIATEコマンドを使用する特定のプリンターセッション要求にのみ割り当てることができます（以下を参照）。
In addition, the TN3270E server may also maintain one or more pools of printer device-names that are not associated with any terminal. These printer devices can only be assigned to specific printer session requests that use the CONNECT command (see below). This allows for those host applications that generate printed output bound for a printer whose device-name is determined by something other than the device-name of the terminal that initiated the print request (for example, when the userid of the person signed on to a terminal determines the print destination). It is also possible that a pool of printer device-names could be maintained to satisfy generic requests for printers (i.e., those that specify neither CONNECT nor ASSOCIATE).
さらに、TN3270Eサーバーは、どの端末にも関連付けられていないプリンターデバイス名の1つ以上のプールを維持することもできます。これらのプリンターデバイスは、CONNECTコマンドを使用する特定のプリンターセッション要求にのみ割り当てることができます（以下を参照）。これにより、印刷要求を開始した端末のデバイス名以外でデバイス名が決定されるプリンターにバインドされた印刷出力を生成するホストアプリケーションが可能になります（たとえば、ユーザーのユーザーIDが端末が印刷先を決定します）。プリンターの一般的な要求（つまり、CONNECTもASSOCIATEも指定していない要求）を満たすために、プリンターのデバイス名のプールを維持することもできます。
CONNECT can be used by the client in two ways: if the resource-name it specifies is a device-name, then the client is requesting a specific device-name. If the specified resource-name is not a device-name, then the client is requesting any one of the device-names associated with the resource-name.
CONNECTは、クライアントが2つの方法で使用できます。それが指定するリソース名がデバイス名である場合、クライアントは特定のデバイス名を要求します。指定されたリソース名がデバイス名ではない場合、クライアントはリソース名に関連付けられたデバイス名のいずれかを要求しています。
In either case, the resource indicated by the specified resource-name must not conflict with the device-type; e.g., if the client requests DEVICE-TYPE IBM-3287-1 (a printer) and specifies CONNECT T1000001, but T1000001 is a device-name defined at the host as a terminal, then the server must deny the request. Further, if the requested resource-name is a device-name already associated with some other Telnet session, or if it is not defined to the server, the server must deny the request.
どちらの場合でも、指定されたresource-nameによって示されるリソースは、デバイスタイプと競合してはなりません。たとえば、クライアントがDEVICE-TYPE IBM-3287-1（プリンター）を要求し、CONNECT T1000001を指定したが、T1000001がホストで端末として定義されたデバイス名である場合、サーバーは要求を拒否する必要があります。さらに、要求されたリソース名がすでに他のTelnetセッションに関連付けられているデバイス名である場合、またはサーバーに定義されていない場合、サーバーは要求を拒否する必要があります。
ASSOCIATE can be used by the client only when requesting a DEVICE-TYPE that represents a printer, and the specified device-name must be that of a terminal that was returned by the server in a previous DEVICE-TYPE IS <device-type> CONNECT <device-name> command.
ASSOCIATEは、プリンターを表すDEVICE-TYPEを要求する場合にのみクライアントで使用でき、指定されたデバイス名は、以前のDEVICE-TYPE IS <device-type> CONNECTでサーバーによって返された端末の名前である必要があります<デバイス名>コマンド。
The ASSOCIATE command requests that this session be assigned the device-name of the printer that is paired with the terminal named in the request. If the device-type does not represent a printer, or if the device-name is not that of a terminal, then the server must deny the request. Also, if the server does not have defined a partner printer for the specified terminal, it must deny the request.
ASSOCIATEコマンドは、このセッションに、要求で指定された端末とペアになっているプリンターのデバイス名を割り当てることを要求します。 device-typeがプリンターを表していない場合、またはdevice-nameが端末の名前ではない場合、サーバーは要求を拒否する必要があります。また、サーバーが指定された端末のパートナープリンターを定義していない場合は、要求を拒否する必要があります。
The use of the ASSOCIATE command is to be as follows: A client first connects and requests a terminal from one of the terminal pools; it then uses the terminal device-name returned by the server (see "Accepting a Request", section 7.1.4 below) in a second session request, this time asking for the printer that is paired with the terminal session it just established. This allows clients to associate a printer session with a terminal rather than having to have prior knowledge of a printer device-name.
ASSOCIATEコマンドの使用法は次のとおりです。クライアントは最初に接続し、端末プールの1つから端末を要求します。次に、サーバーから返されたターミナルデバイス名（以下の「リクエストの受け入れ」のセクション7.1.4を参照）を2番目のセッションリクエストで使用します。今回は、確立したばかりのターミナルセッションとペアになっているプリンターを要求します。これにより、クライアントは、プリンターのデバイス名を事前に知っている必要がなく、プリンターセッションを端末に関連付けることができます。
The server must accept the client's request or deny it as a whole - it cannot, for example, accept the DEVICE-TYPE request but deny the CONNECT portion.
サーバーはクライアントの要求を受け入れるか、全体として拒否する必要があります。たとえば、DEVICE-TYPE要求を受け入れることはできませんが、CONNECT部分は拒否します。
If the server wishes to accept the request, it sends back the DEVICE-TYPE IS command confirming the requested device-type and the CONNECT command specifying the device-name of the terminal or printer assigned to this session.
サーバーが要求を受け入れたい場合、サーバーは、要求されたデバイスタイプを確認するDEVICE-TYPE ISコマンドと、このセッションに割り当てられた端末またはプリンターのデバイス名を指定するCONNECTコマンドを送り返します。
Normally, the client should accept any DEVICE-TYPE IS <device-type> CONNECT <device-name> sent by the server. An exception to this would be if the client must (e.g., to satisfy local-site policy) be connected to a specific LU name and is presented with a device-name which does not match the one requested by the client (this could happen, for example, if the client requested what it thought was a device-name, but what was defined at the server as the name of a pool of devices). In this case, the client should reject the DEVICE-TYPE IS command by terminating TN3270E negotiations.
通常、クライアントはサーバーから送信されたDEVICE-TYPE IS <device-type> CONNECT <device-name>を受け入れます。これに対する例外は、クライアントが特定のLU名に接続する必要がある場合（たとえば、ローカルサイトのポリシーを満たすため）、クライアントによって要求されたものと一致しないデバイス名が提示される場合です（これは発生する可能性があります）。たとえば、クライアントがデバイス名と思ったものを要求したが、サーバーでデバイスのプールの名前として定義されたものを要求した場合）。この場合、クライアントはTN3270Eネゴシエーションを終了することにより、DEVICE-TYPE ISコマンドを拒否する必要があります。
If the server wishes to deny the request, it sends back the DEVICE-TYPE REJECT command with one of the following reason-codes:
サーバーが要求を拒否する場合は、次の理由コードのいずれかを使用してDEVICE-TYPE REJECTコマンドを送り返します。
Reason code name Explanation
---------------- -----------------------------------
INV-DEVICE-TYPE The server does not support the
requested device-type.
INV-NAME The resource-name or device-name specified in the CONNECT or ASSOCIATE command is not known to the server.
INV-NAME CONNECTまたはASSOCIATEコマンドで指定されたリソース名またはデバイス名がサーバーに認識されていません。
DEVICE-IN-USE The requested device-name is already associated with another session.
DEVICE-IN-USE要求されたデバイス名はすでに別のセッションに関連付けられています。
TYPE-NAME-ERROR The requested device-name or resource-name is incompatible with the requested device-type (such as terminal/printer mismatch).
TYPE-NAME-ERROR要求されたデバイス名またはリソース名は、要求されたデバイスタイプと互換性がありません（端末/プリンターの不一致など）。
UNSUPPORTED-REQ The server is unable to satisfy the type of request sent by the client; e.g., a specific terminal or printer was requested but the server does not have any such pools of device-names defined to it, or the ASSOCIATE command was used but no partner printers are defined to the server.
UNSUPPORTED-REQサーバーは、クライアントから送信された要求のタイプを満たすことができません。たとえば、特定の端末またはプリンターが要求されたが、サーバーにそのようなデバイス名のプールが定義されていないか、ASSOCIATEコマンドが使用されましたが、サーバーにパートナープリンターが定義されていません。
INV-ASSOCIATE The client used the ASSOCIATE command and either the device-type is not a printer or the device-name is not a terminal.
INV-ASSOCIATEクライアントがASSOCIATEコマンドを使用し、デバイスタイプがプリンタではないか、デバイス名が端末ではありません。
CONN-PARTNER The client used the CONNECT command to request a specific printer but the device-name requested is the partner to some terminal.
CONN-PARTNERクライアントはCONNECTコマンドを使用して特定のプリンターを要求しましたが、要求されたデバイス名は何らかの端末のパートナーです。
UNKNOWN-ERROR Any other error in device type or name processing has occurred.
UNKNOWN-ERRORデバイスタイプまたは名前の処理でその他のエラーが発生しました。
The process of negotiating a device-type and device-name that are acceptable to both client and server may entail several iterations of DEVICE-TYPE REQUEST and DEVICE-TYPE REJECT commands. The client must make use of the reason-code specified by the server in any DEVICE-TYPE REJECT command(s) to minimize the amount of negotiation necessary. For example, if the client initially requests that it be assigned a specific terminal device-name via the CONNECT command, and the server rejects the request with a reason-code of UNSUPPORTED-REQ, the client must make no further specific terminal requests in the negotiations. If at any point in the process either side wishes to "bail out," it can simply send a WON'T (or DON'T) TN3270E command to the other side. At this point both sides are free to negotiate other Telnet options (including traditional tn3270).
クライアントとサーバーの両方で受け入れ可能なデバイスタイプとデバイス名をネゴシエートするプロセスでは、DEVICE-TYPE REQUESTコマンドとDEVICE-TYPE REJECTコマンドを何度か繰り返す必要があります。クライアントは、サーバーが指定した理由コードをDEVICE-TYPE REJECTコマンドで使用して、必要なネゴシエーションの量を最小限に抑える必要があります。たとえば、クライアントが最初にCONNECTコマンドを介して特定の端末デバイス名を割り当てるように要求し、サーバーが理由コードUNSUPPORTED-REQで要求を拒否した場合、クライアントは交渉。プロセスのいずれかの時点でいずれかの側が「救済」を希望する場合は、単にWO N'T（またはDO N'T）TN3270Eコマンドを反対側に送信できます。この時点で、両側は他のTelnetオプション（従来のtn3270を含む）を自由にネゴシエートできます。
Once the DEVICE-TYPE negotiation has successfully completed (i.e, when the client receives a DEVICE-TYPE IS command that is acceptable), the client must initiate the FUNCTIONS negotiation by sending the FUNCTIONS REQUEST command to the server. After this initial REQUEST command, both sides are free to transmit FUNCTIONS REQUEST and FUNCTIONS IS commands as needed.
DEVICE-TYPEネゴシエーションが正常に完了すると（つまり、クライアントが受け入れ可能なDEVICE-TYPE ISコマンドを受信すると）、クライアントはFUNCTIONS REQUESTコマンドをサーバーに送信してFUNCTIONSネゴシエーションを開始する必要があります。この最初のREQUESTコマンドの後、両側は必要に応じてFUNCTIONS REQUESTコマンドとFUNCTIONS ISコマンドを自由に送信できます。
The FUNCTIONS REQUEST command contains a list of the TN3270E functions that the sender would like to see supported on this session. All functions not in the list are to be considered unsupported. The list is terminated by the IAC code that precedes the SE command. Functions may appear in any order in the list.
FUNCTIONS REQUESTコマンドには、送信者がこのセッションでサポートされていることを確認したいTN3270E関数のリストが含まれています。リストにない機能はすべてサポート対象外と見なされます。リストは、SEコマンドの前にあるIACコードで終了します。関数はリスト内で任意の順序で表示されます。
Upon receipt of a FUNCTIONS REQUEST command, the recipient has two choices:
FUNCTIONS REQUESTコマンドを受信すると、受信者には2つの選択肢があります。
- it may respond in the positive (meaning it agrees to support all functions in the list, and not to transmit any data related to functions not in the list). To do this, it sends the FUNCTIONS IS command with the function-list exactly as it was received. At this point, FUNCTIONS negotiation has successfully completed.
- 肯定的に応答する場合があります（リストのすべての機能をサポートし、リストにない機能に関連するデータを送信しないことに同意することを意味します）。これを行うために、受信したとおりにfunction-listを含むFUNCTIONS ISコマンドを送信します。この時点で、FUNCTIONSネゴシエーションは正常に完了しています。
- it may respond in the negative by sending a FUNCTIONS REQUEST command in which the function-list differs from the one it received (and not simply in the order of appearance of functions in the list; at least one function must have been added to, or removed from, the list).
- function-listが受信したものとは異なるFUNCTIONS REQUESTコマンドを送信することで否定的に応答する場合があります（リスト内の関数の出現順ではありません。少なくとも1つの関数が追加されている必要があります。またはリストから削除されました）。
To avoid endlessly looping, both parties must not add to the function-list it receives any function that it has previously added and that the other side has removed.
無限ループを回避するために、両方のパーティは、以前に追加した機能と反対側が削除した機能を受け取る機能リストに追加しないでください。
The process of sending FUNCTIONS REQUEST commands back and forth continues until one side receives a function-list it is willing to live with. It uses the FUNCTIONS IS command to accept the list, and, once this command is received by the other side, all necessary negotiation has been completed. At this point, 3270 data stream transmission can begin.
FUNCTIONS REQUESTコマンドを前後に送信するプロセスは、一方の側が共存できる関数リストを受信するまで続きます。 FUNCTIONS ISコマンドを使用してリストを受け入れ、このコマンドが相手側で受信されると、必要なすべてのネゴシエーションが完了します。この時点で、3270データストリームの送信を開始できます。
Note that it is possible that the function-list agreed to is null; this is referred to as "basic TN3270E". See the section entitled "Basic TN3270E" for more information.
合意された関数リストがnullである可能性があることに注意してください。これは「基本TN3270E」と呼ばれます。詳細については、「基本的なTN3270E」というタイトルのセクションを参照してください。
If an impasse is reached during FUNCTIONS negotiation (for example, if a client requested and was granted a DEVICE-TYPE representing a printer, but refuses to accept either the SCS-CTL-CODES or DATA-STREAM-CTL function), then the "offended" party should terminate the negotiation by sending an IAC DON'T (or WON'T) TN3270E.
FUNCTIONSネゴシエーション中に行き詰まりに達した場合（たとえば、クライアントがプリンターを表すDEVICE-TYPEを要求して許可されたが、SCS-CTL-CODES関数またはDATA-STREAM-CTL関数のいずれかを受け入れることを拒否した場合）、「気分を害した」当事者は、IAC DO N'T（またはWO N'T）TN3270Eを送信して、交渉を終了する必要があります。
The following list briefly describes the 3270 functions that may be negotiated in the function-list:
次のリストは、function-listでネゴシエートできる3270機能を簡単に説明しています。
Function Name Description
------------- -----------
SCS-CTL-CODES (Printer sessions only). Allows the use
of the SNA Character Stream (SCS) and SCS
control codes on the session. SCS is
used with LU type 1 SNA sessions.
DATA-STREAM-CTL (Printer sessions only). Allows the use of the standard 3270 data stream. This corresponds to LU type 3 SNA sessions.
DATA-STREAM-CTL（プリンターセッションのみ）。標準3270データストリームの使用を許可します。これは、LUタイプ3 SNAセッションに対応します。
RESPONSES Provides support for positive and negative response handling. Allows the server to reflect to the client any and all definite, exception, and no response requests sent by the host application.
RESPONSES肯定応答と否定応答の処理をサポートします。サーバーがクライアントに、ホストアプリケーションから送信されたすべての明確な例外、例外なしの応答要求を反映できるようにします。
BIND-IMAGE Allows the server to send the SNA Bind image and Unbind notification to the client.
BIND-IMAGEサーバーがSNAバインドイメージとアンバインド通知をクライアントに送信できるようにします。
SYSREQ Allows the client and server to emulate some (or all, depending on the server) of the functions of the SYSREQ key in an SNA environment.
SYSREQクライアントとサーバーが、SNA環境でSYSREQキーの機能の一部（またはサーバーによってはすべて）をエミュレートできるようにします。
See the section entitled "Details of Processing TN3270E Functions" for a more detailed explanation of the meaning and use of these functions.
これらの関数の意味と使用法の詳細については、「TN3270E関数の処理の詳細」というタイトルのセクションを参照してください。
If in the process of functions negotiation an unrecognized function code is recieved, the recipient should simply remove that function code from the list and continue normal functions negotiation.
関数ネゴシエーションの過程で認識されない関数コードが受信された場合、受信者はリストからその関数コードを削除し、通常の関数ネゴシエーションを続行する必要があります。
3270 device communications are generally understood to be block oriented in nature. That is, each partner buffers data until an entire "message" has been built, at which point the data is sent to the other side. The "outbound message" (from host to device) consists of a 3270 command and a series of buffer orders, buffer addresses, and data, while the "inbound message" contains only buffer orders, addresses and data. The end of a message is understood to be the last byte transmitted (note that this discussion disregards SNA chaining). The Telnet EOR command is used to delimit these natural blocks of 3270 data within the Telnet data stream.
3270デバイス通信は、一般にブロック指向であると一般に理解されています。つまり、各パートナーは、「メッセージ」全体が構築されるまでデータをバッファリングします。この時点で、データは反対側に送信されます。 「ホストからデバイスへの」送信メッセージは、3270コマンドと一連のバッファ順序、バッファアドレス、およびデータで構成されますが、「受信メッセージ」には、バッファ順序、アドレス、およびデータのみが含まれます。メッセージの終わりは、送信された最後のバイトであると理解されます（この説明では、SNAチェーンは無視されることに注意してください）。 Telnet EORコマンドは、Telnetデータストリーム内の3270データのこれらの自然なブロックを区切るために使用されます。
In TN3270E, each 3270 message must be prefixed with a TN3270E header, which consists of five bytes and whose format is defined below (see the section entitled "The TN3270E Message Header"). A "data message" in TN3270E therefore has the following construction:
TN3270Eでは、各3270メッセージの前にTN3270Eヘッダーを付ける必要があります。TN3270Eヘッダーは5バイトで構成され、そのフォーマットは以下で定義されます（「TN3270Eメッセージヘッダー」というタイトルのセクションを参照）。したがって、TN3270Eの「データメッセージ」は次のような構造になっています。
<TN3270E Header><data><IAC EOR>
It should be noted that it is possible that, for certain message types, there is no data portion present. In this case, the TN3270E data message consists of:
特定のメッセージタイプでは、データ部分が存在しない可能性があることに注意してください。この場合、TN3270Eデータメッセージは次のもので構成されます。
<TN3270E Header><IAC EOR>
If either side wishes to transmit the decimal value 255 and have it interpreted as data, it must "double" this byte. In other words, a single occurrence of decimal 255 will be interpreted by the other side as an IAC, while two successive bytes containing decimal 255 will be treated as one data byte with a value of decimal 255.
10進数の値255を送信してデータとして解釈させる場合は、このバイトを「2倍」にする必要があります。つまり、10進数の255が1回出現すると、反対側ではIACとして解釈されますが、10進数の255を含む2つの連続するバイトは、10進数の255の値を持つ1つのデータバイトとして扱われます。
It is strongly recommended that Telnet commands (other than IAC IAC) should be sent between TN3270E data messages, with no header and no trailing IAC EOR. If a TN3270E data message containing either IAC IP (to be interpreted as 3270 Attention) or IAC AO (to be interpreted as SYSREQ) is received, the receiver should defer processing the command until the 3270 data has been processed (see the appropriate sections for discussion of 3270 Attention and SYSREQ). If a TN3270E data message containing any other IAC-command sequence (other than IAC IAC) is received, it is implementation dependent when the IAC-command sequence will be processed, but it must be processed. The receiver may process it immediately, which in effect causes it to be processed as if it had been received before the current TN3270E data message, or the processing may be deferred until after the current TN3270E data message has been processed. It is because of this ambiguity that the presence of Telnet commands within a TN3270E data message (i.e., between the header and the trailing IAC EOR) is not recommended; neither clients nor servers should send such data.
Telnetコマンド（IAC IAC以外）は、ヘッダーや後続のIAC EORなしで、TN3270Eデータメッセージ間で送信することを強くお勧めします。 IAC IP（3270アテンションとして解釈される）またはIAC AO（SYSREQとして解釈される）のいずれかを含むTN3270Eデータメッセージを受信した場合、受信者は3270データが処理されるまでコマンドの処理を延期する必要があります（適切なセクションを参照）。 3270 AttentionとSYSREQの説明）。他のIACコマンドシーケンス（IAC IAC以外）を含むTN3270Eデータメッセージを受信した場合、IACコマンドシーケンスを処理するタイミングは実装に依存しますが、処理する必要があります。受信者はそれをすぐに処理できます。これにより、現在のTN3270Eデータメッセージの前に受信されたかのように処理されます。または、現在のTN3270Eデータメッセージが処理されるまで処理が延期される場合があります。このあいまいさが原因で、TN3270Eデータメッセージ内（つまり、ヘッダーと後続のIAC EORの間）でTelnetコマンドを使用することはお勧めできません。クライアントもサーバーもそのようなデータを送信するべきではありません。
As stated earlier, each data message in TN3270E must be prefixed by a header, which consists of five bytes and is formatted as follows:
前述のように、TN3270Eの各データメッセージには、5バイトで構成され、次のようなフォーマットのヘッダーが前に付いている必要があります。
-----------------------------------------------------------
| DATA-TYPE | REQUEST-FLAG | RESPONSE-FLAG | SEQ-NUMBER |
-----------------------------------------------------------
1 byte 1 byte 1 byte 2 bytes
The DATA-TYPE field indicates how the data portion of the message is to be interpreted by the receiver. Possible values for the DATA-TYPE field are:
DATA-TYPEフィールドは、メッセージのデータ部分が受信者によってどのように解釈されるかを示します。 DATA-TYPEフィールドの可能な値は次のとおりです。
Data-type Name Code Meaning
-------------- ---- ---------------------------------
3270-DATA 0x00 The data portion of the message
contains only the 3270 data stream.
SCS-DATA 0x01 The data portion of the message contains SNA Character Stream data.
SCS-DATA 0x01メッセージのデータ部分には、SNA文字ストリームデータが含まれています。
RESPONSE 0x02 The data portion of the message constitutes device-status information and the RESPONSE-FLAG field indicates whether this is a positive or negative response (see below).
RESPONSE 0x02メッセージのデータ部分はデバイスステータス情報を構成し、RESPONSE-FLAGフィールドはこれが肯定応答か否定応答かを示します（以下を参照）。
BIND-IMAGE 0x03 The data portion of the message is the SNA bind image from the session established between the server and the host application.
BIND-IMAGE 0x03メッセージのデータ部分は、サーバーとホストアプリケーションの間で確立されたセッションからのSNAバインドイメージです。
UNBIND 0x04 The data portion of the message is an Unbind reason code.
UNBIND 0x04メッセージのデータ部分は、バインド解除理由コードです。
NVT-DATA 0x05 The data portion of the message is to be interpreted as NVT data.
NVT-DATA 0x05メッセージのデータ部分はNVTデータとして解釈されます。
REQUEST 0x06 There is no data portion present in the message. Only the REQUEST-FLAG field has any meaning.
REQUEST 0x06メッセージにデータ部分がありません。 REQUEST-FLAGフィールドのみが意味を持ちます。
SSCP-LU-DATA 0x07 The data portion of the message is data from the SSCP-LU session.
SSCP-LU-DATA 0x07メッセージのデータ部分は、SSCP-LUセッションからのデータです。
PRINT-EOJ 0x08 There is no data portion present in the message. This value can be sent only by the server, and only on a printer session.
PRINT-EOJ 0x08メッセージにデータ部分がありません。この値は、サーバーとプリンターセッションでのみ送信できます。
The REQUEST-FLAG field only has meaning when the DATA-TYPE field has a value of REQUEST; otherwise, the REQUEST-FLAG field must be ignored by the receiver and should be set to 0x00 by the sender. Possible values for the REQUEST-FLAG field are:
REQUEST-FLAGフィールドは、DATA-TYPEフィールドの値がREQUESTの場合にのみ意味があります。それ以外の場合、REQUEST-FLAGフィールドは受信側で無視する必要があり、送信側で0x00に設定する必要があります。 REQUEST-FLAGフィールドの可能な値は次のとおりです。
Request-Flag Name Code Meaning
----------------- ---- ---------------------------------
ERR-COND-CLEARED 0x00 The client sends this to the server
when some previously encountered
printer error condition has been
cleared. (See the section entitled
"The RESPONSES Function" below.)
The RESPONSE-FLAG field only has meaning for certain values of the DATA-TYPE field. For DATA-TYPE field values of 3270-DATA and SCS-DATA, the RESPONSE-FLAG is an indication of whether or not the sender of the data expects to receive a response. In this case the possible values of RESPONSE-FLAG are:
RESPONSE-FLAGフィールドは、DATA-TYPEフィールドの特定の値に対してのみ意味があります。 DATA-TYPEフィールド値が3270-DATAおよびSCS-DATAの場合、RESPONSE-FLAGは、データの送信者が応答を受信することを期待しているかどうかを示します。この場合、RESPONSE-FLAGの可能な値は次のとおりです。
Response-Flag Name Code Meaning
------------------ ---- ---------------------------------
NO-RESPONSE 0x00 The sender does not expect the
receiver to respond either
positively or negatively to this
message. The receiver must
therefore not send any response
to this data-message.
ERROR-RESPONSE 0x01 The sender only expects the receiver to respond to this message if some type of error occurred, in which case a negative response must be sent by the receiver.
ERROR-RESPONSE 0x01送信者は、何らかのタイプのエラーが発生した場合にのみ受信者がこのメッセージに応答することを期待します。この場合、受信者は否定応答を送信する必要があります。
ALWAYS-RESPONSE 0x02 The sender expects the receiver to respond negatively if an error occurs, or positively if no errors occur. One or the other must always be sent by the receiver.
ALWAYS-RESPONSE 0x02送信者は、エラーが発生した場合は受信者が否定的に応答し、エラーが発生しなかった場合は肯定的に応答することを期待します。どちらか一方は常に受信側から送信される必要があります。
For a DATA-TYPE field value of RESPONSE, the RESPONSE-FLAG is an actual response to a previous data message (which must by definition have had a DATA-TYPE of either 3270-DATA or SCS-DATA and a RESPONSE-FLAG value of either ERROR-RESPONSE or ALWAYS-RESPONSE). In this case the possible values of RESPONSE-FLAG are:
DATA-TYPEフィールド値がRESPONSEの場合、RESPONSE-FLAGは前のデータメッセージに対する実際の応答です（定義上、DATA-TYPEが3270-DATAまたはSCS-DATAであり、RESPONSE-FLAG値がERROR-RESPONSEまたはALWAYS-RESPONSE）。この場合、RESPONSE-FLAGの可能な値は次のとおりです。
Response-Flag Name Code Meaning
------------------ ---- ---------------------------------
POSITIVE-RESPONSE 0x00 The previous message was received
and executed successfully with
no errors.
NEGATIVE-RESPONSE 0x01 The previous message was received but an error(s) occurred while processing it.
NEGATIVE-RESPONSE 0x01前のメッセージを受信しましたが、その処理中にエラーが発生しました。
Accompanying status information will be found in the data portion of the message.
付随するステータス情報は、メッセージのデータ部分にあります。
For any other values of the DATA-TYPE field, the RESPONSE-FLAG field must be ignored by the receiver and should be set to 0x00 by the sender.
DATA-TYPEフィールドの他の値については、RESPONSE-FLAGフィールドは受信側で無視する必要があり、送信側で0x00に設定する必要があります。
The SEQ-NUMBER field is only used when the RESPONSES function has been agreed to. It contains a 2 byte binary number, and is used to correlate positive and negative responses to the data messages for which they were intended. This field must be sent in network byte order ("big endian"). If either byte contains a 0xff, it should be doubled to 0xffff before sending and stripped back to 0xff upon receipt; this is standard IAC escaping. See the section entitled "The RESPONSES Function" for further information on the use of the SEQ-NUMBER field. When the RESPONSES function is not agreed to, this field should always be set to 0x0000 by the sender and ignored by the receiver.
SEQ-NUMBERフィールドは、RESPONSES機能に同意した場合にのみ使用されます。 2バイトの2進数が含まれており、それらが意図されたデータメッセージに対する肯定応答と否定応答を関連付けるために使用されます。このフィールドは、ネットワークバイトオーダー（「ビッグエンディアン」）で送信する必要があります。いずれかのバイトに0xffが含まれている場合は、送信前に2倍にして0xffffにし、受信時に0xffに戻す必要があります。これは標準のIACエスケープです。 SEQ-NUMBERフィールドの使用の詳細については、「RESPONSES関数」というタイトルのセクションを参照してください。 RESPONSES機能が合意されていない場合、このフィールドは送信者によって常に0x0000に設定され、受信者によって無視される必要があります。
As has been stated earlier, whether or not the use of each of the TN3270E functions is allowed on a session is negotiated when the connection is established. It is possible that none of the functions are agreed to (in this case, the function-list in the FUNCTIONS REQUEST and FUNCTIONS IS commands is null). This mode of operation is referred to as "basic TN3270E". Note that, since neither the SCS-CTL-CODES function nor the DATA-STREAM-CTL function is agreed to, basic TN3270E refers to terminal sessions only.
前述のように、セッションで各TN3270E機能の使用が許可されているかどうかは、接続が確立されたときにネゴシエートされます。どの関数も合意されていない可能性があります（この場合、FUNCTIONS REQUESTコマンドおよびFUNCTIONS ISコマンドの関数リストはnullです）。この動作モードは「基本TN3270E」と呼ばれます。 SCS-CTL-CODES機能もDATA-STREAM-CTL機能も合意されていないため、基本的なTN3270Eは端末セッションのみを参照することに注意してください。
Basic TN3270E requires the support of only the following TN3270E header values:
基本的なTN3270Eでは、次のTN3270Eヘッダー値のみのサポートが必要です。
Header field Value
------------ -----
DATA-TYPE 3270-DATA
DATA-TYPE NVT-DATA
The REQUEST-FLAG, RESPONSE-FLAG and SEQ-NUMBER fields are not used in basic TN3270E.
REQUEST-FLAG、RESPONSE-FLAG、およびSEQ-NUMBERフィールドは、基本的なTN3270Eでは使用されません。
At any given time, a TN3270E connection can be considered to be operating in either "3270 mode" or "NVT mode". In 3270 mode, each party may send data messages with the DATA-TYPE flag set to 3270- DATA; sending a DATA-TYPE flag set to NVT-DATA constitutes a request to switch modes. In NVT mode, each party may send data messages with the DATA-TYPE flag set to NVT-DATA; sending 3270-DATA is a request to switch modes. The connection is initially in 3270 mode when TN3270E operation is successfully negotiated. When a party receives a message with a DATA-TYPE different from the mode it is operating in, the mode of operation for the connection is switched. Switching modes results in the client performing the equivalent of a 3270 Erase/Reset operation, as described in [5], using the default partition (screen) size. The server cannot assume the client preserves any attributes of the previous environment across a mode switch.
常に、TN3270E接続は「3270モード」または「NVTモード」で動作していると見なすことができます。 3270モードでは、各パーティがDATA-TYPEフラグを3270- DATAに設定してデータメッセージを送信できます。 DATA-TYPEフラグセットをNVT-DATAに送信すると、モードを切り替える要求が構成されます。 NVTモードでは、各パーティはDATA-TYPEフラグをNVT-DATAに設定してデータメッセージを送信できます。 3270-DATAの送信は、モードを切り替える要求です。 TN3270E操作が正常にネゴシエートされたとき、接続は最初は3270モードです。パーティが、動作しているモードとは異なるデータタイプのメッセージを受信すると、接続の動作モードが切り替わります。モードを切り替えると、クライアントは、デフォルトのパーティション（画面）サイズを使用して、[5]で説明されている3270の消去/リセット操作と同等の操作を実行します。サーバーは、クライアントがモードスイッチ全体で以前の環境の属性を保持することを想定できません。
Note that even when sending NVT-DATA, each side should buffer data until an entire message is built (for the client, this would normally mean until the user presses Enter). At that point, a complete TN3270E data message should be built to transmit the NVT data.
NVT-DATAを送信する場合でも、メッセージ全体が構築されるまで両側でデータをバッファリングする必要があることに注意してください（クライアントの場合、これは通常、ユーザーがEnterキーを押すまで意味します）。その時点で、NVTデータを送信するために完全なTN3270Eデータメッセージを作成する必要があります。
Typically, NVT data is used by a server to interact with the user of a client. It allows the server to do this using a simple NVT data stream, instead of requiring a 3270 data stream. An example would be a server which displays a list of 3270 applications to which it can connect the client. The server would use NVT data to display the list and read the user's choice. Then the server would connect to the application, and begin the exchange of 3270 data between the application and the client.
通常、NVTデータはサーバーによって使用され、クライアントのユーザーと対話します。これにより、サーバーは、3270データストリームを要求する代わりに、単純なNVTデータストリームを使用してこれを行うことができます。例としては、クライアントに接続できる3270アプリケーションのリストを表示するサーバーがあります。サーバーはNVTデータを使用してリストを表示し、ユーザーの選択を読み取ります。次に、サーバーはアプリケーションに接続し、アプリケーションとクライアント間の3270データの交換を開始します。
Agreement by both parties to a specific function in the FUNCTIONS REQUEST function-list implies agreement by each party to support a related set of values in the TN3270E header. It also implies a willingness to adhere to the rules governing the processing of data messages with regard to the agreed upon function. Either party that fails to accept header values associated either with agreed upon functions or with basic TN3270E, or attempts to use header values associated with a function that is not a part of basic TN3270E and was not agreed upon, will be considered non-conforming and in violation of the protocol. The following sections detail for each TN3270E function the associated header values and processing rules.
FUNCTIONS REQUEST function-listの特定の関数に対する両当事者の合意は、TN3270Eヘッダーの関連する値のセットをサポートするための各当事者による合意を意味します。また、合意された機能に関して、データメッセージの処理を管理するルールを遵守する意思があることも意味します。合意された機能または基本的なTN3270Eのいずれかに関連付けられたヘッダー値を受け入れることに失敗した当事者、または基本的なTN3270Eの一部ではないが合意されなかった機能に関連付けられたヘッダー値を使用しようとした当事者は、不適合と見なされ、プロトコルに違反しています。以下のセクションでは、各TN3270E関数の関連するヘッダー値と処理規則について詳しく説明します。
This function can only be supported on a 3270 printer session.
この機能は、3270プリンターセッションでのみサポートされます。
Agreement to support this function requires that the party support the following TN3270E header values:
この機能をサポートするための合意には、当事者が以下のTN3270Eヘッダー値をサポートすることが必要です。
Header field Value
------------ -----
DATA-TYPE SCS-DATA
DATA-TYPE PRINT-EOJ
A client representing a printer device uses this function to indicate its willingness to accept a data stream that includes SCS control codes. For the purposes of NVT mode versus 3270 mode, SCS-DATA must be treated exactly like 3270-DATA (i.e., it can cause a switch from NVT mode to 3270 mode).
プリンタデバイスを表すクライアントは、この関数を使用して、SCS制御コードを含むデータストリームを受け入れる意思を示します。 NVTモードと3270モードの目的では、SCS-DATAを3270-DATAとまったく同じように扱う必要があります（つまり、NVTモードから3270モードに切り替わる可能性があります）。
When a printer device-type has been negotiated, either the SCS-CTL-CODES function or the DATA-STREAM-CTL function, or both, must be negotiated. This enables the server to know when it should and should not accept a session with a host application on behalf of the client. If only the SCS-CTL-CODES function is agreed to, then the server will not establish sessions with host applications that would send 3270 data stream control. If both SCS-CTL-CODES and DATA-STREAM-CTL are agreed to, then the server will establish sessions both with host applications that would send SCS control codes and with those that would send 3270 orders.
プリンターのデバイスタイプがネゴシエートされた場合、SCS-CTL-CODES関数またはDATA-STREAM-CTL関数、あるいはその両方がネゴシエートされる必要があります。これにより、サーバーは、クライアントに代わってホストアプリケーションとのセッションを受け入れる必要があるかどうかを知ることができます。 SCS-CTL-CODES機能のみが合意されている場合、サーバーは、3270データストリーム制御を送信するホストアプリケーションとのセッションを確立しません。 SCS-CTL-CODESとDATA-STREAM-CTLの両方に同意した場合、サーバーは、SCS制御コードを送信するホストアプリケーションと3270注文を送信するホストアプリケーションの両方とのセッションを確立します。
The server should send a TN3270E message with DATA-TYPE set to PRINT-EOJ at the end of each print job to indicate to the client that it may now take whatever action is appropriate for its environment (e.g., close a disk or spool file, etc.). The server may have multiple criteria for determining when it should send a PRINT-EOJ, such as receipt of SNA End Bracket from the host application, or expiration of a pre-defined timeout value.
サーバーは、各印刷ジョブの最後にDATA-TYPEをPRINT-EOJに設定したTN3270Eメッセージを送信して、クライアントが環境に適したアクション（ディスクやスプールファイルを閉じるなど）を実行できることをクライアントに示す必要があります。等。）。サーバーは、ホストアプリケーションからのSNAエンドブラケットの受信や、事前定義されたタイムアウト値の期限切れなど、PRINT-EOJを送信するタイミングを決定するための複数の基準を持つ場合があります。
This function can only be supported on a 3270 printer session.
この機能は、3270プリンターセッションでのみサポートされます。
Agreement to support this function requires that the party support the following TN3270E header values:
この機能をサポートするための合意には、当事者が以下のTN3270Eヘッダー値をサポートすることが必要です。
Header field Value
------------ -----
DATA-TYPE 3270-DATA
DATA-TYPE PRINT-EOJ
A client representing a printer device uses this function to indicate its willingness to accept a data stream that includes 3270 orders and attributes.
プリンターを表すクライアントは、この関数を使用して、3270の注文と属性を含むデータストリームを受け入れる意思を示します。
When a printer device-type has been negotiated, either the SCS-CTL-CODES function or the DATA-STREAM-CTL function, or both, must be negotiated. This enables the server to know when it should and should not accept a session with a host application on behalf of the client. If only the DATA-STREAM-CTL function is agreed to, then the server will not establish sessions with host applications that would send SCS control codes in a data stream. If both SCS-CTL-CODES and DATA-STREAM-CTL are agreed to, then the server will establish sessions both with host applications that would send SCS control codes and with those that would send 3270 orders.
プリンターのデバイスタイプがネゴシエートされた場合、SCS-CTL-CODES関数またはDATA-STREAM-CTL関数、あるいはその両方がネゴシエートされる必要があります。これにより、サーバーは、クライアントに代わってホストアプリケーションとのセッションを受け入れる必要があるかどうかを知ることができます。 DATA-STREAM-CTL機能のみが合意されている場合、サーバーは、データストリームでSCS制御コードを送信するホストアプリケーションとのセッションを確立しません。 SCS-CTL-CODESとDATA-STREAM-CTLの両方に同意した場合、サーバーは、SCS制御コードを送信するホストアプリケーションと3270注文を送信するホストアプリケーションの両方とのセッションを確立します。
The server should send a TN3270E message with DATA-TYPE set to PRINT-EOJ at the end of each print job to indicate to the client that it may now take whatever action is appropriate for its environment (e.g., close a disk or spool file, etc.). The server may have multiple criteria for determining when it should send a PRINT-EOJ, such as receipt of SNA End Bracket from the host application, or expiration of a pre-defined timeout value.
サーバーは、各印刷ジョブの最後にDATA-TYPEをPRINT-EOJに設定したTN3270Eメッセージを送信して、クライアントが環境に適したアクション（ディスクやスプールファイルを閉じるなど）を実行できることをクライアントに示す必要があります。等。）。サーバーは、ホストアプリケーションからのSNAエンドブラケットの受信や、事前定義されたタイムアウト値の期限切れなど、PRINT-EOJを送信するタイミングを決定するための複数の基準を持つ場合があります。
This function can only be supported when the TN3270E server represents SNA terminals and printers.
この機能は、TN3270EサーバーがSNA端末およびプリンターを表す場合にのみサポートできます。
Agreement to support this function requires that the party support the following TN3270E header values:
この機能をサポートするための合意には、当事者が以下のTN3270Eヘッダー値をサポートすることが必要です。
Header field Value
------------ -----
DATA-TYPE BIND-IMAGE
DATA-TYPE UNBIND
DATA-TYPE SSCP-LU-DATA
When BIND-IMAGE is in effect, the server must inform the client when an SNA session has been established with a host application, and when such a session has been terminated. It uses DATA-TYPE values of BIND-IMAGE and UNBIND to convey this information.
BIND-IMAGEが有効な場合、サーバーは、ホストアプリケーションとのSNAセッションが確立されたとき、およびそのようなセッションが終了したときにクライアントに通知する必要があります。 BIND-IMAGEおよびUNBINDのDATA-TYPE値を使用して、この情報を伝えます。
When establishing an SNA session on behalf of a client, the server will receive a Bind RU from the host application. It will also receive a Start Data Traffic RU. Once both of these have been responded to positively by the server, it must then inform the client of the presence of this session by sending it a data message with the DATA-TYPE flag set to BIND-IMAGE. The data portion of this message must contain the bind image exactly as it was received in the Bind RU that the server accepted on behalf of the client. The format and maximum length of this bind image are defined in [6].
クライアントに代わってSNAセッションを確立すると、サーバーはホストアプリケーションからBind RUを受け取ります。また、Start Data Traffic RUも受け取ります。これらの両方がサーバーによって肯定的に応答されると、DATA-TYPEフラグがBIND-IMAGEに設定されたデータメッセージを送信することにより、このセッションの存在をクライアントに通知する必要があります。このメッセージのデータ部分には、サーバーがクライアントの代わりに受け入れたBind RUで受信したとおりのバインドイメージが含まれている必要があります。このバインドイメージの形式と最大長は、[6]で定義されています。
When an SNA session between the server and a host application is terminated, the server must send a data message to the client with the DATA-TYPE flag set to UNBIND. If the server was notified of the session termination via an SNA Unbind RU, it should include the Unbind reason code in the data portion of the message it sends to the client. If the server itself requested the SNA session termination (for example, as part of SYSREQ key processing), it should set the data portion of the UNBIND message to 0x01, indicating "normal end of session".
サーバーとホストアプリケーション間のSNAセッションが終了すると、サーバーはDATA-TYPEフラグをUNBINDに設定してクライアントにデータメッセージを送信する必要があります。サーバーがSNA Unbind RUを介してセッションの終了を通知された場合、クライアントに送信するメッセージのデータ部分にUnbind理由コードを含める必要があります。サーバー自体が（たとえば、SYSREQキー処理の一部として）SNAセッションの終了を要求した場合、サーバーはUNBINDメッセージのデータ部分を0x01に設定して、「通常のセッションの終了」を示す必要があります。
Another aspect of the BIND-IMAGE function alters the allowable DATA-TYPE flag values slightly from the behavior described in the section entitled "Basic TN3270E". When BIND-IMAGE is in effect, data messages with DATA-TYPE set to 3270-DATA or SCS-DATA are not allowed before the first BIND-IMAGE is received by the client; only SSCP-LU-DATA or NVT-DATA can be used to transmit user- oriented data. The same applies to data messages exchanged after an UNBIND is sent and before another BIND-IMAGE is received by the client. Once the client receives a BIND-IMAGE data message, the allowable DATA-TYPE values, in addition to SSCP-LU-DATA, now include 3270-DATA and/or SCS-DATA, depending on whether a terminal or printer device-type was negotiated, and whether a printer client agreed to DATA-STREAM-CTL or SCS-CTL-CODES, or both. (See the section entitled "The SYSREQ Function" for further discussion of the SSCP-LU session in an SNA environment.)
BIND-IMAGE関数の別の側面は、「基本的なTN3270E」というタイトルのセクションで説明されている動作から、許容されるDATA-TYPEフラグ値をわずかに変更します。 BIND-IMAGEが有効な場合、DATA-TYPEが3270-DATAまたはSCS-DATAに設定されたデータメッセージは、クライアントが最初のBIND-IMAGEを受信するまで許可されません。ユーザー指向のデータを送信するために使用できるのは、SSCP-LU-DATAまたはNVT-DATAのみです。 UNBINDの送信後、クライアントが別のBIND-IMAGEを受信する前に交換されるデータメッセージにも同じことが当てはまります。クライアントがBIND-IMAGEデータメッセージを受信すると、SSCP-LU-DATAに加えて、許容されるDATA-TYPE値に、端末またはプリンターのデバイスタイプがどちらであったかに応じて、3270-DATAおよび/またはSCS-DATAが含まれるようになります。ネゴシエートされ、プリンタクライアントがDATA-STREAM-CTLまたはSCS-CTL-CODES、あるいはその両方に同意したかどうか。 （SNA環境でのSSCP-LUセッションの詳細については、「SYSREQ関数」というタイトルのセクションを参照してください。）
This function can be supported for both terminal and printer sessions connected to both SNA and non-SNA servers.
この機能は、SNAサーバーと非SNAサーバーの両方に接続されている端末セッションとプリンターセッションの両方でサポートできます。
Agreement to support this function requires that the party support the following TN3270E header values:
この機能をサポートするための合意には、当事者が以下のTN3270Eヘッダー値をサポートすることが必要です。
Header field Value
------------ -----
DATA-TYPE RESPONSE
DATA-TYPE REQUEST
RESPONSE-FLAG -all values-
REQUEST-FLAG ERR-COND-CLEARED
SEQ-NUMBER binary values from 0-32767
Whenever a data message is sent with a DATA-TYPE of either SCS-DATA or 3270-DATA, the sender must set the RESPONSE-FLAG field to either NO-RESPONSE, ERROR-RESPONSE, or ALWAYS-RESPONSE. It is anticipated that the client side will normally set RESPONSE-FLAG to NO-RESPONSE. The server, if it represents an SNA device, should set RESPONSE-FLAG to reflect the response value set in the RH of the RU that generated this data message - Definite Response resulting in a RESPONSE-FLAG value of ALWAYS-RESPONSE, Exception Response resulting in ERROR-RESPONSE being set, and No Response causing a setting of NO-RESPONSE. A non-SNA server should set RESPONSE-FLAG to ERROR-RESPONSE.
データメッセージがSCS-DATAまたは3270-DATAのDATA-TYPEで送信される場合は常に、送信者はRESPONSE-FLAGフィールドをNO-RESPONSE、ERROR-RESPONSE、またはALWAYS-RESPONSEのいずれかに設定する必要があります。クライアント側は通常、RESPONSE-FLAGをNO-RESPONSEに設定することが予想されます。サーバーがSNAデバイスを表す場合、サーバーはRESPONSE-FLAGを設定して、このデータメッセージを生成したRUのRHに設定された応答値を反映する必要があります-明確な応答によりALWAYS-RESPONSEのRESPONSE-FLAG値が生成され、例外応答が生成されますERROR-RESPONSEが設定され、No Responseが設定される原因となるNo Response。非SNAサーバーは、RESPONSE-FLAGをERROR-RESPONSEに設定する必要があります。
In addition, the sender must keep a count of the messages with a DATA-TYPE of 3270-DATA or SCS-DATA that it sends on a given TN3270E session. This counter should start at zero for the first such message, and be incremented by one for each subsequent message. Note that this counter is independent of any SNA sequence numbers, and should not be reset to zero as a result of Bind or Unbind. If the counter reaches the maximum of 32767, it should be restarted at zero. The sender must place this value in the SEQ-NUMBER field of the TN3270E header before it sends the message. Note that the SEQ-NUMBER field must be set regardless of the value of the RESPONSE-FLAG field.
さらに、送信者は、特定のTN3270Eセッションで送信するDATA-TYPEが3270-DATAまたはSCS-DATAのメッセージの数を保持する必要があります。このカウンターは、そのような最初のメッセージに対してゼロから始まり、後続のメッセージごとに1ずつ増加します。このカウンターはSNAシーケンス番号とは無関係であり、BindまたはUnbindの結果としてゼロにリセットしないでください。カウンターが最大値の32767に達した場合は、ゼロから再始動する必要があります。送信者は、メッセージを送信する前に、この値をTN3270EヘッダーのSEQ-NUMBERフィールドに配置する必要があります。 SEQ-NUMBERフィールドは、RESPONSE-FLAGフィールドの値に関係なく設定する必要があることに注意してください。
Whenever a data message with a DATA-TYPE of either SCS-DATA or 3270- DATA is received, the receiver must attempt to process the data in the data portion of the message, then determine whether or not it should send a data message with a DATA-TYPE of RESPONSE. If the data message it has just processed had a RESPONSE-FLAG value of NO-RESPONSE, or if it had a value of ERROR-RESPONSE and there were no errors encountered while processing the data, then no RESPONSE type message should be sent. Otherwise, a data message should be sent in which the header DATA-TYPE field is set to RESPONSE, and in which the SEQ-NUMBER field is a copy of the SEQ-NUMBER field from the message to which this response corresponds. The RESPONSE-FLAG field in this header must have a value of either POSITIVE-RESPONSE or NEGATIVE-RESPONSE. A POSITIVE-RESPONSE should be sent if the previously processed message's header specified ALWAYS-RESPONSE and no errors were encountered in processing the data. A NEGATIVE-RESPONSE should be sent when
DATA-TYPEがSCS-DATAまたは3270- DATAのデータメッセージを受信した場合は常に、受信側はメッセージのデータ部分のデータを処理し、データメッセージを送信するかどうかを決定する必要があります。応答のデータタイプ。処理したばかりのデータメッセージのRESPONSE-FLAG値がNO-RESPONSEである場合、またはERROR-RESPONSEの値があり、データの処理中にエラーが発生しなかった場合、RESPONSEタイプのメッセージは送信されません。それ以外の場合は、ヘッダーDATA-TYPEフィールドがRESPONSEに設定され、SEQ-NUMBERフィールドがこの応答が対応するメッセージからのSEQ-NUMBERフィールドのコピーであるデータメッセージを送信する必要があります。このヘッダーのRESPONSE-FLAGフィールドには、POSITIVE-RESPONSEまたはNEGATIVE-RESPONSEのいずれかの値が必要です。以前に処理されたメッセージのヘッダーがALWAYS-RESPONSEを指定し、データの処理中にエラーが発生しなかった場合は、POSITIVE-RESPONSEを送信する必要があります。 NEGATIVE-RESPONSEは、
1) the previously processed message specified ERROR-RESPONSE or ALWAYS-RESPONSE and
1）以前に処理されたメッセージはERROR-RESPONSEまたはALWAYS-RESPONSEを指定し、
2) some kind of error occurred while processing the data.
2）データの処理中に何らかのエラーが発生しました。
Normally only the client will be constructing and sending these RESPONSE messages. A negative response sent by the client to the server is the equivalent of a Unit Check Status [7]. All references to device status and sense codes in this section rely on [7].
通常、クライアントだけがこれらのRESPONSEメッセージを作成して送信します。クライアントからサーバーに送信される否定応答は、ユニットチェックステータス[7]に相当します。このセクションのデバイスステータスとセンスコードへのすべての参照は、[7]に依存しています。
The data portion of a RESPONSE message must consist of one byte of binary data. The value of this byte gives a more detailed account of the results of having processed the previously received data message. The possible values for this byte are:
RESPONSEメッセージのデータ部分は、1バイトのバイナリデータで構成されている必要があります。このバイトの値は、以前に受信したデータメッセージを処理した結果のより詳細な説明を提供します。このバイトの可能な値は次のとおりです。
For a RESPONSE-FLAG value of POSITIVE-RESPONSE -
RESPONSE-FLAG値がPOSITIVE-RESPONSEの場合-
Value Meaning
----- -------
0x00 Successful completion (when sent by the client,
this is equivalent to "Device End").
For a RESPONSE-FLAG value of NEGATIVE-RESPONSE -
NEGATIVE-RESPONSEのRESPONSE-FLAG値の場合-
Value Meaning
----- -------
0x00 An invalid 3270 command was received
(equivalent to "Command Reject").
0x01 Printer is not ready (equivalent to "Intervention Required").
0x01プリンターの準備ができていません（「要介入」に相当）。
0x02 An illegal 3270 buffer address or order sequence was received (equivalent to "Operation Check").
0x02不正な3270バッファアドレスまたは順序シーケンスが受信されました（「動作チェック」に相当）。
0x03 Printer is powered off or not connected (equivalent to "Component Disconnected").
0x03プリンターの電源がオフになっているか、接続されていません（「コンポーネントが切断されました」と同等）。
When the server receives any of the above responses, it should pass along the appropriate information to the host application. The appropriate information is determined by whether the server represents an SNA or a non-SNA device.
サーバーが上記の応答のいずれかを受信すると、適切な情報をホストアプリケーションに渡します。適切な情報は、サーバーがSNAまたは非SNAデバイスのどちらを表すかによって決まります。
An SNA server should pass along a POSITIVE-RESPONSE from the client as an SNA positive Response Unit to the host application. It should translate a NEGATIVE-RESPONSE from the client into an SNA negative Response Unit in which the Sense Data Indicator bit is on and which contains one of the following sense codes:
SNAサーバーは、クライアントからのPOSITIVE-RESPONSEをSNA肯定応答ユニットとしてホストアプリケーションに渡す必要があります。クライアントからのNEGATIVE-RESPONSEを、センスデータインジケータービットがオンで、次のいずれかのセンスコードを含むSNAネガティブレスポンスユニットに変換する必要があります。
RESPONSE-FLAG Equivalent SNA Sense Code
------------- ---------- --------------
0x00 Command Reject 0x10030000
0x01 Intervention Required 0x08020000
0x01介入が必要0x08020000
0x02 Operation Check 0x10050000
0x02動作チェック0x10050000
0x03 Component Disconnected 0x08310000
0x03コンポーネントが切断されました0x08310000
A non-SNA server should pass along a POSITIVE-RESPONSE from the client by setting the Device End Status bit on. It should reflect a NEGATIVE-RESPONSE from the client by setting the Unit Check Status Bit on, and setting either the Command Reject, Intervention Required, or Operation Check Sense bit on when responding to the Sense command.
非SNAサーバーは、デバイス終了ステータスビットをオンに設定することにより、クライアントからPOSITIVE-RESPONSEを渡す必要があります。ユニットチェックステータスビットをオンに設定し、センスコマンドに応答するときにコマンド拒否、介入が必要、または動作チェックセンスビットをオンに設定することにより、クライアントからのNEGATIVE-RESPONSEを反映する必要があります。
In the case of Intervention Required or Component Disconnected being passed by the server to the host application, the host would normally refrain from sending any further data to the printer. If and when the error condition at the client has been resolved, the client must send to the server a data message whose header DATA-TYPE field is set to REQUEST, and whose REQUEST-FLAG is set to ERR-COND-CLEARED. Note that this message has no data portion. Upon receipt of this message, the server should pass along the appropriate information to the host application so that it may resume sending printer output. Again, the form of this information depends on whether the server represents an SNA or a non-SNA device.
サーバーがホストアプリケーションに渡したIntervention RequiredまたはComponent Disconnectedの場合、ホストは通常、それ以上のデータをプリンターに送信しません。クライアントでのエラー条件が解決された場合、クライアントは、ヘッダーDATA-TYPEフィールドがREQUESTに設定され、REQUEST-FLAGがERR-COND-CLEAREDに設定されたデータメッセージをサーバーに送信する必要があります。このメッセージにはデータ部分がないことに注意してください。このメッセージを受信すると、サーバーは適切な情報をホストアプリケーションに渡して、プリンター出力の送信を再開できるようにする必要があります。繰り返しますが、この情報の形式は、サーバーがSNAまたは非SNAデバイスを表すかどうかによって異なります。
An SNA server should reflect an ERR-COND-CLEARED to the host application by sending an SNA LUSTAT RU with one of the following sense codes:
SNAサーバーは、次のいずれかのセンスコードでSNA LUSTAT RUを送信することにより、ERR-COND-CLEAREDをホストアプリケーションに反映する必要があります。
- if the previous error condition was an Intervention Required, the server should send sense code 0x00010000
- 以前のエラー条件が介入が必要な場合、サーバーはセンスコード0x00010000を送信する必要があります
- if the previous error condition was Component Disconnected, the server should send sense code 0x082B0000
- 以前のエラー条件がコンポーネントの切断であった場合、サーバーはセンスコード0x082B0000を送信する必要があります
A non-SNA server should set the corresponding bits in the Ending Status and Sense Condition bytes.
非SNAサーバーは、対応するビットを終了ステータスバイトとセンス条件バイトに設定する必要があります。
This function can only be supported when the TN3270E server represents SNA devices.
この機能は、TN3270EサーバーがSNAデバイスを表す場合にのみサポートできます。
Agreement to support this function requires that the party support the following TN3270E header values:
この機能をサポートするための合意には、当事者が以下のTN3270Eヘッダー値をサポートすることが必要です。
Header field Value
------------ -----
DATA-TYPE SSCP-LU-DATA
The 3270 SYSREQ key can be useful in an SNA environment when the ATTN key is not sufficient to terminate a process. (See the section entitled "The 3270 ATTN Key" for more information.)
3270 SYSREQキーは、ATTNキーがプロセスを終了するのに十分でない場合に、SNA環境で役立ちます。 （詳細については、「3270 ATTNキー」というタイトルのセクションを参照してください。）
In SNA, there is a session between the host application (the PLU, or Primary Logical Unit) and the TN3270E server representing the client (the SLU, or Secondary Logical Unit). This is referred to as the PLU-SLU session, and it is the one on which normal communications flow. There is also a session between the host telecommunications access method (the SSCP, or System Services Control Point) and the SLU, and it is referred to as the SSCP-LU session. This session is used to carry various control information and is normally transparent to the user; normal 3270 data stream orders are not allowed in this data. For more information, refer to [7].
SNAでは、ホストアプリケーション（PLU、またはプライマリ論理ユニット）とクライアントを表すTN3270Eサーバー（SLU、またはセカンダリ論理ユニット）の間にセッションがあります。これはPLU-SLUセッションと呼ばれ、通常の通信が流れるセッションです。ホスト通信アクセス方式（SSCP、またはシステムサービスコントロールポイント）とSLUの間にもセッションがあり、SSCP-LUセッションと呼ばれます。このセッションは、さまざまな制御情報を伝達するために使用され、通常はユーザーに対して透過的です。このデータでは、通常の3270データストリームの順序は許可されていません。詳細については、[7]を参照してください。
The terminal display and keyboard are usually "owned" by the PLU-SLU session, meaning any data the user types is sent to the host application. The SYSREQ key is used to toggle ownership of the keyboard and display between the PLU-SLU session and the SSCP-LU session. In other words, the user is able to press SYSREQ and then communicate directly with the host SSCP. The user may then enter any valid Unformatted Systems Services commands, which are defined in the USS table associated with the SLU. The most common USS command users employ is "LOGOFF," which requests that the SSCP immediately terminate the PLU-SLU session. The usual reason for requesting such an action is that the host application (the PLU) has stopped responding altogether.
端末のディスプレイとキーボードは通常、PLU-SLUセッションによって「所有」されます。つまり、ユーザーが入力したデータはすべてホストアプリケーションに送信されます。 SYSREQキーは、キーボードの所有権とPLU-SLUセッションとSSCP-LUセッションの間の表示を切り替えるために使用されます。つまり、ユーザーはSYSREQを押してから、ホストSSCPと直接通信できます。次に、ユーザーは、SLUに関連付けられたUSSテーブルで定義されている有効な未フォーマットシステムサービスコマンドを入力できます。ユーザーが使用する最も一般的なUSSコマンドは「LOGOFF」で、SSCPがPLU-SLUセッションを直ちに終了することを要求します。このようなアクションを要求する通常の理由は、ホストアプリケーション（PLU）が完全に応答を停止したことです。
Whenever the keyboard and display are owned by the SSCP-LU session, no data is allowed to flow in either direction on the PLU-SLU session. Once "in" the SSCP-LU session, the user may decide to switch back to the PLU-SLU session by again pressing the SYSREQ key.
キーボードとディスプレイがSSCP-LUセッションによって所有されている場合は常に、PLU-SLUセッションでどちらの方向にもデータを流すことはできません。 SSCP-LUセッションに「入る」と、ユーザーは再度SYSREQキーを押すことにより、PLU-SLUセッションに戻ることを決定できます。
The design of some TN3270E servers allows them to fully support the SYSREQ key because they are allowed to send USS commands on the SSCP-LU session. Other TN3270E servers operate in an environment which does not allow them to send USS commands to the SSCP; this makes full support of the SYSREQ key impossible. For such servers, TN3270E provides for emulation of a minimal subset of functions, namely, for the sequence of pressing SYSREQ and typing LOGOFF that many users employ to immediately terminate the PLU-SLU session.
一部のTN3270Eサーバーの設計では、SSCP-LUセッションでUSSコマンドを送信できるため、SYSREQキーを完全にサポートできます。他のTN3270Eサーバーは、USSコマンドをSSCPに送信できない環境で動作します。これにより、SYSREQキーの完全なサポートが不可能になります。このようなサーバーの場合、TN3270Eは、機能の最小限のサブセットのエミュレーションを提供します。つまり、SYSREQを押してLOGOFFを入力するシーケンスで、多くのユーザーがPLU-SLUセッションを即座に終了します。
The Telnet Abort Output (AO) command is the mechanism used to implement SYSREQ key support in TN3270E because, in a real SNA session, once the user presses the SYSREQ key, the host application is prevented from sending any more output to the terminal (unless the user presses SYSREQ a second time), but the user's process continues to execute.
Telnet Abort Output（AO）コマンドは、TN3270EにSYSREQキーのサポートを実装するために使用されるメカニズムです。これは、実際のSNAセッションでは、ユーザーがSYSREQキーを押すと、ホストアプリケーションはそれ以上の出力を端末に送信できないためです（ユーザーはもう一度SYSREQを押しますが、ユーザーのプロセスは引き続き実行されます。
In order to implement SYSREQ key support, TN3270E clients that have agreed to the SYSREQ function should 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 should transmit a Telnet AO command to the server.
SYSREQキーのサポートを実装するには、SYSREQ機能に同意したTN3270Eクライアントが、3270 SYSREQキーへのマッピングとして識別されるキー（またはキーの組み合わせ）を提供する必要があります。ユーザーがこのキーを押すと、クライアントはサーバーにTelnet AOコマンドを送信する必要があります。
Upon receipt of the AO command, a TN3270E server that has agreed to the SYSREQ function should enter what will be loosely termed "suspended mode" for the connection. If a server that has not agreed to the SYSREQ function receives an AO command, it should simply ignore it. Any attempt by the host application to send data to the client while the connection is "suspended" should be responded to by the server with a negative response, sense code 0x082D, indicating an "LU Busy" condition. The server should not transmit anything to the client on behalf of the host application. While the connection is "suspended," any data messages exchanged between the client and server should have the DATA-TYPE flag set to SSCP-LU-DATA; the data stream will be as defined in [7], specifically the section entitled
AOコマンドを受信すると、SYSREQ機能に同意したTN3270Eサーバーは、接続の「サスペンドモード」と大まかに呼ばれるものに入る必要があります。 SYSREQ機能に同意していないサーバーがAOコマンドを受け取った場合は、単にそれを無視する必要があります。接続が「中断」されている間にホストアプリケーションがクライアントにデータを送信しようとすると、サーバーは否定応答、センスコード0x082Dで応答し、「LUビジー」状態を示します。サーバーは、ホストアプリケーションに代わってクライアントに何も送信しないでください。接続が「一時停止」されている間、クライアントとサーバー間で交換されるデータメッセージでは、DATA-TYPEフラグをSSCP-LU-DATAに設定する必要があります。データストリームは、[7]で定義されているとおり、具体的には、
"Operation in SSCP-SLU Session."
「SSCP-SLUセッションでの操作。」
At this point, the behavior of the server depends upon whether or not it is allowed to send USS commands on the SSCP-LU session. Servers that have this ability should simply act as a vehicle for passing USS commands and responses between the client and the SSCP.
この時点で、サーバーの動作は、SSCP-LUセッションでUSSコマンドを送信できるかどうかによって異なります。この機能を持つサーバーは、クライアントとSSCPの間でUSSコマンドと応答を渡すための手段として機能する必要があります。
Servers that are not allowed to send USS commands on the SSCP-LU session should behave as follows:
SSCP-LUセッションでUSSコマンドの送信を許可されていないサーバーは、次のように動作する必要があります。
- if the user transmits the string LOGOFF (upper or lower case), the server should send an Unbind SNA RU to the host application. This will result in termination of the PLU-SLU session. If the BIND-IMAGE function was agreed upon, then the server should also send a data message to the client with the DATA-TYPE flag set to UNBIND and the data portion set to 0x01.
- ユーザーがストリングLOGOFF（大文字または小文字）を送信する場合、サーバーはUnbind SNA RUをホストアプリケーションに送信する必要があります。これにより、PLU-SLUセッションが終了します。 BIND-IMAGE関数が合意された場合、サーバーは、DATA-TYPEフラグをUNBINDに設定し、データ部分を0x01に設定して、データメッセージもクライアントに送信する必要があります。
- if the user transmits anything other than LOGOFF, the server should respond with the string "COMMAND UNRECOGNIZED" to the client. The server should not send anything to the host application on behalf of the client.
- ユーザーがLOGOFF以外のものを送信した場合、サーバーは文字列 "COMMAND UNRECOGNIZED"でクライアントに応答する必要があります。サーバーは、クライアントに代わってホストアプリケーションに何も送信しないでください。
Regardless of which kind of server is present (i.e., whether or not it may send USS commands on the SSCP-LU session), while the connection is suspended, the user may press the "SYSREQ" key again. This will result in the transmission of another AO to the server. The server should then send to the host application an LUSTAT RU with a value of 0x082B indicating "presentation space integrity lost". The server will then "un-suspend" the Telnet connection to the client, meaning it will allow the host application to once again send data to the client.
存在するサーバーの種類に関係なく（つまり、SSCP-LUセッションでUSSコマンドを送信できるかどうかに関係なく）、接続が一時停止している間に、ユーザーはもう一度「SYSREQ」キーを押すことができます。これにより、別のAOがサーバーに送信されます。次に、サーバーは、「プレゼンテーションスペースの整合性が失われた」ことを示す0x082Bの値を持つLUSTAT RUをホストアプリケーションに送信する必要があります。次に、サーバーはクライアントへのTelnet接続の「中断を解除」します。つまり、ホストアプリケーションがもう一度クライアントにデータを送信できるようになります。
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. The Telnet Interrupt Process (IP) command was defined expressly for such a purpose, so it is used to implement support for the 3270 ATTN key. This requires two things:
3270 ATTNキーは、SNA環境の多くのホストアプリケーションによって、ユーザーが現在のプロセスの実行を中断したいことを示すものとして解釈されます。 Telnet割り込み処理（IP）コマンドは、そのような目的のために明示的に定義されたため、3270 ATTNキーのサポートを実装するために使用されます。これには2つのことが必要です。
- TN3270E clients should 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 should transmit a Telnet IP command to the server.
- TN3270Eクライアントは、キーボードマッピングの一部として、3270 ATTNキーにマップする単一のキーまたはキーの組み合わせを提供する必要があります。ユーザーがこのキーを押すと、クライアントはサーバーにTelnet IPコマンドを送信する必要があります。
- TN3270E servers should translate the IP command received from a TN3270E 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 should send a SIGNAL RU to the host application.
-TN3270Eサーバーは、TN3270Eクライアントから受信したIPコマンドを適切な形式に変換し、それをATTNキーとしてホストアプリケーションに渡す必要があります。つまり、SNAセッションでSLUを表すサーバーは、SIGNAL RUをホストアプリケーションに送信する必要があります。
The ATTN key is not supported in a non-SNA environment; therefore, a TN3270E server representing non-SNA 3270 devices should ignore any Telnet IP commands it receives from a client.
ATTNキーは非SNA環境ではサポートされていません。したがって、非SNA 3270デバイスを表すTN3270Eサーバーは、クライアントから受信するTelnet IPコマンドを無視する必要があります。
3270 structured fields provide a much wider range of features than "old-style" 3270 data, such as support for graphics, partitions and IPDS printer data streams. It would be unreasonable to expect all TN3270E clients to support all possible structured field functions, yet there must be a mechanism by which those clients that are capable of supporting some or all structured field functions can indicate their wishes.
3270構造化フィールドは、グラフィック、パーティション、IPDSプリンターデータストリームのサポートなど、「旧式の」3270データよりもはるかに幅広い機能を提供します。すべてのTN3270Eクライアントがすべての可能な構造化フィールド関数をサポートすることを期待するのは不合理ですが、一部またはすべての構造化フィールド関数をサポートできるクライアントが希望を示すことができるメカニズムが必要です。
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 device. The device responds with a Query Reply structured field(s) listing which, if any, structured field functions it supports.
3270構造化フィールドの設計は、さまざまな構造化フィールド機能のサポートのレベル（サポートなしを含む）を伝える便利な手段を提供します。このメカニズムはRead Partition Queryコマンドで、ホストアプリケーションからデバイスに送信されます。デバイスは、サポートする構造化フィールド機能がある場合は、それをリストするQuery Reply構造化フィールドで応答します。
The Query Reply is also used to indicate some device capabilities which do not require the use of structured fields, such as extended color support and extended highlighting capability. Most host applications will use Read Partition Query to precisely determine a device's capabilities when there has been some indication that the device supports the "extended data stream".
クエリ応答は、拡張カラーサポートや拡張強調表示機能など、構造化フィールドの使用を必要としない一部のデバイス機能を示すためにも使用されます。ほとんどのホストアプリケーションは、デバイスが「拡張データストリーム」をサポートしているという何らかの兆候があった場合に、パーティションの読み取りクエリを使用してデバイスの機能を正確に判断します。
Therefore, all TN3270E clients that negotiate a terminal device-type that contains a "-E" suffix, the DYNAMIC terminal type, or a printer device-type, must be able to respond to a Read Partition Query command. Note that these clients must support both the Read Partition Query (Type 02), and all forms of the Read Partition Query List (Type 03).
したがって、「-E」サフィックスを含む端末デバイスタイプ、DYNAMIC端末タイプ、またはプリンターデバイスタイプをネゴシエートするすべてのTN3270Eクライアントは、パーティションクエリの読み取りコマンドに応答できる必要があります。これらのクライアントは、読み取りパーティションクエリ（タイプ02）とすべての形式の読み取りパーティションクエリリスト（タイプ03）の両方をサポートする必要があることに注意してください。
Implementors of TN3270E clients should note that the command codes for the various 3270 Read and Write commands have different values depending on how the server is connected to the host (local versus remote, SNA versus non-SNA). Clients should be coded to check for the various possible values if they wish to be compatible with the widest range of servers. See [7] for further details.
TN3270Eクライアントの実装者は、さまざまな3270読み取りおよび書き込みコマンドのコマンドコードの値が、サーバーとホストの接続方法（ローカルとリモート、SNAと非SNA）に応じて異なることに注意する必要があります。クライアントは、さまざまなサーバーとの互換性を希望する場合、さまざまな値をチェックするようにコーディングする必要があります。詳細については、[7]を参照してください。
Since TN3270E is a Telnet Option governed by [8], both client and server are free to attempt to initiate negotiation of TN3270E by sending a DO TN3270E command. However, just as is usually the case with the Telnet DO TERMINAL-TYPE, it is anticipated that the server will normally be the one sending the DO TN3270E, and the client will be responding with a WILL or a WON'T TN3270E.
TN3270Eは[8]によって管理されるTelnetオプションであるため、クライアントとサーバーの両方がDO TN3270Eコマンドを送信することにより、自由にTN3270Eのネゴシエーションを開始できます。ただし、Telnet DO TERMINAL-TYPEの通常の場合と同様に、サーバーは通常、DO TN3270Eを送信するサーバーであり、クライアントはWILLまたはWO N'T TN3270Eで応答します。
In many environments, it is very helpful to have in place a mechanism that allows timely notification of the loss of a 3270 session. TN3270E does not require that any form of keep-alive mechanism be employed by either clients or servers, but implementors wishing to support such a mechanism should consider the following guidelines.
多くの環境では、3270セッションが失われたことをタイムリーに通知できるメカニズムを用意しておくと非常に役立ちます。 TN3270Eでは、クライアントまたはサーバーでキープアライブメカニズムを使用する必要はありませんが、そのようなメカニズムをサポートする実装者は、次のガイドラインを考慮する必要があります。
There are at least three possible means of providing a keep-alive mechanism in TN3270E: the TCP Keepalive, the Telnet IAC NOP command [8], and the Telnet DO TIMING-MARK option [9]. Each method has its advantages and disadvantages. It is recommended that TN3270E clients and servers that support keep-alives should support all three methods, and that both sides should always respond to TIMING-MARKs.
TN3270Eでキープアライブメカニズムを提供するには、少なくとも3つの方法があります。TCPキープアライブ、Telnet IAC NOPコマンド[8]、およびTelnet DO TIMING-MARKオプション[9]です。それぞれの方法には長所と短所があります。キープアライブをサポートするTN3270Eクライアントとサーバーは3つの方法すべてをサポートし、両側が常にTIMING-MARKに応答することをお勧めします。
Note that both clients and servers could be configured to "actively" implement keep-alives. That is, both sides could send a TIMING-MARK or a NOP or issue a TCP Keepalive in order to determine whether or not the partner is still alive. Alternatively, network administrators may wish to configure only one side to send keep-alives; in this case, the other side would be a "passive" participant which simply responds to the keep-alives it receives.
クライアントとサーバーの両方がキープアライブを「アクティブに」実装するように構成できることに注意してください。つまり、パートナーがまだ生きているかどうかを判断するために、両側がTIMING-MARKまたはNOPを送信するか、TCPキープアライブを発行することができます。または、ネットワーク管理者は、キープアライブを送信するように片側のみを構成することもできます。この場合、相手側は、受信したキープアライブに単に応答する「パッシブ」参加者になります。
Implementors who want their code to be capable of being an "active" keep-alive participant should make their client or server configurable so that administrators can set which, if any, keep-alive mechanism should be employed, and how often it should be used.
コードを「アクティブな」キープアライブ参加者にできるようにしたい実装者は、クライアントまたはサーバーを構成可能にして、管理者がキープアライブメカニズムを採用する必要があるかどうか、および使用する頻度を設定できるようにする必要があります。 。
Upon failure of a session on which keep-alives are used, both parties should make the proper notifications. A client should give the user some indication of the failure, such as an error code in the Operator Information Area of the screen. A server should notify the host application that the session has been terminated, for example by sending an UNBIND with type CLEANUP in an SNA environment.
キープアライブが使用されているセッションで障害が発生した場合、両方の当事者が適切な通知を行う必要があります。クライアントは、画面のオペレーター情報領域にあるエラーコードなど、ユーザーに失敗の兆候を示す必要があります。サーバーは、たとえばSNA環境でタイプCLEANUPのUNBINDを送信することにより、セッションが終了したことをホストアプリケーションに通知する必要があります。
The following example shows a TN3270E-capable server and a traditional tn3270 client establishing a connection:
次の例は、接続を確立するTN3270E対応サーバーと従来のtn3270クライアントを示しています。
Server: IAC DO TN3270E Client: IAC WON'T TN3270E Server: IAC DO TERMINAL-TYPE Client: IAC WILL TERMINAL-TYPE Server: IAC SB TERMINAL-TYPE SEND IAC SE Client: IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SE 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 (3270 data stream is exchanged)
サーバー：IAC DO TN3270Eクライアント：IAC WO N'T TN3270Eサーバー：IAC DO TERMINAL-TYPEクライアント：IAC WILL TERMINAL-TYPEサーバー：IAC SB TERMINAL-TYPE SEND IAC SEクライアント：IAC SB TERMINAL-TYPE IS IBM-3278-2 IAC SEサーバー：IAC DO EOR IAC WILL EORクライアント：IAC WILL EOR IAC DO EORサーバー：IAC DO BINARY IAC WILL BINARYクライアント：IAC WILL BINARY IAC DO BINARY（3270データストリームが交換されます）
The following example shows a TN3270E-capable server and a TN3270E-capable client establishing a generic pool (non-specific) terminal session:
次の例は、TN3270E対応サーバーとTN3270E対応クライアントが汎用プール（非特定）端末セッションを確立することを示しています。
Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT anyterm IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE (3270 data stream is exchanged)
サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E SEND DEVICE-TYPE IAC SEクライアント：IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 IAC SEサーバー：IAC SB TN3270E DEVICE-TYPE IS IBM-3278- 2 CONNECT anyterm IAC SEクライアント：IAC SB TN3270E機能要求応答IAC SEサーバー：IAC SB TN3270E機能は応答IAC SE（3270データストリームが交換されます）
The following example shows a TN3270E-capable server and a TN3270E-capable client establishing a terminal session where the client requests a specific device-name:
次の例は、クライアントが特定のデバイス名を要求するターミナルセッションを確立するTN3270E対応サーバーとTN3270E対応クライアントを示しています。
Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5-E CONNECT myterm IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E CONNECT myterm IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES BIND-IMAGE IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES BIND-IMAGE IAC SE (3270 data stream is exchanged)
サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E SEND DEVICE-TYPE IAC SEクライアント：IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5-E CONNECT myterm IAC SEサーバー：IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E CONNECT myterm IAC SEクライアント：IAC SB TN3270E機能要求応答BIND-IMAGE IAC SEサーバー：IAC SB TN3270E機能は応答BIND-IMAGE IAC SE（3270データストリームが交換されます）
The following example shows a TN3270E-capable server and a TN3270E-capable client establishing a terminal session where the client requests a resource-name and is returned a device-name chosen by the server:
次の例は、TN3270E対応サーバーとTN3270E対応クライアントが端末セッションを確立することを示しています。クライアントはリソース名を要求し、サーバーによって選択されたデバイス名が返されます。
Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5-E CONNECT pool1 IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E CONNECT term0013 IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST BIND-IMAGE IAC SE Server: IAC SB TN3270E FUNCTIONS IS BIND-IMAGE IAC SE (3270 data stream is exchanged)
サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E送信デバイスタイプIAC SEクライアント：IAC SB TN3270Eデバイスタイプ要求IBM-3278-5-E CONNECT pool1 IAC SEサーバー：IAC SB TN3270EデバイスタイプIS IBM-3278-5-E CONNECT term0013 IAC SEクライアント：IAC SB TN3270E機能要求バインド画像IAC SEサーバー：IAC SB TN3270E機能はバインド画像IAC SE（3270データストリームが交換されます）
The following example shows a TN3270E-capable server and a TN3270E-capable client attempting to establish a terminal session; multiple attempts are necessary because the device-name initially requested by the client is already in use:
次の例は、ターミナルセッションを確立しようとするTN3270E対応サーバーとTN3270E対応クライアントを示しています。最初にクライアントから要求されたデバイス名がすでに使用されているため、複数回の試行が必要です。
Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5 CONNECT myterm IAC SE Server: IAC SB TN3270E DEVICE-TYPE REJECT REASON DEVICE-IN-USE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 CONNECT herterm IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT herterm IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE (3270 data stream is exchanged)
サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E SEND DEVICE-TYPE IAC SEクライアント：IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5 CONNECT myterm IAC SEサーバー：IAC SB TN3270E DEVICE-TYPE REJECT REASON DEVICE使用中のIAC SEクライアント：IAC SB TN3270Eデバイスタイプ要求IBM-3278-2 CONNECT herterm IAC SEサーバー：IAC SB TN3270EデバイスタイプはIBM-3278-2 CONNECT herterm IAC SEクライアント：IAC SB TN3270E機能要求応答IAC SEサーバー：IAC SB TN3270E機能は応答IAC SE（3270データストリームが交換されます）
The following example shows a TN3270E-capable server and a TN3270E-capable client establishing a printer session where the client requests a specific device-name, and where some amount of 3270 function negotiation is required before an agreement is reached:
次の例は、TN3270E対応サーバーとTN3270E対応クライアントがプリンターセッションを確立するところを示しています。クライアントは特定のデバイス名を要求し、合意に達する前にある程度の3270機能のネゴシエーションが必要です。
Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT myprt IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT myprt IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC Server: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL RESPONSES IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST DATA-STREAM-CTL IAC Server: IAC SB TN3270E FUNCTIONS IS DATA-STREAM-CTL IAC SE
サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E SEND DEVICE-TYPE IAC SEクライアント：IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 CONNECT myprt IAC SEサーバー：IAC SB TN3270E DEVICE-TYPE IS IBM- 3287-1 CONNECT myprt IAC SEクライアント：IAC SB TN3270E機能要求データストリームSTREAM-CTL IACサーバー：IAC SB TN3270E機能要求データストリーム-CTL応答IAC SEクライアント：IAC SB TN3270E機能要求データストリーム-CTL IACサーバー： IAC SB TN3270E機能はDATA-STREAM-CTL IAC SE
(3270 data stream is exchanged)
（3270データストリームが交換されます）
The following example shows a TN3270E-capable server and a TN3270E-capable client establishing first a specific terminal session, then a printer session where the "partner" printer for the assigned terminal is requested:
次の例は、TN3270E対応サーバーとTN3270E対応クライアントが最初に特定の端末セッションを確立し、次に割り当てられた端末の「パートナー」プリンターが要求されるプリンターセッションを示しています。
Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 CONNECT termxyz IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2 CONNECT termxyz IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE (3270 data stream is exchanged) . . . . (user decides to request a printer session, so client again connects to Telnet port on server) Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 ASSOCIATE termxyz IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT termxyz's-prt IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES IAC SE (3270 data stream is exchanged)
サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E SEND DEVICE-TYPE IAC SEクライアント：IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2 CONNECT termxyz IAC SEサーバー：IAC SB TN3270E DEVICE-TYPE IS IBM- 3278-2 CONNECT termxyz IAC SEクライアント：IAC SB TN3270E機能要求応答IAC SEサーバー：IAC SB TN3270E機能は応答IAC SE（3270データストリームが交換されます）。 。 。 。 （ユーザーがプリンターセッションを要求することにしたため、クライアントはサーバーのTelnetポートに再度接続します）サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E SEND DEVICE-TYPE IAC SEクライアント：IAC SB TN3270E DEVICE-TYPE REQUEST IBM -3287-1 ASSOCIATE termxyz IAC SE Server：IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT termxyz's-prt IAC SE Client：IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES RESPONSES IAC SE Server：IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES応答IAC SE（3270データストリームが交換されます）
The following example shows a TN3270E-capable server and a TN3270E-capable client establishing first a terminal session where a resource-name was requested and a server chosen device-name was returned, then a printer session where the "partner" printer for the assigned terminal is requested:
次の例は、TN3270E対応サーバーとTN3270E対応クライアントが、最初にリソース名が要求され、サーバーが選択したデバイス名が返されたターミナルセッションを確立し、次に割り当てられた「パートナー」プリンターが接続されているプリンターセッションを示しています。端末が要求されます：
Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5 CONNECT poolxyz IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5 CONNECT terma IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE (3270 data stream is exchanged) . . . . (user decides to request a printer session, so client again connects to Telnet port on server) Server: IAC DO TN3270E Client: IAC WILL TN3270E Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1 ASSOCIATE terma IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT terma's-prt IAC SE Client: IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES RESPONSES IAC SE Server: IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES RESPONSES IAC SE (3270 data stream is exchanged)
サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E SEND DEVICE-TYPE IAC SEクライアント：IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5 CONNECT poolxyz IAC SEサーバー：IAC SB TN3270E DEVICE-TYPE IS IBM- 3278-5 CONNECT terma IAC SEクライアント：IAC SB TN3270E機能要求応答IAC SEサーバー：IAC SB TN3270E機能は応答IAC SE（3270データストリームが交換されます）。 。 。 。 （ユーザーがプリンターセッションを要求することにしたため、クライアントはサーバーのTelnetポートに再度接続します）サーバー：IAC DO TN3270Eクライアント：IAC WILL TN3270Eサーバー：IAC SB TN3270E SEND DEVICE-TYPE IAC SEクライアント：IAC SB TN3270E DEVICE-TYPE REQUEST IBM -3287-1 ASSOCIATE terma IAC SE Server：IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1 CONNECT terma's-prt IAC SE Client：IAC SB TN3270E FUNCTIONS REQUEST SCS-CTL-CODES RESPONSES IAC SE Server：IAC SB TN3270E FUNCTIONS IS SCS-CTL-CODES応答IAC SE（3270データストリームが交換されます）
These extensions to telnet do not provide any security features beyond that of ordinary telnet; so a TN3270E session is no more secure than an ordinary telnet session. Once standard authentication and/or privacy mechanisms for telnet have been defined, these may also be usable by TN3270E. One of the important uses of authentication would be to answer the question of whether or not a given user should be allowed to "use" a specific terminal or printer device-name.
telnetに対するこれらの拡張は、通常のtelnetを超えるセキュリティ機能を提供しません。そのため、TN3270Eセッションは通常のtelnetセッションよりも安全ではありません。 Telnetの標準認証および/またはプライバシーメカニズムが定義されると、これらはTN3270Eでも使用できるようになります。認証の重要な用途の1つは、特定のユーザーが特定の端末またはプリンターのデバイス名を「使用」できるようにするかどうかという質問に答えることです。
[1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, January 1988.
[1] Rekhter、J。、「Telnet 3270 Regime Option」、RFC 1041、1988年1月。
[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, February 1989.
[2] VanBokkelen、J。、「Telnet Terminal-Type Option」、RFC 1091、1989年2月。
[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD 27, RFC 856, May 1983.
[3] Postel、J。、およびJ. Reynolds、「Telnet Binary Transmission」、STD 27、RFC 856、1983年5月。
[4] Postel, J., "Telnet End of Record Option", RFC 885, December 1983.
[4] Postel、J。、「Telnet End of Record Option」、RFC 885、1983年12月。
[5] "3270 Information Display System - Data Stream Programmer's Reference", publication number GA24-0059, IBM Corporation.
[5] 「3270 Information Display System-Data Stream Programmer's Reference」、資料番号GA24-0059、IBM Corporation。
[6] "SNA Formats", publication number GA27-3136, IBM Corporation.
[6] 「SNA Formats」、資料番号GA27-3136、IBM Corporation。
[7] "3174 Establishment Controller Functional Description", publication number GA23-0218, IBM Corporation.
[7] 「3174 Establishment Controller Functional Description」、資料番号GA23-0218、IBM Corporation。
[8] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[8] Postel、J。、およびJ. Reynolds、「Telnet Protocol Specification」、STD 8、RFC 854、1983年5月。
[9] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31, RFC 860, May 1983.
[9] Postel、J。、およびJ. Reynolds、「Telnet Timing Mark Option」、STD 31、RFC 860、1983年5月。
[10] J. Penner, "TN3270 Current Practices", RFC 1576, January, 1994.
[10] J. Penner、「TN3270 Current Practices」、RFC 1576、1994年1月。
Portions of this document were drawn from the following sources:
このドキュメントの一部は、次のソースから引用されました。
- A White Paper written by Owen Reddecliffe, WRQ Corporation, October 1991.
- 1991年10月、WRQ CorporationのOwen Reddecliffeによって書かれた白書。
- Experimental work on the part of Cleve Graves and Michelle Angel, OpenConnect Systems, 1992 - 1993.
- Cleve GravesとMichelle Angelによる実験的作業、OpenConnect Systems、1992年-1993年。
- Discussions at the 1993 IETF meetings.
- 1993 IETFミーティングでの議論。
- Discussions on the "TN3270E" list, 1993-94 and 1997.
- 「TN3270E」リストに関する議論、1993-94および1997。
Bill Kelly Division of University Computing 144 Parker Hall Auburn University, AL 36849
ビルケリーユニバーシティコンピューティング部門144パーカーホールオーバーン大学、アラバマ州36849
Phone: (334) 844-4512 EMail: kellywh@mail.auburn.edu
電話：（334）844-4512メール：kellywh@mail.auburn.edu
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。