RFC2355 日本語訳
2355 TN3270 Enhancements. B. Kelly. June 1998. (Format: TXT=89394 bytes) (Obsoletes RFC1647) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Kelly Request for Comments: 2355 Auburn University Obsoletes: 1647 June 1998 Category: Standards Track
コメントを求めるワーキンググループB.ケリー要求をネットワークでつないでください: 2355 オーバーン大学は以下を時代遅れにします。 1647 1998年6月のカテゴリ: 標準化過程
TN3270 Enhancements
TN3270増進
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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 Optionの下で交渉されて、RFC1041[1]で定義されるようにTelnet3270Regime Optionに関係ありません。
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
1. 序論… 2 1.1 RFC1647に変化します… 4 2. TN3270E概要… 5 3. コマンド名とコード… 6 4. 意味を命令してください… 7 5. デフォルト仕様… 9 6. 動機… 9 7. TN3270Eサブ交渉は統治されます… 9 7.1 装置タイプ交渉… 9 7.1 .1デバイスは水たまりになります… 10 7.1 .2 コマンドを接続してください… 12
Kelly Standards Track [Page 1] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[1ページ]。
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
7.1.3 コマンドを関連づけてください… 12 7.1 .4 申し込みに応じます… 13 7.1 .5 コマンドを拒絶してください… 13 7.2機能交渉… 14 7.2 .1 命令します… 14 7.2 TN3270Eの.2リストは機能します… 16 8. TN3270Eデータメッセージ… 16 8.1 TN3270Eメッセージヘッダー… 18 8.1 .1データ型分野… 18 8.1 .2要求旗の分野… 19 8.1 .3応答旗の分野… 19 8.1 .4SEQ-ナンバーフィールド… 20 9. 基本的なTN3270E… 20 9.1 3270年のモードとNVTモード… 21 10. 処理TN3270Eの細部は機能します… 22 10.1 Sc CTLコードは機能します… 22 10.2 データストリームCTL機能… 23 10.3 ひもイメージ機能… 24 10.4 応答は機能します… 25 10.4.1 応答メッセージ… 26 10.5 SYSREQは機能します… 28 10.5.1 バックグラウンド… 28 10.5.2 SYSREQのTN3270E実装… 29 11. 3270年のATTNキー… 30 12. 3270は分野を構造化しました… 31 13. 実装ガイドライン… 31 13.1 3270のデータが注意を流します… 31 13.2 TN3270E telnetオプションの交渉… 32 13.3 「生きている生活費」メカニズム… 32 13.4の例… 32 14. セキュリティ問題… 36 15. 参照… 36 16. 著者注… 37 17. 作者のアドレス… 37 18. 完全な著作権宣言文… 38
1. Introduction
1. 序論
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 Optionsを交渉するデファクトスタンダードによって実行されました--端末のタイプの[2]、Binary Transmission[3]、およびEndのRecord[4]。 規格としてこの交渉を指定するRFCが全くないことに注意してください。 RFC1041は、3270Regime Telnet Optionを定義することによって3270年の端末のサポートを交渉するメソッドを標準化するのを試みました。 ほんのわずかな開発者とベンダーは、今までに、RFCが1041であると実装しました。
Kelly Standards Track [Page 2] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[2ページ]。
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].
このドキュメントは「伝統的なtn3270」として3270年のデータ・ストリームを交換する前にこれらの3Telnet Optionsを交渉する既存の習慣について言及するでしょう。 伝統的な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サーバと非SNA3270台のデバイスを表すものを見分けません。
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 RequestとResponse Unitsの参照は[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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
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.
- 3270ATTNと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年のデータ・ストリームを組み込むホストアプリケーション、または特にクライアント側の機械的な誤りで引き起こされる場合がありました。
Kelly Standards Track [Page 3] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[3ページ]。
- 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 Bind情報にアクセスできたメカニズムが全くありませんでした。 Bindイメージは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であるとサポートされたクライアントが分野を構造化したかどうか決定できたメカニズムが全くなかったか、またはクライアントは、それらを受けるよう要求できました。
1.1 Changes to RFC 1647
1.1 RFC1647への変化
This document replaces RFC 1647; the following is a summary of the changes that have been incorporated:
このドキュメントはRFC1647を取り替えます。 ↓これは法人組織であった変化の概要です:
- Reworded the Introduction to refer to traditional tn3270 in the
past tense.
- 過去時制で伝統的なtn3270について言及するためにIntroductionを言い換えました。
Affected sections: 1.
影響を受けるセクション: 1.
- Added this section documenting changes to RFC 1647
- 加えられて、このセクションドキュメントはRFC1647に変化します。
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) コマンド2)が制限している言葉遣いを取り除くサーバの維持されたデバイスプール3)の組織と使用がTN3270E装置タイプ交渉における装置名とリソース名の間で区別して、装置名とリソース名のために最大の長さに定義するASSOCIATEの動機と使用をはっきりさせてください。
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 (第一節)
Kelly Standards Track [Page 4] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[4ページ]。
- 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.
- エンド・オブ・ジョブがプリンタのための指示であるとサポートするために0×08の値で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 Fieldの記述をはっきりさせます。
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に発信して、剥取って戻る前に0xffを含むどちらのバイトも0xffffに倍にしなければなりません。
Affected sections: 8.1.4
影響を受けるセクション: 8.1.4
- Defined the format and maximum length of the Bind image.
- Bindイメージの書式と最大の長さを定義しました。
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-TYPEsに関する紛らわしい言葉遣いをはっきりさせました。
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.
- ケルベロスを示すためにSecurity部を言い換えました。
Affected sections: 14.
影響を受けるセクション: 14.
2. TN3270E Overview
2. TN3270E概要
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
これらの問題を扱うために、このドキュメントは新しいTelnet Optionを提案します--TN3270E。 telnetクライアントとサーバは無料でTN3270Eオプションのサポートを交渉できるでしょう。 どちらの側もTN3270Eを支えないなら、伝統的なtn3270を使用できます。 さもなければ、サブ交渉は、TN3270Eのどんな部分集合がそうするかを決定するために起こるでしょう。
Kelly Standards Track [Page 5] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[5ページ]。
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.
セッションのときに、使用されてください。 反対側がTN3270Eを拒否するなら、両方のタイプの3270年のエミュレーションができるクライアントかサーバが最初に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 suboptionsの交渉は始まることができます。 TN3270Eサブ交渉の2個の多量栄養素は以下の通りです。
- a device-type negotiation that is similar to, but somewhat
more complicated than, the existing Telnet Terminal-Type Option.
- 同様の、しかし、いくらか複雑な装置タイプ交渉、既存のTelnet Terminal-タイプ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.
- BIND情報のサーバからクライアントまでのプリンタデータストリーム型などの3270のサポートしている関数(3270年のデータ・ストリームかSNAキャラクターStream)、肯定しているか否定している応答交換、デバイス状態情報、および通過の1セットの交渉。
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キャラクターStream、またはデバイス状態情報)ものを運ぶ旗とインディケータを含むでしょう。
3. Command Names and Codes
3. コマンド名とコード
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"によって先行されていない場合、すべての数字直定数が本書ではデシマル値を指定します、その場合、16進値は表されます。
TN3270E 40
ASSOCIATE 00
CONNECT 01
DEVICE-TYPE 02
FUNCTIONS 03
IS 04
REASON 05
REJECT 06
REQUEST 07
SEND 08
TN3270E40の副00が接続する、01装置タイプ02機�%%BODY%%3は廃棄物06要求07が08を送る04理由05です。
Reason-codes
CONN-PARTNER 00
DEVICE-IN-USE 01
INV-ASSOCIATE 02
INV-NAME 03
理由コードコン-パートナー00使用中のデバイス01INV-仲間02INV-名前03
Kelly Standards Track [Page 6] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[6ページ]。
INV-DEVICE-TYPE 04
TYPE-NAME-ERROR 05
UNKNOWN-ERROR 06
UNSUPPORTED-REQ 07
INV-装置タイプ04タイプ名前誤り05未知の誤り06サポートされないREQ07
Function Names
BIND-IMAGE 00
DATA-STREAM-CTL 01
RESPONSES 02
SCS-CTL-CODES 03
SYSREQ 04
機能は01の応答02のSc CTLコード03SYSREQ04とひもイメージ00データストリームCTLを命名します。
4. Command Meanings
4. コマンド意味
Refer to the Telnet Protocol Specification [8] for the meaning of IAC, DO, WILL, etc.
ウィル、IACの意味についてテルネット・プロトコルSpecification[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がそうしない、TN3270E
The sender of this command refuses to send TN3270E information.
このコマンドの送付者は、情報をTN3270Eに送るのを拒否します。
IAC DO TN3270E
IACは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]の同等物とRecord Option[4]のTelnet EndがTN3270E Optionの交渉で含意されることに注意してください。 すなわち、TN3270Eをサポートするのに同意する交渉へのパーティーが、双方向のバイナリーとEOR送信をサポートするのに自動的に必要です。
IAC SB TN3270E SEND DEVICE-TYPE IAC SE
IAC SB TN3270Eは装置タイプ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.
サーバだけがこのコマンドを送るかもしれません。 このコマンドは、クライアントが装置タイプと任意に装置名情報を伝えるよう要求するのに使用されます。
Kelly Standards Track [Page 7] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[7ページ]。
IAC SB TN3270E DEVICE-TYPE REQUEST <device-type>
[ [CONNECT <resource-name>] | [ASSOCIATE <device-name>] ] IAC SE
IAC SB TN3270E装置タイプ要求<装置タイプ>[<リソース名の>を接続する]| [<装置名>を関連づけます]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に続かなければなりません、そして、<装置名>はASSOCIATEに続かなければなりません。 (セクションが、より詳細な情報のための「装置タイプ交渉」の権利を与えられるのを見てください。)
IAC SB TN3270E DEVICE-TYPE IS <device-type> CONNECT
<device-name> IAC SE
IAC SB TN3270E装置タイプは<装置タイプ>が<装置名>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装置タイプは理由<理由コード>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 REQUESTコマンドを拒絶するのに使用されると、機能リストが前の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コマンドで受け取られたリストに合わなければならないことに注意してください。
Kelly Standards Track [Page 8] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[8ページ]。
5. Default Specification
5. デフォルト仕様
WON'T TN3270E
TN3270Eであるだろう
DON'T TN3270E
TN3270E
i.e., TN3270E will not be used.
すなわち、TN3270Eは使用されないでしょう。
6. Motivation
6. 動機
See the section entitled "Introduction".
セクションが「序論」の権利を与えられるのを見てください。
7. TN3270E Sub-negotiation Rules
7. TN3270Eサブ交渉規則
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年のデータ・ストリーム送信は起こることができます。
7.1 DEVICE-TYPE Negotiation
7.1 装置タイプ交渉
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)
erminals: IBM-3278-2IBM3278-2E(24行x80あん部ディスプレイ)のIBM-3278-3IBM3278-3E(32行x80あん部ディスプレイ)のIBM-3278-4IBM3278-4E(43行x80あん部ディスプレイ)のIBM-3278-5IBM3278-5E(27行x132あん部ディスプレイ)の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
'3278'と'3287'の使用がどんな特定のデバイス能力も除くことを意図しないことに注意してください。 単に、彼らが端末のための一般的に知られている名称と3270年のデバイスのファミリーのプリンタメンバーであるので、それらはここで使用されます。 意志は可能な装置タイプの数を最小にして、関連するデータ・ストリーム能力で特定のIBMハードウェアの協会を壊すことによって装置タイプ交渉(伝統的なtn3270との比較における)を簡素化することです。 例えば、装置タイプの交渉
Kelly Standards Track [Page 9] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[9ページ]。
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.
IBM3278-2Eはそういうものとして物理的な3279モデルS2Bに関連している機能のどれかの使用を排除しません。 3270年のデータ・ストリームの、より高度な関数をサポートするクライアントの能力はIBMの装置タイプと型番の交渉で示されるのではなく、むしろRead Partition QueryとQuery Replyの組み合わせることで示されるでしょう。
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.
80のコラムに従って、端末の装置タイプは皆、「プライマリ」のディスプレイが24の行のサイズであるとサポートします。 「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"接尾語かダイナミックなタイプと端末の装置タイプを交渉するクライアント(プリンタデバイスを交渉するものと同様にタイプ)は、受け入れて、質問コマンドを仕切るためにaが、読んだ応じることができなければなりません(セクションが「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スクリーン分野(logmodeのPSERVIC分野における11番目のバイト)が0×03に設定されるBindをもたらすべきです、代替の画面サイズがQuery Reply(使用可能なArea)によって測定されるのを示して。
7.1.1 Device Pools
7.1.1 デバイスプール
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名」、および「ネットワーク名」を考えることができます。 彼らは特定の端末かプリンタデバイスについて言及します。
Kelly Standards Track [Page 10] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[10ページ]。
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クライアントをサポートしたいなら、それはターミナルセションのために、そのようなクライアントからの要望に応じるのに使用できる1セットの端末の装置名を維持しなければなりません。 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
また、さらに、TN3270Eサーバはどんな端末にも関連づけられないプリンタ装置名の1つ以上のプールを維持するかもしれません。 CONNECTコマンドを使用する特定のプリンタセッション要求にこれらのプリンタデバイスを割り当てることができるだけです(以下を見てください)。 これが装置名が印刷要求を開始した端末の装置名以外の何かで決定するプリンタに向かっているプリント出力を生成するそれらのホストアプリケーションを考慮する、(
Kelly Standards Track [Page 11] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[11ページ]。
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).
端末に署名される人のユーザIDが印刷の目的地を決定するときの例 また、プリンタ(すなわち、CONNECTもASSOCIATEも指定しないもの)を求めるジェネリック要求を満たすためにプリンタ装置名のプールを維持できたのも可能です。
7.1.2 CONNECT Command
7.1.2 接続コマンド
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.
クライアントは2つの方法でCONNECTを使用できます: それが指定するリソース名が装置名であるなら、クライアントは特定の装置名を要求しています。 指定されたリソース名が装置名でないなら、クライアントはリソース名に関連しているデバイス名のいずれも要求しています。
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.
どちらの場合ではも、指定されたリソース名によって示されたリソースは装置タイプと衝突してはいけません。 例えばクライアントがDEVICE-TYPE IBM-3287-1(プリンタ)を要求して、CONNECT T1000001を指定しますが、T1000001がホストで端末と定義された装置名であるなら、サーバは要求を否定しなければなりません。 さらに、要求されたリソース名が既にある他のTelnetセッションに関連している装置名である、またはそれがサーバと定義されないなら、サーバは要求を否定しなければなりません。
7.1.3 ASSOCIATE Command
7.1.3 仲間コマンド
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.
プリンタを表すDEVICE- TYPEを要求するときだけ、クライアントはASSOCIATEを使用できます、そして、指定された装置名は端末では、前のDEVICE-TYPE IS<装置タイプ>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は要求で命名される端末と対にされるプリンタの装置名がこのセッションに割り当てられるという要求を命令します。 装置タイプがプリンタを表さないか、または装置名が端末のものでないなら、サーバは要求を否定しなければなりません。 また、サーバに指定された端末への定義されたaパートナープリンタがないなら、それは要求を否定しなければなりません。
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つから端末をつなげて、要求します。 そして、それは2番目のセッション要求(それがただ設立したターミナルセションと対にされるプリンタを求める今回)でサーバ(「申し込みに応じます」、セクション7.1.4未満を見る)によって返された端末の装置名を使用します。 これで、プリンタ装置名に関する先の知識を持たなければならないというよりむしろクライアントは端末とのプリンタセッションを関連づけることができます。
Kelly Standards Track [Page 12] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[12ページ]。
7.1.4 Accepting a Request
7.1.4 申し込みに応じること。
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.
サーバが要請を受け入れたいなら、それは、端末かプリンタの装置名がこのセッションまで選任した要求された装置タイプとCONNECTコマンド指定を確認しながら、DEVICE-TYPE ISコマンドを返送します。
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.
これへの例外はクライアントは特定のLU名に関しなければならなくて(例えばローカル・サイト方針を満たす)、クライアントによって要求されたものに合っていない装置名を与えるかどうかということでしょう。通常、クライアントはサーバによって送られたどんなDEVICE-TYPE IS<装置タイプ>CONNECT<装置名>も受け入れるはずです。(例えば、クライアントがそれが装置名であると考えたことを要求するならこれが起こることができる、サーバでデバイスのプールの名前と定義されたことだけ) この場合、クライアントは、TN3270E交渉を終えることによって、DEVICE-TYPE ISコマンドを拒絶するべきです。
7.1.5 REJECT Command
7.1.5 拒絶コマンド
If the server wishes to deny the request, it sends back the DEVICE- TYPE REJECT command with one of the following reason-codes:
サーバが要求を否定したいなら、以下の理由コードの1つでDEVICE- TYPE REJECTコマンドを返送します:
Reason code name Explanation
---------------- -----------------------------------
INV-DEVICE-TYPE The server does not support the
requested device-type.
理由コードネームのExplanation---------------- ----------------------------------- サーバがするINV-DEVICE-TYPEは要求された装置タイプをサポートしません。
INV-NAME The resource-name or device-name
specified in the CONNECT or ASSOCIATE
command is not known to the server.
リソース名か装置名がCONNECTかASSOCIATEコマンドで指定したINV-NAMEはサーバに知られていません。
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
UNSUPPORTED-REQ、サーバはクライアントによって送られた要求のタイプを満たすことができません。 しかし、例えば特定の端末かプリンタが要求されました。
Kelly Standards Track [Page 13] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[13ページ]。
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.
サーバにはそれ、または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.
クライアントのコン-PARTNERは特定のプリンタを要求するCONNECTコマンドを使用しますが、ある端末への装置名が、要求したパートナーです。
UNKNOWN-ERROR Any other error in device type or
name processing has occurred.
装置タイプか名前処理におけるUNKNOWN-ERROR Any他の誤りは発生しました。
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の理由コードで要求を拒絶するなら、クライアントは交渉におけるさらなるどんな特定の端末の要求もしてはいけません。 どちらの側もプロセスの任意な点で「脱出したい」なら、それは単にaを送ることができます。もう片方に面がないでしょう(or DON'T) TN3270Eが、命令する。 ここに、両側は自由に他のTelnetオプションを交渉できます(伝統的なtn3270を含んでいて)。
7.2 FUNCTIONS Negotiation
7.2 機能交渉
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交渉がいったん首尾よくそうすると、完成していて(i.e、クライアントが受信するとき、DEVICE-TYPE ISはそれが許容できると命令します)、クライアントは、FUNCTIONS REQUESTコマンドをサーバに送ることによって、FUNCTIONS交渉を開始しなければなりません。この後初期のREQUESTは命令します、そして、両側は自由にFUNCTIONS REQUESTを伝えることができます、そして、FUNCTIONS ISは必要に応じて命令します。
7.2.1 Commands
7.2.1 コマンド
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
FUNCTIONS REQUESTコマンドは送付者がこのセッションのときにサポートされるのを見たがっているTN3270E機能のリストを含んでいます。 すべての機能はリストでサポートされないのは考えられないことです。 リストは先行するIACコードによって終えられます。
Kelly Standards Track [Page 14] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[14ページ]。
the SE command. Functions may appear in any order in the list.
SEは命令します。 機能はリストに順不同に現れるかもしれません。
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.
- それは積極的で応じるかもしれません(リストでのすべての機能をサポートして、リストでないことでの機能に関連する少しのデータも送らないのに同意することを意味します)。 これをするために、それはちょうどそれを受け取ったように機能リストがある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).
- それは、ネガで機能リストがそれが受け取ったもの(そして、加えられるか、または取り外された必須、リストにおける、機能の外観の注文; 単に少なくとも1つの機能におけるリストでない)と異なっているFUNCTIONS REQUESTコマンドを送ることによって、応じるかもしれません。
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.
機能リストが、同意したのが、可能であるというメモはヌルです。 これは「基本的な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 DON'T(or WON'T) TN3270Eを送ることによって、交渉を終えるべきです。
Kelly Standards Track [Page 15] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[15ページ]。
7.2.2 List of TN3270E Functions
7.2.2 TN3270E機能のリスト
The following list briefly describes the 3270 functions that may be negotiated in the 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.
機能名前記述------------- ----------- SCS-CTL-CODES(プリンタセッション専用)。 セッションのSNAキャラクターStream(SCS)とSCS制御コードの使用を許します。 SCSはLUタイプ1SNAセッションと共に使用されます。
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タイプ3SNAセッションに対応しています。
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 Providesは積極的で否定的な応答のために取り扱いをサポートします。 クライアントにいくらかとすべて明確な状態で反射するサーバ、例外を送りましたが、要求がホストアプリケーションで送らなかったどんな応答も許容します。
BIND-IMAGE Allows the server to send the SNA Bind
image and Unbind notification to the
client.
BIND-IMAGE Allows、SNA BindイメージとUnbind通知をクライアントに送るサーバ。
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 Allowsと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.
認識されていない機能がコード化する交渉が機能の途中にrecievedされるなら、受取人は、リストからその機能コードを単に取り除いて、正規曲線交渉を続けるべきです。
8. TN3270E Data Messages
8. TN3270Eデータメッセージ
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
一般に、3270のデバイスコミュニケーションが現実に指向のブロックであることが理解されています。 全体の「メッセージ」(データは指す)が建てられるまで、すなわちそれぞれのパートナーバッファデータを反対側に送ります。 「外国行きのメッセージ」(ホストからデバイスまでの)は3270年のコマンド、一連のバッファ注文、バッファアドレス、およびデータから成ります、「本国行きのメッセージ」はバッファ注文、アドレス、およびデータだけを含んでいますが。 メッセージが理解されているaの終わり
Kelly Standards Track [Page 16] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[16ページ]。
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.
最後のバイトは伝わりました(この議論が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では、5バイトから成って、書式が以下で定義されるTN3270Eヘッダーと共に3270年のそれぞれのメッセージを前に置かなければなりません(セクションが「TN3270Eメッセージヘッダー」の権利を与えられるのを見てください)。 したがって、TN3270Eの「データメッセージ」には、以下の工事があります:
<TN3270E Header><data><IAC EOR>
<TN3270Eヘッダー><データ><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>
<TN3270Eヘッダー><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.
デシマル値255を伝えて、それを持っているというサイド願望がデータを解釈したなら、それはこのバイトを「倍増しなければなりません」。 言い換えれば、10進255人のただ一つの発生が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を除いた)がTN3270Eデータメッセージの間に送られるべきであることが強く勧められます、ヘッダーと少しもいいえがIAC EORを引きずっていない状態で。 IAC IP(3270Attentionとして解釈される)かIAC AO(SYSREQとして解釈される)のどちらかを含むTN3270Eデータメッセージが受信されているなら、受信機は、3270年のデータが処理されるまで(3270のAttentionとSYSREQの議論に関して相当区を見てください)コマンドを処理しながら、据え置くはずです。 IAC-コマンド・シーケンスが処理されますが、それを処理しなければならないとき、いかなる他のIAC-コマンド・シーケンス(IAC IACを除いた)も含むTN3270Eデータメッセージが受信されているなら、実装に依存しています。 受信機はすぐに、それを処理するかもしれません(事実上、まるで現在のTN3270Eデータメッセージの前にそれを受け取ったか、または現在のTN3270Eデータメッセージを処理してある後まで処理を延期するかもしれないかのようにそれを処理させます)。 このあいまいさのために、TN3270Eデータメッセージ(すなわち、ヘッダーと引きずっているIAC EORの間の)の中のTelnetコマンドの存在は推薦されません。 クライアントもサーバもそのようなデータを送るべきではありません。
Kelly Standards Track [Page 17] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[17ページ]。
8.1 The TN3270E Message Header
8.1 TN3270Eメッセージヘッダー
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
----------------------------------------------------------- | データ型| 要求旗| 応答旗| SEQ-数| ----------------------------------------------------------- 1バイト1バイト1バイト2バイト
8.1.1 DATA-TYPE Field
8.1.1 データ型分野
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.
データ型ネーム・コード意味-------------- ---- --------------------------------- データが分配するメッセージの3270-DATA0x00は3270年のデータ・ストリームだけを含んでいます。
SCS-DATA 0x01 The data portion of the message
contains SNA Character Stream data.
データが分配するメッセージのSCS-DATA0x01はSNAキャラクターStreamデータを含んでいます。
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).
データが分配するメッセージのRESPONSE0x02はデバイス状態情報を構成します、そして、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-IMAGE0x03はサーバとホストアプリケーションの間で確立されたセッションからのSNAひものイメージです。
UNBIND 0x04 The data portion of the message is
an Unbind reason code.
データが分配するメッセージのUNBIND0x04はUnbind理由コードです。
NVT-DATA 0x05 The data portion of the message is to
be interpreted as NVT data.
解釈されて、メッセージのデータ部にはNVTデータとしてあるNVT-DATA0×05。
REQUEST 0x06 There is no data portion present in
the message. Only the REQUEST-FLAG
field has any meaning.
REQUEST0x06Thereはメッセージの現在のデータ部ではありません。 REQUEST-FLAG分野だけには、どんな意味もあります。
SSCP-LU-DATA 0x07 The data portion of the message is
data from the SSCP-LU session.
データが分配するメッセージのSSCP-LU-DATA0x07はSSCP-LUセッションからのデータです。
Kelly Standards Track [Page 18] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[18ページ]。
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-EOJ0x08Thereはメッセージの現在のデータ部ではありません。 単にサーバと、プリンタセッションだけの上にこの値を送ることができます。
8.1.2 REQUEST-FLAG Field
8.1.2 要求旗の分野
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分野は、受信機で無視しなければならなくて、送付者によって0×00に設定されるべきです。 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.)
要求旗のネーム・コード意味----------------- ---- --------------------------------- 何らかの以前に遭遇したプリンタエラー条件をクリアしてあるとき、クライアントのERR-COND-CLEARED0x00はこれをサーバに送ります。 (セクションが以下で「応答機能」の権利を与えられるのを見てください。)
8.1.3 RESPONSE-FLAG Field
8.1.3 応答旗の分野
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分野のある値のための意味があるだけです。 3270-DATAとSCS- DATAのDATA-TYPE分野値のために、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.
応答旗のネーム・コード意味------------------ ---- --------------------------------- 送付者がするRESPONSEがない0×00は、受信機が明確か否定的にこのメッセージに応じると予想しません。 したがって、受信機はこのデータメッセージに少しの応答も送ってはいけません。
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-RESPONSE0x01は、受信機がこのメッセージに応じると予想します、その場合、受信機は否定応答を送らなければなりません。
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-RESPONSE0x02は、受信機が否定的に応じると予想します。 受信機はいつも1かもう片方を送らなければなりません。
Kelly Standards Track [Page 19] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[19ページ]。
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:
RESPONSEのDATA-TYPE分野価値のために、RESPONSE-FLAGは前のデータメッセージ(定義上3270-DATAかSCS-DATAのどちらかのDATA-TYPEとERROR-RESPONSEかALWAYS-RESPONSEのどちらかのRESPONSE- FLAG値を持っていたに違いない)への実際の応答です。 この場合、RESPONSE-FLAGの可能な値は以下の通りです。
Response-Flag Name Code Meaning
------------------ ---- ---------------------------------
POSITIVE-RESPONSE 0x00 The previous message was received
and executed successfully with
no errors.
応答旗のネーム・コード意味------------------ ---- --------------------------------- 前のPOSITIVE-RESPONSE0x00メッセージは、誤りなしで首尾よく受け取られて、実行されました。
NEGATIVE-RESPONSE 0x01 The previous message was received
but an error(s) occurred while
processing it.
前のNEGATIVE-RESPONSE0x01メッセージを受け取りましたが、誤りはそれを処理している間発生しました。
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分野は、受信機で無視しなければならなくて、送付者によって0×00に設定されるべきです。
8.1.4 SEQ-NUMBER Field
8.1.4 SEQ-ナンバーフィールド
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.
RESPONSES機能が同意されたときだけ、SEQ-NUMBER分野は使用されます。 それは、2バイトの2進の数を含んでいて、彼らが意図したデータメッセージへの積極的で否定的な応答を関連させるのに使用されます。 ネットワークバイトオーダー(「ビッグエンディアン」)でこの野原を送らなければなりません。 どちらのバイトも0xffを含んでいるなら、領収書で0xffに発信して、剥取って戻る前にそれを0xffffに倍にするべきです。 これは標準のIACエスケープです。 セクションがSEQ-NUMBER分野の使用に関する詳細のために「応答機能」の権利を与えられるのを見てください。 RESPONSES機能が同意されないとき、この分野は、いつも送付者によって0×0000に設定されて、受信機によって無視されるべきです。
9. Basic TN3270E
9. 基本的なTN3270E
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コマンドにおける機能リストはヌルです)、可能です。 この運転モードは「基本的なTN3270E」と呼ばれます。 SCS-CTL-CODES機能もDATA-STREAM-CTL機能も同意されないので基本的なTN3270Eがターミナルセションだけについて言及することに注意してください。
Kelly Standards Track [Page 20] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[20ページ]。
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
ヘッダーフィールドValue------------ ----- データ型の3270データのデータ型NVT-データ
The REQUEST-FLAG, RESPONSE-FLAG and SEQ-NUMBER fields are not used in basic TN3270E.
REQUEST-FLAG、RESPONSE-FLAG、およびSEQ-NUMBER分野は基本的なTN3270Eで使用されません。
9.1 3270 Mode and NVT Mode
9.1 3270年のモードとNVTモード
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年のモードで、各当事者は3270DATAに設定されたDATA-TYPE旗でデータメッセージを送るかもしれません。 DATA-TYPE旗のセットをNVT-DATAに送ると、モードを切り換えるという要求は構成されます。 NVTモードで、各当事者はDATA-TYPE旗があるメッセージがNVT-DATAに設定するデータを送るかもしれません。 送付3270-DATAはモードを切り換えるという要求です。 TN3270E操作が初めは首尾よく交渉されるとき、接続が3270年のモードであります。 中にそれが操作しているモードと異なったDATA-TYPEがある状態でパーティーがメッセージを受け取るとき、接続のための運転モードは切り換えられます。 モードを切り換えると、3270Erase/リセット動作の同等物を実行しているクライアントはもたらされます、[5]で説明されるように、デフォルトパーティション(スクリーン)サイズを使用して。 サーバは、クライアントがモード・スイッチの向こう側に前の環境のどんな属性も保存すると仮定できません。
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を意味するでしょう)それぞれの側がデータをバッファリングするはずであることに注意してください。 その時、完全なTN3270Eデータメッセージは、NVTデータを送るために築き上げられるべきです。
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のデータの交換を始めるでしょう。
Kelly Standards Track [Page 21] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[21ページ]。
10. Details of Processing TN3270E Functions
10. 処理TN3270E機能の詳細
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機能リストの具体的な機能への双方による協定はTN3270Eヘッダーで関連する値をサポートする各当事者による同意を含意します。 また、それは機能で同意に関してデータ処理メッセージを支配する規則を固く守る意欲を含意します。 ヘッダー値が機能で同意されるか基本的なTN3270Eに関連していると受け入れないパーティーかヘッダー値を使用する試みのどちらかが、基本的なTN3270Eの一部でない機能と交際して、同意されないで非従って考えられてプロトコルを違反していました。 以下のセクションはそれぞれのTN3270E機能のために関連ヘッダー値と処理規則を詳しく述べます。
10.1 The SCS-CTL-CODES Function
10.1 Sc CTLコード機能
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
ヘッダーフィールドValue------------ ----- データ型Scデータデータ型印刷-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年のモードの目的のために、ちょうど3270-DATAのようにSCS-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,
サーバは環境に適切な状態で動作が何であってもそれが現在取るかもしれないのをクライアントに示すようにそれぞれの印刷仕事の終わりのPRINT-EOJに用意ができているDATA-TYPEがあるTN3270Eメッセージを送るべきです(例えば、ディスクやスプール・ファイルなどを閉じてください)。 サーバには、それがいつPRINT-EOJを送るべきであるかを決定する複数の評価基準があるかもしれません。
Kelly Standards Track [Page 22] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[22ページ]。
such as receipt of SNA End Bracket from the host application, or expiration of a pre-defined timeout value.
ホストアプリケーションからのSNA End Bracketの領収書、または事前に定義されたタイムアウト価値の満了などのように。
10.2 The DATA-STREAM-CTL Function
10.2 データストリームCTL機能
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
ヘッダーフィールドValue------------ ----- データ型の3270データのデータ型印刷-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.
サーバは環境に適切な状態で動作が何であってもそれが現在取るかもしれないのをクライアントに示すようにそれぞれの印刷仕事の終わりのPRINT-EOJに用意ができているDATA-TYPEがあるTN3270Eメッセージを送るべきです(例えば、ディスクやスプール・ファイルなどを閉じてください)。 サーバには、それがいつPRINT-EOJを送るべきであるかを決定する複数の評価基準があるかもしれません、ホストアプリケーションからのSNA End Bracketの領収書、または事前に定義されたタイムアウト価値の満了などのように。
Kelly Standards Track [Page 23] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[23ページ]。
10.3 The BIND-IMAGE Function
10.3 ひもイメージ機能
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
ヘッダーフィールドValue------------ ----- データ型ひもイメージデータ型はデータ型SSCP Luデータを解きます。
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を受けるでしょう。 サーバによって明確に一度これらの両方に応じられて、次に、それは、このセッションの存在についてBIND-IMAGEに設定されたDATA-TYPE旗でデータメッセージをそれに送ることによって、クライアントに知らせなければなりません。 このメッセージのデータ部はちょうどサーバがクライアントを代表して受け入れた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セッションが終えられるとき、サーバはUNBINDに設定されたDATA-TYPE旗でデータメッセージをクライアントに送らなければなりません。 サーバがSNA Unbind RUを通してセッション終了について通知されるなら、それはそれがクライアントに送るメッセージのデータ部にUnbind理由コードを含んでいるでしょうに。 サーバ自体がSNAセッション終了(例えばSYSREQの主要な処理の一部として)を要求するなら、UNBINDメッセージのデータ部を0×01に設定するでしょうに、「セッションの正常な終わり」を示して。
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,
BIND-IMAGE機能のもう一つの側面はわずかに「基本的なTN3270E」の権利を与えられたセクションで説明された振舞いから許容できるDATA- TYPE旗の値を変更します。 BIND-IMAGEが有効であるときに、最初のBIND-IMAGEがクライアントによって受け取られる前にDATA-TYPEがあるメッセージが3270-DATAかSCS-DATAに設定するデータは許容されていません。 ユーザ指向のデータを送るのにSSCP-LU- DATAかNVT-DATAしか使用できません。 同じくらいはUNBINDを送った後とクライアントが別のBIND-IMAGEを受け取る前に交換したデータメッセージに適用されます。 許容できるDATA-TYPEは、一度、クライアントがBIND-IMAGEデータメッセージを受け取るのを評価します。
Kelly Standards Track [Page 24] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[24ページ]。
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.)
SSCP-LU-DATAに加えて、今3270-DATA、そして/または、SCS-DATAを含めてください、端末かプリンタ装置タイプが交渉されたかどうかと、プリンタクライアントがDATA-STREAM-CTL、SCS-CTL-CODES、または両方に同意したかどうかによって。 (セクションがSNA環境における、SSCP-LUセッションのさらなる議論のために「SYSREQ機能」の権利を与えられるのを見てください。)
10.4 The RESPONSES Function
10.4 応答機能
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
ヘッダーフィールドValue------------ ----- DATA-TYPE RESPONSE DATA-TYPE REQUEST RESPONSE-FLAG、0-32767からの-すべて値のREQUEST-FLAG ERR-COND-CLEARED SEQ-NUMBER2進の値
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がない、ERROR-RESPONSEかALWAYS-RESPONSEのどちらかにRESPONSE-FLAG分野を設定しなければなりません。 通常、クライアント側がどんなRESPONSEにもRESPONSE-FLAGを設定しないと予期されます。 それがSNAデバイスを表すなら、サーバは、RESPONSE-FLAGにこのデータメッセージを生成したRUのRHに応答選択値群を反映するように設定するべきです--ALWAYS-RESPONSE(用意ができているERROR- RESPONSEが引き起こしますが、RESPONSEがない設定を引き起こさないどんなResponseももたらすException Response)のRESPONSE-FLAG値をもたらす明確なResponse。 非SNAサーバはERROR-RESPONSEにRESPONSE-FLAGを設定するべきです。
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セッションに送る3270-DATAかSCS-DATAのDATA-TYPEと共にメッセージの数を覚えていなければなりません。 このカウンタは、1日にゼロでそのようなメッセージを始めて、それぞれのその後のメッセージのために1つ増加されるべきです。 このカウンタがどんなSNA一連番号からも独立していて、BindかUnbindの結果、ゼロにリセットされるべきでないことに注意してください。 カウンタが32767の最大に達するなら、それはゼロで再開されるべきです。 メッセージを送る前に送付者はTN3270EヘッダーのSEQ-NUMBER分野にこの値を置かなければなりません。 RESPONSE-FLAG分野の値にかかわらずSEQ-NUMBER分野を設定しなければならないことに注意してください。
Kelly Standards Track [Page 25] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[25ページ]。
10.4.1 Response Messages
10.4.1 応答メッセージ
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
SCS-DATAか3270DATAのどちらかのDATA-TYPEがあるデータメッセージが受信されているときはいつも、受信機は、メッセージのデータ部でデータを処理するのを試みて、次に、それがRESPONSEのDATA-TYPEがあるデータメッセージを送るべきであるかどうか決定しなければなりません。 それがちょうど処理したデータメッセージがいいえRESPONSEのRESPONSE-FLAG値を持ったか、それには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メッセージを構成して、送るでしょう。 クライアントによってサーバに送られた否定応答はUnit Check Status[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 -
POSITIVE-RESPONSEのRESPONSE-FLAG値、-
Value Meaning
----- -------
0x00 Successful completion (when sent by the client,
this is equivalent to "Device End").
値の意味----- ------- 0×00 無事終了(クライアントによって送られると、これは「デバイスエンド」に同等です)。
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").
値の意味----- ------- 0×00 3270年の無効のコマンドを受け取りました(「コマンド拒否」に同等な)。
Kelly Standards Track [Page 26] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[26ページ]。
0x01 Printer is not ready (equivalent to
"Intervention Required").
0×01プリンタは準備ができていません(「介入が必要」に同等な)。
0x02 An illegal 3270 buffer address or order
sequence was received (equivalent to
"Operation Check").
0×02 3270年の不法なバッファアドレスかオーダー系列を受け取りました(「動作チェック」に同等な)。
0x03 Printer is powered off or not connected
(equivalent to "Component Disconnected").
0×03プリンタは、動力付きである、または接続されていません(「コンポーネントは切断したこと」に同等な)。
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サーバはSNAの積極的なResponse UnitとしてのクライアントからホストアプリケーションまでPOSITIVE-RESPONSEを回すべきです。 それはSense Data IndicatorビットがオンであるSNAの否定的Response Unitへのクライアントからの以下のセンス・コードの1つを含むNEGATIVE-RESPONSEを翻訳するべきです:
RESPONSE-FLAG Equivalent SNA Sense Code
------------- ---------- --------------
0x00 Command Reject 0x10030000
応答旗の同等なSNAセンス・コード------------- ---------- -------------- 0×00 コマンド拒否0x10030000
0x01 Intervention Required 0x08020000
0×01 介入は0×08020000を必要としました。
0x02 Operation Check 0x10050000
0×02 動作チェック0x10050000
0x03 Component Disconnected 0x08310000
0×08310000であると切断された0×03コンポーネント
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サーバはDevice End Statusビットを設定するのによるクライアントからPOSITIVE-RESPONSEを回すべきです。 それはUnit Check Status Bitを設定するのによるクライアントからNEGATIVE-RESPONSEを反映するべきです、そして、Senseコマンドに応じるとき、Command Reject、Intervention Required、またはOperation Check Senseを設定するのは取り組みました。
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デバイスを表すかどうかに依存します。
Kelly Standards Track [Page 27] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[27ページ]。
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サーバは以下のセンス・コードの1つでSNA LUSTAT RUを送ることによって、ホストアプリケーションにERR-COND-CLEAREDを反映するべきです:
- if the previous error condition was an Intervention
Required, the server should send sense code 0x00010000
- 前のエラー条件がIntervention Requiredであるなら、サーバはセンス・コード0x00010000を送るでしょうに。
- if the previous error condition was Component
Disconnected, the server should send sense code 0x082B0000
- 前のエラー条件がComponent Disconnectedであるなら、サーバはセンス・コード0x082B0000を送るでしょうに。
A non-SNA server should set the corresponding bits in the Ending Status and Sense Condition bytes.
非SNAサーバはEnding StatusとSense Conditionバイトで対応するビットを設定するべきです。
10.5 The SYSREQ Function
10.5 SYSREQ機能
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
ヘッダーフィールドValue------------ ----- データ型SSCP Luデータ
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.)
ATTNキーがプロセスを終えるために十分でないときに、3270年のSYSREQキーはSNA環境で役に立つ場合があります。 (セクションが詳しい情報のために「3270年のATTNキー」の権利を与えられるのを見てください。)
10.5.1 Background
10.5.1 バックグラウンド
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、またはPrimary Logical Unit)とクライアントの代理をするTN3270Eサーバ(SLU、またはSecondary Logical Unit)とのセッションがあります。 これはPLU-SLUセッションと呼ばれます、そして、それは正常なコミュニケーションが流れるものです。 また、ホストテレコミュニケーションアクセス法(SSCP、またはSystem Services Control Point)と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
通常、端末のディスプレイとキーボードはPLU-SLUセッションで「所有されています」、送られるユーザがホストアプリケーションにタイプするどんなデータも意味して。 SYSREQキーは、PLU-SLUセッションとSSCP-LUセッションの間でキーボードとディスプレイの所有権を切り換えるのに使用されます。 言い換えれば、ユーザは、ホストSSCPと共にSYSREQを押して、次に、直接伝達できます。 そして、ユーザはいずれにも入るかもしれません。
Kelly Standards Track [Page 28] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[28ページ]。
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.
有効なUnformatted Systems Services(SLUに関連しているUSSテーブルで定義される)は命令します。 ユーザが使う中で最も一般的なUSSコマンドは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セッションまで元に戻ると決めるかもしれない“in"。
10.5.2 TN3270E Implementation of SYSREQ
10.5.2 SYSREQのTN3270E実装
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サーバはそれらがSSCPへのコマンドをUSSに送ることができない環境で作動します。 これで、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)コマンドはホストアプリケーションが本当のSNAセッションのときにユーザがいったんSYSREQキーを押すと実行するしかし、端末(ユーザがもう一度SYSREQを押さない場合)へのそれ以上の出力、ユーザのプロセスが、続けている発信から防がれるのでTN3270Eで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クライアントはSYSREQを3270に写像するとして主要な状態で特定されるキー(または、一組の鍵)を提供するべきです。 ユーザがこのキーを押すと、クライアントは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]、明確に権利を与えられたセクションで定義されるようにあるでしょう。
Kelly Standards Track [Page 29] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[29ページ]。
"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に送ることができるかどうかによります。 この能力を持っているサーバはUSSコマンドと応答をクライアントとSSCPの間に渡すための乗り物として単に機能するべきです。
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機能が同意されるなら、サーバはUNBINDに設定されたDATA-TYPE旗でデータメッセージをクライアントに送るでしょうに、そして、データ部は0×01にセットしました。
- 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以外の何かを伝えるなら、ストリングが「コマンド認識されていません、な」状態でサーバはクライアントに反応するべきです。 サーバはクライアントを代表してホストアプリケーションに何も送るべきではありません。
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接続をクライアントに「不-中断させるでしょう」、ホストアプリケーションがもう一度それでデータをクライアントに送ることができることを意味して。
11. The 3270 ATTN Key
11. 3270年のATTNキー
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 Interrupt Process(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クライアントは彼らのキー割当一覧の一部としてATTNを3270に主要な状態で写像するキーの単一のキーか組み合わせを提供するべきです。 ユーザがこのキーを押すと、クライアントは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
- TN3270Eサーバは、TN3270Eクライアントから受け取られたIPコマンドを適切なフォームに翻訳して、ATTNキーとしてホストアプリケーションにそれを回すべきです。 言い換えれば
Kelly Standards Track [Page 30] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[30ページ]。
server representing an SLU in an SNA session should send a
SIGNAL RU to the host application.
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環境で支えられません。 したがって、非SNA3270台のデバイスを表すTN3270Eサーバはそれがクライアントから受け取るどんなTelnet IPコマンドも無視するべきです。
12. 3270 Structured Fields
12. 3270は分野を構造化しました。
3270 structured fields provide a much wider range of features than "old-style" 3270 data, such as support for graphics, partitions and IPDS printer 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の構造化された分野が「古いスタイル」3270のデータよりはるかに広い範囲の特徴を提供します、グラフィックスのサポートや、パーティションやIPDSプリンタデータ・ストリームなどのように。すべての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".
Query Replyは、能力を強調しながら、また、拡張色のサポートなどの構造化された分野の使用を必要としないいくつかのデバイス能力を示すのに使用されて、広げられます。 ほとんどのホストアプリケーションが、デバイスが「拡張データ・ストリーム」をサポートするという何らかの指示があったとき、正確にデバイスの能力を決定するのにRead Partition Queryを使用するでしょう。
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"接尾語を含む端末の装置タイプを交渉するすべてのTN3270Eクライアント(ダイナミックな端末のタイプ、またはプリンタ装置タイプ)が、読書パーティション質問命令に応じることができなければなりません。 これらのクライアントがRead Partition Query(02をタイプする)とRead Partition Query Listのすべての用紙の両方を支えなければならないことに注意してください(03をタイプしてください)。
13. Implementation Guidelines
13. 実施要綱
13.1 3270 Data Stream Notes
13.1 3270 データ・ストリーム注意
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クライアントの作成者は、様々な3270ReadとWriteコマンドのためのコマンドコードにはサーバがどうホスト(ローカル、対リモートSNA対非SNA)に接されるかに依存する異価があることに注意するべきです。 クライアントは、様々な可能な値がないかどうかそれらが最も広い範囲のサーバと互換性がありたがっているかどうかチェックするためにコード化されるべきです。 [7] さらに詳しい明細については見てください。
Kelly Standards Track [Page 31] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[31ページ]。
13.2 Negotiation of the TN3270E Telnet Option
13.2 TN3270E telnetオプションの交渉
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 Optionであるので、クライアントとサーバの両方が、DO TN3270Eコマンドを送ることによってTN3270Eの交渉を開始するのを無料で試みることができます。 しかしながら、ちょうど通常、Telnet DO TERMINAL-TYPEに関してそうであるように通常、サーバがDO TN3270Eを送るものになると予期されて、クライアントはウィルかWON'T TN3270Eと共にこたえるでしょう。
13.3 A "Keep-alive" Mechanism
13.3 「生きている生活費」メカニズム
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.
生きている生活費メカニズムを提供する少なくとも3つの可能な手段がTN3270Eにあります: TCP Keepalive、Telnet IAC NOPコマンド[8]、およびTelnet DO TIMING-マークのオプション[9]。 各メソッドには、その利点と損失があります。 それがサポートするそのTN3270Eクライアントとサーバがすべての3つのメソッドをサポートするべきであるのがアリフを保って推薦されて、両側はいつもTIMING-MARKsにこたえるべきです。
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-マークかNOPを送るか、またはTCP Keepaliveを発行するかもしれません。 あるいはまた、ネットワーク管理者は、送る半面だけがアリフを保つのを構成したがっているかもしれません。 この場合、反対側は「受動」の関係者でしょう(単にそれが受ける生活費アリフに応じます)。
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.
生活費アリフが使用されているセッションの失敗では、双方は適切な通知をするべきです。 クライアントは失敗のいくつかのしるしをユーザに与えるべきです、スクリーンのOperator情報Areaのエラーコードのように。 サーバは、セッションが終えられたことをホストアプリケーションに通知するべきです、例えば、SNA環境でタイプCLEANUPでUNBINDを送ることによって。
13.4 Examples
13.4 例
The following example shows a TN3270E-capable server and a traditional tn3270 client establishing a connection:
以下の例は、TN3270Eできるサーバと伝統的なtn3270クライアントが取引関係を築くのを示します:
Kelly Standards Track [Page 32] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[32ページ]。
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はTN3270Eクライアントをします: IACがそうしない、TN3270Eサーバ: IACは端末のタイプクライアントをします: IACウィル端末のタイプサーバ: IAC SBの端末のタイプはIAC SEクライアントを送ります: IAC SBの端末のタイプはIBM-3278-2IAC SEサーバです: IACはEOR IACウィルEORクライアントをします: IACウィルEOR IACはEORサーバをします: IACは2進のIACウィルに2進のクライアントをします: IACウィルBINARY IACはバイナリーをします。(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はTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E装置タイプはIBM-3278-2IAC SEサーバを要求します: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2CONNECT anyterm IAC SE Client: 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はTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E DEVICE-TYPE REQUEST IBM3278-5E CONNECT myterm IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM3278-5E CONNECT myterm IAC SE Client: 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 resource-name and is returned a device-name chosen by the server:
以下の例は、TN3270EできるサーバとTN3270Eの有能なクライアントがクライアントがリソース名を要求して、サーバによって選ばれた装置名を返されるターミナルセションを設立するのを示します:
Kelly Standards Track [Page 33] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[33ページ]。
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はTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E DEVICE-TYPE REQUEST IBM3278-5E CONNECT pool1 IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM3278-5E CONNECT term0013 IAC SE Client: 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はTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5CONNECT myterm IAC SE Server: IAC SB TN3270E装置タイプは理由使用中のデバイスIAC SEクライアントを拒絶します: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2CONNECT herterm IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2CONNECT herterm IAC SE Client: 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はTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1CONNECT myprt IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1CONNECT myprt IAC SE Client: IAC SB TN3270E機能はデータストリームCTL IACサーバを要求します: IAC SB TN3270E機能はデータストリームCTL応答IAC SEクライアントを要求します: IAC SB TN3270E機能はデータストリームCTL IACサーバを要求します: IAC SB TN3270E機能はデータストリームCTL IAC SEです。
Kelly Standards Track [Page 34] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[34ページ]。
(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はTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-2CONNECT termxyz IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-2CONNECT termxyz IAC SE Client: IAC SB TN3270E機能は応答IAC SEサーバを要求します: IAC SB TN3270E FUNCTIONS IS RESPONSES IAC SE(3270年のデータ・ストリームを交換する)… (ユーザが、プリンタセッションを要求すると決めるので、クライアントは再びサーバ) サーバのTelnetポートに接続します: IACはTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1ASSOCIATE termxyz IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1CONNECT termxyzのもの-prt IAC SE Client: IAC SB TN3270E機能はSc CTLコード応答IAC SEサーバを要求します: IAC SB TN3270E機能はCTLがコード化するSc応答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
サーバ: IACはTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5CONNECT poolxyz IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5CONNECT terma IAC SE Client: IAC SB TN3270E機能は応答IAC SEを要求します。
Kelly Standards Track [Page 35] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[35ページ]。
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 SB TN3270E FUNCTIONS IS RESPONSES IAC SE(3270年のデータ・ストリームを交換する)… (ユーザが、プリンタセッションを要求すると決めるので、クライアントは再びサーバ) サーバのTelnetポートに接続します: IACはTN3270Eクライアントをします: IACウィルTN3270E Server: IAC SB TN3270Eは装置タイプIAC SEクライアントを送ります: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3287-1ASSOCIATE terma IAC SE Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3287-1CONNECT termaのもの-prt IAC SE Client: IAC SB TN3270E機能はSc CTLコード応答IAC SEサーバを要求します: IAC SB TN3270E機能はCTLがコード化するSc応答IAC SEです。(3270年のデータ・ストリームを交換します)
14. Security Considerations
14. セキュリティ問題
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つは与えられたユーザが特定の端末かプリンタ装置名を「使用すること」が許容されるべきであるかどうかに関する質問に答えるだろうことです。
15. References
15. 参照
[1] Rekhter, J., "Telnet 3270 Regime Option", RFC 1041, January 1988.
[1]Rekhter、J.、「telnet3270政権オプション」、RFC1041、1988年1月。
[2] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, February 1989.
[2]VanBokkelen、J.、「telnet端末のタイプオプション」、RFC1091、1989年2月。
[3] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD 27, RFC 856, May 1983.
[3] ポステル、J.、およびJ.レイノルズ、「telnetバイナリー送信」、STD27、RFC856は1983がそうするかもしれません。
[4] Postel, J., "Telnet End of Record Option", RFC 885, December 1983.
[4] ポステル、J.、「記録的なオプションのtelnet終わり」、RFC885、1983年12月。
[5] "3270 Information Display System - Data Stream Programmer's Reference", publication number GA24-0059, IBM Corporation.
[5] 「3270年の情報はシステムを表示します--データはプログラマの参照を流す」公表番号GA24-0059、IBM社。
[6] "SNA Formats", publication number GA27-3136, IBM Corporation.
[6]「SNA形式」、公表数のGA27-3136、IBM社。
Kelly Standards Track [Page 36] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[36ページ]。
[7] "3174 Establishment Controller Functional Description", publication number GA23-0218, IBM Corporation.
[7] 「3174年の設立のコントローラの機能的な記述」、公表数のGA23-0218、IBM社。
[8] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
[8] STD8、RFC854がそうするポステル、J.とJ.レイノルズ、「telnetプロトコル仕様」1983。
[9] Postel, J., and J. Reynolds, "Telnet Timing Mark Option", STD 31, RFC 860, May 1983.
[9] ポステル、J.、およびJ.レイノルズ、「telnetタイミング・マークオプション」、STD31、RFC860は1983がそうするかもしれません。
[10] J. Penner, "TN3270 Current Practices", RFC 1576, January, 1994.
[10] J.ペネル、「TN3270現在の実務」、RFC1576、1994年1月。
16. Author's Note
16. 著者注
Portions of this document were drawn from the following sources:
以下のソースからこのドキュメントの一部を得ました:
- A White Paper written by Owen Reddecliffe, WRQ Corporation,
October 1991.
- 1991年10月のオーエンReddecliffe、WRQ社によって書かれたホワイトPaper。
- Experimental work on the part of Cleve Graves and Michelle
Angel, OpenConnect Systems, 1992 - 1993.
- クリーブ・グラーブとミシェルAngel、OpenConnect Systems、1992--1993側の実験研究。
- Discussions at the 1993 IETF meetings.
- 1993年のIETFミーティングにおける議論。
- Discussions on the "TN3270E" list, 1993-94 and 1997.
- "TN3270E"リスト、1993-94、および1997についての議論。
17. Author's Address
17. 作者のアドレス
Bill Kelly
Division of University Computing
144 Parker Hall
Auburn University, AL 36849
ビルケリー大学師団Computing144レプホールオーバーン大学、AL 36849
Phone: (334) 844-4512
EMail: kellywh@mail.auburn.edu
以下に電話をしてください。 (334) 844-4512 メールしてください: kellywh@mail.auburn.edu
Kelly Standards Track [Page 37] RFC 2355 TN3270 Enhancements June 1998
ケリーStandardsはTN3270増進1998年6月にRFC2355を追跡します[37ページ]。
18. Full Copyright Statement
18. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Kelly Standards Track [Page 38]
ケリー標準化過程[38ページ]
一覧
スポンサーリンク
