RFC1921 日本語訳
1921 TNVIP Protocol. J. Dujonc. March 1996. (Format: TXT=57475 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Dujonc Request for Comments: 1921 Bull S.A. Category: Informational March 1996
Dujoncがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1921年の雄牛S.A.カテゴリ: 情報の1996年3月
TNVIP Protocol
TNVIPプロトコル
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The goal of this document specifies a Telnet profile to support VIP terminal emulation allowing the access to the BULL hosts applications through a TCP/IP network.
このドキュメントの目標は、TCP/IPネットワークを通してVIPターミナルエミュレーション許容がBULLホストアプリケーションへのアクセスであるとサポートするためにTelnetプロフィールを指定します。
Table of Contents
目次
1. Motivation . . . . . . . . . . . . . . . . . . . . . . 2
2. Background . . . . . . . . . . . . . . . . . . . . . . 3
3. Telnet Options and Commands Used . . . . . . . . . . . 3
3.1. Terminal type option . . . . . . . . . . . . . . . . 4
3.1.1. Subnegotiation of the Terminal Type . . . . . . . . 4
3.1.2. Terminal-types supported by the TNVIP protocol . . 4
3.1.3. TNVIP terminal models . . . . . . . . . . . . . . . 5
3.1.4. Mailbox name . . . . . . . . . . . . . . . . . . . 5
3.2. End of Record Option . . . . . . . . . . . . . . . . 6
3.3. Binary Transmission option . . . . . . . . . . . . . 6
3.4. Suppress Go Ahead option . . . . . . . . . . . . . . 7
4. TNVIP functions . . . . . . . . . . . . . . . . . . . 8
4.1. TNVIP terminal station . . . . . . . . . . . . . . . 9
4.1.1. Local and online states . . . . . . . . . . . . . . 9
4.1.2. Data receiving . . . . . . . . . . . . . . . . . 10
4.1.3. Data sending . . . . . . . . . . . . . . . . . . 10
4.2. TNVIP Server functions . . . . . . . . . . . . . . 10
4.2.1. VIP Terminal Manager . . . . . . . . . . . . . . 10
5. TNVIP Messages Format . . . . . . . . . . . . . . . 12
5.1. Address Field . . . . . . . . . . . . . . . . . . . 12
5.2. Command field . . . . . . . . . . . . . . . . . . . 13
5.3. Parameter field . . . . . . . . . . . . . . . . . . 14
6. The screen flow . . . . . . . . . . . . . . . . . . 14
6.1. Screen data messages . . . . . . . . . . . . . . . 14
6.2. Local state monitoring messages . . . . . . . . . . 15
6.3. Screen response messages . . . . . . . . . . . . . 16
6.3.1 Page overflow processing . . . . . . . . . . . . . 17
1. 動機. . . . . . . . . . . . . . . . . . . . . . 2 2。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . 3 3。 telnetオプションとコマンドは.33.1を使用しました。 端末のタイプオプション. . . . . . . . . . . . . . . . 4 3.1.1。 端末のタイプ. . . . . . . . 4 3.1.2のもののSubnegotiation。 TNVIPプロトコル. . 4 3.1.3でサポートされた端末のタイプ。 TNVIP端末モデル. . . . . . . . . . . . . . . 5 3.1.4。 メールボックス名. . . . . . . . . . . . . . . . . . . 5 3.2。 記録的なオプション. . . . . . . . . . . . . . . . 6 3.3の終わり。 2進のTransmissionオプション. . . . . . . . . . . . . 6 3.4。 Go Aheadオプション. . . . . . . . . . . . . . 7 4を抑圧してください。 TNVIPは.84.1に機能します。 TNVIP終着駅. . . . . . . . . . . . . . . 9 4.1.1。 地方の、そして、オンラインの州. . . . . . . . . . . . . . 9 4.1の.2。 データ受信. . . . . . . . . . . . . . . . . 10 4.1.3。 .104.2を送るデータ。 TNVIP Serverは.104.2に.1に機能します。 VIPターミナル・マネージャ. . . . . . . . . . . . . . 10 5。 TNVIPメッセージは.125.1をフォーマットします。 分野. . . . . . . . . . . . . . . . . . . 12 5.2を扱ってください。 分野. . . . . . . . . . . . . . . . . . . 13 5.3を命令してください。 パラメタ分野. . . . . . . . . . . . . . . . . . 14 6。 スクリーン流動. . . . . . . . . . . . . . . . . . 14 6.1。 データメッセージ. . . . . . . . . . . . . . . 14 6.2を上映してください。 メッセージ. . . . . . . . . . 15 6.3をモニターする地方の州。 スクリーン応答メッセージ. . . . . . . . . . . . . 16 6.3.1ページオーバーフロー処理. . . . . . . . . . . . . 17
Dujonc Informational [Page 1] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[1ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
6.4. Screen data purge indication message . . . . . . . 17
7. The printer flow . . . . . . . . . . . . . . . . . . 17
7.1. Printer data messages . . . . . . . . . . . . . . . 17
7.2. Printer response messages . . . . . . . . . . . . . 18
7.3. 7800 printer status management . . . . . . . . . . 19
7.4. Printer state request message . . . . . . . . . . 20
7.5. Printer state response messages . . . . . . . . . . 20
7.6. Printer purge indication message . . . . . . . . . 20
8. The Screen Copy Printing flow . . . . . . . . . . . 21
8.1. Screen copy request messages . . . . . . . . . . . 21
8.2. Screen copy data message . . . . . . . . . . . . . 21
8.3. Screen copy response messages . . . . . . . . . . . 22
8.4. Screen copy purge indication message . . . . . . . 23
9. The TM attention . . . . . . . . . . . . . . . . . . 23
10. The Break Key . . . . . . . . . . . . . . . . . . . 24
11. The Logout Key . . . . . . . . . . . . . . . . . . . 24
12. TNVIP messages list . . . . . . . . . . . . . . . . 24
12.1. Screen Flow . . . . . . . . . . . . . . . . . . . . 24
12.2. Printer flow . . . . . . . . . . . . . . . . . . . 26
12.3. Screen Copy Printing messages flow . . . . . . . . 28
13. Security Considerations . . . . . . . . . . . . . . 29
14. References . . . . . . . . . . . . . . . . . . . . . 30
15. Author's Address . . . . . . . . . . . . . . . . . . 30
6.4. データパージ指示メッセージ. . . . . . . 17 7を上映してください。 プリンタ流動. . . . . . . . . . . . . . . . . . 17 7.1。 プリンタデータメッセージ. . . . . . . . . . . . . . . 17 7.2。 プリンタ応答メッセージ. . . . . . . . . . . . . 18 7.3。 7800 プリンタ状態管理. . . . . . . . . . 19 7.4。 プリンタ州の要求メッセージ. . . . . . . . . . 20 7.5。 プリンタ州の応答メッセージ. . . . . . . . . . 20 7.6。 プリンタパージ指示メッセージ. . . . . . . . . 20 8。 Screen Copy Printingは.218.1に流れます。 コピー要求メッセージ. . . . . . . . . . . 21 8.2を上映してください。 コピーデータメッセージ. . . . . . . . . . . . . 21 8.3を上映してください。 コピー応答メッセージ. . . . . . . . . . . 22 8.4を上映してください。 コピーパージ指示メッセージ. . . . . . . 23 9を上映してください。 TM注意. . . . . . . . . . . . . . . . . . 23 10。 中断キー. . . . . . . . . . . . . . . . . . . 24 11。 主要な状態で、.24 12にログアウトしてください。 TNVIPメッセージは.24 12.1を記載します。 流れ. . . . . . . . . . . . . . . . . . . . 24 12.2を上映してください。 プリンタ流動. . . . . . . . . . . . . . . . . . . 26 12.3。 スクリーンCopy Printingメッセージは.28 13に流れます。 セキュリティ問題. . . . . . . . . . . . . . 29 14。 参照. . . . . . . . . . . . . . . . . . . . . 30 15。 作者のアドレス. . . . . . . . . . . . . . . . . . 30
1. Motivation
1. 動機
P200 [7] and 7800 [8] VIP (Visual Information Projection) terminals differ mainly from NVT terminals [1] in that they work in block mode and have the capability to manage an associated printer. Generally in a DSA (Distributed Systems Architecture) network they are managed through the VIP transmission line procedure (character oriented). That is the reason why they are generically referred as VIP terminals.
P200[7]と7800台の[8]VIP(視覚情報Projection)端末が[1] ブロックモードで働いていて、関連プリンタを管理する能力を持っているという点において主にNVT端末と異なっています。 一般に、DSA(分配されたSystems Architecture)ネットワークでは、VIP伝送路手順(適応するキャラクタ)でそれらは管理されます。 それはそれらがVIP端末として一般的に参照される理由です。
This document specifies the options to be modified successfully, to pass from the NVT terminal emulation supported on a Telnet connection, to a VIP terminal emulation. It defines also the format of the messages exchanged between the server and the client when the TNVIP protocol is successfully negotiated.
このドキュメントはTelnet接続のときにサポートされたNVTターミナルエミュレーションから変化するように首尾よく変更されるためにオプションを指定します、VIPターミナルエミュレーションに。 また、それはTNVIPプロトコルが首尾よく交渉されるときサーバとクライアントの間で交換されたメッセージの書式を定義します。
Dujonc Informational [Page 2] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[2ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
2. Background
2. バックグラウンド
VIP terminal family includes a broad range of different terminal types. They work in block mode with an ASCII or 8 binary bits set of characters.
VIP端末ファミリーは広範囲な異なった端末のタイプを入れます。 彼らはビットが設定するキャラクタのASCIIか8バイナリーでブロックモードで働いています。
The Bull terminals in the DSA network environment use the services of a Terminal Manager (TM) [2]. It is generally installed in a communication processor (as a Datanet or Mainway system) where it assures the connection with the BULL host application generally through a DSA session.
DSAネットワーク環境におけるBull端末はTerminalマネージャ(TM)[2]のサービスを利用します。 一般に、それは一般にDSAセッションによるBULLホストアプリケーションとの関係を保証する通信プロセッサ(DatanetかMainwayシステムとしての)にインストールされます。
The Terminal Manager is in charge to present the terminal station and to manage the session connection to the host computer. It offers generally a possibility of dialog with the terminal to allow the user to modify the connection parameters, to manage the session (connection request, abort, etc ..). The set of commands and responses used is called "TM Local Dialog".
Terminalマネージャは、終着駅を提示して、セッション接続をホストコンピュータに管理するために担当しています。 それは、セッション(接続要求、アボートなど)を管理するためにユーザが端末がある対話で接続パラメタを変更できる一般に可能性を提供します。 コマンドと使用される応答のセットは「TMのローカルの対話」と呼ばれます。
3. Telnet Options and Commands Used
3. オプションとコマンドが使用したtelnet
The mandatory telnet parameters to be negotiated successfully between the "TNVIP server" and the "TNVIP client" are :
「TNVIPサーバ」と「TNVIPクライアント」の間で首尾よく交渉されるべき義務的なtelnetパラメタは以下の通りです。
- the Terminal-Type option [3] to define a VIP terminal model and
if necessary a Mailbox name to request a specific access point in
the "TNVIP server",
- 「TNVIPサーバ」の特定のアクセスポイントを要求するためにVIP端末モデルと必要ならMailbox名を定義するTerminal-タイプオプション[3]
- the End Of Record option [4] to delimit the TNVIP message at the
Telnet level. As the End Of Record (EOR) code indicates the end of
an effective data unit, Telnet should attempt to send the data up
to and including the EOR code together to promote communication
efficiency.
- TelnetレベルでTNVIPメッセージを区切るEnd Of Recordオプション[4]。 End Of Record(EOR)コードが有効なデータ単位の終わりを示すとき、Telnetは、コミュニケーション効率を促進するためにEORコードを含めてデータを一緒に送るのを試みるはずです。
Others Telnet parameters, can be optionally negotiated as :
以下として交渉されて、他のものTelnetパラメタは任意にそうであることができます。
- the Binary Transmission option [5], when the terminal emulation
uses a 8 binary bits set of characters,
- ターミナルエミュレーションが8の2進のビットキャラクタを使用するときのBinary Transmissionオプション[5]
- the Suppress Go Ahead option [6], when no synchronisation of the
data transmission from the "TNVIP client" with the DSA session
turn or the ISO session token is needed.
- DSAセッション回転との「TNVIPクライアント」からのデータ伝送の連動でないことのSuppress Go Aheadオプション[6]かISOセッショントークンが必要です。
When the two parties (the "TNVIP server" and the "TNVIP client") have negotiated successfully a TNVIP terminal type and the EOR telnet option, that means they agree to respect the TNVIP protocol (the TNVIP message format and the exchange rules).
2回のパーティー(「TNVIPサーバ」と「TNVIPクライアント」)が首尾よくTNVIPの端末のタイプとEOR telnetオプションを交渉したとき、それは、彼らが、TNVIPプロトコル(TNVIPメッセージ・フォーマットと交換規則)を尊敬するのに同意することを意味します。
Dujonc Informational [Page 3] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[3ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
3.1 Terminal type option
3.1 端末のタイプオプション
IAC DO TERMINAL-TYPE
IACは端末でタイプします。
Sender (the "TNVIP server" party) is willing to receive terminal
type information in a subsequent sub-negotiation.
送付者(「TNVIPサーバ」パーティー)は、その後のサブ交渉における端末のタイプ情報を受け取っても構わないと思っています。
IAC WILL TERMINAL-TYPE
IACは端末でタイプするでしょう。
Sender (the terminal "TNVIP client" party) is willing to send
terminal-type information in a subsequent sub-negotiation.
送付者(端末の「TNVIPクライアント」パーティー)は、その後のサブ交渉における端末のタイプ情報を送っても構わないと思っています。
3.1.1 Subnegotiation of the Terminal Type
3.1.1 端末のタイプのSubnegotiation
IAC SB TERMINAL-TYPE SEND IAC SE
IAC SBの端末のタイプはIAC SEを送ります。
Sender (the "TNVIP server" party) requests the receiver to
transmit his next terminal-type, and switch emulation modes (if
more than one terminal type is supported).
送付者(「TNVIPサーバ」パーティー)は、彼の次の端末のタイプ、およびスイッチエミュレーション・モードを伝えるよう受信機に要求します(1台以上の端末のタイプがサポートされるなら)。
IAC SB TERMINAL-TYPE IS tnvip-terminal-model@MB-name IAC SE
IAC SBの端末のタイプは tnvip-terminal-model@MB-name IAC SEです。
Sender (the terminal "TNVIP client" party) is stating the name of
his current (or only) terminal-type. Optionally, a mailbox name
can be added to request a particular access point in the "TNVIP
server". By default, the "TNVIP server" uses a generic access
point.
送付者(端末の「TNVIPクライアント」パーティー)は彼の現在(単に)の端末のタイプの名前を述べています。 任意に、「TNVIPサーバ」の特定のアクセスポイントを要求するためにメールボックス名を加えることができます。 デフォルトで、「TNVIPサーバ」はジェネリックアクセスポイントを使用します。
3.1.2 Terminal-types supported by the TNVIP protocol
3.1.2 TNVIPプロトコルによってサポートされた端末のタイプ
The TNVIP terminal type string given at the Telnet negotiation is formatted as follows :
Telnet交渉のときに与えられたTNVIPの端末のタイプストリングは以下の通りフォーマットされます:
<TNVIP-terminal-model> [ <@ character> <Mailbox-name> ]
<TNVIP-端末モデル>。[<@キャラクタ><Mailbox-名の>]
The @ character is used as separator between the VIP-terminal-model and the Mailbox-name.
@キャラクタはVIP端末モデルとMailbox-名前の間の分離符として使用されます。
Dujonc Informational [Page 4] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[4ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
3.1.3 TNVIP terminal models
3.1.3 TNVIP端末モデル
The valid TNVIP terminal models are the following ASCII character strings. (The table gives for each terminal model string the hexadecimal number indicating the associated DSA model number defined in the DSA terminal presentation protocols ).
有効なTNVIP端末モデルは以下のASCII文字列です。 (テーブルはそれぞれの端末モデルストリングのためにDSAの端末のプレゼンテーションプロトコルで定義された関連DSA型番を示す16進数を与えます。)
P200 family 7800 family
-------------------------------- --------------------------------
! TNVIP model ! DSA code ! ! TNVIP model ! DSA code !
-------------------------------- --------------------------------
! VIP7700 ! 33 ! ! VIP7804 ! 3E !
! VIP7760 ! 3A ! ! VIP7804V ! 4A !
! DKU7005 ! 3D ! ! VIP7814 ! 47 !
! DKU7007D ! 40 ! ! HDS7 ! 4D !
! DKU7105 ! 41 ! ! VIP8800 ! 4F !
! DKU7107D ! 42 ! --------------------------------
! DKU7211 ! 45 !
! DKU7211D ! 4E !
--------------------------------
P200ファミリー7800ファミリー-------------------------------- -------------------------------- ! TNVIPモデル!DSAコード!TNVIPはDSAコードをモデル化します!-------------------------------- -------------------------------- ! VIP7700 33!!VIP7804 3!E!VIP7760!3A!VIP7804V!4A!DKU7005!3D!VIP7814 47!!DKU7007D40!!HDS7!4D!DKU7105 41!!VIP8800 4!F!DKU7107D42!-------------------------------- ! DKU7211 45!!DKU7211D!4E!--------------------------------
The D character at the end of the string indicates that the terminal supports the Remote Forms function [9]. It is the capability to store forms in the terminal allowing the host application to display a form stored in the terminal sending a short length command without sending all the data of the form. This function is usually supported by the terminal concentrators.
ストリングの端のDキャラクタは、端末が、Remote Formsが機能[9]であるとサポートするのを示します。 それはホストアプリケーションがフォームに関するすべてのデータを送るというわけではなくて短い長さのコマンドを送りながら端末に保存された書式を表示するのを許容しながら端末にフォームを保存する能力です。 通常、この機能は端末の集中装置によってサポートされます。
3.1.4 Mailbox name
3.1.4 メールボックス名
The mailbox name allows the "TNVIP client" to request a specialized access point referenced by this name in the "TNVIP server". It is an ASCII character string. Its presence in the Telnet terminal type string is optional. When not present, a generic (default) access can be provided by the "TNVIP server".
メールボックス名で、「TNVIPクライアント」は「TNVIPサーバ」のこの名前によって参照をつけられる専門化しているアクセスポイントを要求できます。 それはASCII文字列です。 Telnetの端末のタイプストリングでの存在は任意です。 存在していないとき、「TNVIPサーバ」はジェネリック(デフォルト)アクセスを提供できます。
When the "TNVIP server" is a gateway to DSA hosts, the mailbox name defines the DSA session access point of the terminal in the server. Its length is limited to 12 characters. Lower case characters are allowed but are processed as upper case. This string is generally used to identify a specific terminal station (having a printer for example) or to use a particular declaration of this terminal in the "TNVIP server".
「TNVIPサーバ」がDSAホストへのゲートウェイであるときに、メールボックス名はサーバで端末のDSAセッションアクセスポイントを定義します。長さは12のキャラクタに制限されます。 小文字キャラクタは、許容されていますが、大文字として処理されます。 一般に、このストリングは特定の終着駅(例えばプリンタを持っている)を特定するか、または「TNVIPサーバ」における、この端末の特定の宣言を使用するのにおいて使用されています。
Dujonc Informational [Page 5] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[5ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
3.2 End of Record Option
3.2記録的なオプションの終わり
VIP device communications are block oriented. That is, each partner buffers data until an entire "message" has been built, at which point the data are sent to the other side. The end of a message is understood to be the last byte transmitted. The Telnet EOR command is used to delimit these natural blocks of TNVIP data within the Telnet data stream. An <EOR> is sent at the end of each TNVIP message, in both directions.
VIPデバイスコミュニケーションはブロック指向しています。 全体の「メッセージ」(データは指す)が建てられるまで、すなわちそれぞれのパートナーバッファデータを反対側に送ります。 メッセージの終わりは伝えられた最後のバイトであることが理解されています。 Telnet EORコマンドは、Telnetデータ・ストリームの中でこれらの自然なブロックのTNVIPデータを区切るのに使用されます。 両方の方向によるそれぞれのTNVIPメッセージの終わりに<EOR>を送ります。
IAC WILL END-OF-RECORD
記録のIACウィルエンド
The sender of this command requests permission to begin
transmission of the Telnet END-OF-RECORD (EOR) code when
transmitting data characters, or the sender of this command
confirms it will now begin transmission of EORs with transmitted
data characters.
データキャラクタを伝えるときのTelnet END-OF-RECORD(EOR)コードの送信、またはこのコマンドの送付者を始めるこのコマンド要求許可の送付者は、現在伝えられたデータキャラクタとのEORの送信を始めると確認します。
IAC DO END-OF-RECORD
IACは記録を終わらせます。
The sender of this command requests that the sender of data starts
transmitting the EOR code when transmitting data, or the sender of
this command confirms that the sender of data is expected to
transmit EORs.
データを送るとき、このコマンドの送付者が、データの送付者がEORコードを伝え始めるよう要求するか、またはこのコマンドの送付者は、データの送付者がEORを伝えると予想されると確認します。
3.3 Binary Transmission option
3.3 2進のTransmissionオプション
According to the character set used by the emulation, the "TNVIP client" and the "TNVIP server" can be led to negotiate the Telnet binary transmission option.
エミュレーションで使用される文字集合によると、「TNVIPクライアント」と「TNVIPサーバ」がTelnetの2進のトランスミッションオプションを交渉するように導くことができます。
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データ・バイトとして扱われるでしょうが。
IAC DO TRANSMIT-BINARY
IACはバイナリーを伝えてします。
Sender requests that sender of the data starts transmitting or
confirms that the sender of data is expected to transmit
characters that are to be interpreted as 8 bits of binary data by
the receiver.
送付者は、データの送付者が伝わり始めるよう要求するか、またはデータの送付者がバイナリ・データの8ビットとして受信機によって解釈されることになっているキャラクタを伝えると予想されると確認します。
IAC WILL TRANSMIT-BINARY
IACウィル、バイナリーを伝えます。
Sender requests permission to begin transmitting, or confirms it
will now begin transmitting binary data.
送付者は、伝わり始める許可を要求するか、または現在バイナリ・データを伝え始めると確認します。
Dujonc Informational [Page 6] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[6ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
IAC WON'T TRANSMIT-BINARY
IACが伝えない、バイナリーを伝えます。
If the connection is already being operated in binary transmission
mode, the sender of this command demands to begin transmitting
data characters which are to be interpreted as standard NVT ASCII
characters by the receiver of the data. If the connection is not
already being operated in binary transmission mode, the sender of
this command refuses to begin transmitting characters which are to
be interpreted as binary characters by the receiver of the data
(i.e., the sender of the data requests to continue transmitting
characters in its present mode).
接続が2進の転送方式で既に手術されているなら、このコマンドの送付者は、標準のNVT ASCII文字としてデータの受信機によって解釈されることになっているデータキャラクタを伝え始めるのを要求します。 接続が2進の転送方式で既に手術されていないなら、このコマンドの送付者は、データ(すなわち、現在のモードでキャラクタを伝え続けているというデータ要求の送付者)の受信機で2進のキャラクタとして解釈されることになっているキャラクタを伝え始めるのを拒否します。
IAC DON'T TRANSMIT-BINARY
IACはバイナリーを伝えてしません。
If the connection is already being operated in binary transmission
mode, the sender of this command requests that the sender of the
data start transmitting characters which are to be interpreted as
standard NVT ASCII characters by the receiver of the data
(i.e.,the party sending this command). If the connection is not
already being operated in binary transmission mode, the sender of
this command requests that the sender of data continue
transmitting characters which are to be interpreted in the present
mode.
接続が2進の転送方式で既に手術されているなら、このコマンドの送付者は、データの送付者がデータ(すなわち、このコマンドを送るパーティー)の受信機で標準のNVT ASCII文字として解釈されることになっているキャラクタを伝え始めるよう要求します。 接続が2進の転送方式で既に手術されていないなら、このコマンドの送付者は、データの送付者が、現在のモードで解釈されることになっているキャラクタを伝え続けているよう要求します。
3.4 Suppress Go Ahead option
3.4はGo Aheadオプションを抑圧します。
The "TNVIP client" can use the receiving of the Telnet GoAhead command as the signal allowing the terminal operator to transmit data. That can allow the synchronisation between the data transmitted from the terminal and the DSA "turn".
「TNVIPクライアント」は端末オペレータがデータを送ることができる信号としてTelnet GoAheadコマンドの受信を使用できます。 それは端末から送られたデータの間の連動を許容できます、そして、DSAは「ターンします」。
When the Suppress Go Ahead option is not negotiated, the "TNVIP server" must send the Telnet Go Ahead command (GA) when its input message queue (from the "TNVIP client") is empty and the DSA turn is at the terminal side, to invite the terminal to transmit some data.
Suppress Go Aheadオプションが交渉されないとき、それがいくつかのデータを送るために、待ち行列(「TNVIPクライアント」からの)が空であり、端末を招待するためにDSA回転が終線にあるというメッセージを入力したとき、「TNVIPサーバ」はTelnet Go Aheadコマンド(ジョージア)を送らなければなりません。
To suppress this mechanism, the "TNVIP client" can request the no sending of the Telnet GoAhead commands by the "TNVIP server", negotiating the Suppress GO Ahead option of the Telnet Protocol.
このメカニズムを抑圧するために、「TNVIPクライアント」は、Telnet GoAheadについて発信していないのが「TNVIPサーバ」で命令するよう要求できます、テルネット・プロトコルのSuppress GO Aheadオプションを交渉して。
In this case, the terminal transmission to the "TNVIP server" is synchronised on the transport credit.
この場合、「TNVIPサーバ」への端末トランスミッションはそうです。輸送クレジットでは、連動しました。
Note: The Telnet GA command never need to be sent by the "TNVIP
client" even if the telnet Suppress Go Ahead has not been
negotiated.
以下に注意してください。 ジョージアがtelnet Suppress Go Aheadが交渉されていなくても「TNVIPクライアント」によって送られるのが決して必要でないと命令するTelnet。
Dujonc Informational [Page 7] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[7ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
IAC DO SUPPRESS-GO-AHEAD
IACは開始許可を抑圧してします。
The sender of this command (the "TNVIP client" party) requests that the sender of data starts suppressing GA when transmitting data.
このコマンド(「TNVIPクライアント」パーティー)の送付者は、データを送るとき、データの送付者がジョージアを抑圧し始めるよう要求します。
IAC WILL SUPPRESS-GO-AHEAD
IACウィル、開始許可を抑圧します。
The sender of this command (the "TNVIP server" party) confirms it
will now begin suppressing transmission of GAs with transmitted
data characters.
このコマンド(「TNVIPサーバ」パーティー)の送付者は、現在伝えられたデータキャラクタとのGAsのトランスミッションを抑圧し始めると確認します。
IAC DON'T SUPPRESSS-GO-AHEAD
IACはSUPPRESSS進行命令でしません。
The sender of this command (the "TNVIP client" party) requests
that the receiver of the command start transmitting GAs when
transmitting data.
このコマンド(「TNVIPクライアント」パーティー)の送付者は、データを送るとき、コマンドの受信機がGAsを伝え始めるよう要求します。
IAC WON'T SUPPRESS-GO-AHEAD
IACが抑圧しない、開始許可を抑圧します。
The sender of this command (the "TNVIP server" party) confirms it
will now begin transmitting the GA character when transmitting
data characters.
このコマンド(「TNVIPサーバ」パーティー)の送付者は、現在データキャラクタを伝えるとき、ジョージアキャラクタを伝え始めると確認します。
4. TNVIP functions
4. TNVIP機能
The TNVIP protocol allows the following functions :
TNVIPプロトコルは以下の機能を許容します:
- Support of a VIP terminal emulation addressing the screen and its
associated printer .
- スクリーンとその関連プリンタを扱うVIPターミナルエミュレーションのサポート。
- Selection of the terminal type model at the connection time.
- 接続時間の端末のタイプモデルの選択。
- Specific or generic access to the "TNVIP server" by referencing or
not a Mailbox name.
- Mailbox名ではなく、参照をつけるのによる「TNVIPサーバ」への特定であるかジェネリックアクセス。
- TNVIP protocol independent of the terminal data presentation
protocol (7800 or P200).
- TNVIPは端末のデータの表現プロトコル(7800かP200)の如何にかかわらず議定書を作ります。
- Support of the DSA End To End Acknowledgement.
- 承認を終わらせるDSAエンドのサポート。
- Support of the DSA Terminal Manager local attention.
- DSA Terminalのマネージャの地方の注意のサポート。
- Support of the DSA turn to the terminal side.
- 終線へのDSA回転のサポート。
- Support of the DSA secret read.
- DSA秘密のサポートは読みました。
- Control of the hard copy.
- ハードコピーのコントロール。
Dujonc Informational [Page 8] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[8ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
4.1 TNVIP terminal station
4.1 TNVIP終着駅
The "TNVIP client" acts as the interface adapter between the TNVIP connection and an application program. The "TNVIP client" is mainly defined to support a VIP terminal emulation program but can be used by other else program using the TNVIP protocol.
「TNVIPクライアント」はTNVIP接続とアプリケーション・プログラムの間のインタフェースアダプターとして機能します。 「TNVIPクライアント」をVIPターミナルエミュレーションプログラムをサポートするために主に定義されますが、TNVIPプロトコルを使用しながら、他のほかのプログラムで使用できます。
A VIP terminal emulation manages:
VIPターミナルエミュレーションは管理されます:
- a screen buffer,
- スクリーンバッファ
- a printer buffer if it supports the associated printer,
- プリンタバッファはそれであるなら関連プリンタを支えます。
- the interface with the communication line
- 通信回線とのインタフェース
and runs using the following rules:
以下の規則を使用する走行:
When the VIP terminal emulation exchanges a message on the communication line, it is in the BUSY state until the end of the message exchange. That means when the VIP terminal is sending a message it can't receive and when it is receiving a message it can't send.
VIPターミナルエミュレーションがメッセージを通信回線と交換するとき、交換処理の終わりまでそれはBUSY状態にあります。 それは、VIP端末がいつそれが受け取ることができないメッセージを送るか、そして、それがいつ送ることができないメッセージを受け取っているかを意味します。
Note: If a VIP terminal works in the half duplex mode, as the TNVIP
protocol uses a Telnet connection it allows a full duplex
mode processing.
以下に注意してください。 VIP端末がハーフデュプレックスモードで働いているなら、TNVIPプロトコルがTelnet接続を使用するとき、それは全二重モード処理を許します。
4.1.1 Local and online states
4.1.1 地方の、そして、オンラインの州
The VIP terminal has the capability to switch between these two states. The LOCAL state is generally used to process local terminal tests or to modify the configuration. In this state, the data coming from the line are ignored.
VIP端末には、これらの2つの州を切り換える能力があります。 一般に、LOCAL状態は、ローカル・ターミナルテストを処理するか、または構成を変更するのに使用されます。 この状態では、系列から来るデータは無視されます。
The LOCAL state allows the "TNVIP client" to request to the server the screen and printer data flows to be suspended.
LOCAL州で、「TNVIPクライアント」は、中断するためにスクリーンとプリンタデータフローをサーバに要求できます。
The ONLINE state indication allows the "TNVIP server" to resume the screen and printer flows.
ONLINE州の指示で、「TNVIPサーバ」はスクリーンとプリンタ流れを再開できます。
For these reasons the TNVIP protocol differentiates the screen and printer flows from the screen copy printing flow and defines to report the two states to the "TNVIP server".
これらの理由で、TNVIPプロトコルは、スクリーンコピー印刷流動とスクリーンとプリンタ流れを区別して、「TNVIPサーバ」への2つの州をレポートと定義します。
Dujonc Informational [Page 9] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[9ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
4.1.2 Data receiving
4.1.2 データ受信
When a VIP terminal emulation receives a data message from the line, according to the address given in the header message,it sends data to the screen buffer or to the printer buffer.
ヘッダーメッセージで与えられたアドレスに応じてVIPターミナルエミュレーションが系列からデータメッセージを受け取るとき、それはスクリーンバッファ、または、プリンタバッファにデータを送ります。
A message received at the screen or printer address is deleted and ignored if the terminal emulation is in the LOCAL state and a BUSY status is returned.
ターミナルエミュレーションがLOCAL状態にあって、BUSY状態が返されるなら、スクリーンかプリンタアドレスに受け取られたメッセージは、削除されて、無視されます。
The printer buffer is busy when the terminal is transmitting the data from the printer buffer to the printer device. A data message for the printer is deleted and ignored if the terminal is in the printing state and a BUSY status is returned.
プリンタバッファは、端末であるならデータを送っていることでプリンタバッファからプリンタデバイスまで忙しいです。 端末が印刷状態にあって、BUSY状態が返されるなら、プリンタへのデータメッセージは、削除されて、無視されます。
When a BUSY state is encountered, the "TNVIP client" according to the type of message received (request or indication) reports or not the BUSY acknowledgement to the "TNVIP server".
BUSY状態が遭遇するとき、「TNVIPサーバ」へのBUSY承認ではなく、メッセージのタイプに従った「TNVIPクライアント」レポートします受け取られていている(要求か指示)。
4.1.3 Data sending
4.1.3 データ発信
A VIP terminal emulation can send message even if the terminal is in the LOCAL state.
端末がLOCAL状態にあっても、VIPターミナルエミュレーションはメッセージを送ることができます。
4.2 TNVIP Server functions
4.2 TNVIP Server機能
4.2.1 VIP Terminal Manager
4.2.1 VIPターミナル・マネージャ
Its function is to act as a gateway between the VIP terminal and the VIP application. Generally the application is a remote DSA application.
機能はVIP端末とVIPアプリケーションの間のゲートウェイとして機能することです。 一般にアプリケーションはリモートDSAアプリケーションです。
It manages the screen and printer devices of the VIP terminal station.
それはVIP終着駅のスクリーンとプリンタデバイスを管理します。
Dujonc Informational [Page 10] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[10ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
In the following example figure, the "TNVIP server" is a DSA server and manages three VIP terminal units TU1, TU2 and TU3.
以下の例の図では、「TNVIPサーバ」は、DSAサーバであり、TU1、TU2、およびTU3を3つのVIP端末装置管理します。
Generic access
--------------
!----> LD 1S ----> DV 1S (screen) ---->!
MB 1 --> SN 1 TU 1
!----> LD 1P ----> DV 1P (printer) ---->!
ジェネリックアクセス-------------- !---->LD片面単密度---->DV片面単密度(スクリーン)---->! MB1-->SN1トゥ1!---->LD 1P---->DV 1P(プリンタ)---->!
Specific accesses
-----------------
!----> LD 2S ----> DV 2S (screen) ---->TU 2
MB 2 --> SN 2
!----> LD 2P ----> !
!
!----> LD 3P ----> DV 3S (printer) ---->!
MB 3 --> SN 3 TU 3
!----> LD 3S ----> DV 3P (screen) ---->!
特定のアクセス----------------- !---->LD2S---->DV2S(スクリーン)---->トゥ2MB2-->SN2!---->LD 2P---->!---->LD 3P---->DV3S(プリンタ)---->! MB3-->SN3トゥ3!---->LD3S---->DV 3P(スクリーン)---->!
Each Terminal Unit (TU object) is declared as containing one or two devices (DV objects). The Terminal Manager maps this physical representation to a logical representation where the station (SN object) is the logical representation of a terminal unit, and the logical device (LD) object a logical representation of the real device.
各Terminal Unit(TUは反対する)は1か2台のデバイス(DVオブジェクト)を含むとして申告されます。 Terminalマネージャはステーション(SNは反対する)が端末装置の論理的な表現であり、論理的なデバイス(LD)オブジェクトが実際のデバイスの論理的な表現である論理的な表現にこの具現を写像します。
- TU1 will be chosen by default on generic request (without mailbox
name) or by the MB1 name addressing on specific request. It can
manage the associated printer device.
- TU1はデフォルトでジェネリック要求(メールボックス名のない)か扱うという特定の要求でのMB1名によって選ばれるでしょう。 それは関連プリンタデバイスに対処できます。
- MB2 will be addressed to access the TU2 terminal unit. TU2 is
defined in a specific way because it will be presented to the host
application as a station composed of a screen (the TU2 one's) and
a printer (the TU3 one's).
- MB2は、TU2端末装置にアクセスするために扱われるでしょう。 ステーションがスクリーンで構成されたのでそれがホストアプリケーションに提示されるのでTU2が特定の方法で定義される、(TU2、人のもの)、プリンタ、(TU3、人のもの)
- MB3 will be addressed to access TU3 terminal unit. TU3 is also
defined in a specific way because the printer device is shared by
several logical stations (SN2 and SN3) and must be well
identified.
- MB3は、TU3端末装置にアクセスするために扱われるでしょう。 TU3をまた、プリンタデバイスがいくつかの論理的なステーション(SN2とSN3)によって共有されるので特定の方法で定義されて、よく特定しなければなりません。
Dujonc Informational [Page 11] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[11ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
5. TNVIP Messages Format
5. TNVIPメッセージ形式
Each TNVIP message is delimited by the Telnet EOR command.
それぞれのTNVIPメッセージはTelnet EORコマンドで区切られます。
Therefore, a TNVIP message has the following format:
したがって、TNVIPメッセージには、以下の形式があります:
<TNVIP Header> <parameters> <IAC EOR>
<TNVIPヘッダー><パラメタ><IAC EOR>。
The TNVIP header is mandatory and have a fixed length of two bytes.
TNVIPヘッダーは、義務的であり、2バイトの固定長さに義務的でした。
Some TNVIP messages need no parameter. In this case, the TNVIP message has the following construction:
いくつかのTNVIPメッセージはパラメタを全く必要としません。 この場合、TNVIPメッセージには、以下の工事があります:
<TNVIP Header> <IAC EOR>
<TNVIPヘッダー><IAC EOR>。
It is strongly recommended that Telnet commands (other than IAC IAC) should be sent between TNVIP messages, with no TNVIP header and no trailing IAC EOR. If a TNVIP 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 TNVIP message, or the processing may be deferred until after the current TNVIP message has been processed. It is because of this ambiguity that the presence of Telnet commands within a TNVIP message is not recommended; neither "TNVIP client"s nor "TNVIP server"s should send such data.
Telnetコマンド(IAC IACを除いた)がTNVIPメッセージの間に送られるべきであることが強く勧められます、TNVIPヘッダーと少しもいいえがIAC EORを引きずっていない状態で。 IAC-コマンド・シーケンスが処理されますが、それを処理しなければならないとき、いかなる他のIACコマンド・シーケンス(IAC IACを除いた)も含むTNVIPデータメッセージが受信されているなら、実装に依存しています。 受信機はすぐに、それを処理するかもしれません(事実上、まるで現在のTNVIPメッセージの前にそれを受け取ったか、または現在のTNVIPメッセージを処理してある後まで処理を延期するかもしれないかのようにそれを処理させます)。 このあいまいさのために、TNVIPメッセージの中のTelnetコマンドの存在は推薦されません。 「TNVIPクライアント」sも「TNVIPサーバ」sもそのようなデータを送るべきではありません。
The TNVIP header contains 2 bytes. The first one indicates the address <ADR> and the second the command <CDE>.
TNVIPヘッダーは2バイトを含んでいます。 最初の人はアドレス<ADR>を示します、そして、2番目はコマンド<CDE>を示します。
5.1 Address Field
5.1 アドレス・フィールド
The <ADR> address field is mandatory and is defined on one byte.
<ADR>アドレス・フィールドは、義務的であり、1バイトで定義されます。
The TNVIP protocol defines 3 addresses:
TNVIPプロトコルは3つのアドレスを定義します:
- ADR = SCREEN = 96 (0x60) for the screen commands flow,
- スクリーンのためのSCREEN ADR==96(0×60)は流れを命令します。
- ADR = PRINTER = 104 (0x68) for the printer commands flow,
- ADRはプリンタ・コマンド流動のためにPRINTER=104(0×68)と等しいです。
- ADR = SCPM = 105 (0x69) for the screen copy printing commands
flow.
- スクリーンコピー印刷のためのSCPM ADR==105(0×69)は流れを命令します。
A request message with an unknown or unsupported address will be discarded by the receiver which replies with a NOT-AVAILABLE response message.
未知の、または、サポートされないアドレスがある要求メッセージはAVAILABLEでない応答メッセージで返答する受信機によって捨てられるでしょう。
Dujonc Informational [Page 12] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[12ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
5.2 Command field
5.2 コマンド欄
The <CDE> command field is mandatory and defined on one byte.
<CDE>コマンド欄は、義務的で1バイトで定義されています。
The command byte <CDE> is structured as follows:
コマンドバイト<CDE>は以下の通り構造化されます:
<Command-Type><Message-Type>
<コマンドタイプ><メッセージタイプ>。
- The Command-Type fills the six most significant bits of the <CDE>
byte. The most significant bit is always 0.
- Command-タイプは<CDE>バイトの6つの最上位ビットをいっぱいにしています。 いつも最も重要なビットは0です。
Its value is ranged from 0 to 31 included. It defines the command
associated to the message for the flow identified by the address
field.
値から、0〜31を含んでいて、及んでいます。 それはアドレス・フィールドによって特定された流れへのメッセージに関連づけられたコマンドを定義します。
- The Message-Type fills the two less significant bits of the <CDE>
byte.
- Message-タイプは<CDE>バイトのそれほど重要でない2ビットをいっぱいにしています。
0 = Indication message. No response message is expected. An
indication message with an undefined command type or with an
unknown address is deleted and ignored.
0は指示メッセージと等しいです。 応答メッセージは全く予想されません。 削除されて、未定義のコマンドタイプか未知のアドレスがある指示メッセージは無視されます。
1 = Request message. The sender of a request message is waiting
for a response message having the same address value. When a
request message is sent for a given address, it is not allowed to
send another request to the same address before the receiving
response. If an end point receives a request before having sent
the response of the previous request, it deletes the second
request but have to send back a PROTOCOL-VIOLATION response after
the response of the first request. A request message with a not
defined address is replied to by a NOT-AVAILABLE response message.
A request message with an unknown or unsupported command <CDE> for
this address will be deleted by the receiver and replied to by an
UNKNOWN-COMMAND response message.
1は要求メッセージと等しいです。 要求メッセージの送付者は同じアドレス値を持っている応答メッセージを待っています。 与えられたアドレスのために要求メッセージを送るとき、それは受信応答の前に別の要求を同じアドレスに送ることができません。 前の要求の応答を送る前にエンドポイントが要求を受け取るなら、最初の要求の応答の後にプロトコル-VIOLATION応答を返送しなければならないのを除いて、それは2番目の要求を削除します。 定義されなかったアドレスがある要求メッセージはAVAILABLEでない応答メッセージによって答えられます。 これのための<CDE>が扱う未知の、または、サポートされないコマンドがある要求メッセージは、受信機によって削除されて、UNKNOWN-COMMAND応答メッセージによって答えられるでしょう。
2 = Response message. This message is the response to the current
request message. The receiver of this message is allowed to send
another request message on the flow defined by the ADR field.
2は応答メッセージと等しいです。 このメッセージは現在の要求メッセージへの応答です。 このメッセージの受信機はADR分野によって定義された流れに別の要求メッセージを送ることができます。
3 = Response and request message. This message is a positive
response to the current request message sent by the receiver, but
is also a request message.
3は応答と要求メッセージと等しいです。 このメッセージは、受信機によって現在の要求メッセージに送られた、積極的な応答ですが、また、要求メッセージです。
Dujonc Informational [Page 13] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[13ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
The following table gives the <CDE> commands list with their hexadecimal values
以下のテーブルは>コマンドがそれらの16進値で記載する<CDEを与えます。
Command Indication Request Response Resp/Req
--------------------------------------------------------
DATA 00 01
PASSW 04 05
ACK 0A
ERROR 0E
BUSY 12
ABORTED 16
PURGED 1A
NOT-AVAILABLE 1E
PROTOCOL-VIOLATION 22
UNKNOWN-COMMAND 26
PURGE 28
LOCAL-STATE 2D
ONLINE-STATE 30
STATE-REQ 35
READY 3A
STANDBY 3E
COPY-REQ 41
LOCAL-COPY 47
コマンド指示要求応答Resp/Req-------------------------------------------------------- データ00 01PASSW04 05ACK 0A誤り0のE忙しい12は2D16の掃除された1A利用可能でない1ユーロのプロトコル違反22未知のコマンド26パージ28の30状態-REQ35持ち合わせの3A地方の州のオンライン州の予備3をコピー-REQ41地方のコピー47E中止しました。
5.3 Parameter field
5.3 パラメタ分野
This field has a variable length and its content is depending on the two previous fields (address and command).
この分野には、可変長があります、そして、内容が前の2つのフィールド(アドレスとコマンド)によっています。
6. The screen flow
6. スクリーン流動
All the following messages contain the value SCREEN = 96 (0x60) in the ADR field.
以下のすべてのメッセージがADR分野に値のSCREEN=96(0×60)を保管しています。
6.1 Screen data messages
6.1 スクリーンデータメッセージ
These messages are defined to transport in the parameter field of the TNVIP message, the data in the terminal presentation negotiated by the "Terminal Type" telnet command.
これらのメッセージはTNVIPメッセージ(「端末のタイプ」telnetコマンドで交渉された端末のプレゼンテーションにおけるデータ)のパラメタ分野での輸送と定義されます。
The parameter has the following format:
パラメタには、以下の形式があります:
<FC1> <FC2> <STX> < screen data>
<FC1><FC2><STX><スクリーンデータ>。
- The FC1, FC2 bytes are the functions codes of the VIP procedure
transmission [9]. Their values are comprised between 32 (0x20)
included and 127 (0x7F) included.
- FC1であり、FC2バイトはVIP手順送信[9]の機能コードです。 (0x7F)を含んでいて、それらの値は(0×20)が含んだ32と127の間包括されます。
Dujonc Informational [Page 14] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[14ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
- The STX byte is defined by the value 2 and acts as the introducer
of the screen data.
- STXバイトは、値2によって定義されて、スクリーンの誘導子としてデータを機能させます。
A screen data message can be sent in a request or in an indication message. The command values are defined as follows:
要求か指示メッセージでスクリーンデータメッセージを送ることができます。 コマンド値は以下の通り定義されます:
<CDE> = DATA indication = 0
<CDE>=DATA指示=0
<CDE> = DATA request = 1
<CDE>=DATAは=1を要求します。
<CDE> = PASSWORD indication = 4
<CDE>=PASSWORD指示=4
<CDE> = PASSWORD request = 5
<CDE>=PASSWORDは=5を要求します。
Generally, the "TNVIP server" only sends indication messages to the screen. The request message is used mainly for the printer device. But a DSA/TNVIP gateway server should use the screen data request message when it processes a DSA end to end acknowledgement request from the DSA application and synchronizes the response message receipt with the DSA end to end acknowledgement.
一般に、「TNVIPサーバ」は指示メッセージをスクリーンに送るだけです。 要求メッセージは主にプリンタデバイスに使用されます。 しかし、DSAアプリケーションからの承認要求を終わらせるためにDSAエンドを処理して、承認を終わらせるために応答メッセージ領収書をDSAエンドと同期させると、DSA/TNVIPゲートウェイサーバはスクリーンデータ要求メッセージを使用するべきです。
The password request and the password indication message are defined, to be used by the programs in the "TNVIP client" machine which don't emulate terminal. In this way, they have the indication that a secret read (password acquisition) is requested by the "TNVIP server". When the program is a terminal emulation this information is not necessary because the data contains the terminal presentation command to request this secret read.
パスワード要求とパスワード指示メッセージは、「TNVIPクライアント」マシンの端末をエミュレートしないプログラムで使用されるために定義されます。 このように、彼らには、秘密が「TNVIPサーバ」によって要求されると読む(パスワード獲得)指示があります。 プログラムがターミナルエミュレーションであるときに、データがこの秘密が読んだよう要求する端末のプレゼンテーション命令を含んでいるので、この情報は必要ではありません。
6.2 Local state monitoring messages
6.2 メッセージをモニターする地方の州
Before to switch in the local state, the "TNVIP client" sends a LOCAL-STATE request message to the "TNVIP server". This last one sends back an acknowledgement message and suspends the screen and printer data flow until it receives a LINE-STATE indication message.
以前、地方の状態で切り替わるように、「TNVIPクライアント」はLOCAL-州要求メッセージを「TNVIPサーバ」に送ります。 線州指示メッセージを受け取るまで、最後のこれは、確認メッセージを返送して、スクリーンとプリンタデータフローを吊します。
Note: In the local state, only the messages from the "TNVIP server"
to the screen or printer devices are deleted. The messages
from the "TNVIP client" screen device or the messages
associated to others addresses are allowed.
以下に注意してください。 地方の状態では、スクリーンか「TNVIPサーバ」からプリンタデバイスまでのメッセージだけが削除されます。 「TNVIPクライアント」スクリーンデバイスからのメッセージか他のものアドレスに関連づけられたメッセージが許容されています。
The following command values are defined as:
以下のコマンド値は以下と定義されます。
<CDE> = LOCAL-STATE request = 45 (0x2D). It is sent by the "TNVIP
client". There is no parameter field.
<CDE>はLOCAL-州要求=45(0x2D)と等しいです。 それは「TNVIPクライアント」によって送られます。 パラメタ分野が全くありません。
Dujonc Informational [Page 15] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[15ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
<CDE> = ONLINE-STATE indication = 48 (0x30). It is sent by the
"TNVIP client" to indicate the "TNVIP server" is allowed to resume
the screen data flow. There is no parameter field.
<CDE>はONLINE-州指示=48(0×30)と等しいです。 それは、「TNVIPサーバ」がスクリーンデータフローを再開できるのを示すために「TNVIPクライアント」によって送られます。 パラメタ分野が全くありません。
6.3 Screen response messages
6.3 スクリーン応答メッセージ
These messages are indications used to respond to the screen data request previously received.
これらのメッセージは以前に受け取られたスクリーンデータ要求に応じるのに使用される指摘です。
The command values are defined as follows:
コマンド値は以下の通り定義されます:
<CDE> = ACK response indication = 10 (0x0A). The screen data
previously received has been well processed or the LOCAL STATE is
acknowledged by the "TNVIP server". There is no parameter field.
<CDE>=ACK応答指示=10(0x0A)。 以前に受け取られたスクリーンデータをよく処理してあるか、またはLOCAL STATEは「TNVIPサーバ」によって承認されます。 パラメタ分野が全くありません。
<CDE> = ERR response indication = 14 (0x0E). The screen data
previously received has not been correctly processed. There is no
parameter field.
<CDE>=ERR応答指示=14(0x0E)。 以前に受け取られたスクリーンデータは正しく処理されていません。 パラメタ分野が全くありません。
<CDE> = BUSY response indication = 18 (0x12). The screen data
previously received has been deleted because the terminal is in the
local state. There is no parameter field.
<CDE>はBUSY応答指示=18(0×12)と等しいです。 端末が地方の状態にあるので、以前に受け取られたスクリーンデータは削除されました。 パラメタ分野が全くありません。
<CDE> = ABORTED response indication = 22 (0x16). The receipt of the
screen data request has been aborted by a reset terminal command.
There is no parameter field.
<CDE>はABORTED応答指示=22(0×16)と等しいです。 データが要求するスクリーンの領収書はリセット端末命令で中止されました。 パラメタ分野が全くありません。
<CDE> = PURGED response indication = 26 (0x1A). The processing of
the screen data request has been aborted by a purge indication
message. There is no parameter field.
<CDE>=PURGED応答指示=26(0x1A)。 データが要求するスクリーンの処理はパージ指示メッセージによって中止されました。 パラメタ分野が全くありません。
<CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The screen
device is not supported. Normally this command has never to be
generated because the screen device should always be present. There
is no parameter field.
<CDE>=AVAILABLEでない応答指示=30(0x1E)。 スクリーンデバイスは支えられません。 通常、スクリーンデバイスがいつも存在しているべきであるので、このコマンドは決して生成される必要はありません。 パラメタ分野が全くありません。
<CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
screen request received has been deleted because an other screen
request is already in process. That means several screen request
messages have been sent without waiting for the response. It is a
consequence of the non-compliance of the protocol. There is no
parameter field.
<CDE>はプロトコル-VIOLATION応答指示=34(0×22)と等しいです。 他のスクリーン要求がプロセスに既にあるので、受け取られたスクリーン要求は削除されました。 それは、応答を待たないでいくつかのスクリーン要求メッセージを送ることを意味します。 それはプロトコルの不承諾の結果です。 パラメタ分野が全くありません。
<CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The screen
request received has been deleted because the <CDE> field value is
unknown. It is a consequence of the non-compliance of the protocol.
There is no parameter field.
<CDE>はUNKNOWN-COMMAND応答指示=38(0×26)と等しいです。 <CDE>分野価値が未知であるので、受け取られたスクリーン要求は削除されました。 それはプロトコルの不承諾の結果です。 パラメタ分野が全くありません。
Dujonc Informational [Page 16] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[16ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
6.3.1 Page overflow processing
6.3.1 ページオーバーフロー処理
The page overflow processing is not supported through the TNVIP protocol to avoid the retransmission of the message. That leads the "TNVIP client" side to process it locally. When a data message induces a page overflow, the terminal emulation alerts the user possibly requesting (in manual mode) an "enter" action before clearing the screen and reprocessing the data received.
ページオーバーフロー処理は、メッセージの「再-トランスミッション」を避けるためにTNVIPプロトコルを通してサポートされません。 それは、「TNVIPクライアント」側が局所的にそれを処理するように導きます。 データメッセージがページオーバーフローを引き起こすとき、ターミナルエミュレーションはデータが受けたスクリーンと再処理をきれいにする前にことによると「入ってください」という動作を要求する(手動モードで)ユーザを警告します。
Note: When the "TNVIP client" is processing a page overflow , the
terminal emulation should be in the BUSY state and should
stop getting message from the line ("TNVIP server") until the
page overflow processing is complete.
以下に注意してください。 「TNVIPクライアント」がページオーバーフローを処理しているとき、ターミナルエミュレーションは、BUSY状態にあるべきであり、ページオーバーフロー処理が完全になるまで系列(「TNVIPサーバ」)からメッセージを得るのを止めるべきです。
6.4 Screen data purge indication message
6.4 スクリーンデータパージ指示メッセージ
This message is used to purge the current screen request message. When the side which receive the message has not already acknowledged the screen request, it tries to abort the processing of the request and returns a screen purged response message. If it has already replied, it ignores and deletes the message.
このメッセージは、現在のスクリーン要求メッセージを掃除するのに使用されます。 メッセージを受け取る側が既にスクリーン要求を承諾していないとき、それは、要求の処理を中止しようとして、スクリーンの掃除された応答メッセージを返します。 既に返答したなら、それは、メッセージを無視して、削除します。
The following command value is defined as:
以下のコマンド値は以下と定義されます。
<CDE> = PURGE indication = 40 (0x28). There is no parameter field.
<CDE>はPURGE指示=40(0×28)と等しいです。 パラメタ分野が全くありません。
7. The printer flow
7. プリンタ流動
All the following messages contain the PRINTER value 104 (0x68) in the ADR field. The support of this address is optional. If the "TNVIP server" doesn't address this device, no message with this address will be exchanged. If the "TNVIP client" receives a request message with this address and does not support the printer, it replies with a printer NOT-AVAILABLE response message.
以下のすべてのメッセージがADR分野にPRINTER値104(0×68)を保管しています。 このアドレスのサポートは任意です。 「TNVIPサーバ」がこのデバイスを扱わないと、このアドレスがあるメッセージを全く交換しないでしょう。 「TNVIPクライアント」がこのアドレスで要求メッセージを受け取って、プリンタを支えないなら、それはプリンタAVAILABLEでない応答メッセージで返答します。
7.1 Printer data messages
7.1 プリンタデータメッセージ
These messages are defined to transport the printer data in the parameter field of the TNVIP message. These messages are only sent from the "TNVIP server" to the "TNVIP client".
これらのメッセージは、TNVIPメッセージのパラメタ分野でプリンタデータを輸送するために定義されます。 「TNVIPサーバ」から「TNVIPクライアント」にこれらのメッセージを送るだけです。
The parameter has the following format:
パラメタには、以下の形式があります:
<FC1> <FC2> <STX> <printer data>
<FC1><FC2><STX><プリンタデータ>。
- The FC1, FC2 bytes are the function codes of the VIP procedure
transmission. Their values are ranged from 32 (0x20) to 127
(0x7F) included.
- FC1であり、FC2バイトはVIP手順送信の機能コードです。 それらの値から、32対127(0×20)(0x7F)を含んでいて、及んでいます。
Dujonc Informational [Page 17] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[17ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
- The STX byte is defined by the value 2 and acts as the introducer
of the printer data.
- STXバイトは、値2によって定義されて、プリンタの誘導子としてデータを機能させます。
To manage correctly the printer device, the protocol only defines request message. Whereas the "TNVIP server" is ensured than the "TNVIP client" processes a screen data message only when the previous one have been processed. When it receives a printer data message, the "TNVIP client" transfers it in the printer buffer. The terminal is busy only during this transfer. So, if the "TNVIP client" receives another printer data it deletes them because the previous printing (transfer between the printer buffer and the printer) is not ended.
正しくプリンタデバイスを管理するために、プロトコルは要求メッセージを定義するだけです。 「TNVIPサーバ」は「TNVIPクライアント」プロセスより確実にされますが、前のものであるときにだけ、スクリーンデータメッセージを処理してあります。 プリンタデータメッセージを受け取るとき、「TNVIPクライアント」はプリンタバッファでそれを移します。 端末はこの転送だけの間忙しいです。 それで、「TNVIPクライアント」が別のプリンタデータを受け取るなら、前の印刷(プリンタバッファとプリンタの間で移す)が終わらないので、それはそれらを削除します。
The printer data structure depends on the terminal presentation family (P200 or 7800). The two presentations define two modes of printing. The first one needs the printer data are in the presentation of the screen (7800 or P200 commands) and data are converted by the terminal in the printer presentation (TTY, SDP, copy. The second mode allows to give the printer data in the real presentation of the printer. For this reason it is called "transparent print".
プリンタデータ構造は端末のプレゼンテーションファミリー(P200か7800)に頼っています。 2つのプレゼンテーションが印刷の2つのモードを定義します。 プリンタデータはスクリーン(7800かP200コマンド)のプレゼンテーション中です、そして、データはプリンタプレゼンテーションにおける端末によって変換されます。TTY、SDP、コピー2番目のモードでプリンタの本当のプレゼンテーションにおけるプリンタデータを与えます。最初の人が必要である、(この理由で、それは「わかりやすい印刷」と呼ばれます。
In the P200 terminal presentation, transparent print data are introduced by the sequence of the two ASCII characters ESC Z (0x1B 0x5A ). P200 formatted print are introduced by the sequence of two ASCII characters ESC X (0x1B 0x58) or ESC Y (0x1B 0x59).
P200の端末のプレゼンテーションでは、見え透いた印刷データは2ASCIIキャラクタESC Z(0x1B 0x5A)の系列によって紹介されます。 フォーマットされたP200は印刷します。2ASCII文字ESC X(0x1B0x58)かESC Y(0x1B0x59)の系列で、導入します。
In the 7800 terminal presentation, transparent print data are introduced by the command PTD (Print Transparent Data). 7800 formatted print are introduced by the command PHD (Print Host Data).
7800年の端末のプレゼンテーションでは、見え透いた印刷データはコマンドPTDによって紹介されます(Transparent Dataを印刷してください)。 7800年のフォーマットされた印刷はコマンドPHDによって導入されます(Host Dataを印刷してください)。
<CDE> = DATA request = 1 (0x01).
<CDE>=DATAは=1(0×01)を要求します。
7.2 Printer response messages
7.2 プリンタ応答メッセージ
These messages are used to report the printing end status of the printer data request previously received.
これらのメッセージは、以前に受け取られたプリンタデータ要求の印刷完了状態を報告するのに使用されます。
The following command values are defined as:
以下のコマンド値は以下と定義されます。
<CDE> = ACK response indication = 10 (0x0A). The printer data
previously received have been well processed.
<CDE>=ACK応答指示=10(0x0A)。 以前に受け取られたプリンタデータをよく処理してあります。
<CDE> = ERR response indication = 14 (0x0E). The printer data
previously received have not been correctly processed (invalid
command, buffer overflow , printer off...)
<CDE>=ERR応答指示=14(0x0E)。 以前に受け取られたプリンタデータは正しく処理されていません。(無効のコマンド、バッファオーバーフロー、…のプリンタ)
<CDE> = BUSY response indication = 18 (0x12). The printer data
received have been deleted because the previous printing request is
<CDE>はBUSY応答指示=18(0×12)と等しいです。 前の印刷要求が削除されたので、受け取られたプリンタデータは削除されました。
Dujonc Informational [Page 18] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[18ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
not ended. Several printer data request messages have been sent
without waiting for the response.
終わりません。 応答を待たないで、いくつかのプリンタデータ要求メッセージを送りました。
<CDE> = ABORTED response indication = 22 (0x14). The printing has
been aborted by the terminal operator.
<CDE>はABORTED応答指示=22(0×14)と等しいです。 印刷は端末オペレータによって中止されました。
<CDE> = PURGED response indication = 26 (0x18). The printing request
has been aborted by a printer data purge indication message.
<CDE>はPURGED応答指示=26(0×18)と等しいです。 印刷要求はプリンタデータパージ指示メッセージによって中止されました。
<CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The printer
device is not supported.
<CDE>=AVAILABLEでない応答指示=30(0x1E)。 プリンタデバイスは支えられません。
<CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
printer request received has been deleted because an other printer
request is already in process. That means several printer request
messages have been sent without waiting for the response. It is a
consequence of the non-compliance of the protocol. There is no
parameter field.
<CDE>はプロトコル-VIOLATION応答指示=34(0×22)と等しいです。 他のプリンタ要求がプロセスに既にあるので、受け取られたプリンタ要求は削除されました。 それは、応答を待たないでいくつかのプリンタ要求メッセージを送ることを意味します。 それはプロトコルの不承諾の結果です。 パラメタ分野が全くありません。
<CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The
printer request received has been deleted because of an unknown
<CDE> field value. It is a consequence of the non-compliance of the
protocol. There is no parameter field.
<CDE>はUNKNOWN-COMMAND応答指示=38(0×26)と等しいです。 受け取られたプリンタ要求は未知の<CDE>分野価値のために削除されました。 それはプロトコルの不承諾の結果です。 パラメタ分野が全くありません。
For all the above commands, the parameter field may contain
specific terminal status if one was requested in the printer data
received (response to PDENQ 7800 terminal presentation command).
すべての上のコマンドのために、1つがデータが受けたプリンタ(PDENQ7800の端末のプレゼンテーション命令への応答)で要求されたなら、パラメタ分野は特定の端末の状態を含むかもしれません。
7.3 7800 printer status management
7.3 7800年のプリンタ状態管理
When emulating a 7800 terminal [8], the "TNVIP client" takes charge of adding to the printer data the printer differed status request (PDENQ 7800 command) to synchronize the printing end with the sending of the printer acknowledgement response.
7800年の端末[8]を見習うとき、「TNVIPクライアント」はプリンタ承認応答の発信と印刷エンドを同期させるというプリンタの異なった状態要求(PDENQ7800コマンド)をプリンタデータに追加する充電を取ります。
Some DSA applications are written to manage the 7800 printer status, so they send themselves the printer status request at the beginning of the printer data. That is the reason why when the "TNVIP client" receives this command at the beginning of the printer data, it must send back the 7800 status response in the parameter field of the printer data response message.
いくつかのDSAアプリケーションが7800年のプリンタ状態を管理するために書かれているので、それらはプリンタデータの始めにプリンタ状態要求を自分たちに送ります。 それは「TNVIPクライアント」がプリンタデータの始めにこのコマンドを受け取るときそれがプリンタデータ応答メッセージのパラメタ分野で7800年の状態応答を返送しなければならない理由です。
The 7800 terminal presentation defines also immediate printer status request and response (PENQ which allows to get an immediate response indicating the current printer status). These commands have to be exchanged in the TNVIP screen data flow.
また、7800年の端末のプレゼンテーションは即座のプリンタ状態要求と応答(即時型反応に現在のプリンタ状態を示させるのを許容するPENQ)を定義します。 TNVIPスクリーンデータフローでこれらのコマンドを交換しなければなりません。
Dujonc Informational [Page 19] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[19ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
7.4 Printer state request message
7.4 プリンタ州の要求メッセージ
This message is sent by the "TNVIP server" to know the printer state of the "TNVIP client" without sending printer data.
「TNVIPサーバ」でこのメッセージを送って、送付プリンタデータなしで「TNVIPクライアント」のプリンタ状態を知ります。
The following command value is defined as:
以下のコマンド値は以下と定義されます。
<CDE> = STATE-REQ request = 53 (0x35). There is no parameter field.
<CDE>=州-REQは=53(0×35)を要求します。 パラメタ分野が全くありません。
7.5 Printer state response messages
7.5 プリンタ州の応答メッセージ
These messages are sent by the "TNVIP client" in order to report the printer state to the "TNVIP server".
これらのメッセージは、「TNVIPサーバ」にプリンタ状態を報告するために「TNVIPクライアント」によって送られます。
The following command values are defined as:
以下のコマンド値は以下と定義されます。
<CDE> = READY response indication = 58 (0x3A). The printer state is
ready to print. There is no parameter field.
<CDE>=READY応答指示=58(0x3A)。 プリンタ状態は印刷する準備ができています。 パラメタ分野が全くありません。
<CDE> = STANDBY response indication = 62 (0x3E). The printer device
is in standby and is temporarily unavailable. There is no parameter
field.
<CDE>=STANDBY応答指示=62(0x3E)。 プリンタデバイスは、予備であって、一時入手できません。 パラメタ分野が全くありません。
<CDE> = PURGED response indication = 26 (0x1A). The printer state
request has been aborted by a printer state purge indication
message. There is no parameter field.
<CDE>=PURGED応答指示=26(0x1A)。 プリンタ州の要求はプリンタ州のパージ指示メッセージによって中止されました。 パラメタ分野が全くありません。
<CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The printer
device is not supported. There is no parameter field.
<CDE>=AVAILABLEでない応答指示=30(0x1E)。 プリンタデバイスは支えられません。 パラメタ分野が全くありません。
<CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
printer state request received has been deleted because an other
printer request is already in process. That means several printer
request messages have been sent without waiting for the response. It
is a consequence of the non-compliance of the protocol. There is no
parameter field.
<CDE>はプロトコル-VIOLATION応答指示=34(0×22)と等しいです。 他のプリンタ要求がプロセスに既にあるので、州の要求が受けたプリンタは削除されました。 それは、応答を待たないでいくつかのプリンタ要求メッセージを送ることを意味します。 それはプロトコルの不承諾の結果です。 パラメタ分野が全くありません。
<CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The printer
state request received has been deleted because the <CDE> field
value is unknown. It is a consequence of the non-compliance of the
protocol. There is no parameter field.
<CDE>はUNKNOWN-COMMAND応答指示=38(0×26)と等しいです。 <CDE>分野価値が未知であるので、州の要求が受けたプリンタは削除されました。 それはプロトコルの不承諾の結果です。 パラメタ分野が全くありません。
7.6 Printer purge indication message
7.6 プリンタパージ指示メッセージ
This message is used by the "TNVIP server" to purge the current printer request message. When the "TNVIP client" receives this message, if it has not already acknowledged the printer data, it aborts the printing and returns a printer data purge acknowledgement
このメッセージは「TNVIPサーバ」によって使用されて、現在のプリンタ要求メッセージを掃除します。 既にプリンタデータを承認していないなら「TNVIPクライアント」がこのメッセージを受け取るとき、それは、印刷を中止して、プリンタデータパージ承認を返します。
Dujonc Informational [Page 20] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[20ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
response message. If it has already replied, it ignores and deletes the message.
応答メッセージ。 既に返答したなら、それは、メッセージを無視して、削除します。
The printer purge command value is defined as:
プリンタパージコマンド価値は以下と定義されます。
<CDE> = PURGE indication = 40 (0x28). There is no parameter field.
<CDE>はPURGE指示=40(0×28)と等しいです。 パラメタ分野が全くありません。
8. The Screen Copy Printing flow
8. Screen Copy Printing流動
All the following messages contain the SCPM address value 105 (0x69) in the ADR field. The support of this address is mandatory.
以下のすべてのメッセージがADR分野にSCPMアドレス値105(0×69)を保管しています。 このアドレスのサポートは義務的です。
8.1 Screen copy request messages
8.1 スクリーンコピー要求メッセージ
As the printer device can be used by the "TNVIP server", if the terminal user wishes a screen copy printing, the "TNVIP" client has to synchronize the user request with the "TNVIP server" printing .
「TNVIPサーバ」でプリンタデバイスを使用できるとき、端末ユーザが、スクリーンコピーが印刷であることを願うなら、"TNVIP"クライアントはユーザ要求を「TNVIPサーバ」印刷と同時にさせなければなりません。
The TNVIP protocol defines that the "TNVIP client" has to inform the "TNVIP server" when it wants to print a screen copy and waits for its authorization before beginning
プロトコルが定義する「TNVIPクライアント」がそれがいつスクリーンコピーを印刷したくて、始めの前に承認を待つかを「TNVIPサーバ」に知らせるために持っているTNVIP
The following command values are defined as:
以下のコマンド値は以下と定義されます。
<CDE> = COPY-REQ request = 65 (0x41). It is used from the "TNVIP
client" to the "TNVIP server" to request a screen copy printing.
<CDE>=COPY-REQは=65(0×41)を要求します。 それは、スクリーンコピー印刷を要求するのに「TNVIPクライアント」から「TNVIPサーバ」まで使用されます。
<CDE> = LOCAL-COPY response and request = 71 (0x47). It is sent by
the "TNVIP server" to acknowledge the COPY-REQ message indicating
the screen copy can be done locally. It is also a request message
because it is equivalent to a screen copy data request message and
the "TNVIP server" is waiting for a screen copy response message
from the "TNVIP client" but on the SCPM flow. There is no parameter
field.
<CDE>はLOCAL-COPY応答と等しく、=71(0×47)を要求します。 「TNVIPサーバ」でそれを送って、局所的にスクリーンコピーを示すCOPY-REQメッセージができると認めます。 また、スクリーンコピーデータ要求メッセージに同等であるので、それは要求メッセージです、そして、「TNVIPサーバ」は「TNVIPクライアント」からスクリーンコピー応答メッセージを待っていますが、SCPMでは、流れてください。 パラメタ分野が全くありません。
8.2 Screen copy data message
8.2 スクリーンコピーデータメッセージ
They are defined in order to transport in the parameter of the message the screen copy data in the terminal presentation. It is used by the "TNVIP client" when it wants to send the screen copy data directly to the DSA application (a VIP terminal using a VIP transmission procedure indicates this special request by the STA byte =PRT=0x1A).
それらは、メッセージのパラメタで端末のプレゼンテーションにおけるスクリーンコピーデータを輸送するために定義されます。 スクリーンコピーデータを直接DSAアプリケーションに送りたいと(VIPトランスミッション手順を用いるVIP端末はSTAバイト=PRT=0x1Aによるこの特別な要求を示します)、それは「TNVIPクライアント」によって使用されます。
Dujonc Informational [Page 21] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[21ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
The parameter field has the following format:
パラメタ分野には、以下の形式があります:
<FC1> <FC2> <STX> <screen-copy-data>
<FC1><FC2><STX><スクリーンコピーデータ>。
- The FC1, FC2 bytes are the functions codes of the VIP procedure
transmission. Their values are ranged from 32 (0x20) to 127
(0x7F) included.
- FC1であり、FC2バイトはVIP手順送信の機能コードです。 それらの値から、32対127(0×20)(0x7F)を含んでいて、及んでいます。
- The STX byte is defined by the value 2 and acts as the introducer
of the screen data.
- STXバイトは、値2によって定義されて、スクリーンの誘導子としてデータを機能させます。
Screen copy data message can be sent in a request or indication message.
要求か指示メッセージでスクリーンコピーデータメッセージを送ることができます。
The command values are defined as follows:
コマンド値は以下の通り定義されます:
<CDE> = DATA indication = 0
<CDE>=DATA指示=0
<CDE> = DATA request = 1
<CDE>=DATAは=1を要求します。
8.3 Screen copy response messages
8.3 スクリーンコピー応答メッセージ
These messages are sent by the "TNVIP client" (local copy) to report the end of printing status of the screen copy.
これらのメッセージは、スクリーンコピーの印刷状態の端を報告するために「TNVIPクライアント」(地方のコピー)によって送られます。
The ACK response is also used by the "TNVIP server" to acknowledge a screen copy data request sent to the host application.
また、ACK応答は「TNVIPサーバ」によって使用されて、データが要求するスクリーンコピーがホストアプリケーションに発信したと認めます。
The ERR message is also used by the server to refuse a COPY-REQ message.
また、ERRメッセージはサーバによって使用されて、COPY-REQメッセージを拒否します。
The following command values are defined as:
以下のコマンド値は以下と定義されます。
<CDE> = ACK response indication = 10 (0x0A). The "TNVIP client"
reports the screen copy has been well printed or the "TNVIP server"
acknowledges the screen copy data request. There is no parameter
field.
<CDE>=ACK応答指示=10(0x0A)。 「TNVIPクライアント」は、スクリーンコピーがよく印刷されたか、または「TNVIPサーバ」がデータが要求するスクリーンコピーを承認すると報告します。 パラメタ分野が全くありません。
<CDE> = ERR response indication = 14 (0x0E). The screen copy has not
been correctly printed (invalid command, buffer overflow ...) or has
been refused by the "TNVIP server". It can optionally contain a
reason code value defined on one byte.
<CDE>=ERR応答指示=14(0x0E)。 スクリーンコピーは、正しく印刷されていないか(無効のコマンド、バッファオーバーフロー…)、または「TNVIPサーバ」によって拒否されました。 それは任意に1バイトで定義された理由コード値を含むことができます。
- 1 : The printer is busy, retry later.
- 1 : プリンタは忙しく、後で再試行してください。
<CDE> = BUSY response indication = 18 (0x12). The screen copy has
not been correctly printed because the printer device is already
printing. There is no parameter field.
<CDE>はBUSY応答指示=18(0×12)と等しいです。 プリンタデバイスが既に印刷しているので、スクリーンコピーは正しく印刷されていません。 パラメタ分野が全くありません。
Dujonc Informational [Page 22] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[22ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
<CDE> = ABORTED response indication =22 (0x16). The screen copy has
been aborted by the terminal operator. There is no parameter field.
<CDE>はABORTED応答指示=22(0×16)と等しいです。 スクリーンコピーは端末オペレータによって中止されました。 パラメタ分野が全くありません。
<CDE> = PURGED response indication = 26 (0x1A). The screen copy
request message has been aborted by a purge indication message.
There is no parameter field.
<CDE>=PURGED応答指示=26(0x1A)。 スクリーンコピー要求メッセージはパージ指示メッセージによって中止されました。 パラメタ分野が全くありません。
<CDE> = NOT-AVAILABLE response indication = 30 (0x1E). The screen
copy has not been correctly printed because the printer device is
not supported. There is no parameter field.
<CDE>=AVAILABLEでない応答指示=30(0x1E)。 プリンタデバイスが支えられないので、スクリーンコピーは正しく印刷されていません。 パラメタ分野が全くありません。
<CDE> = PROTOCOL-VIOLATION response indication = 34 (0x22). The
screen copy request received has been deleted because an other
screen copy request is already in process. That means several screen
copy request messages have been sent without waiting for the
response. It is a consequence of the non-compliance of the protocol.
There is no parameter field.
<CDE>はプロトコル-VIOLATION応答指示=34(0×22)と等しいです。 他のスクリーンコピー要求がプロセスに既にあるので、コピー要求が受けたスクリーンは削除されました。 それは、応答を待たないでいくつかのスクリーンコピー要求メッセージを送ることを意味します。 それはプロトコルの不承諾の結果です。 パラメタ分野が全くありません。
<CDE> = UNKNOWN-COMMAND response indication = 38 (0x26). The screen
copy request received has been deleted because the <CDE> field value
is unknown. It is a consequence of the non-compliance of the
protocol. There is no parameter field.
<CDE>はUNKNOWN-COMMAND応答指示=38(0×26)と等しいです。 <CDE>分野価値が未知であるので、コピー要求が受けたスクリーンは削除されました。 それはプロトコルの不承諾の結果です。 パラメタ分野が全くありません。
8.4 Screen copy purge indication message
8.4 スクリーンコピーパージ指示メッセージ
This message is used to purge the current screen copy request message. When the "TNVIP server" or the "TNVIP client" receives this message, if it has not already acknowledged the request message, it returns a screen copy purge acknowledgement message. If it has already replied, it ignores and deletes the message.
このメッセージは、現在のスクリーンコピー要求メッセージを掃除するのに使用されます。 既に要求メッセージを承認していないなら「TNVIPサーバ」か「TNVIPクライアント」がこのメッセージを受け取るとき、それはスクリーンコピーパージ確認メッセージを返します。 既に返答したなら、それは、メッセージを無視して、削除します。
The following command value is defined as:
以下のコマンド値は以下と定義されます。
<CDE> = PURGE indication = 40 (0x28).There is no parameter field.
40(0×28)<CDE>=PURGE指示=.Thereはパラメタ分野ではありません。
9. The TM attention
9. TM注意
The TM attention is the signal used to activate the local dialog of the DSA Terminal Manager.
TM注意はDSA Terminalマネージャのローカルの対話を活性化するのに使用される信号です。
The Telnet Abort Output (AO) command [1] is the mechanism used to implement the TM attention key support in TNVIP.
Telnet Abort Output(AO)コマンド[1]はTNVIPでTMがアテンションキーサポートであると実装するのに使用されるメカニズムです。
IAC AO (0xFF 0xF5)
IAC AO(0xFF 0xF5)
In order to implement the TM attention key support, "TNVIP clients" should provide a key (or combination of keys) that is identified as mapping to the TM attention key. When the user presses this key(s),
TMアテンションキーサポートを実装するために、「TNVIPクライアント」はマッピングとしてTMアテンションキーに特定されるキー(または、一組の鍵)を提供するべきです。 ユーザがこのキーを押すと
Dujonc Informational [Page 23] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[23ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
the "TNVIP client" should transmit a Telnet AO command to the "TNVIP server".
「TNVIPクライアント」は「TNVIPサーバ」にTelnet AOコマンドを伝えるべきです。
Upon receipt of the AO command, a "TNVIP server" that implements the DSA Terminal Manager should enter in what will be loosely termed "TM Local Dialog", suspending the eventual DSA host connection, else it should simply ignore it.
AOコマンドを受け取り次第、DSA Terminalマネージャを実行する「TNVIPサーバ」は緩く「TMのローカルの対話」と呼ばれることに入るべきです、最後のDSAホスト接続を停学処分にしてほかに、それは単にそれを無視するべきです。
10. The Break Key
10. 中断キー
Generally, there is no break key on the real VIP terminal. The break signal is transmitted to the host application through a TM local dialog command ($*$BRK for example)
一般に、本当のVIP端末で主要などんな中断もありません。 中断信号はTMのローカルの対話コマンドでホストアプリケーションに送信されます。(例えば、$*$BRK)
On "TNVIP client" emulating VIP terminal, it is often possible to map the break signal on a special key combination or by other way (using mouse ...).
VIP端末を見習っている「TNVIPクライアント」では、特別な主要な組み合わせか他の方法で中断信号を写像するのはしばしば可能です(マウスを…使用して)。
The Telnet Break (BRK) command [1] is used to map the Break signal of the TNVIP.
Telnet Break(BRK)コマンド[1]は、TNVIPに関するBreak信号を写像するのに使用されます。
IAC BRK (0xFF 0xF3)
IAC BRK(0xFF 0xF3)
11. The Logout Key
11. 主要な状態で、ログアウトしてください。
The Telnet Interrupt Process (IP) command [1] can be used to map the logout command of the TM Local Dialog ($*$LO for example) if it is implemented on the "TNVIP server".
それが「TNVIPサーバ」で実行されるなら、TM Local Dialog(例えば、$*$LO)のログアウトコマンドを写像するのにTelnet Interrupt Process(IP)コマンド[1]を使用できます。
IAC IP (0xFF 0xF4)
IAC IP(0xFF 0xF4)
12. TNVIP messages list
12. TNVIPメッセージリスト
All the TNVIP commands are summarized here after (and the values are given in hexadecimal).
すべてのTNVIPコマンドが後にここへまとめられます(16進で値を与えます)。
12.1 Screen Flow
12.1 スクリーン流動
Data request (allowed in the two ways)
データ要求(2つの方法で許容されています)
SCREEN DATA-REQ <FC1> <FC2> STX [<screen-data>] IAC EOR
60 01 <FC1> <FC2> 02 [<screen-data>] FF EF
スクリーンデータ-REQ<FC1><FC2>STX[<スクリーンデータ>]IAC EOR60 01<FC1><FC2>02[<スクリーンデータ>]ff EF
- Allowed responses to the screen Data request.
- Dataが要求するスクリーンへの応答を許容しました。
SCREEN ACK IAC EOR
60 0A FF EF
スクリーンACK IAC EOR60 0A ff EF
Dujonc Informational [Page 24] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[24ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
SCREEN ERROR IAC EOR
60 0E FF EF
スクリーン誤りIAC EOR60 0Eのff EF
SCREEN BUSY IAC EOR
60 12 FF EF
忙しいIAC EOR60 12ff EFを上映してください。
SCREEN ABORTED IAC EOR
60 16 FF EF
スクリーンはIAC EOR60 16ff EFを中止しました。
SCREEN PURGED IAC EOR
60 1A FF EF
スクリーンはIAC EOR60 1A ff EFを掃除しました。
Password request (only from the "TNVIP server" to the "TNVIP client")
パスワード要求(単に「TNVIPサーバ」から「TNVIPクライアント」までの)
SCREEN PASSW-REQ <FC1> <FC2> STX [<screen-data>] IAC EOR
60 05 <FC1> <FC2> 02 [<screen-data>] FF EF
スクリーンPASSW-REQ<FC1><FC2>STX[<スクリーンデータ>]IAC EOR60 05<FC1><FC2>02[<スクリーンデータ>]ff EF
- Allowed responses to the password request.
- パスワード要求への応答を許容しました。
SCREEN ACK IAC EOR
60 0A FF EF
スクリーンACK IAC EOR60 0A ff EF
SCREEN ERROR IAC EOR
60 0E FF EF
スクリーン誤りIAC EOR60 0Eのff EF
SCREEN BUSY IAC EOR
60 12 FF EF
忙しいIAC EOR60 12ff EFを上映してください。
SCREEN ABORTED IAC EOR
60 16 FF EF
スクリーンはIAC EOR60 16ff EFを中止しました。
SCREEN PURGED IAC EOR
60 1A FF EF
スクリーンはIAC EOR60 1A ff EFを掃除しました。
Local state request (only from the "TNVIP client" to the "TNVIP server").
ローカルの州の要求(単に「TNVIPクライアント」から「TNVIPサーバ」までの)。
SCREEN LOCAL-ST IAC EOR
60 2D FF EF
スクリーン、地方、-、IAC EOR60 2D ff第EF
- Allowed responses to the Local state request.
- Localへの許容応答は要求を述べます。
SCREEN ACK IAC EOR
60 0A FF EF
スクリーンACK IAC EOR60 0A ff EF
SCREEN PURGED IAC EOR
60 1A FF EF
スクリーンはIAC EOR60 1A ff EFを掃除しました。
Dujonc Informational [Page 25] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[25ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
Responses to request violating the TNVIP protocol (allowed in the two ways)
TNVIPプロトコルに違反する要求する応答(2つの方法で許容されています)
SCREEN NOT-AVAIL IAC EOR
60 0E FF EF
スクリーン利益でないIAC EOR60 0Eのff EF
SCREEN PROT-VIOL IAC EOR
60 22 FF EF
スクリーンPROT-ビオールIAC EOR60 22ff EF
SCREEN UNKN-CDE IAC EOR
60 26 FF EF
スクリーンUNKN-CDE IAC EOR60 26ff EF
Indications (allowed in the two ways)
指摘(2つの方法で許容されています)
SCREEN DATA-IND <FC1> <FC2> STX [<screen-data>] IAC EOR
60 00 <FC1> <FC2> 02 [<screen-data>] FF EF
スクリーンデータ-IND<FC1><FC2>STX[<スクリーンデータ>]IAC EOR60 00<FC1><FC2>02[<スクリーンデータ>]ff EF
SCREEN PURGE IAC EOR
60 28 FF EF
スクリーンパージIAC EOR60 28ff EF
Password indication (only from the "TNVIP server" to the "TNVIP client").
パスワード指示(単に「TNVIPサーバ」から「TNVIPクライアント」までの)。
SCREEN PASSW-IND <FC1> <FC2> STX [<screen-data>] IAC EOR
60 04 <FC1> <FC2> 02 [<screen-data>] FF EF
スクリーンPASSW-IND<FC1><FC2>STX[<スクリーンデータ>]IAC EOR60 04<FC1><FC2>02[<スクリーンデータ>]ff EF
On line state indication (only from the "TNVIP client" to the "TNVIP server").
線の上では、指示(単に「TNVIPクライアント」から「TNVIPサーバ」までの)を述べてください。
SCREEN ONLINE-ST IAC EOR
60 30 FF EF
スクリーン、オンライン、-、IAC EOR60 30ff第EF
12.2 Printer flow
12.2 プリンタ流動
Data request (only from the "TNVIP server" to the "TNVIP client")
データ要求(単に「TNVIPサーバ」から「TNVIPクライアント」までの)
PRINTER DATA-REQ <FC1> <FC2> STX [<printer-data>] IAC EOR
68 01 <FC1> <FC2> 02 [<printer-data>] FF EF
プリンタデータ-REQ<FC1><FC2>STX[<プリンタデータ>]IAC EOR68 01<FC1><FC2>02[<プリンタデータ>]ff EF
- Allowed responses to the printer data request.
- データが要求するプリンタへの応答を許容しました。
PRINTER ACK [<status>] IAC EOR
68 0A [<status>] FF EF
プリンタACK[<状態>]IAC EOR68 0A[<状態>]ff EF
PRINTER ERROR [<status>] IAC EOR
68 0E [<status>] FF EF
プリンタ誤り[<状態>]IAC EOR68 0E[<状態>]のff EF
Dujonc Informational [Page 26] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[26ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
PRINTER BUSY [<status>] IAC EOR
68 12 [<status>] FF EF
プリンター使用中[<状態>]IAC EOR68 12[<状態>]ff EF
PRINTER ABORTED [<status>] IAC EOR
68 16 [<status>] FF EF
プリンタの中止になっている[<状態>]IAC EOR68 16[<状態>]ff EF
PRINTER PURGED [<status>] IAC EOR
68 1A [<status>] FF EF
プリンタの掃除された[<状態>]IAC EOR68 1A[<状態>]ff EF
PRINTER NOT-AVAIL [<status>] IAC EOR
68 1E [<status>] FF EF
プリンタ利益[<状態>]でないIAC EOR68 1E[<状態>]のff EF
State request (only from the "TNVIP server" to the "TNVIP client")
州の要求(単に「TNVIPサーバ」から「TNVIPクライアント」までの)
PRINTER STATE-REQ IAC EOR
68 35 FF EF
プリンタ状態-REQ IAC EOR68 35ff EF
- Allowed responses to the state request.
- 州の要求への応答を許容しました。
PRINTER READY IAC EOR
68 3A FF EF
プリンタの持ち合わせのIAC EOR68 3A ff EF
PRINTER STANDBY IAC EOR
68 3E FF EF
プリンタ予備IAC EOR68 3Eのff EF
PRINTER PURGED IAC EOR
68 1A FF EF
プリンタの掃除されたIAC EOR68 1A ff EF
PRINTER NOT-AVAIL IAC EOR
68 1E FF EF
プリンタ利益でないIAC EOR68 1Eのff EF
Responses to request violating the TNVIP protocol (allowed in the two ways)
TNVIPプロトコルに違反する要求する応答(2つの方法で許容されています)
PRINTER PROT-VIOL IAC EOR
68 22 FF EF
プリンタPROT-ビオールIAC EOR68 22ff EF
PRINTER UNKN-CDE IAC EOR
68 26 FF EF
プリンタUNKN-CDE IAC EOR68 26ff EF
Indication (only from the "TNVIP server" to the "TNVIP client")
指示(単に「TNVIPサーバ」から「TNVIPクライアント」までの)
PRINTER PURGE IAC EOR
68 28 FF EF
プリンタパージIAC EOR68 28ff EF
Dujonc Informational [Page 27] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[27ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
12.3 Screen Copy Printing messages flow
12.3 スクリーンCopy Printingメッセージ流動
Copy request (only from the "TNVIP client" to the "TNVIP server")
コピー要求(単に「TNVIPクライアント」から「TNVIPサーバ」までの)
SCPM COPY-REQ IAC EOR
69 41 FF EF
SCPMコピー-REQ IAC EOR69 41ff EF
- Allowed responses to the copy request (from the "TNVIP server" to
the "TNVIP client")
- コピー要求への許容応答(「TNVIPサーバ」から「TNVIPクライアント」までの)
SCPM ERROR <reason> IAC EOR
69 0E <reason> FF EF
SCPM誤り<理由>IAC EOR69 0Eの<理由>ff EF
SCPM PURGED IAC EOR
69 1A FF EF
SCPMはIAC EOR69 1A ff EFを掃除しました。
SCPM NOT-AVAIL IAC EOR
69 1E FF EF
SCPM利益でないIAC EOR69 1Eのff EF
SCPM LOCAL-COPY-RQ IAC EOR
69 47 FF EF
SCPM地方のコピーRQ IAC EOR69 47ff EF
Local copy request (only from the "TNVIP server" to the "TNVIP client" )
ローカルのコピー要求(単に「TNVIPサーバ」から「TNVIPクライアント」までの)
SCPM LOCAL-COPY-RQ IAC EOR
69 47 FF EF
SCPM地方のコピーRQ IAC EOR69 47ff EF
- Allowed responses to the local copy request (from the "TNVIP
client" to the "TNVIP server").
- ローカルのコピー要求(「TNVIPクライアント」から「TNVIPサーバ」までの)への応答を許容しました。
SCPM ACK IAC EOR
69 0A FF EF
SCPM ACK IAC EOR69 0A ff EF
SCPM ERROR IAC EOR
69 0E FF EF
SCPM誤りIAC EOR69 0Eのff EF
SCPM BUSY IAC EOR
69 12 FF EF
SCPMの忙しいIAC EOR69 12ff EF
SCPM ABORTED IAC EOR
69 16 FF EF
SCPMはIAC EOR69 16ff EFを中止しました。
SCPM PURGED IAC EOR
69 1A FF EF
SCPMはIAC EOR69 1A ff EFを掃除しました。
SCPM NOT-AVAIL IAC EOR
69 1E FF EF
SCPM利益でないIAC EOR69 1Eのff EF
Dujonc Informational [Page 28] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[28ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
Data request. (only from the "TNVIP client" to the "TNVIP server")
データ要求。 (単に「TNVIPクライアント」から「TNVIPサーバ」までの)
SCPM DATA-REQ <FC1> <FC2> STX [<screen-data>] IAC EOR
69 01 <FC1> <FC2> 02 [<screen-data>] FF EF
SCPMデータ-REQ<FC1><FC2>STX[<スクリーンデータ>]IAC EOR69 01<FC1><FC2>02[<スクリーンデータ>]ff EF
- Allowed responses to the data request
- データ要求への許容応答
SCPM ACK IAC EOR
69 0A FF EF
SCPM ACK IAC EOR69 0A ff EF
SCPM PURGED IAC EOR
69 1A FF EF
SCPMはIAC EOR69 1A ff EFを掃除しました。
SCPM NOT-AVAIL IAC EOR
69 1E FF EF
SCPM利益でないIAC EOR69 1Eのff EF
Responses to request violating the TNVIP protocol (allowed in the two ways)
TNVIPプロトコルに違反する要求する応答(2つの方法で許容されています)
SCPM PROT-VIOL IAC EOR
69 22 FF EF
SCPM PROT-ビオールIAC EOR69 22ff EF
SCPM UNKN-CDE IAC EOR
69 26 FF EF
SCPM UNKN-CDE IAC EOR69 26ff EF
Indications (allowed in the two ways)
指摘(2つの方法で許容されています)
SCPM DATA-IND <FC1> <FC2> STX [<screen-data>] IAC EOR
69 00 <FC1> <FC2> 02 [<screen-data>] FF EF
SCPMデータ-IND<FC1><FC2>STX[<スクリーンデータ>]IAC EOR69 00<FC1><FC2>02[<スクリーンデータ>]ff EF
SCPM PURGE IAC EOR
69 28 FF EF
SCPMパージIAC EOR69 28ff EF
13. Security Considerations
13. セキュリティ問題
Security issues are not addressed in this document. It is anticipated that once authentication mechanisms have become well established, use of them can be made by TNVIP. 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.
安全保障問題は本書では記述されません。 TNVIPが認証機構がいったん確固とするようになると、それらの使用をすることができると予期されます。 認証の重要な用途の1つは与えられたユーザが特定の端末を「使用すること」が許容されるべきであるかどうかに関する質問に答えるだろうことです。
Dujonc Informational [Page 29] RFC 1921 TNVIP Protocol March 1996
Dujoncの情報[29ページ]のRFC1921TNVIPは1996年3月に議定書を作ります。
14. References
14. 参照
[1] Postel, J., and J. Reynolds, "Telnet Protocol Specification", STD
8, RFC 854, USC/Information Sciences Institute, May 1983.
[1] ポステル、J.、およびJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854(科学が設けるUSC/情報)は1983がそうするかもしれません。
[2] "Communications. MainWay. Terminal Management. DNS-E",
Ref : 39A213EB Rev00, BULL S.A.
[2] 「コミュニケーション。」 MainWay。 端末の管理。 「DNS-E」、審判: 39A213EB Rev00、S.Aに押し進んでください。
[3] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
Software, Inc., February 1989.
[3]VanBokkelen、J.、「telnet端末のタイプオプション」、RFC1091、FTPソフトウェアInc.、1989年2月。
[4] Postel, J., "Telnet End of Record Option", RFC 885,
USC/Information Sciences Institute, December 1983.
[4] ポステル、J.、「記録的なオプションのtelnet終わり」、RFC885、科学が1983年12月に設けるUSC/情報。
[5] Postel, J., and J. Reynolds, "Telnet Binary Transmission", STD
27, RFC 856, USC/Information Sciences Institute, May 1983.
[5] ポステル、J.、およびJ.レイノルズ、「telnetバイナリー送信」、STD27、RFC856(科学が設けるUSC/情報)は1983がそうするかもしれません。
[6] Postel, J., and J. Reynolds, "Telnet Suppress Go Ahead Option",
STD 29, RFC 858, USC/Information Sciences Institute, May 1983.
[6] ポステル、J.、およびJ.レイノルズ、「telnetが先で碁を抑圧する、オプション、」、STD29(RFC858、科学が設けるUSC/情報)は1983にそうするかもしれません。
[7] "Affinity V2. DKU7107 Reference Manual"
Ref : 40 A2 23 WA, BULL S.A.
[7] 「親近感V2。」 「DKU7107リファレンスマニュアル」審判: 40A2 23ワシントン、S.Aに押し進んでください。
[8] "Affinity V2. VIP7800 Reference Manual"
Ref : 40 A2 24 WA, BULL S.A.
[8] 「親近感V2。」 「VIP7800リファレンスマニュアル」審判: 40A2 24ワシントン、S.Aに押し進んでください。
[9] "Bull Questar 200. TCS 7424 et TCS 7434. Transmission de donnees.
Manuel de reference"
Ref : 80 F2 41DC Rev0, BULL S.A.
[9] 「雄牛Questar200。」 TCS7424et TCS7434。 トランスミッションde donnees。 「マヌエルde参照」Ref: 80F2 41DC Rev0、S.Aに押し進んでください。
15. Author's Address
15. 作者のアドレス
Jean-Yves Dujonc BULL S.A. rue Jean Jaures 78340 Les Clayes-sous-Bois France
ジーン-イヴDujonc BULL S.A.悔悟ジーン・ジョーレス78340・レス・Clayes小銭Boisフランス
Phone: 1 30 80 62 95 Fax: 1 30 80 65 40 EMail: J.Y.Dujonc@frcl.bull.fr
以下に電話をしてください。 1、30 80 62 95、Fax: 1 30 80 65 40はメールされます: J.Y.Dujonc@frcl.bull.fr
Dujonc Informational [Page 30]
Dujonc情報です。[30ページ]
一覧
スポンサーリンク
