JP2002533808A - コンピュータ・ソフトウェア・アプリケーション間通信のためのプロトコル - Google Patents

Abstract

(57)【要約】 ２つのアプリケーション・プログラムの間のメッセージング互換性が、所定のオプションのイニシエーションとネゴシエーションとを備えるプロトコルを利用した会話を介して確立され、前記オプションが、追加オプションを含むように拡張可能であるオプションの組に属することを特徴とする、コンピュータ・ソフトウェア・アプリケーション間の通信およびメッセージングのプロトコルを開示する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】

本発明は、コンピュータ・ソフトウェア・アプリケーション間通信およびメッ
セージング互換性確立のためのプロトコルに関する。このプロトコルは、アプリ
ケーション統合およびｅ−ｃｏｍｍｅｒｃｅに関する。

【０００２】 [用語の定義] 「メッセージング」とはメッセージの転送のことであり、アプリケーション・
データ、命令、およびアプリケーション間の応答が含まれる。メッセージは、内
容と一定のサイズの両方を有する。しかし、「通信」は、情報をメッセージとみ
なすことができるか否かに無関係に、情報を送受するすべての形態を含むより広
義の概念である。本明細書で使用される用語「アプリケーション間」通信は、「
アプリケーション」（下で定義する）間の通信ならびにアプリケーションの内部
の通信を指す。

【０００３】 コンピュータ・アプリケーション（通常は、本明細書において「アプリケーシ
ョン」と呼称する）は、（ｉ）エンド・アプリケーションすなわち、メッセージ
を生成し、解釈し、それに作用するアプリケーション、（ｉｉ）（ａ）エンド・
アプリケーションとして解釈し、生成し、作用するが、主にルーティングおよび
価値の付加／マッピングのために存在するメッセージ・ブローカと、（ｂ）非同
期メッセージ・キューイング・ミドルウェア（「ＭＱＭ」）（たとえば、ＩＢＭ
社のＭＱＳｅｒｉｅｓまたはＭｉｃｒｏｓｏｆｔ社のＭＳＭＱなどのＭＱＭシス
テム）と、（ｃ）ＳＷＩＦＴ ＣＢＴ（ＳＷＩＦＴ ＣＢＴの説明については下
を参照されたい）などのメッセージ・ゲートウェイとを含む「ミドルウェア」ア
プリケーション、（ｉｉｉ）「ミドルウェア」、（ｉｖ）リモート・手続呼出し
（ＲＰＣ）などのメッセージング・プロトコル、（ｖ）メッセージングＡＰＩ（
アプリケーション・プログラミング・インターフェース）、（ｖｉ）アプリケー
ション内のコンポーネント、および（ｖｉｉ）コンピュータ・システムに関する
コンポーネント（プロセス、スレッド、またはサブルーチンなど）を含むものと
して広く解釈されなければならない。

【０００４】 用語「ミドルウェア」は、ハードウェア、ソフトウェア（プロトコル、ＡＰＩ
、およびプロシージャ呼出しを含む）、または通信の間で動作するソフトウェア
を記述するために作り出された。

【０００５】

【従来の技術】

コンピュータ・ソフトウェアのアプリケーション間通信およびメッセージング
のプロトコルによって、他の用途の中でも、異なるコンピュータ・アプリケーシ
ョンが、互いにメッセージを交換できるようになる。プロトコルは、アプリケー
ション統合、インターフェース相互作用、およびアプリケーション・プラグアン
ドプレイの配布にとって中心となる重要性を有する可能性がある。しかし、現在
、アプリケーション間メッセージングおよびアプリケーション間の相互運用性を
支配する共通の規格は存在しない。したがって、異なるプロトコルおよびアプリ
ケーション・インターフェースの間を、どのように接続するか、接続に合意する
か、又は適合する方法を定義する共通の規格または最適な手法は未だ存在しない
。

【０００６】 簡単な例を挙げると、両方向データ・フローまたは「ウィンドウイング」をサ
ポートするか否かを確立する手順を定義する共通の標準はまだない（「ウィンド
ウイング」は、次のメッセージを送る前に個々の応答の受信を待たずにメッセー
ジを送信する技法であり、したがって、１０の「ウィンドウ」は、最大１０個の
未解決の応答が許容されることを意味する）。多くのプロトコルには、それを他
のアプリケーションと共に使用できなくする特定の制約も含まれる。

【０００７】 したがって、２つの異なるアプリケーションの間で通信を成功裡に送信できる
ようにする標準アプリケーション間通信プロトコルの緊急の必要が存在する。こ
のアプリケーション間通信プロトコルに対する必要は、多くの異なるコンピュー
ティング・セクタに存在するが、この必要は、アプリケーション統合、エンター
プライズ・アプリケーション統合（ＥＡＩ）、インターネット・アプリケーショ
ン統合（ＩＡＩ）、ｅ−ｃｏｍｍｅｒｃｅ、およびメッセージングで特に深刻で
ある。

【０００８】 たとえば、バンキング／財務分野では、多くの異なるアプリケーションが、Ｓ
．Ｗ．Ｉ．Ｆ．Ｔ． ｓｃ．（「ＳＷＩＦＴ」）によって開発されたグローバル
・バンキング・ネットワークと通信する必要がある。Ｓ．Ｗ．Ｉ．Ｆ．Ｔ．は、
Ｓｏｃｉｅｔｙ ｆｏｒ Ｗｏｒｌｄ−ｗｉｄｅ Ｉｎｔｅｒｂａｎｋ Ｆｉｎ
ａｎｃｉａｌ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓの頭字語であるが、金融
機関の間のネットワークを稼動させる共同組織である。ＳＷＩＦＴは、メッセー
ジに関する厳格なフォーマット要件を有し、これによって組織が、参加する機関
との支払い、確認、および他のトランザクションを自動化できるようになる。

【０００９】 しかし、バック・オフィス・アプリケーションは、Ｓ．Ｗ．Ｉ．Ｆ．Ｔ．ネッ
トワークと直接に通信することができない（１９９８年において）。メッセージ
を送受信するために、所定の銀行のアプリケーションは、ＳＷＩＦＴコンピュー
タ・ベース端末（ＣＢＴ）と称される銀行内のコンピュータと通信しなければな
らない。そして、そのＳＷＩＦＴ ＣＢＴが、ＳＷＩＦＴネットワークと通信す
る。ＣＢＴは、厳格な要件を満たさなければならず、ＳＷＩＦＴネットワーク上
で使用される前に証明されなければならない。異なる会社がＳＷＩＦＴ ＣＢＴ
を作り、その結果、ほとんどのＣＢＴが、それ自体のアプリケーション・インタ
ーフェースを有する。

【００１０】 バック・オフィス・アプリケーションがＳＷＩＦＴ ＣＢＴと通信する万能の
標準的な方法は、まだ存在しない。バック・オフィス・アプリケーション・ベン
ダは、異なるＣＢＴにリンクしたい場合に、複数の仕様に従わなければならない
。これを回避するために、多くのバック・オフィス・アプリケーション・ベンダ
は、通常はバッチ・タイプのインターフェース（すなわち、複数のメッセージが
後続処理のためにデータ・ファイルに書き込まれるインターフェース）であるそ
れ自体のインターフェースを指定し、ＣＢＴとの統合はユーザに委ねる。これは
、満足なものではなく、バンキング産業に毎年数百万の統合コストを課す。

【００１１】 ＳＷＩＦＴは、２０００年に次世代（ＮＧ）製品およびサービスを導入する可
能性が高く、それらが従来のＣＢＴに代わる可能性がある。ＮＧの下では、ＳＷ
ＩＦＴ Ｎｅｔ Ｌｉｎｋ（ＳＮＬ）が、銀行内でアプリケーションと新しいＳ
ＷＩＦＴネットワークの間に常駐しなければならない唯一の必須ソフトウェア・
コンポーネントである。しかし、アプリケーションは、ＳＮＬを直接に使用する
のではなく、ゲートウェイまたはメッセージング・システムと通信し続ける可能
性が高い。ＮＧ単独で、通信およびアプリケーション統合の標準的な方法に対す
る必要がなくなる可能性は低い。

【００１２】 この問題のスケールは、ある例から最もよく諒解される。この例では、ＳＷＩ
ＦＴのスケールおよび成功も示される。ＳＷＩＦＴは、約６３５４の金融機関を
カバーし、１７５ヶ国で動作する。この機関には、２９８４のメンバ、２６５９
のサブメンバ、および７１１の参加者が含まれる。１９９８年のトラヒックは、
９億メッセージを超えると期待される。サブメンバ機関の一部は、ＳＷＩＦＴに
、その中央局または地方局を介して接続される。サブメンバの７０％が、ＳＷＩ
ＦＴに直接に接続されると仮定すると、約５５００台のＳＷＩＦＴ ＣＢＴがあ
る。また、ＣＢＴあたり平均３つのバック・オフィス・アプリケーションがある
と仮定すると、単独でＳＷＩＦＴと通信する必要がある約１６５００のバンキン
グ・アプリケーションがある。これらのアプリケーションの多くが、銀行によっ
て内部で開発されたインターフェースを有する。これらは、アプリケーション・
メッセージをＳＷＩＦＴに通信するための単一の標準に従わない。

【００１３】 メッセージ・キューイング・ミドルウェア（ＭＱＭ）システムおよびメッセー
ジ・ブローカ（ＭＢ）システムは、異なるアプリケーションの間でアプリケーシ
ョン・メッセージを送るための部分的な解決策であり、金融市場でかなりの成功
を収めた。ＭＱＭ／ＭＢシステムは、組織に、メッセージを渡すための標準と、
それを拡充する方法を与える。主要銀行は、現在、メッセージング・インフラス
トラクチャを全世界で標準化するために、ＭＱＭ／ＭＢシステムに注目し、実装
しつつある。

【００１４】 ＭＱＭ／ＭＢシステムは、通常、アプリケーション・プログラミング・インタ
ーフェース（ＡＰＩ）を備え、このＡＰＩによって、ｐｕｔおよびｇｅｔ、スト
ア・アンド・フォワード機能、ルール・ベースのエンジン、およびデータの再フ
ォーマッティングおよびマッピングが可能になる。さらに、その目的位置の結果
、ＭＱＭ／ＭＢベースのシステムは、それによらなければ不可能であるはずの監
視機能および追加機能を提供することができる。適切に確立されたＭＱＭ／ＭＢ
システムが複数存在する。たとえば、ストア・アンド・フォワードを備えるｐｕ
ｔアンドｇｅｔインフラストラクチャであるＩＢＭ社のＭＱＳｅｒｉｅｓは、適
切に確立されている。ＭＱＳｅｒｉｅｓには、安全で信頼性のあるメッセージン
グが組み込まれている。ＴＩＢＣＯ社のＴＩＢ／ＥＴＸが、ＩＢＭ社のＭＱＳｅ
ｒｉｅｓに似た、もう１つのｐｕｔアンドｇｅｔインフラストラクチャである。
Ｎｅｗ Ｅｒａ Ｏｆ Ｎｅｔｗｏｒｋｓ（ＮＥＯＮ）社のＮＥＯＮｅｔが、も
う１つの例であり、この場合、アプリケーションと同期してメッセージのストア
・アンド・フォワードを行うのに関係データベース技術が使用される。ＮＥＯＮ
ｅｔは、ｐｕｔアンドｇｅｔインフラストラクチャも提供する。

【００１５】 それぞれが独占的であり、かなりのユーザ・ベースを有する複数の適切に確立
されたＭＱＭ／ＭＢシステムがあるので、既存のＭＱＭ／ＭＢシステムのどれも
が、アプリケーション間通信、アプリケーション統合、ｅ−ｃｏｍｍｅｒｃｅ、
およびメッセージングのデファクト・スタンダードにならない可能性がある。し
たがって、これらのＭＱＭ／ＭＢシステムが、共通のプロトコルを採用し、それ
ら自体の間および他のアプリケーションとの効率的なメッセージングを可能にす
る必要が存在する。

【００１６】 標準的なアプリケーション・プログラミング・インターフェース（ＡＰＩ）が
、異なるアプリケーションの間でアプリケーション・メッセージを送るための部
分的な解決策でもある。Ｃａｎｄｌｅ社のＲｏｍａ ＢＳＰ製品が、そのような
ＡＰＩである。最近（１９９８年以降）、Ｏｐｅｎ Ａｐｐｌｉｃａｔｉｏｎｓ
Ｇｒｏｕｐ（ＯＡＧ）が、ＩＢＭ社のＡｐｐｌｉｃａｔｉｏｎ Ｍｅｓｓａｇ
ｉｎｇ Ｉｎｔｅｒｆａｃｅ（ＡＭＩ）標準規格を採用した。しかし、ＡＭＩの
ような共通のｐｕｔ（）およびｇｅｔ（）のＡＰＩは、必ずしもｓｅｎｄ（）お
よびｒｅｃｅｉｖｅ（）には向いてはいない。

【００１７】 メッセージ指向のミドルウェアは、一般に、非同期式（コネクションレス）ま
たは同期式（コネクション指向）のいずれかとして分類することができる。非同
期メッセージング・キューイング・ミドルウェア（ＭＱＭ）は、従来、同期式の
解決策、主にＲＰＣ（リモート・手続呼出し）よりも柔軟性があり、高機能であ
ると見なされてきた。しかし、ＭＱＭシステムは、コストが高く、かなりのイン
フラストラクチャを必要とする。

【００１８】 ＴＥＬＮＥＴについても言及することができるが、ＴＥＬＮＥＴは、ある形の
オプション・ネゴシエーションをサポートする端末エミュレーション・プロトコ
ルである。ＴＥＬＮＥＴについて、本明細書の「発明の詳述」の節（「ＲＡＣＥ
：ＴＥＬＮＥＴとの比較」）で詳細に述べる。

【００１９】

【発明の実施の形態】

本発明の第１の態様によれば、第１コンピュータ・アプリケーションから第２
コンピュータ・アプリケーションにメッセージを通信する方法であって、第１ア
プリケーションと第２アプリケーションの間のメッセージング互換性が、所定の
オプションのイニシエーションとネゴシエーションとを含むプロトコルを使用し
て確立され、オプションが、追加オプションを含むように拡張可能であるオプシ
ョンの組に属することを特徴とする方法が提供される。

【００２０】 したがって、本発明は、この第１の態様では、「オプション」のネゴシエーシ
ョンを基礎とするアプリケーション間メッセージング用のプロトコルの利用の洞
察に基づいている。「オプション」は、メッセージを転送するための手法（すな
わち、メッセージの通信の正しい手引き）の特徴または特性となりえる。

【００２１】 拡張性は、通常は、一意の識別子を各オプションに割り当てることによって達
成することができる。その一意の識別子（数字であってもよい）が、あらゆるネ
ゴシエーション・ダイアログに利用される。数字を利用してオプションを識別す
ることは、たとえば、オプションの組が簡単に拡張可能であり、無制限であるこ
とを意味する。

【００２２】 一意の識別子を、以下のようにイニシエーションに利用してもよい。接続する
当事者が、本質的に、接続される当事者に所定のオプションの実行または受入を
行うかどうかを尋ねる要求を送信する。好ましい実施形態では、これが「ＤＯ
（オプション識別子）」のようになる。接続される当事者は、そのオプションを
実行できる場合には「ＷＩＬＬ」、そのオプションを実行できない場合には「Ｗ
ＯＮＴ」と言うことができる。

【００２３】 次の例が、実際のオプションおよびオプション・ネゴシエーションの概念を最
もよく示す。第１アプリケーションが、メッセージのバッチを送信することを望
み、それらのメッセージが、バッチ・メッセージ・ファイルに既に保管されてい
ると想像されたい。メッセージは、既にバッチ・メッセージ・ファイル内にある
ので、第１アプリケーションは、まず、第２アプリケーションに、バッチ・メッ
セージ・ファイル転送をサポートするかどうかを尋ねる。第２アプリケーション
が、サポートすると言う場合には、第１アプリケーションは、そのメッセージを
バッチ・メッセージ・ファイルとして転送する。第２アプリケーションが、サポ
ートしないと言う場合には、第１アプリケーションは、「ｐｕｔ／ｇｅｔ」など
、異なるより単純な接続タイプを提案することができる。第２アプリケーション
が合意する場合には、第１アプリケーションは、「ｐｕｔ」を使用して各メッセ
ージを個別に送信することができる。第２アプリケーションが合意しない場合に
は、第１アプリケーションは、「ｓｅｎｄ／ｒｅｃｅｉｖｅ」など、別の接続タ
イプを提案することができる。第２アプリケーションが合意する場合には、第１
アプリケーションは、「ｓｅｎｄ」を使用して各メッセージを個別に送信するこ
とができる。これ以外で第２アプリケーションが合意しない場合には、互換性に
達することができない。

【００２４】 この形で、システムに柔軟性が導入される。というのは、本発明の方法が、複
数の通信プロトコルをサポートするだけではなく、アプリケーションが、たとえ
ば１つまたは複数の共通分母が見つかるまでのネゴシエーションおよび妥協のプ
ロセスを介して、実際の１つまたは複数の通信プロトコルのどれを使用するかを
簡単にネゴシエートできるようにするからである。具体的な例は、本発明の方法
によって、上述のオプション・ネゴシエーションの例で説明した形で、異なるＣ
ＢＴインターフェースがｓｅｎｄ／ｒｅｃｅｉｖｅまたはｐｕｔ／ｇｅｔまたは
バッチのどれを使用する場合であっても、そのＣＢＴインターフェースと通信で
きるようにすることである。

【００２５】 他の当事者は、提案されたオプションをサポートしない場合に、単に「ＷＯＮ
Ｔ」を応答しなければならない。これらの当事者は、異なるオプション・タイプ
に合意することによって妥協することができ、そうでない場合には、メッセージ
ングを確立することができない（基本のデフォルトがない場合）。

【００２６】 すべてではないが、一部のオプションは、パラメータ値によって定義される必
要がある。たとえば、次の、パラメータ値を用いるオプション・ネゴシエーショ
ンを検討されたい。第１アプリケーションが、ウィンドウイング、具体的には１
０のパラメータ値を使用するウィンドウイングのオプションを使用することを望
むと想像されたい。この種のメッセージ・ウィンドウイングは、どの時点でも１
０個までのメッセージを未応答にしておくことができるので、第２アプリケーシ
ョンとのメッセージ伝送が高速になる。第１アプリケーションは、第２アプリケ
ーションがウィンドウイングのオプション、具体的には値１０のウィンドウをサ
ポートするか否かを要求することによって、第２アプリケーションとのダイアロ
グを開始する。第２アプリケーションが、２のウィンドウをサポートするだけで
あると想像されたい。第２アプリケーションは、ウィンドウイングをサポートす
るが、２までのウィンドウだけであると述べることによって応答する。第１アプ
リケーションは、これを受け入れる。このダイアログ全体を、「ネゴシエーショ
ン」とみなすこともでき、したがって、本明細書ではこの用語を使用する。多く
の従来技術のシステムでは、あるアプリケーションから別のアプリケーションへ
の１メッセージの固定ウィンドウがあり、追加オプションを含むようにシステム
を拡張する余地がない。これは、明らかに、本発明の「拡張可能なネゴシエート
されるオプション」方法より柔軟性が少ない。

【００２７】 本発明では、ネゴシエーションが、あらゆる所定のメッセージング・オプショ
ンの許容可能なパラメータ値の範囲内で行われることが好ましい。したがって、
もう一度ウィンドウイングを使用すると、許容可能なパラメータ値の範囲を１か
ら１０までとすることができ、前の例では、送信側が１０までをサポートし、受
信側が２または２までをサポートする。しかし、オプションの中には、パラメー
タ値を含まないものがある。

【００２８】 どのオプション・パラメータ値でも、ネゴシエートするための要求に含めるこ
とができ、これによって、ネゴシエーションが高速になる。というのは、通常、
２「ラウンド・トリップ」ではなく、１「ラウンド・トリップ」だけのネゴシエ
ーションが必要になるからである。必要な場合には、さらに追加パケットを用い
てオプションをネゴシエートすることができる。また、接続する当事者は、単一
のトランザクションで、できる限り多数の、それがサポートするオプションを宣
言することができ、やはりネゴシエーションが高速になる。

【００２９】 好ましい実施形態では、接続する当事者が、「ＤＯ オプション・タイプ」要
求を送り、接続される当事者が、そのオプション・タイプをサポートする場合に
「ＷＩＬＬ」応答を送る。接続する当事者だけが、ネゴシエーションを開始する
ことができる。この手法によって、ネゴシエーションを制御し、妥協することが
できる接続する当事者がもたらされる。

【００３０】 「片側イニシエーション」によって、実装がかなり簡単になり、端末をエミュ
レートするためのＴＥＬＮＥＴプロトコルで発生する、対称ネゴシエーションで
生じる可能性がある無限ループがなくなる（ＴＥＬＮＥＴに関する注釈について
は、「発明の詳述」を参照されたい）。対称ネゴシエーションは、本発明の可能
性でもある。

【００３１】 さらに、ネゴシエーションを、アプリケーションの間の会話の初期の限られた
回数または単独の発生だけに制限することができる。これによって、実装がかな
り簡単になり、ＴＥＬＮＥＴで発生する可能性がある無限ネゴシエーション・ル
ープが発生しなくなる。

【００３２】 第２アプリケーションを、メッセージ指向のプロトコルまたはＡＰＩとするこ
とができるので、このプロトコルによって、メッセージ指向のプロトコルおよび
アプリケーション・インターフェースへのマッピングが可能になる（すなわち、
相互運用性が達成される）。これは、ストア・アンド・フォワード機能性なしで
達成することができる。

【００３３】 第２の態様によれば、第１コンピュータ・アプリケーションから第２コンピュ
ータ・アプリケーションにメッセージを通信する方法であって、第１アプリケー
ションと第２アプリケーションの間のメッセージング互換性が、所定のオプショ
ンのネゴシエーションだけに制限される必須要素を有する言語を使用するプロト
コルを使用して確立され、オプションが、追加オプションを含むように拡張可能
であるオプションの組に属することを特徴とする方法が提供される。

【００３４】 この態様でオプション・ネゴシエーション言語によって例示される単純なコア
言語（すなわち「基本プロトコル」）の使用には、より単純なシステムの設計と
、通信の開始点およびメッセージングのデフォルト（ならびにオプション設計フ
ェーズ中のオプション仕様のデフォルト）の構成とのしやすさなどの多数の長所
がある。他のオプションおよびオプションのさまざまな値を含めるための拡張性
があるので、単純さが、より複雑なシステムを設計する能力を損なうことはない
。プロトコル言語に、接続要求を追加することができ、この接続要求は、通常は
、接続される当事者によってサポートされる。定義済みの切断言語を使用するこ
ともできる。

【００３５】 好ましい実施形態では、オプション・ネゴシエーションは、ターゲット・サー
ビスおよびターゲット・アプリケーションが接続要求パケットで指定されるまで
発生しない。認証性、暗号化（保護された認証性、機密性、および保全性）、お
よびユーザ・パスワードを、ネゴシエーション中に提供することができる。

【００３６】 第３の態様では、第１コンピュータ・アプリケーションから第２コンピュータ
・アプリケーションにメッセージを通信する方法であって、第１アプリケーショ
ンまたは第２アプリケーションもしくはその両方が、上で述べた本発明の第１ま
たは第２の態様で定義されるプロトコルに対する属性を宣言する、方法が提供さ
れる。

【００３７】 属性は、アプリケーションの特性であり、アプリケーションがサポートできる
特徴である。すべての属性が、オプションに直接に関連するわけではないが、プ
ロトコルでは、オプションに関連するこれらの宣言された属性を、関連するオプ
ションをネゴシエートするための指示として扱うことができる。

【００３８】 好ましい実施形態では、第１アプリケーションまたは第２アプリケーションも
しくはその両方が、属性を宣言する。その後、関連するオプションが、プロトコ
ルを介してネゴシエートされる。最終チェックとして、アプリケーション属性に
従うために、ネゴシエーション結果を検証する。

【００３９】 「属性」と「オプション」を区別することが重要である。オプションは、プロ
トコルに属し、ネゴシエートされ、一意のオプション識別子を与えられ、オプシ
ョン仕様として文書化される。オプションは、ネゴシエートすることができる選
択肢を表す。その一方で、属性は、アプリケーションに属し、アプリケーション
の特性である。属性は、オプション・ネゴシエーションを生成し、ネゴシエーシ
ョンの結果の突合せを可能にするために宣言される。属性は、アプリケーション
がサポートすることに合意する特性である。

【００４０】 もう１つの態様では、アプリケーション、サービス、接続、またはメッセージ
のアドレスの一部として名前を割り当て、又は、使用する方法であって、メッセ
ージが、前記方法のいずれかを使用して通信される方法がある。もう１つの態様
では、上の発明的方法のいずれかを使用して標準ＡＰＩを確立する方法がある。

【００４１】 本発明のプロトコルは、英国のＧｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗ
ｏｒｋｓ Ｌｉｍｉｔｅｄ社によって開発されたＲＡＣＥ Ｐｒｏｔｏｃｏｌに
よって例示される。このプロトコルを、以下の「発明の詳述」でさらに説明する
。ＲＡＣＥは、メッセージを転送する際のアプリケーション通信と接続性を扱う
。

【００４２】 もう１つの態様では、上の発明的方法のいずれかを使用するアプリケーション
統合の方法が提供される。ポリシ、アダプタ、およびエージェントも、上述の方
法のいずれかを使用して追加することができる。技術用語「アプリケーション統
合」、「ポリシ」、「アダプタ」、および「エージェント」を以下に定義する。

【００４３】 アプリケーション統合とは、データ、情報、ワークフロー、およびプロセスを
、制限なくアプリケーション間において共用することをいう。この規律には、通
信ミドルウェア（メッセージ指向ミドルウェア、メッセージングＡＰＩ、同期式
メッセージング、非同期式メッセージング、アプリケーション間通信、およびメ
ッセージングが含まれる）、データベース・ミドルウェア、およびシステム・ミ
ドルウェアなどの技術の組が含まれる。アプリケーション統合は、すべてのレベ
ル（たとえば、ビジネス／ユーザ、アプリケーション、ＡＰＩ、トランスポート
／データ）で実行される。エンタープライズ・アプリケーション統合（ＥＡＩ）
およびインターネット・アプリケーション統合（ＩＡＩ）は、組織内および組織
間とインターネット上でのアプリケーション統合を説明する専門語である。アプ
リケーション統合内で、主要な目標は、アプリケーション・インターフェースを
、たとえば単純なｐｕｔ／ｇｅｔ、ｓｅｎｄ／ｒｅｃｅｉｖｅ、またはデータベ
ースのｗｒｉｔｅ／ｒｅａｄに簡略化することである。アプリケーション・イン
ターフェースを簡略化することによって、アプリケーションの統合が簡単になり
、統合をより早く行える。もう１つの主要な目標は、アプリケーションをそのメ
ッセージングから疎に結合（または分離）することである。アプリケーション・
インターフェースを簡略化し、分離することによって、以前にはアプリケーショ
ン内にあった機能性を、アプリケーションの外部に移動することができる。アプ
リケーションの外部に移された機能性は、より簡単に変更でき、有用品として提
供することができる。

【００４４】 ポリシとは、基礎となる機能（この場合にはアプリケーション間通信）を駆動
するための、アプリケーションの外部に存在する定義である。ポリシは、アプリ
ケーションを変更せずに定義し、変更することができる。ポリシでは、セキュリ
ティなど、機能に影響するが、アプリケーションが知る必要がない特徴が導入さ
れる。

【００４５】 アダプタとは、２つの非互換アプリケーション・インターフェースの間の接続
性、変換、および翻訳を提供する、ソフトウェア・コンポーネントである。たと
えば、Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉｍｉｔｅｄ
社は、異なるＣＢＴインターフェース、ＭＱＭ／ＭＢシステム、ＡＰＩ、および
プロトコルの間でメッセージを交換するアダプタを作成する。あるアダプタが、
ＲＡＣＥとＬｏｇｉｃａ社のＣＢＴの間で話すことになる。もう１つのアダプタ
が、ＲＡＣＥとＳＷＩＦＴ自体のＣＢＴのうちの１つとの間で話すことになる。
この場合、アプリケーションは、ＲＡＣＥを使って、Ｌｏｇｉｃａ社の製品また
はＳＷＩＦＴ製品のいずれかと話すことができる。その代わりに、第３のアダプ
タによって、アプリケーションがいずれかと話すことができる。アダプタは、既
製品または１個限り（注文品）とすることができる。人々は即座の接続を求める
ので、アダプタが有用品になればなるほどよい。アダプタは、使い易さおよび管
理しやすさのために、ＲＡＣＥ Ｓｅｒｖｉｃｅｓ（ＲＡＣＥ Ｓｅｒｖｉｃｅ
ｓの注釈については、「発明の詳述」を参照されたい）などの共通の環境を必要
とする。アダプタは（ほとんどの他のメッセージング製品と同様に）、安全で信
頼性があるものでなければならない。ＲＡＣＥプロトコルを用いると、アダプタ
およびＲＡＣＥアプリケーションを、シームレスにプラグインすることすなわち
、プラグアンドプレイが可能になる。

【００４６】 エージェントとは、アダプタと同様に、アプリケーションの外部で機能性を追
加するソフトウェア・コンポーネントである。たとえば、セキュリティ・アルゴ
リズム、ディレクトリ・サービスなどである。やはり、エージェントは、使い易
さおよび管理しやすさのために、ＲＡＣＥ ＡＰＩおよびＲＡＣＥ Ｓｅｒｖｉ
ｃｅｓなどの共通の環境を必要とする。

【００４７】 本発明の最後の態様では、本発明の方法を実行するようにプログラムされたコ
ンピュータ・ハードウェア装置、コンピュータ・ハードウェアが本発明の方法を
実行できるようにするソフトウェアを用いてプログラムされた記憶媒体、および
本発明の方法を使用するかこれに頼って交換されるアプリケーション・メッセー
ジが提供される。

【００４８】 [発明の詳述] 本発明を、英国のＧｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌ
ｉｍｉｔｅｄ社によって開発され、配布され、実施を許諾される、ＲＡＣＥ Ｐ
ｒｏｔｏｃｏｌと称する実施形態に関してさらに説明する。ＲＡＣＥは、Ｇｌｏ
ｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉｍｉｔｅｄ社の商標であ
り、Ｒａｐｉｄ Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ａｎ
ｄ Ｅｍｕｌａｔｉｏｎの頭字語である。ＲＡＣＥは、アプリケーション・メッ
セージの転送、メッセージング・インターフェース間の適合、アプリケーション
の結合／分離、アプリケーション統合の支援、相互運用性の使用可能化、および
メッセージングおよびｅ−ｃｏｍｍｅｒｃｅの本質的な標準規格の提供のために
、コンピュータ・システム間の通信の共通言語となるように設計されている。

【００４９】 ＲＡＣＥは、アプリケーションが互いに通信し、メッセージを渡す方法を標準
化する、アプリケーション間通信プロトコルである。ＲＡＣＥは、インターネッ
トおよび企業ネットワーク用に設計されているが、原則として、どのネットワー
ク上でも使用することができる。付録１に、ＲＡＣＥのより詳細な扱いを示す、
ソフトウェア開発者用のＲａｃｅ Ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉ
ｏｎ Ｖｅｒｓｉｏｎ １．１（草案）を示す。

【００５０】 ＲＡＣＥの長所は、この頭字語を詳細に検討することによって要約することが
できる。ＲＡＣＥは、開発者がすばやくアプリケーションを統合できるようにし
、メッセージを極端にすばやく転送できるようにするので、「Ｒａｐｉｄ」（高
速）である。語「Ａｐｐｌｉｃａｔｉｏｎ」（アプリケーション）が使用されて
いるのは、ＲＡＣＥが、アプリケーション間のプロトコルであり、アプリケーシ
ョン・メッセージの転送を扱うからである。「Ｃｏｍｍｕｎｉｃａｔｉｏｎ」（
通信）が使用されているのは、ＲＡＣＥが通信プロトコルであるからである。「
Ｅｍｕｌａｔｉｏｎ」（エミュレーション）が適用されるのは、ＲＡＣＥを用い
てアプリケーションをエミュレートできるからである。ＲＡＣＥは、現代のコン
ピュータ・システムが簡単に利用することができる。［発明の実施の形態］で定
義される、ネゴシエートされるオプションによって、アプリケーションから独立
の、安全で信頼性があり高速のメッセージングが可能になる。ネゴシエートされ
るオプションを用いて、ＲＡＣＥが、他のすべてのメッセージ転送プロトコルを
肩代わりすることができる、先例のない機能の組を提供することができる。

【００５１】 [ＲＡＣＥ：ＴＥＬＮＥＴとの比較] ＲＡＣＥは、周知のインターネット・プロトコルであるＴＥＬＮＥＴに表面上
類似する部分がある。ルータおよびプリンタなどの専用装置を含むコンピュータ
・システムの大多数がＴＥＬＮＥＴを利用する。ＴＥＬＮＥＴは、端末をエミュ
レートできるようにする汎用プロトコルである。コンピューティングの初期の時
代には、メインフレーム・コンピュータに多数の物理的な端末が接続されていた
。現在、ＴＥＬＮＥＴが物理的接続を置換し、リモート・アクセスを提供するの
に幅広く使用されている。ＴＥＬＮＥＴによって、端末が端末と通信すること、
コンピュータがコンピュータに通信することも可能になる。しかし、ＴＥＬＮＥ
Ｔには、メッセージの先頭と末尾を定義するのに本質的に必要な境界の概念が含
まれないので、ＴＥＬＮＥＴを使用してメッセージをすばやく通信することはで
きない。

【００５２】 ＴＥＬＮＥＴとＲＡＣＥは、いくつかの概念的な類似性を共有する。両者は、
たとえば、そのプロトコルが行えることの「基本プロトコル」を前提としている
。ＴＥＬＮＥＴの場合、基本プロトコルは、限られた文字セットを用いた仮想端
末からの通信である。ＲＡＣＥの場合、基本プロトコルは、本明細書で前に説明
した接続および基本オプション・ネゴシエーションである。単純な基本プロトコ
ルは、それを用いてほとんどのコンピュータ・システムで簡単な実装が可能にな
るので、非常に有利である。

【００５３】 第２に、ＴＥＬＮＥＴとＲＡＣＥは、オプションをネゴシエートする方法が基
本プロトコルに組み込まれ、その結果、夫々のプロトコルを「動的に」拡張でき
るようになっている（すなわち、挙動を、プログラム作成時に固定するのではな
く、接続中に変更することができ、新しいアプリケーションを簡単に統合するこ
とができる）。ＲＡＣＥの場合、接続するアプリケーションが、あるオプション
を実行できる場合に、そのアプリケーションは、まず、他方のアプリケーション
がそのオプションをサポートするかどうかを尋ねる。そのアプリケーションは、
自由裁量のパラメータ値と共に「ＤＯ」及び／または「ＷＩＬＬ」「オプション
」を送信する。「ＤＯ」は、オプションを要求するために送信される。「ＷＩＬ
Ｌ」は、オプションを提供するために送信される。他方のアプリケーションは、
そのオプションをサポートしない場合に、それぞれ「ＷＯＮＴ」及び／または「
ＤＯＮＴ」「オプション」を応答する。そうでない場合には、自由裁量のパラメ
ータ値と共に「ＤＯ」及び／または「ＷＩＬＬ」「オプション」を応答し、その
後、この２つのアプリケーションは、オプション仕様に応じて、そのオプション
を仮定するか、さらにネゴシエーションを行う。これは、あらゆるアプリケーシ
ョンが、非常に基本的な語彙を用いてＲＡＣＥ会話に参加できることを意味する
。その一方で、これは、ほとんどすべてのことを行うためにこのプロトコルを拡
張できることも意味する。実際、オプションで、基本プロトコルを否定すること
ができる。

【００５４】 さらに、ＴＥＬＮＥＴは、インターネット・コミュニティのために公表された
。ＴＣＰ／ＩＰなどの基礎となるインターネット・プロトコルが一般化するにつ
れて、ＴＥＬＮＥＴも一般化した。ＲＡＣＥでは、同一の信頼性のある８ビット
ＴＣＰトランスポートを仮定することができ（実際にはすべての信頼性のあるト
ランスポートが適当であるが）、ＴＥＬＮＥＴに似たＩｎｔｅｒｐｒｅｔ−Ａｓ
−Ｃｏｍｍａｎｄ（ＩＡＣ：コマンドとして解釈される）文字を使用することが
できる（実際には特殊な区切り文字のプレフィックスに使用されるが）。ＲＡＣ
Ｅは、インターネット・コミュニティの標準規格として公開することもできる。

【００５５】 ＲＡＣＥは、ＴＥＬＮＥＴと多くの重要な相違がある。ＲＡＣＥの目的は、ア
プリケーション・メッセージの転送であるが、ＴＥＬＮＥＴの目的は、端末のエ
ミュレーションである。したがって、ＲＡＣＥは、デフォルトでパケットを使用
する単一方向バイナリ転送を提供するが、ＴＥＬＮＥＴは、デフォルトで、パケ
ット境界のない、テキストおよび端末制御文字の両方向転送を提供する。ＲＡＣ
Ｅがこの手法を採用するのは、追加の機能性の範囲を失わずに最初の実装を簡単
にするためである。

【００５６】 ＲＡＣＥは、オプション・ネゴシエーションでも異なる。ＴＥＬＮＥＴでは、
オプション・ネゴシエーションが対称であり、接続中のいつでも行うことができ
る。ＲＡＣＥでは、片側すなわち接続する側だけが、ネゴシエーションを開始す
ることができ、これは、会話の開始時においてのみ行うことができる。ＲＡＣＥ
のオプション・ネゴシエーションに対する手法によって、接続する当事者の実装
がさらに簡単になる。というのは、ネゴシエーションをサポートする必要がない
からである。接続される当事者も、実装が簡単になる。というのは、ネゴシエー
ションが、基本プロトコル内の１点だけで発生するからである。その後、接続す
る当事者と接続される当事者の両者が、安定した機能セットを想定することがで
きる。さらに、接続される当事者は、ＷＯＮＴまたはＤＯＮＴをサポートする必
要がない。というのは、接続する当事者が、デフォルトでＷＯＮＴまたはＤＯＮ
Ｔを開始できないからである。この手法によって、そうでなければかなりの考慮
とプログラミングによって防がなければならない無限ネゴシエーション・ループ
が回避される。オプション仕様でこれを否定することができ、したがって、この
手法では、接続中の任意の時点での対称ネゴシエーションが排除されない。ＲＡ
ＣＥのオプション・ネゴシエーションは、より高速でもある。というのは、ネゴ
シエーション・パラメータが、ネゴシエーションの要求と共に含まれるからであ
る。ＴＥＬＮＥＴでは、こうなっておらず、ネゴシエーション・パラメータが必
要な場合には、１ラウンド・トリップではなく２ラウンド・トリップが必要であ
る。

【００５７】 ＴＥＬＮＥＴによって端末をエミュレートできるのと同様に、ＲＡＣＥでは、
アプリケーションをエミュレートすることができる。アプリケーション・メッセ
ージ標準が確立された後に、アプリケーションを簡単にエミュレートすることが
できる。このエミュレーションは、新しい種類のアプリケーションすなわち、既
存のアプリケーションの間に入り、個々のアプリケーションまたは集合的なアプ
リケーションの価値を拡張でき、強化できるアプリケーションに取って代わられ
る。

【００５８】 [ＲＡＣＥの他の特徴] ＲＡＣＥは、コネクション指向とコネクションレスの両方にすることができる
。接続する当事者が、ＭＱＭインフラストラクチャ（非同期式のコネクションレ
スである）に接続するのにＲＡＣＥを使用するが、存在することが保証される（
たとえば、ＭＱＭと同一の計算機に常駐するので）場合には、ＭＱＭと同一のコ
ネクションレス特性を共有する。その一方で、接続する当事者が、ホスト・アプ
リケーションに直接に接続する場合には、コネクション指向になる（ストア・ア
ンド・フォワード・インフラストラクチャが不要になるので、実際に実装するコ
ストがはるかに安くなる）。

【００５９】 ＲＡＣＥは、異なるメッセージ指向のミドルウェア技術およびシステムの間の
接続のための標準も提供する。現在（１９９８年時点）、ＲＡＣＥに似たプロト
コルを標準として使用するための唯一の代替案は、Ｃａｎｄｌｅ社のＲｏｍａ
ＢＳＰ製品などの標準ＡＰＩを使用することである。

【００６０】 ＲＡＣＥを用いると、ＲＡＣＥ接続の他方を変更せずに、アプリケーションお
よびアダプタのスワップ・インおよびスワップ・アウトを行えるようになる、す
なわち、アダプタ、アプリケーション、ＭＱＭ、およびＭＢを、真の有用品にす
ることができる。Ｒｏｍａ ＢＳＰの場合、コード（異なるＭＱＭまたはＭＢに
接続するための）を、接続の他方に追加しなければならない。これは、アプリケ
ーションが、新しいＭＱＭまたはＭＢシステムをサポートできるようになる前に
再コンパイルされリンクされる、または新しい実行時モジュールを追加するのい
ずれかが必要であることを意味する。

【００６１】 さらに、ＲＡＣＥを用いると、ＴＣＰ／ＩＰで、割り当てられたＴＣＰ／ＵＤ
Ｐポート番号が可能になるように、階層化されたプロトコル、サービス、および
アプリケーションの割り当てられた名前も可能になる。

【００６２】 ＲＡＣＥは、インターネットおよび企業ネットワーク上でｅ−ｃｏｍｍｅｒｃ
ｅを行うのに使用できるのと同様に、ＳＷＩＦＴ Ｎｅｔ Ｌｉｎｋ（ＳＮＬ）
の有無を問わずに、新しいＳＷＩＦＴネットワークと直接に通信し、その上で通
信する方法も提供することができる。

【００６３】 [ＲＡＣＥのオプションの一部の説明] ＲＡＣＥでは、オプションが、オプション番号によって一意に識別される。オ
プションの番号付けによって、最初のＲＡＣＥプロトコル・リリースまたはＲＡ
ＣＥ Ｓｐｅｃｉｆｉｃａｔｉｏｎの一部ではない、将来の番号付けまたは実験
的番号付けが可能になる。

【００６４】 ＮＯＲＥＰＬＹ：応答を返し、待ち、解釈しなければならない場合の基本プロ
トコルの挙動を否定する。これによって、このプロトコルが、（ｉ）アプリケー
ションが、アプリケーション・レベルで肯定応答／応答／同期化を処理する場合
、または（ｉｉ）アプリケーションが、メッセージを発し、メッセージがそこに
到着し、解釈されるかどうかを忘れる／無視する場合のいずれかの異なるアプリ
ケーションに役立つようになる。

【００６５】 ＷＩＮＤＯＷ：これは、アプリケーション間のメッセージの伝送を高速化する
のに使用される技法である。応答が必要な場合には、通常は、アプリケーション
は、次のメッセージを送る前に、応答を待つ。ウィンドウイングを使用すること
によって、メッセージ応答を待たずに複数のメッセージを送ることができる。し
たがって、未解決のメッセージのウィンドウがある。これによって、はるかによ
い性能が与えられるが、１）リンクに障害が発生した場合に、未解決のメッセー
ジのすべてを送りなおし、調停しなければならず、２）送信する側でのプログラ
ムが複雑になる。すなわち、送信するプログラムが、送信したものと未解決の応
答を記憶しなければならない。

【００６６】 ＬＧＲＰ：ＬＧＲＰとは、「ｌｏｇｉｃａｌ ｇｒｏｕｐｉｎｇ」（論理グル
ープ化）である。これは、単一の作業単位として扱われなければならない、すな
わち、全体として処理される、複数のメッセージを識別する方法である。これは
、１）バッチ指向アプリケーションからのメッセージのバッチの処理、２）トラ
ンザクションを全体として完了するためにトランザクションのすべての部分（メ
ッセージ）を完了しなければならないトランザクションのために重要である。ト
ランザクションの一部が失敗する場合には、トランザクション全体が失敗し、行
われたことがロール・バックされる。

【００６７】 追加オプションには、ＭＯＤＥ、ＳＥＱＮＯ、ＰＤＥ、ＲＲＥＦ、ＬＧＩＡＵ
ＴＨ、ＭＳＧＡＵＴＨ、ＭＳＧＬＥＮ、ＢＡＴＣＨ、ＮＯＭ、およびＢＩＧＦＯ
ＯＴが含まれる。将来のオプションに、暗号化、圧縮、ｇｅｔ／ｐｕｔ、ポーリ
ング、メッセージおよびファイルのブロック転送、およびアタッチメントのオプ
ションを含めることができる。

【００６８】 ＲＡＣＥオプションの総合的な説明については、付録１を参照されたい。

【００６９】 また、ＲＡＣＥ ＡＰＩを用いると、ポリシおよびエージェントによってアプ
リケーション属性およびネゴシエーションを指示することができる。

【００７０】 [ＲＡＣＥ ＡＰＩ] ＲＡＣＥ ＡＰＩは、Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉｍｉｔｅｄ社のＲＡＣＥ Ｐｒｏｔｏｃｏｌの実装である。ＲＡＣＥ Ａ
ＰＩは、開発者のためのＲＡＣＥ Ｐｒｏｔｏｃｏｌへのアクセスを提供し、す
ばやくポータブルなアプリケーション統合を容易にする。

【００７１】 ＲＡＣＥ ＡＰＩは、アプリケーション属性という概念を導入するのでユニー
クである。各アプリケーションは、サポートすることに合意する属性を宣言する
。デフォルトで、これらの属性は、ＲＡＣＥ Ｐｒｏｔｏｃｏｌの「基本プロト
コル」に近い。ＲＡＣＥ ＡＰＩでは、ＲＡＣＥ Ｐｒｏｔｏｃｏｌオプション
をネゴシエート（ＲＡＣＥパートナーと）して、属性に互換性があるかどうかを
調べる。そうである場合には、接続が確立され、アプリケーションが、どの属性
が合意されたかを調べることができる。そうでない場合には、接続がクローズさ
れる。ＲＡＣＥ ＡＰＩでは、ポータブルで極端に柔軟な独自のアプリケーショ
ン・プログラム・インターフェース（ＡＰＩ）も提供される。

【００７２】 したがって、ＲＡＣＥ ＡＰＩは、デフォルトとして、次のように動作する。 ａ）アプリケーションにその属性を宣言させ、 ｂ）それに従ってプロトコル・オプションをネゴシエートし、 ｃ）ネゴシエーション結果がアプリケーション属性と一致するかどうかを検
査する。

【００７３】 たとえば、接続するアプリケーション（ＤＴＥ）が以下の属性、ＮＯＲＥＰＬ
Ｙ＿ＯＦＦ、ＭＯＤＥ＿ＯＵＴＰＵＴ、ＰＤＥ＿ＯＮ、およびＰＤＥ＿ＯＦＦを
宣言する。この場合、ＲＡＣＥ ＡＰＩは、ＮＯＲＥＰＬＹをネゴシエートしな
い。というのは、応答が基本プロトコルに含まれる（すなわち、デフォルトで仮
定される）からである。ＲＡＣＥ ＡＰＩは、パラメータＯＵＴＰＵＴのＭＯＤ
Ｅを提案し、継続するためにはそれを突き合わせなければならない。ＲＡＣＥ
ＡＰＩは、ＰＤＥを提案し、ＰＤＥが合意されるか否かに関係なく継続する（ア
プリケーションがＰＤＥおよびＰＤＥなしをサポートするので）。ＡＰＩの第１
の実施形態では、アプリケーションがこのデフォルトを上書きすることができる
。これは、他のプロトコルへのマッピングのために重要である。また、第１のオ
プションが失敗した場合に第２、第３などのオプションをネゴシエートするため
に、アプリケーションがネゴシエーション中に仲裁できるようにすることが必要
になる場合がある。

【００７４】 属性がオプションに関連する必要はない。たとえば、「ＭＯＤＥ ｃｏｎｔｒ
ｏｌ」をとりあげる。この属性は、ＭＯＤＥ＿ＩＮＰＵＴ、ＭＯＤＥ＿ＯＵＴＰ
ＵＴ、およびＭＯＤＥ＿ＢＯＴＨであり、アプリケーションは、そのうちの１つ
または複数を宣言することができる。オプションは、ＭＯＤＥであり、属性ＭＯ
ＤＥ＿ＯＵＴＰＵＴおよびＭＯＤＥ＿ＢＯＴＨのみについてネゴシエートされる
。また、アプリケーションがＭＯＤＥ＿ＩＮＰＵＴをサポートしない場合に、そ
のアプリケーションが基本プロトコルのＭＯＤＥ制御をサポートしない（まった
く正常である）ことに留意されたい。セキュリティのために、アプリケーション
は、属性ＳＥＣＵＲＥ＿ＯＮおよびＳＥＣＵＲＥ＿ＯＦＦを使用することができ
る。セキュリティが必要な場合には、ＳＥＣＵＲＥ＿ＯＮを宣言する。そうでな
い場合には、ＳＥＣＵＲＥ＿ＯＦＦを宣言する。どちらでも構わない場合には、
ＳＥＣＵＲＥ＿ＯＮとＳＥＣＵＲＥ＿ＯＦＦの両方を宣言する。これがネゴシエ
ートされる場合には、ＲＡＣＥ ＡＰＩが、まず最高レベルのセキュリティを選
び、下位レベルへ進む。これには、複数のオプションのネゴシエーションを含め
ることができる。

【００７５】 [ＲＡＣＥ Ｃｏｎｎｅｃｔ] ＲＡＣＥ Ｃｏｎｎｅｃｔは、Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗ
ｏｒｋｓ Ｌｉｍｉｔｅｄ社のＲＡＣＥ Ｐｒｏｔｏｃｏｌ用のソフトウェア開
発キット（ＳＤＫ）である。このＳＤＫには、ＲＡＣＥ ＡＰＩが含まれる。

【００７６】 [ＲＡＣＥ Ｓｅｒｖｉｃｅｓおよびアダプタ] ＲＡＣＥ Ｓｅｒｖｉｃｅｓは、Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔ
ｗｏｒｋｓ Ｌｉｍｉｔｅｄ社のエンドユーザ用ソフトウェア製品である。ＲＡ
ＣＥ Ｓｅｒｖｉｃｅｓは、ポリシ、ネーミング、セキュリティ、エージェント
、およびアダプタ（Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌ
ｉｍｉｔｅｄ社およびサード・パーティからの）を管理する統合フレームワーク
を提供する。ＲＡＣＥ Ｓｅｒｖｉｃｅｓを用いると、アプリケーションをすば
やく展開し、エンタープライズ・レベルでリンケージを中央からリモート管理す
ることができる。Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉ
ｍｉｔｅｄ社は、ＭＱＳｅｒｉｅｓおよびＭＳＭＱなどの企業メッセージング・
ストラクチャとバッチ通信と対話型通信の間で切り替えられるようにするための
既製品のアダプタを提供する予定である。アダプタ製品は、ＲＡＣＥ技術に基づ
いて作成される。ＲＡＣＥによって、アダプタが、自然に、類似するストア・ア
ンド・フォワード解決策より高速になり、プラグアンドプレイが促進される。

【００７７】 [付録１] ＲＡＣＥ Ｐｒｏｔｏｃｏｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．１（草案） ＧＬＯＢＡＬ ＦＩＮＡＮＣＩＡＬ ＮＥＴＷＯＲＫＳ ＬＩＭＩＴＥＤ ｗｗｗ．ｇｆｎ．ｃｏ．ｕｋ 英国ハーペンデン 電話：＋４４ （０）１５８２ ４６７ ４８６ [著作権] Ｃｏｐｙｒｉｇｈｔ（Ｃ）Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒ
ｋｓ Ｌｉｍｉｔｅｄ，１９９９。全権留保。この刊行物のどの部分も、Ｇｌｏ
ｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉｍｉｔｅｄ社の書面によ
る事前の許可のない、複写または複製、あらゆる方法または形態または媒体上で
の他の人物への販売または転送を禁止する。

【００７８】 [機密性] この刊行物には、Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌ
ｉｍｉｔｅｄ社からの所有情報が含まれる。受取人は、Ｇｌｏｂａｌ Ｆｉｎａ
ｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉｍｉｔｅｄ社からの書面による許可なくこ
の情報を第三者に開示してはならない。

【００７９】 [否認] Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉｍｉｔｅｄ社は
、内容の正確さを保証するために全力を尽くすが、Ｇｌｏｂａｌ Ｆｉｎａｎｃ
ｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉｍｉｔｅｄ社は、この文書に現れる可能性があ
る故意でない誤りまたは脱落について責任を負わない。

【００８０】 [概要] １．０１ 序 Ｒａｐｉｄ Ａｐｐｌｉｃａｔｉｏｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ａｎｄ
Ｅｍｕｌａｔｉｏｎ（ＲＡＣＥ）Ｐｒｏｔｏｃｏｌは、アプリケーション間通
信および相互運用性に関する標準規格である。このプロトコルの意図は、共通の
インターフェースを提供し、汎用のアプリケーション間メッセージ転送を容易に
することである。

【００８１】 ＲＡＣＥ Ｐｒｏｔｏｃｏｌは、アプリケーションを接続し、メッセージを転
送する、単純で拡張可能な効率的な方法を提供する。アプリケーションは、基本
プロトコルを仮定し、通信中にプロトコルを変更するためにプロトコル・オプシ
ョンをネゴシエートすることができる。実装が単純であり、必要だけに基づくの
で、アプリケーションを簡単に統合することができる。このプロトコルは開放型
なので、あらゆる複雑な通信要件をサポートすることができる。たとえば、この
プロトコルは、保護されたデータ伝送、ウィンドウイング、データ圧縮などをサ
ポートすることができる。単純なプロトコル・オプションを組み合わせることに
よって、ＲＡＣＥは、強力な機能を使用可能にする。このプロトコルは、効率的
であり、最大の転送速度を達成することができる。

【００８２】 ＲＡＣＥは、アプリケーション・メッセージ標準を定義せず、アプリケーショ
ン・メッセージ・オブジェクトとインターフェースしない。すべてのバイナリ・
データと、したがって、アプリケーション・メッセージを、ＲＡＣＥを介して渡
すことができる。アプリケーション・レベルのプロトコルは、ＲＡＣＥの上で階
層化するかＲＡＣＥにマッピングすることができ、ＲＡＣＥがメッセージ応答を
提供するか否かを選択できる。

【００８３】 ネゴシエートされるオプションによって、プロトコル・マッピングが容易にな
り、そうでなければ非互換のアプリケーションが、共通のプロトコルに合意でき
るようになる。ＲＡＣＥにマッピングされた後に、プロトコルは、アプリケーシ
ョンが簡単に話すことができ、他のプロトコルにマッピングすることができる。
アプリケーションをそのメッセージングから分離することによって、ＲＡＣＥは
、複数のプロトコルおよび複数のアプリケーション・インターフェースへの単一
のゲートウェイを提供する。通信は、どのアプリケーションも変更せずに変更す
ることができる。

【００８４】 ＲＡＣＥは、アプリケーションの置換およびエミュレーションを援助する。メ
ッセージ構文が定義された後に、アプリケーションを置換し、エミュレートする
ことができる。ＲＡＣＥは、メッセージ変換自体を実行するのではなく、メッセ
ージング・アプリケーションおよびアダプタを有用品として使用できるようにす
る。ＲＡＣＥの手法は、標準のアプリケーション・プログラミング・インターフ
ェース（ＡＰＩ）だけを使用しては達成できない「プラグアンドプレイ」を与え
る。

【００８５】 ＲＡＣＥは、ＸＭＬと共に、ｅ−ｃｏｍｍｅｒｃｅおよびアプリケーション統
合の基礎の標準を提供する。ＲＡＣＥは、企業ネットワークおよびインターネッ
ト上で良好に動作し、現在のＳＭＴＰメールおよびＨＴＴＰシステムが提供しな
い種類の柔軟性およびスループットを与える。

【００８６】 [動機づけ] 現在、アプリケーション間通信の標準はない。

【００８７】 メッセージングは、桁はずれに成長し、メッセージング・ミドルウェアは、現
在は主要な技術として受け入れられている。同期式の「ｐｕｔ」サービスおよび
「ｇｅｔ」サービスを提供するメッセージ・キューイング・ミドルウェア（ＭＱ
Ｍ）が、ありふれたものになってきた。たとえば、ＩＢＭ社のＭＱＳｅｒｉｅｓ
およびＭｉｃｒｏｓｏｆｔ Ｍｅｓｓａｇｅ Ｑｕｅｕｅ（ＭＳＭＱ）である。
メッセージ・ブローカリング（ＭＢ）システムは、多数あり、ルーティング、ワ
ークフロー管理、およびデータ・マッピングの役割をレガシ・アプリケーション
から引き継ぎ始めている。ミドルウェアの役割が変化し、完全に新しい手法への
道が開かれた。メッセージングの成長は、自動化、グローバライゼーション、ｅ
−ｃｏｍｍｅｒｃｅ、およびリアルタイム清算の必要によって駆り立てられる。

【００８８】 アプリケーション間通信の標準化に対する必要が明らかにある。互いに通信す
る必要があるアプリケーションの数が、劇的に増加し、統合作業が、制御できな
くなりつつある。ＭＱＭシステムおよびＭＢシステムの展開によって、それらの
システムが解決すると思われたものと同数の統合問題が生じる。１つのメッセー
ジング・ミドルウェア解決策だけでは不十分であることは明白である。顧客は、
統合のコストと遅れにいらいらし、だまされたと感じることもしばしばである。
顧客は、一緒に即座に機能することができ、有用品のように使用することができ
るインターオペラブルなアプリケーションを求めている。

【００８９】 ＭＱＭシステムおよびＭＢシステムは、アプリケーション間通信の標準を提供
できない。というのは、これらが、独自であり、高価なストア・アンド・フォワ
ード・インフラストラクチャを必要とするからである。メッセージ・キューイン
グ・システムは、キューイングに必要であるが、接続性の標準ではない。既製の
アプリケーションは、すべてのシステムをサポートすることができず、ユーザが
、単一のシステムを採用すると期待することはできない。組織は、互いに合併し
、通信することを必要とする。ＭＱＭシステムおよびＭＢシステムは、互いに通
信することを必要とする。直接アプリケーション通信が十分である時には、第３
のシステムを使用することが非現実的であることがしばしばである。

【００９０】 標準化団体が、これらの問題に対処するために形成されたが、決定的な勧告を
期待するには早すぎる。採用されている一般的な手法は、アプリケーション・プ
ログラミング・インターフェース（ＡＰＩ）を標準化することであるが、これは
、意味をなすが、「プラグアンドプレイ」解決策を提供しない。「ｐｕｔ」ＡＰ
Ｉおよび「ｇｅｔ」ＡＰＩは、必ずしも「ｓｅｎｄ」および「ｒｅｃｅｉｖｅ」
に向いてはいない。アプリケーションが、異なる形で通信できるようになる前に
、実行時ライブラリをインストールし、テストする必要がある。場合によっては
、アプリケーションをもう一度コンパイルし、リンクする必要がある場合がある
。また、標準ＡＰＩは、異なるプログラミング言語およびコンピューティング・
プラットフォームで変化する。

【００９１】 必要なものは、共通のＡＰＩのほかに、共通のプロトコル（ＲＡＣＥ）である
。プロトコルは、ＡＰＩに似て、オープンで標準的とすることができる仕様であ
る。これには、実装のためのストア・アンド・フォワードのコストが含まれない
。標準プロトコルを用いると、アプリケーションが、そのアプリケーション自体
を変更せずに新しいアプリケーションと通信できるようになる。単純なプロトコ
ルによって、多数による簡単な実装が可能になる。柔軟なプロトコルによって、
他のプロトコルおよびメッセージング・アダプタとの相互運用性が促進される。

【００９２】 既存のプロトコルは、オープンなメッセージング用に設計されておらず、適切
でない。リモート・プロシージャ呼出し（ＲＰＣ）プロトコルは、リモート・プ
ロシージャの呼出しのために企図され、これによって、アプリケーションを分散
することができる。ＲＰＣは、よいアプリケーション通信プロトコルであるが、
ネゴシエーションを行う基本的な能力が欠けている。ＴＥＬＮＥＴプロトコルは
、ネゴシエーションを行うが、完全に異なる目的すなわち、専用端末の置換およ
びエミュレーションのために設計されている。ＴＥＬＮＥＴには、メッセージと
いう概念がない。オブジェクトの定義および内容を扱う他のプロトコルは、階層
化された機能であり、一塊にされた標準ではない。

【００９３】 最後に、分析家は、一部のアプリケーションが、同期式メッセージング（プロ
トコルを使用するコネクション指向メッセージング）ではなく非同期式メッセー
ジング（ＭＱＭを使用するコネクションレス・メッセージング）を必要とすると
信じることがしばしばである。非同期式メッセージングでは、ストア・アンド・
フォワードが用いられ、したがって、ネットワークおよびネットワーク・パート
ナが使用可能でないかどうかに関係ない。その一方で、同期式メッセージングは
、ネットワーク接続とパートナがあることを必要とする。しかし、プロトコルは
、その使用に応じて、非同期式と同期式の両方にすることができる。たとえば、
プロトコルが、ＭＱＭ（ローカル・システム上）との直接通信に使用される場合
には、メッセージングは非同期式であるが、アプリケーションを変更せずに簡単
に同期式にすることができる。ソフトウェア・コンポーネント間の通信にプロト
コルを使用することは、プロシージャ呼出しの使用と比較して、ディスク・アク
セスを伴う時に、大きな性能低下がないので、効率的である。

【００９４】 [一般的な考慮事項] ＲＡＣＥ Ｐｒｏｔｏｃｏｌは、通常は、伝送制御プロトコル（ＴＣＰ）接続
として実施されるが、あらゆる類似するデータ・トランスポート上で使用するこ
とができる。ＲＡＣＥでは、信頼性のある両方向非同期８ビット順序付きバイト
・ストリームを仮定する。ＴＣＰのＵｒｇｅｎｔデータは使用しない。ＴＣＰ使
用について、割り当てられるポート番号が、そのうちに必要になる。

【００９５】 ＲＡＣＥは、２つのアプリケーションの間の通信プロトコルである。ＴＣＰを
使用するＲＡＣＥ接続を形成するために、データ端末装置（ＤＴＥ）と称する１
つのアプリケーションが、データ通信機器（ＤＣＥ）と称する第２のアプリケー
ションへの接続を開始し、このＤＣＥは、割り当てられたポートをリスンする。
ＤＴＥ（接続するアプリケーション）およびＤＣＥ（リスンするアプリケーショ
ン）は、どのコンピュータ・システムでも、同一のコンピュータにも常駐するこ
とができる。ＤＴＥおよびＤＣＥは、同一のアプリケーションとすることができ
る。ＤＴＥアプリケーションおよびＤＣＥアプリケーションが常駐するコンピュ
ータ・システムを、それぞれＤＴＥホストおよびＤＣＥホストと称する。

【００９６】 実際には、ＤＣＥホストが、単一のＴＣＰポート上で複数のＤＣＥアプリケー
ションをサービスすることができる。この場合、ＤＣＥホスト上に、デーモンま
たはサーバ・プログラムが必要である。ＲＡＣＥプロトコルは、異なるＤＣＥア
プリケーションの間のこの種の並行性に向いているが、デーモンの実装およびデ
ーモンとアプリケーションの間のインターフェースの定義は、この文書の範囲外
である。規約によって、ＤＣＥデーモンをＲＡＣＥＤと呼ぶ。

【００９７】 ＴＣＰを介して接続された後に、ＤＴＥアプリケーションおよびＤＣＥアプリ
ケーションは、基本プロトコルを仮定する。基本プロトコルでは、接続、プロト
コル・オプションのネゴシエーション、基本的なメッセージ転送、および切断が
可能である。基本プロトコルは、ＲＡＣＥをそこなわずに単純である。

【００９８】 基本プロトコルから離れるために、ＤＴＥは、１つまたは複数のプロトコル・
オプションのネゴシエーションを開始することができる。これによって、実際の
プロトコルを実行時に合意することができ、プラグアンドプレイが与えられる。
各プロトコル・オプションは、文書化され、一意の番号を割り当てられる。一部
のプロトコル・オプションでは、異なる値および使用法をネゴシエートするため
にパラメータが使用される。

【００９９】 ＲＡＣＥでは、単純さのためおよび無限ネゴシエーション・ループを回避する
ために、片側ネゴシエーションを採用する。ＲＡＣＥでは、パラメータ・データ
を初期ネゴシエーション・シーケンスに含めることができ、その結果、通常は１
ラウンド・トリップだけが必要になる。ＲＡＣＥでは、当初は、ネゴシエーショ
ンがセッションの開始時に制限され、その結果、メッセージ転送が一定になる。
ＤＴＥまたはＤＣＥのいずれかが、ネゴシエーション結果に合意しない場合には
、そのＤＴＥまたはＤＣＥは、メッセージ転送に入る前に切断することができる
。

【０１００】 ＲＡＣＥでは、可変長パケットを使用してデータおよび制御情報を転送する。
これらのパケットは、効率的な伝送のために設計され、単純な形で組み立て、解
釈することができる。

【０１０１】 ＲＡＣＥは、階層化されたプロトコルおよびアプリケーションに関する名前の
割当を容易にする。名前は、１文字から６４文字までであり、これによって、ネ
ーミングに関してＴＣＰポート番号よりはるかに広い範囲が与えられる。

【０１０２】 [基本プロトコル] [ダイアログ] デフォルトで、ＲＡＣＥは単一方向メッセージ転送プロトコルである。片側が
ＤＴＥであり、もう一方がＤＣＥである。メッセージは、ＤＴＥによって準備さ
れ、解釈のためにＤＣＥに転送される。 このプロトコルでは、５つの別個のフェーズが使用される。

【０１０３】 フェーズ１：接続 ＴＣＰ接続の後に、ＤＴＥが、ターゲットＤＣＥのサービスおよびアプリケー
ションを選択するためにＣＯＮＮＥＣＴを送信する。ＤＣＥが接続を受け入れる
ことができる場合には、ＤＣＥはＲＥＡＤＹを応答する。そうでない場合には、
ＤＣＥはＤＩＳＣＯＮＮＥＣＴを応答し、これによって、終了の理由（ＡＰＰＮ
ＯＴＡＶＡ、ＡＰＰＢＵＳＹなど）を示す。

【０１０４】 ＤＣＥがＤＩＳＣＯＮＮＥＣＴを応答した場合には、ＤＣＥとＤＴＥは、対応
するＤＩＳＣＯＮＮＥＣＴがＤＴＥから期待されないので、リンクをクローズし
なければならない。

【０１０５】 フェーズ２：オプション・ネゴシエーション ＤＣＥが接続を受け入れた後に、ＤＴＥの優先順序で、プロトコル・オプショ
ンをネゴシエートする。ＤＴＥが、ネゴシエートされるプロトコル・オプション
を全く有しない場合には、ＤＴＥは、ネゴシエーション・フェーズを完全にスキ
ップすることができる。

【０１０６】 サポートされるオプションのそれぞれについて、ＤＴＥは、オプション仕様に
応じて、オプションの提供、オプションの要求、または提供と要求の両方のいず
れかを行うことができる。オプションを提供するためには、ＤＴＥがＷＩＬＬを
送信する。ＤＣＥが、ＤＴＥが指定されたオプションを実行することを望む場合
には、ＤＣＥはＤＯを応答する。そうでない場合には、ＤＯＮＴを応答する。オ
プションを要求するためには、ＤＴＥがＤＯを送信する。ＤＣＥが指定されたオ
プションを実行できる場合には、ＤＣＥはＷＩＬＬを応答する。そうでない場合
には、ＤＣＥはＷＯＮＴを返す。

【０１０７】 ＤＣＥは、プロトコル・オプションをサポートしない場合に、ＤＯＮＴ／ＷＯ
ＮＴを応答するだけでよい。

【０１０８】 オプション・パラメータが必要な場合には、オプション仕様に従って、ＤＯ／
ＷＩＬＬにオプション・パラメータを含める。オプションが合意された後に、オ
プション仕様に従って、ＨＥＲＥ−ＩＳを使用してさらにネゴシエートすること
ができる。

【０１０９】 ＤＴＥは、ＤＣＥからの対応するＤＯ／ＤＯＮＴ／ＷＩＬＬ／ＷＯＮＴ／ＨＥ
ＲＥ−ＩＳパケットを待たずに、複数のＤＯ／ＷＩＬＬ／ＨＥＲＥ−ＩＳパケッ
トを送信することができる。しかし、一部のオプションが他のオプションに依存
するので、ＤＴＥは、ネゴシエーションの順序について注意しなければならない
。ＤＴＥは、オプションで別途指定されない限り、サポートされるオプションの
それぞれについて１つのＤＯ／ＷＩＬＬパケットだけを送信しなければならない
。

【０１１０】 ネゴシエーションは、ＤＴＥが各ＤＯ／ＷＩＬＬ要求に対するＤＯ／ＷＩＬＬ
／ＤＯＮＴ／ＷＯＮＴ応答を受信し、追加のネゴシエーションが完了した後に完
了する。

【０１１１】 フェーズ３：ＲＥＡＤＹ、ＲＥＡＤＹ ネゴシエーションを終了し、メッセージ転送に入るために、ＤＴＥは、ＲＥＡ
ＤＹを送信する。ＤＣＥは、ネゴシエーションに満足している場合に、ＲＥＡＤ
Ｙを応答し、この２つが、メッセージ転送に入る。そうでなく、ＤＣＥが、ＲＥ
ＡＤＹの受信の後に進行を望まない場合には、ＤＣＥは、ＲＥＡＤＹではなくＤ
ＩＳＣＯＮＮＥＣＴを応答し、これによって終了の理由（ＩＮＳＮＥＧＯＰＴ）
を示す。

【０１１２】 ＤＴＥが、ネゴシエーションの後に進行を望まない場合には、ＤＴＥは、ＲＥ
ＡＤＹではなくＤＩＳＣＯＮＮＥＣＴを送信し、これによって終了の理由（ＩＮ
ＳＮＥＧＯＰＴ）を示す。

【０１１３】 ＤＣＥまたはＤＴＥがＤＩＳＣＯＮＮＥＣＴを送信した場合に、ＤＴＥおよび
ＤＣＥは、対応するＤＩＳＣＯＮＮＥＣＴが期待されないので、リンクをクロー
ズしなければならない。

【０１１４】 フェーズ４：メッセージ転送 転送されるメッセージのそれぞれについて、ＤＴＥは、ＭＥＳＳＡＧＥを組み
立て、送信し、次のメッセージに進む前に、対応するＭＥＳＳＡＧＥ−ＲＥＰＬ
Ｙを待つ。ＤＣＥは、このメッセージを受け入れる場合に、肯定のＭＥＳＳＡＧ
Ｅ−ＲＥＰＬＹ（ＳＵＣＣＥＳＳ）を用いて応答する。そうでない場合には、Ｄ
ＣＥは、否定のＭＥＳＳＡＧＥ−ＲＥＰＬＹを用いて応答し、理由の詳細（ＩＮ
ＶＭＳＧ、…）を示す。ＤＣＥは、入ってくるメッセージの一部またはすべてを
拒絶する場合であっても、それらのメッセージのサービスを継続する。ＤＣＥは
、メッセージを拒絶するのにＭＥＳＳＡＧＥ−ＲＥＰＬＹだけを使用しなければ
ならず、ＤＩＳＣＯＮＮＥＣＴを使用してはならない。

【０１１５】 認証失敗、リソース障害などの場合に、ＤＣＥが、ＤＩＳＣＯＮＮＥＣＴを送
信することによって接続を打ち切る必要がある場合がある。

【０１１６】 フェーズ５：シャットダウン ある点で、どちらかの当事者が、接続のクローズを望む。単一方向接続の場合
、「ｋｅｅｐ ａｌｉｖｅ」タイマが有効でない限り、通常は、メッセージ送信
側が、そのメッセージを転送した後にこれを開始する。

【０１１７】 安全シャットダウンを達成するために、ＤＴＥまたはＤＣＥのいずれかが、コ
ードＳＵＣＣＥＳＳと共にＤＩＳＣＯＮＮＥＣＴを送信することができる。コー
ドＳＵＣＣＥＳＳと共にＤＩＳＣＯＮＮＥＣＴを受信した時に、他方の当事者は
、その処理を完了し、コードＳＵＣＣＥＳＳと共に対応するＤＩＳＣＯＮＮＥＣ
Ｔを返さなければならない。第２のＤＩＳＣＯＮＮＥＣＴの受信時またはこれの
送信の後に、リンクをクローズすることができる。

【０１１８】 ＤＣＥがシャットダウンを要求し、ＤＩＳＣＯＮＮＥＣＴが受信されていない
場合には、ＤＣＥは、適当な時間の間、メッセージの受け入れを継続し、応答を
返さなければならない。ＤＴＥが、メッセージ応答を待っている間にＤＩＳＣＯ
ＮＮＥＣＴを受信した場合には、ＤＴＥは、メッセージ応答を待ち続け、その後
に対応するＤＩＳＣＯＮＮＥＣＴを送信しなければならない。ＤＴＥは、未解決
のメッセージ応答がない時に限ってシャットダウンを要求しなければならず、そ
の後に追加メッセージの送信に進んではならない。

【０１１９】 シャットダウン機構でパケットが導入され、基本プロトコルではＤＣＥがこの
パケットを開始できることに留意されたい。さらに、ＤＴＥまたはＤＣＥは、い
つでもＤＩＳＣＯＮＮＥＣＴを使用して接続を打ち切ることができる。したがっ
て、ＤＴＥは、このイベントを処理する準備ができている必要がある。

【０１２０】 たとえば、基本的なセッションは次の通りである。 ＤＴＥ ＤＣＥ −−− −−− ＣＯＮＮＥＣＴ（"ｒａｃｅ＄ｇｅｎｅｒｉｃ"，"ＴＥＳＴＡＰＰＬ"，）
→ ← ＲＥＡＤＹ（） ＲＥＡＤＹ（） → ← ＲＥＡＤＹ（） ＭＥＳＳＡＧＥ（"Ｈｅｌｌｏ Ｗｏｒｌｄ！"） → ← ＭＥＳＳＡＧＥ−ＲＥＰＬＹ（ＳＵＣＣＥＳＳ） ＤＩＳＣＯＮＮＥＣＴ（ＳＵＣＣＥＳＳ） → ← ＤＩＳＣＯＮＮＥＣＴ（ＳＵＣＣＥＳＳ）

【０１２１】 たとえば、通常の両方向セッションは次の通りである。 ＤＴＥ ＤＣＥ −−− −−− ＣＯＮＮＥＣＴ（"ｒａｃｅ＄ｇｅｎｅｒｉｃ"，"ＴＥＳＴＡＰＰＬ"，）
→ ← ＲＥＡＤＹ（） ＤＯ（ＭＯＤＥ，ＢＩＤＩＲＥＣＴＩＯＮＡＬ） → ← ＷＩＬＬ（ＭＯＤＥ，ＢＩＤＩＲＥＣＴＩＯＮＡＬ） ＷＩＬＬ（ＷＩＮＤＯＷ，３） → ＤＯ（ＷＩＮＤＯＷ，３） → ← ＤＯＮＴ（ＷＩＮＤＯＷ） ← ＷＯＮＴ（ＷＩＮＤＯＷ） ＲＥＡＤＹ（） → ← ＲＥＡＤＹ（） ＭＥＳＳＡＧＥ（"１ＳＴ ＣＬＩＥＮＴ ＭＳＧ"） → ← ＭＥＳＳＡ
ＧＥ−ＲＥＰＬＹ（ＳＵＣＣＥＳＳ） ＭＥＳＳＡＧＥ（"２ＮＤ ＣＬＩＥＮＴ ＭＳＧ"） → ← ＭＥＳＳＡＧＥ（"１ＳＴ ＨＯＳＴ ＭＳＧ"） ← ＭＥＳＳＡＧＥ−ＲＥＰＬＹ（ＳＵＣＣＥＳＳ） ＭＥＳＳＡＧＥ−ＲＥＰＬＹ（ＳＵＣＣＥＳＳ） → ＤＩＳＣＯＮＮＥＣＴ（ＳＵＣＣＥＳＳ） → ← ＭＥＳＳＡＧＥ（"２
ＮＤ ＨＯＳＴ ＭＳＧ"） ＭＥＳＳＡＧＥ−ＲＥＰＬＹ（ＳＵＣＣＥＳＳ） → ← ＤＩＳＣＯＮＮＥＣＴ（ＳＵＣＣＥＳＳ）

【０１２２】 たとえば、ＤＴＥがオプション・ネゴシエーションを拒絶する。 ＤＴＥ ＤＣＥ −−− −−− ＣＯＮＮＥＣＴ（"ｒａｃｅ＄ｇｅｎｅｒｉｃ"，"ＴＥＳＴＡＰＰＬ"，）
→ ← ＲＥＡＤＹ（） ＤＯ（ＭＯＤＥ，ＯＵＴＰＵＴ） → ← ＷＯＮＴ（ＭＯＤＥ） ＤＩＳＣＯＮＮＥＣＴ（ＩＮＳＮＥＧＯＰＴ） →

【０１２３】 たとえば、ＤＣＥがオプション・ネゴシエーションを拒絶する。 ＤＴＥ ＤＣＥ −−− −−− ＣＯＮＮＥＣＴ（"ｒａｃｅ＄ｇｅｎｅｒｉｃ"，"ＴＥＳＴＡＰＰＬ"，）
→ ← ＲＥＡＤＹ（） ＲＥＡＤＹ（） → ← ＤＩＳＣＯＮＮＥＣＴ（ＩＮＳＮＥＧＯＰＴ）

【０１２４】 これらの例では、ＭＯＤＥプロトコル・オプションおよびＷＩＮＤＯＷプロト
コル・オプションと両方向メッセージ転送が、基本プロトコルの一部でない。基
本プロトコルには、ネゴシエートする能力だけが含まれ、オプション自体または
それに関連するプロトコルは含まれない。

【０１２５】 タイムアウトまたはプロトコル・エラーなど、予期されないエラーの場合には
、プログラムは、可能であれば、エラーの詳細を示すためにＤＩＳＣＯＮＮＥＣ
Ｔを送信し、その後にリンクをクローズしなければならない。対応するＤＩＳＣ
ＯＮＮＥＣＴは、ＤＩＳＣＯＮＮＥＣＴにＳＵＣＣＥＳＳが含まれる時に、シャ
ットダウン・フェーズ中にのみ期待されるか送信される。対応するＤＩＳＣＯＮ
ＮＥＣＴは、ＤＩＳＣＯＮＮＥＣＴにＳＵＣＣＥＳＳが含まれる場合であっても
、メッセージ転送が合意されていない場合には期待されない。

【０１２６】 [パケットの使用法] すべてのＲＡＣＥパケットは、パケット・コードから始まり、パケットの終り
（ＥＯＰ）シーケンスで終わる。パケット・コードは、単一のバイトであり、パ
ケットの先頭とパケット・タイプを示す。ＥＯＰシーケンスは、値２５５のＩｎ
ｔｅｒｐｒｅｔ−Ａｓ−Ｃｏｍｍａｎｄ（ＩＡＣ）バイトと、その後の値２５４
のＥＯＰバイトからなる。例を示す。 ＜２００＞＜２５５＞＜０６４＞Ｈｅｌｌｏ Ｗｏｒｌｄ．＜２５５＞＜２５
４＞ ここで、＜２００＞は、パケットの先頭を示し、そのパケットをＭＥＳＳＡＧ
Ｅパケットとして識別する。「＜２５５＞＜０６４＞Ｈｅｌｌｏ Ｗｏｒｌｄ．
」が、パケットの内容である。＜２５５＞＜２５４＞は、パケットの終りを示す
。

【０１２７】 ほとんどのパケットは、個数が変化する可変長フィールドからなる。各フィー
ルドは、その前にプレフィックスとして２バイトのシーケンスが置かれ、もう１
つのフィールドのプレフィックスまたはＥＯＰシーケンスのいずれかで終わる。
フィールド・プレフィックスは、ＩＡＣバイトとその後のフィールド識別子から
なり、フィールド識別子のバイト値は、事前に定義され、両端を含む０から２５
３までの範囲である。オプションのフィールドは省略することができる。フィー
ルドは、０の長さを有することができ、その場合には、フィールド・プレフィッ
クスだけが指定される。例を示す。 ＜１９２＞＜２５５＞＜０３１＞ｒａｃｅ＄ｇｅｎｅｒｉｃ＜２５５＞＜０
３２＞ＴＥＳＴＡＰＰＬ＜２５５＞＜２５４＞ ここで、＜１９２＞は、パケットの先頭を示し、そのパケットをＣＯＮＮＥＣ
Ｔパケットとして識別する。＜２５５＞＜０３１＞は、フィールド３１の先頭を
示し、このフィールド３１には、ターゲット・サービス識別子「ｒａｃｅ＄ｇｅ
ｎｅｒｉｃ」が含まれる。＜２５５＞＜０３２＞は、フィールド３１の終りとフ
ィールド３２の先頭を示し、このフィールド３２には、ターゲット・アプリケー
ション名「ＴＥＳＴＡＰＰＬ」が含まれる。＜２５５＞＜２５４＞は、パケット
の終りとフィールド３２の終りを示す。

【０１２８】 オプション・ネゴシエーション・パケット、ＤＯ／ＷＩＬＬ／ＤＯＮＴ／ＷＯ
ＮＴ／ＨＥＲＥ−ＩＳは、このフィールド・プレフィックス表記に従わない。そ
うではなくて、オプション・コードとオプション・パラメータが、位置によって
暗黙のうちに識別される。オプション・コードは、パケットの第２バイトであり
、オプション・パラメータは、含まれる時に、その直後（通常は第３バイト）で
あり、ＥＯＰシーケンスで終わる。例を示す。 ＜１９３＞＜０４１＞＜２５５＞＜２５４＞

【０１２９】 ここで、＜１９３＞はＤＯパケットを識別する。オプション・コード＜０４１
＞は、パケットの第２バイトである。存在する場合には、オプション・パラメー
タがオプション・コードに続くが、この例では、パラメータがない。

【０１３０】 パケット内では、データは、８ビット・バイナリ・データである。バイト２５
５が使用される場合には、誤解釈を防ぐために二重にしなければならない。これ
は、オプション・ネゴシエーション・パケットと、フィールド・プレフィックス
表記を使用するパケットの両方にあてはまる。データ・バイト２５５を二重にす
ることによって、後続データが再編成され、パケット長が増える（送信中、解釈
の前）。例を示す。 ＜２００＞＜２５５＞＜０６４＞Ｄａｔａ ｂｙｔｅ "＜２５５＞＜２
５５＞" ｍｕｓｔ ｂｅ ｄｏｕｂｌｅｄ．＜２５５＞＜２５４＞

【０１３１】 フィールドは、フィールド内またはオプション・ネゴシエーション・パラメー
タ内に埋め込むことができる。これを機能させるために、各サブフィールド・プ
レフィックスのＩＡＣバイトを二重にし、その結果、第１レベル・パーサが、そ
れをバイナリ・データとして扱えるようにしなければならない。実装の層ごとに
、各サブフィールド・プレフィックスのＩＡＣバイトを二重にしなければならな
い。下記を検討されたい。 ＜１９３＞＜１１６＞ ＜２５５＞＜２５５＞＜０３１＞ ＜２５５＞＜２５５＞＜２５５＞＜２５５＞＜０２０＞ａｂｃｄ ＜２５５＞＜２５５＞＜２５５＞＜２５５＞＜０２１＞ｅｆｇｈ ＜２５５＞＜２５５＞＜０３２＞ｉｊｋｌ＜２５５＞＜２５４＞

【０１３２】 ここで、＜１９３＞は、ＤＯパケットを識別する。オプション・コードは、第
２バイト（１１６）であり、オプション・パラメータは、第３バイトから始まり
、ＥＯＰシーケンスまで続く。＜２５５＞＜２５５＞＜０３１＞は、第１パラメ
ータのサブフィールドを識別し、＜２５５＞＜２５５＞＜０３２＞は、第２パラ
メータのサブフィールドを識別する。第１パラメータのサブフィールド、フィー
ルド３１には、＜２５５＞＜２５５＞＜２５５＞＜２５５＞＜０２０＞および＜
２５５＞＜２５５＞＜２５５＞＜２５５＞＜０２１＞によって識別される、もう
２つのサブフィールドが含まれる。フィールド３１のこの２つのサブフィールド
、フィールド２０および２１には、それぞれ「ａｂｃｄ」および「ｅｆｇｈ」が
含まれる。第２のパラメータ・サブフィールド、フィールド３２には、「ｉｊｋ
ｌ」が含まれる。第１レベルで２つのＩＡＣバイトが使用され、第２レベルで４
つのＩＡＣバイトが使用されている形に留意されたい。この例は、有効なオプシ
ョン仕様に従っておらず、例示のためにのみ含まれる。

【０１３３】 ＲＡＣＥでは、最大パケット長が指示されない。ＭＥＳＳＡＧＥパケットおよ
びＭＥＳＳＡＧＥ−ＲＥＰＬＹパケット（その長さはアプリケーション固有）を
除くすべてのパケットが、定義された最大長を有する。アプリケーションが最大
メッセージ長に合意するためのオプション仕様が、将来に立案される可能性があ
る。

【０１３４】 [サービス識別子およびアプリケーション識別子] ＣＯＮＮＥＣＴパケットには、ターゲット・サービス識別子およびターゲット
・アプリケーション識別子が含まれる。サービス識別子は、サービスのタイプを
識別し、アプリケーション識別子は、アプリケーション名またはサービス・イン
スタンスを識別する。

【０１３５】 プレフィックス「ｒａｃｅ＄」が前に付くサービス識別子およびアプリケーシ
ョン名は、ＲＡＣＥプロトコルのために予約済みである。プレフィックス「＄」
が前に付くサービス識別子およびアプリケーション名は、割り当てられた名前の
ために予約済みである。現在、次の１つのＲＡＣＥサービスだけが定義されてい
る。

【０１３６】 ｒａｃｅ＄ｇｅｎｅｒｉｃ−汎用メッセージング・アプリケーション 他のサービスが、将来に追加される可能性がある。将来のサービスは、異なる
基本プロトコルを仮定する可能性がある。

【０１３７】 [応答コードおよび切断コード] コード値は、情況情報を返すためにＭＥＳＳＡＧＥ−ＲＥＰＬＹおよびＤＩＳ
ＣＯＮＮＥＣＴで使用される。コードは、この文書の後で説明するように、符号
なしの短整数（ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ｉｎｔｅｇｅｒ）（ネットワー
ク・バイト順）である。

【０１３８】 アプリケーションは、このプロトコルの将来のバージョンをサポートするため
に、まだ定義されていないコードを処理する準備ができていなければならない。
汎用ＥＲＲＯＲコードを使用して、認識されないコードを記述することができる
。

【０１３９】 コードがＳＵＣＣＥＳＳの時には、性能を高めるためにそのコードをＭＥＳＳ
ＡＧＥ−ＲＥＰＬＹまたはＤＩＳＣＯＮＮＥＣＴから省略することができる。省
略された場合には、ＳＵＣＣＥＳＳが仮定される。たとえば、＜２０１＞＜２５
５＞＜２５４＞は、＜２０１＞＜２５５＞＜０２１＞＜０００＞＜０００＞＜０
００＞＜０００＞＜２５５＞＜２５４＞と同等である。

【０１４０】 [プロトコル・オプション] この章は、ＲＡＣＥプロトコル・オプション仕様が含まれる。

【０１４１】 Ｇｌｏｂａｌ Ｆｉｎａｎｃｉａｌ Ｎｅｔｗｏｒｋｓ Ｌｉｍｉｔｅｄ（Ｇ
ＦＮ）社が、現在、ＲＡＣＥプロトコル・オプションを保守している。新しいプ
ロトコル・オプションの勧告は、下記の電子メール・アドレスを使用してＧＦＮ
社に送信されなければならない。 ｒａｃｅ＠ｇｆｎ．ｃｏ．ｕｋ すべての勧告は、正当に注意され、受け入れられる場合には、この文書の将来
のバージョンに組み込まれる。

【０１４２】 下記のプロトコル・オプションが定義済みである。 名前 コード 説明 ＭＯＤＥ ３３ メッセージ転送方向 ＮＯＲＥＰＬＹ ３４ メッセージ応答なし ＷＩＮＤＯＷ ３７ メッセージ・ウィンドウ ＳＥＱＮＯ ３８ シーケンス番号付け ＰＤＥ ５３ 可能な重複放出フラグ ＲＲＥＦ ５４ 受信側参照 ＬＧＩＡＵＴＨ ６５ ログイン認証 ＭＳＧＡＵＴＨ ６６ メッセージ認証 ＬＧＲＰ ７２ 論理グループ化 ＭＳＧＬＥＮ ７８ メッセージ長 ＢＡＴＣＨ ４１ バッチ・ファイル転送 ＮＯＭ ４２ メッセージの数 ＢＩＧＦＯＯＴ ８２ ビッグ・コード番号付け

【０１４３】 近い将来に、以下のプロトコル・オプションが追加される予定である。 ・暗号化 ・データ圧縮 ・チェックサム計算 ・メッセージおよびファイルのゴーアヘッドを伴うポーリング ・メッセージおよびファイルのブロック転送

【０１４４】 ３．０１ ＭＯＤＥ ［メッセージ転送のモード］ 識別 名前：ＭＯＤＥ、コード＝３３ 依存性： なし

【０１４５】 概要 ＭＯＤＥプロトコル・オプションによって、ＤＣＥからＤＴＥへのメッセージ
の転送または両方向メッセージ転送が可能になる。デフォルトで、基本プロトコ
ルは、ＤＴＥからＤＣＥへの単一方向メッセージ転送だけをサポートする。

【０１４６】 このオプションでは、メッセージ転送の方向を記述するために、下記の用語を
使用する。 − ＩＮＰＵＴ ＤＴＥからＤＣＥへの一方向（デフォルト） − ＯＵＴＰＵＴ ＤＣＥからＤＴＥへの一方向 − ＢＩＤＩＲＥＣＴＩＯＮＡＬ 両方向（各方向が独立）

【０１４７】 ＯＵＴＰＵＴ（ＤＣＥからＤＴＥへ）およびＢＩＤＩＲＥＣＴＩＯＮＡＬのメ
ッセージ転送は、ＩＮＰＵＴ（ＤＴＥからＤＣＥへ）メッセージ転送に似ている
。メッセージ転送が合意された後に、合意されたモードに応じて、いずれかの当
事者が、メッセージを送信することができる。ＯＵＴＰＵＴメッセージ転送の場
合、ＤＣＥおよびＤＴＥが、メッセージ送受信の役割を切り替える。ＢＩＤＩＲ
ＥＣＴＩＯＮＡＬメッセージ転送の場合、各方向が独立に動作し、ＤＣＥとＤＴ
Ｅの両方が、送信および受信を行うことができる。安全シャットダウンを達成す
るために、基本プロトコルの規則に従う必要がある。すなわち、送信側は、基本
プロトコルのＤＴＥのように振る舞い、受信側は、基本プロトコルのＤＣＥのよ
うに振る舞う。

【０１４８】 メッセージが誤った方向で受信される場合には、受信するアプリケーションが
、コードＰＲＴＣＯＬＥＲＲを用いて切断しなければならない。このオプション
は、メッセージ転送の方向に依存する他のプロトコル・オプションに影響する。

【０１４９】 [動機] アプリケーション間通信は、ＩＮＰＵＴメッセージ転送だけではなく、ＯＵＴ
ＰＵＴメッセージ転送およびＢＩＤＩＲＥＣＴＩＯＮＡＬメッセージ転送を必要
とすることがしばしばである。ＭＯＤＥプロトコル・オプションは、この機能性
をサポートするために基本プロトコルを拡張する。

【０１５０】 [ネゴシエーション] ＤＴＥおよびＤＣＥは、１つまたは複数のモード（ＩＮＰＵＴ、ＯＵＴＰＵＴ
、またはＢＩＤＩＲＥＣＴＩＯＮＡＬ）をサポートすることができる。結果のモ
ードは、ＤＴＥの優先順序でサポートされるモードをネゴシエートすることによ
って得られる。当初は、ＩＮＰＵＴが仮定される。その後、両者がネゴシエート
し、ＤＣＥによって最後に返されたモードが仮定される。

【０１５１】 ＤＴＥが、ＩＮＰＵＴメッセージ転送だけをサポートする場合には、ＩＮＰＵ
Ｔが仮定され、ネゴシエーションは行われない。

【０１５２】 ＤＴＥが、ＢＩＤＩＲＥＣＴＩＯＮＡＬメッセージ転送を使用することを望む
場合には、ＤＴＥは、「ＤＯ ＭＯＤＥ ＢＩＤＩＲＥＣＴＩＯＮＡＬ」を送信
する。 ＜１９３＞＜０３３＞＜００３＞＜２５５＞＜２５４＞ →

【０１５３】 ＤＣＥが、ＢＩＤＩＲＥＣＴＩＯＮＡＬメッセージ転送をサポートする場合に
は、ＤＣＥは、「ＷＩＬＬ ＭＯＤＥ ＢＩＤＩＲＥＣＴＩＯＮＡＬ」を応答し
、ＢＩＤＩＲＥＣＴＩＯＮＡＬメッセージ転送が合意される。 ← ＜１９５＞＜０３３＞＜００３＞＜２５５＞＜２５４＞

【０１５４】 そうではなく、ＤＣＥがＢＩＤＩＲＥＣＴＩＯＮＡＬメッセージ転送をサポー
トしない場合には、ＤＣＥは、「ＷＯＮＴ ＭＯＤＥ」を応答し、ＩＮＰＵＴメ
ッセージ転送が合意されたままになる。 ← ＜１９６＞＜０３３＞＜２５５＞＜２５４＞

【０１５５】 ＤＴＥまたはＤＣＥが、ＢＩＤＩＲＥＣＴＩＯＮＡＬメッセージ転送をサポー
トせず、ＤＴＥが、ＯＵＴＰＵＴメッセージ転送を使用したい場合には、ＤＴＥ
は、「ＤＯ ＭＯＤＥ ＯＵＴＰＵＴ」を送信する。 ＜１９３＞＜０３３＞＜００２＞＜２５５＞＜２５４＞ →

【０１５６】 ＤＣＥが、ＯＵＴＰＵＴメッセージ転送をサポートする場合には、ＤＣＥは、
「ＷＩＬＬ ＭＯＤＥ ＯＵＴＰＵＴ」を応答し、ＯＵＴＰＵＴメッセージ転送
が合意される。 ← ＜１９５＞＜０３３＞＜００２＞＜２５５＞＜２５４＞

【０１５７】 そうではなく、ＤＣＥが、ＯＵＴＰＵＴメッセージ転送をサポートしない場合
には、ＤＣＥは、「ＷＯＮＴ ＭＯＤＥ」を応答し、ＩＮＰＵＴメッセージ転送
が合意されたままになる。 ← ＜１９６＞＜０３３＞＜２５５＞＜２５４＞

【０１５８】 アプリケーションが結果のモードをサポートしない場合には、アプリケーショ
ンは、コードＩＮＳＮＥＧＯＰＴを使用して切断しなければならない。

【０１５９】 [パラメータ] ｛ｍｏｄｅ｝ モードは、メッセージ転送の方向を示す、符号なしのバイトである。可能な値
は、ＢＩＤＩＲＥＣＴＩＯＮＡＬの３またはＯＵＴＰＵＴの２である。他の値は
、すべて無効である。

【０１６０】 例 ＤＴＥが、ＢＩＤＩＲＥＣＴＩＯＮＡＬ、ＯＵＴＰＵＴ、およびＩＮＰＵＴを
サポートする。ＤＣＥが、ＯＵＴＰＵＴをサポートする。両者は、ＯＵＴＰＵＴ
に合意する。 ＜１９３＞＜０３３＞＜００３＞＜２５５＞＜２５４＞ → ← ＜１９６＞＜０３３＞＜２５５＞＜２５４＞ ＜１９３＞＜０３３＞＜００２＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０３３＞＜００２＞＜２５５＞＜２５４＞

【０１６１】 ＤＴＥが、ＯＵＴＰＵＴをサポートする。ＤＣＥが、ＭＯＤＥオプションを理
解せず、ＩＮＰＵＴだけをサポートする。両者は、ＩＮＰＵＴに合意する。ＤＴ
Ｅは、その後、切断する。 ＜１９３＞＜０３３＞＜００２＞＜２５５＞＜２５４＞ → ← ＜１９６＞＜０３３＞＜２５５＞＜２５４＞

【０１６２】 ＤＴＥが、ＢＩＤＩＲＥＣＴＩＯＮＡＬをサポートする。ＤＣＥが、ＩＮＰＵ
Ｔをサポートする。両者は、ＩＮＰＵＴに合意する。ＤＴＥは、その後、切断す
る。 ＜１９３＞＜０３３＞＜００３＞＜２５５＞＜２５４＞ → ← ＜１９６＞＜０３３＞＜２５５＞＜２５４＞

【０１６３】 ＤＴＥが、ＩＮＰＵＴをサポートする。ＤＣＥが、ＢＩＤＩＲＥＣＴＩＯＮＡ
Ｌをサポートする。両者は、ＩＮＰＵＴに合意する。ＤＣＥは、その後、切断す
る。 ネゴシエーションは行われない ＤＴＥは、通常、メッセージ転送のうちの１つの方向だけをサポートするので
、２つのネゴシエーションが必要になることは希である。

【０１６４】 ３．０２ ＮＯＲＥＰＬＹ 識別 名前：ＮＯＲＥＰＬＹ、コード＝３４ 依存性：ＭＯＤＥ

【０１６５】 概要 ＮＯＲＥＰＬＹプロトコル・オプションによって、メッセージ応答がオフにな
る。基本プロトコルでは、送信されるすべてのＭＥＳＳＡＧＥについて、ＭＥＳ
ＳＡＧＥ−ＲＥＰＬＹが期待される。このオプションが有効である時には、メッ
セージ応答が使用されない。

【０１６６】 このオプションは、すべてのモード（ＩＮＰＵＴ、ＯＵＴＰＵＴ、またはＢＩ
ＤＩＲＥＣＴＩＯＮＡＬ）と共に使用することができる。ＢＩＤＩＲＥＣＴＩＯ
ＮＡＬメッセージ転送の場合、アプリケーションは、アプリケーション・レベル
で同期化を提供することができる。ＩＮＰＵＴメッセージ転送またはＯＵＴＰＵ
Ｔメッセージ転送の場合、アプリケーションは、発射し、忘れる。配送確認が不
要な場合には、ＲＡＣＥまたはアプリケーション・レベルの応答なしのメッセー
ジ転送が、効率的であるとわかる場合がある。

【０１６７】 アプリケーション・インターフェースをプログラミングする時には、注意が必
要である。というのは、アプリケーションが、使用可能なメッセージ・バッファ
の数を超えて読み取ることができないからである。使用可能なメッセージ・バッ
ファの数を超えた後には、アプリケーションは、パケット・ストリームの読取を
停止しなければならない。アプリケーションは、１つまたは複数のバッファが使
用可能になった時に、読取をもう一度開始することができる。また、ＤＩＳＣＯ
ＮＮＥＣＴパケットが、パケット・ストリーム内で待っている可能性があること
に留意されたい。

【０１６８】 応答が使用不能にされているのにメッセージ応答を受信した場合には、受信す
るアプリケーションが、コードＰＲＴＣＯＬＥＲＲを用いて切断しなければなら
ない。このオプションは、メッセージ応答の存在に依存する他のプロトコル・オ
プションに影響する。ＭＯＤＥオプションは、ＮＯＲＥＰＬＹオプションの前に
ネゴシエートされなければならない。

【０１６９】 [動機] 多くのアプリケーション・レベル・プロトコルで、アプリケーション固有の応
答が使用され、一部のアプリケーションは、メッセージを発射し、忘れる。ＭＯ
ＤＥオプションとあいまって、このオプションは、ＲＡＣＥをさまざまなアプリ
ケーションおよびアプリケーション・レベル・プロトコルに拡張する。しかし、
選択肢が与えられる時には、ＲＡＣＥメッセージ応答なしでアプリケーション・
レベル・プロトコルをレイヤ化するのではなく、ＲＡＣＥメッセージ応答を用い
てアプリケーション・レベル・プロトコルをマッピングすることが好ましい。

【０１７０】 [ネゴシエーション] ＮＯＲＥＰＬＹは、入力と出力のメッセージ転送について別々にネゴシエート
される。 ＤＴＥが、メッセージ応答を使用不能にしたい（入力ストリームについて）場
合には、ＤＴＥは、「ＤＯ ＮＯＲＥＰＬＹ」を送信する。 ＜１９３＞＜０３４＞＜２５５＞＜２５４＞ → ＤＣＥが、メッセージ応答を使用不能にできる（入力ストリームについて）場
合には、ＤＣＥは、「ＷＩＬＬ ＮＯＲＥＰＬＹ」を応答する。 ← ＜１９５＞＜０３４＞＜２５５＞＜２５４＞ そうではなくて、ＤＣＥが、メッセージ応答を使用不能にすることができない
（入力ストリームについて）場合には、ＤＣＥは、「ＷＯＮＴ ＮＯＲＥＰＬＹ
」を応答する。 ← ＜１９６＞＜０３４＞＜２５５＞＜２５４＞ ＤＣＥが、メッセージ応答を使用不能にすることができる（出力ストリームに
ついて）場合には、ＤＣＥは、「ＷＩＬＬ ＮＯＲＥＰＬＹ」を送信する。 ＜１９５＞＜０３４＞＜２５５＞＜２５４＞ → ＤＣＥが、メッセージ応答を使用不能にしたい（出力ストリームについて）場
合には、ＤＣＥは、「ＤＯ ＮＯＲＥＰＬＹ」を応答する。 ← ＜１９３＞＜０３４＞＜２５５＞＜２５４＞ そうではなくて、ＤＣＥが、メッセージ応答を使用不能にしたくない（出力ス
トリームについて）場合には、ＤＣＥは、「ＤＯＮＴ ＮＯＲＥＰＬＹ」を応答
する。 ← ＜１９４＞＜０３４＞＜２５５＞＜２５４＞

【０１７１】 [パラメータ] なし 例 モードはＢＩＤＩＲＥＣＴＩＯＮＡＬである。ＤＴＥおよびＤＣＥは、メッセ
ージ応答をオフにすることに合意する。 ＜１９３＞＜０３４＞＜２５５＞＜２５４＞ → ＜１９５＞＜０３４＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０３４＞＜２５５＞＜２５４＞ ← ＜１９３＞＜０３４＞＜２５５＞＜２５４＞

【０１７２】 モードはＢＩＤＩＲＥＣＴＩＯＮＡＬである。ＤＴＥは、メッセージ応答をオ
フにすることを望むが、ＤＣＥはこれらを使用可能にする必要がある。メッセー
ジ応答は、入力ストリームについて使用不能にされ、出力ストリームについて使
用可能にされる。 ＜１９３＞＜０３４＞＜２５５＞＜２５４＞ → ＜１９５＞＜０３４＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０３４＞＜２５５＞＜２５４＞ ← ＜１９４＞＜０３４＞＜２５５＞＜２５４＞

【０１７３】 ３．０３ ＷＩＮＤＯＷ 識別 名前：ＷＩＮＤＯＷ、コード＝３７ 依存性：ＭＯＤＥ、ＮＯＲＥＰＬＹ

【０１７４】 [概要] ＷＩＮＤＯＷプロトコル・オプションを用いると、メッセージ応答を待たずに
複数のメッセージを送信できるようになる。用語ウィンドウは、メッセージ応答
が受信されていない未解決のメッセージの数を指す。

【０１７５】 約３個の小さいウィンドウによって、性能が大幅に向上する。大きいウィンド
ウは、それほどの改善をもたらさない。１のウィンドウは、基本プロトコルのデ
フォルトの挙動を表す。

【０１７６】 応答が使用不能にされている場合には、このオプションは効果がない。リンク
に障害が発生した場合には、他方の当事者が、ウィンドウ内のメッセージのすべ
てを受信してはいない場合がある。

【０１７７】 [動機づけ] デフォルトで、次のメッセージを送信できるようになる前に、メッセージ応答
を受信しなければならない。これは時間の浪費になる。応答を受信する前に複数
のメッセージを準備し、送信することができるならば、データ転送がはるかに高
速になる。これによって、受信側がメッセージを処理し、その間に、１つまたは
複数のメッセージ応答が移動中である間に送信側がメッセージを準備し、送信す
ることができるようになる。

【０１７８】 [ネゴシエーション] ＷＩＮＤＯＷは、入力と出力のメッセージ転送について別々にネゴシエートさ
れる。

【０１７９】 ＤＴＥが、１を超えるウィンドウ・サイズを使用したい（入力ストリームにつ
いて）場合には、ＤＴＥは、「ＤＯ ＷＩＮＤＯＷ」を送信し、所望のウィンド
ウ・サイズを指定する。 ＜１９３＞＜０３７＞｛ｗｉｎｄｏｗ−ｓｉｚｅ｝＜２５５＞＜２５４＞
→ ＤＣＥが、ウィンドウイングをサポートする（入力ストリームについて）場合
には、ＤＣＥは、実際のウィンドウ・サイズと共に「ＷＩＬＬ ＷＩＮＤＯＷ」
を応答する。実際のウィンドウ・サイズは、要求されたウィンドウ・サイズ以下
でなければならない。 ← ＜１９５＞＜０３７＞｛ｗｉｎｄｏｗ−ｓｉｚｅ｝＜２５５＞＜２５４
＞ そうではなく、ＤＣＥが、１を超えるウィンドウをサポートしない（入力スト
リームについて）場合には、ＤＣＥは、「ＷＯＮＴ ＷＩＮＤＯＷ」を応答する
。 ← ＜１９６＞＜０３７＞＜２５５＞＜２５４＞ ＤＴＥが、ウィンドウイングをサポートする（出力ストリームについて）場合
には、ＤＴＥは、その最大ウィンドウ・サイズと共に「ＷＩＬＬ ＷＩＮＤＯＷ
」を送信する。 ＜１９５＞＜０３７＞｛ｗｉｎｄｏｗ−ｓｉｚｅ｝＜２５５＞＜２５４＞
→ ＤＣＥが、１を超えるウィンドウ・サイズを使用したい（出力ストリームにつ
いて）場合には、ＤＣＥは、実際のウィンドウ・サイズと共に「ＤＯ ＷＩＮＤ
ＯＷ」を応答する。実際のウィンドウ・サイズは、申し出られたウィンドウ・サ
イズ以下でなければならない。 ← ＜１９３＞＜０３７＞｛ｗｉｎｄｏｗ−ｓｉｚｅ｝＜２５５＞＜２５４
＞ そうではなく、ＤＣＥが、ウィンドウイングを使用したくない（出力ストリー
ムについて）場合には、ＤＣＥは、「ＤＯＮＴ ＷＩＮＤＯＷ」を応答する。 ← ＜１９４＞＜０３７＞＜２５５＞＜２５４＞ どちらかの当事者がウィンドウイングをサポートしない場合には、１のウィン
ドウ・サイズが仮定される（デフォルト）。

【０１８０】 [パラメータ] ｛ｗｉｎｄｏｗ−ｓｉｚｅ｝ ウィンドウ・サイズは、両端を含む１から１２７までの範囲の値を含む符号な
しのバイトである。この範囲の外の値は許容されない。

【０１８１】 [例] モードはＩＮＰＵＴである。ＤＴＥは、１０の入力ウィンドウを望む。ＤＣＥ
は、３の入力ウィンドウをサポートする。両者は、３の入力ウィンドウを使用す
ることに合意する。 ＜１９３＞＜０３７＞＜０１０＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０３７＞＜００３＞＜２５５＞＜２５４＞ モードはＯＵＴＰＵＴである。ＤＴＥは、２の出力ウィンドウをサポートする
。ＤＣＥは、このオプションを理解せず、１の出力ウィンドウだけをサポートす
る。両者は、１の出力ウィンドウを使用することに合意する。 ＜１９５＞＜０３７＞＜００２＞＜２５５＞＜２５４＞ → ← ＜１９４＞＜０３７＞＜２５５＞＜２５４＞ モードはＢＩＤＩＲＥＣＴＩＯＮＡＬである。ＤＴＥは、３の入力ウィンドウ
および３の出力ウィンドウをサポートする。ＤＣＥは、２の入力ウィンドウおよ
び１の出力ウィンドウをサポートする。両者は、２の入力ウィンドウおよび１の
出力ウィンドウを使用することに合意する。 ＜１９３＞＜０３７＞＜００３＞＜２５５＞＜２５４＞ → ＜１９５＞＜０３７＞＜００３＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０３７＞＜００２＞＜２５５＞＜２５４＞ ← ＜１９３＞＜０３７＞＜００１＞＜２５５＞＜２５４＞ （ここでＤＯ
ＮＴを使用することもできる）

【０１８２】 ３．０４ ＳＥＱＮＯ ［シーケンス番号］ 識別 名前：ＳＥＱＮＯ、コード＝３８ 依存性：ＭＯＤＥ、ＮＯＲＥＰＬＹ

【０１８３】 [概要] シーケンス番号（ＳＥＱＮＯ）プロトコル・オプションを用いると、メッセー
ジおよびメッセージ応答に、それらが送信された順序で番号を付けることができ
る。合意される場合に、送信する当事者は、送信されるすべてのメッセージに増
分シーケンス番号を含めなければならず、受信する当事者は、対応するメッセー
ジ応答のそれぞれに同一のシーケンス番号を含めなければならない。メッセージ
のシーケンス番号付けを検査するのは、メッセージ受信側の責任であり、メッセ
ージ応答のシーケンス番号付けを検査するのは、メッセージ送信側の責任である
。

【０１８４】 シーケンス番号の詳細を示すために、Ｆ１０が、ＭＥＳＳＡＧＥパケットおよ
びＭＥＳＳＡＧＥ−ＲＥＰＬＹパケットに含まれる。Ｆ１０には、ネットワーク
・バイト順の符号なし短整数が含まれる。シーケンス番号は、新しい接続の開始
時に１から始まり、１つずつ増分され、６５５３６に達した後に１にラップする
（すなわち、６５５３６、１３１０７１、…が１になる）。０は、有効なシーケ
ンス番号ではない。データ・バイト２５５は、二重にしなければならない。各当
事者は、メッセージ転送の方向ごとに別のシーケンス番号カウンタを維持する。
例を示す。 ＜２００＞＜２５５＞＜０１０＞＜０００＞＜０２１＞＜２５５＞＜０６４
＞ＭＹ ＭＥＳＳＡＧＥ＜２５５＞＜２５４＞ → ← ＜２０１＞＜２５５＞＜０１０＞＜０００＞＜０２１＞＜２５５＞＜２
５４＞

【０１８５】 ここで、メッセージ番号および肯定のメッセージ応答は、シーケンス番号２１
を有する。

【０１８６】 シーケンス番号は、接続中にメッセージおよびメッセージ応答のシーケンシン
グを検査することだけに使用される。送信後または受信時にメッセージと共にシ
ーケンス番号を保管する点はない。

【０１８７】 メッセージまたはメッセージ応答について無効なシーケンス番号に遭遇した場
合には、エラーを検出したアプリケーションが、コードＩＮＶＳＥＱＮＯを用い
て切断しなければならない。

【０１８８】 [動機づけ] ＲＡＣＥでは信頼性のあるトランスポートが仮定されるので、シーケンス番号
付けは、一般に必要ではない。メッセージ応答は、メッセージが受信された順序
で返される。しかし、ＲＡＣＥ接続がシーケンス番号付けをサポートすることが
要求または期待されることがしばしばある。したがって、このオプションによっ
てそれを可能にする。デフォルトで、シーケンス番号付けは、送信を効率的に保
つために、使用されない。

【０１８９】 [ネゴシエーション] ＤＴＥが、シーケンス番号付けを提供できる（メッセージ転送のすべての方向
について）場合に、ＤＴＥは、「ＷＩＬＬ ＳＥＱＮＯ」を送信する。 ＜１９５＞＜０３８＞＜２５５＞＜２５４＞ → ＤＣＥが、シーケンス番号付けを望む（メッセージ転送のすべての方向につい
て）場合に、ＤＣＥは、「ＤＯ ＳＥＱＮＯ」を応答する。 ← ＜１９３＞＜０３８＞＜２５５＞＜２５４＞ そうでない場合には、ＤＣＥは「ＤＯＮＴ ＳＥＱＮＯ」を応答する。 ← ＜１９４＞＜０３８＞＜２５５＞＜２５４＞ ＤＴＥが、シーケンス番号付けを望む（メッセージ転送のすべての方向につい
て）場合に、ＤＴＥは、「ＷＩＬＬ ＳＥＱＮＯ」ではなく「ＤＯ ＳＥＱＮＯ
」を送信する。 ＜１９３＞＜０３８＞＜２５５＞＜２５４＞ → ＤＣＥが、シーケンス番号付けを提供できる（メッセージ転送のすべての方向
について）場合に、ＤＣＥは、「ＷＩＬＬ ＳＥＱＮＯ」を応答する。 ← ＜１９５＞＜０３８＞＜２５５＞＜２５４＞ そうでない場合には、ＤＣＥは、「ＷＯＮＴ ＳＥＱＮＯ」を応答する ← ＜１９６＞＜０３８＞＜２５５＞＜２５４＞ 送信を効率的に保つためには、アプリケーションが、ＳＥＱＮＯを要求せずに
、ＳＥＱＮＯを提供するだけでよい。

【０１９０】 [パラメータ] なし [例] ＤＴＥとＤＣＥの両方が、シーケンス番号付けをサポートするが、どちらもシ
ーケンス番号付けを要求しない。シーケンス番号付けは使用されない。 ＜１９５＞＜０３８＞＜２５５＞＜２５４＞ → ← ＜１９４＞＜０３８＞＜２５５＞＜２５４＞ ＤＴＥが、シーケンス番号付けを要求するが、ＤＣＥが、それをサポートしな
い。シーケンス番号付けは使用されない。 ＜１９３＞＜０３８＞＜２５５＞＜２５４＞ → ← ＜１９６＞＜０３８＞＜２５５＞＜２５４＞ ＤＴＥが、シーケンス番号付けをサポートし、ＤＣＥが、それを要求する。シ
ーケンス番号付けが使用される。 ＜１９５＞＜０３８＞＜２５５＞＜２５４＞ → ← ＜１９３＞＜０３８＞＜２５５＞＜２５４＞

【０１９１】 ３．０５ ＰＤＥ ［可能な重複放出］ 識別 名前：ＰＤＥ、コード＝５３ 依存性：ＭＯＤＥ [概要] 可能な重複放出（ＰＤＥ）プロトコル・オプションを用いると、ＰＤＥフラグ
の使用が可能になる。使用可能にされた後に、送信側は、メッセージ（既に送信
されたものでもよい）に関するＰＤＥフラグを含めなければならない。同様に、
受信側は、ＰＤＥフラグが存在する場合に、可能な重複としてメッセージを扱わ
なければならない。

【０１９２】 Ｆ６５が、ＰＤＥフラグを示すためにＭＥＳＳＡＧＥパケットに含まれる。Ｆ
６５は、バイナリ１を含む符号なしのバイトである。例を示す。 ＜２００＞＜２５５＞＜０６４＞Ｔｅｓｔｉｎｇ １２３＜２５５＞＜０６
５＞＜００１＞＜２５５＞＜２５４＞ Ｆ６５の存在によって、このＭＥＳＳＡＧＥが可能な重複放出であることが示
される。

【０１９３】 アプリケーションは、ＰＤＥフラグを正しく検出または処理できる場合でなけ
れば、ＰＤＥフラグの使用に合意してはならない。このオプションが有効でない
時にＦ６５に遭遇した場合には、受信側のアプリケーションが、コードＩＮＶＰ
ＫＴＦＩＤを用いて切断しなければならない。

【０１９４】 [動機づけ] このオプションによって、重複送信の検出が容易になる。一部のアプリケーシ
ョン・レベル・プロトコルで、ＰＤＥフラグの使用がサポートされている。この
オプションによって、ＲＡＣＥが、これらのプロトコルをよりよくマッピングで
きるようになる。

【０１９５】 [ネゴシエーション] ＰＤＥは、入力と出力のメッセージ転送について別々にネゴシエートされる。 ＤＴＥが、ＰＤＥフラグを提供できる（入力ストリームについて）場合には、
ＤＴＥは、「ＷＩＬＬ ＰＤＥ」を送信する。 ＜１９５＞＜０５３＞＜２５５＞＜２５４＞ → ＰＤＥ情報が、ＤＣＥにとって有用である（入力ストリームについて）場合に
は、ＤＣＥは、「ＤＯ ＰＤＥ」を応答する。 ← ＜１９３＞＜０５３＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、ＰＤＥ情報の受信を望まない（入力ストリームにつ
いて）場合には、ＤＣＥは、「ＤＯＮＴ ＰＤＥ」を応答する。 ← ＜１９４＞＜０５３＞＜２５５＞＜２５４＞ ＰＤＥ情報が、ＤＴＥにとって有用である（出力ストリームについて）場合に
は、ＤＴＥは、「ＤＯ ＰＤＥ」を送信する。 ＜１９３＞＜０５３＞＜２５５＞＜２５４＞ → ＤＣＥが、ＰＤＥフラグを提供できる（出力ストリームについて）場合には、
ＤＣＥは、「ＷＩＬＬ ＰＤＥ」を応答する。 ← ＜１９５＞＜０５３＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、ＰＤＥフラグを提供できない（出力ストリームにつ
いて）場合には、ＤＣＥは、「ＷＯＮＴ ＰＤＥ」を応答する。 ← ＜１９６＞＜０５３＞＜２５５＞＜２５４＞

【０１９６】 [パラメータ] なし [例] モードはＢＩＤＩＲＥＣＴＩＯＮＡＬである。ＤＴＥとＤＣＥの両方が、ＰＤ
Ｅをサポートする。 ＜１９５＞＜０５３＞＜２５５＞＜２５４＞ → ＜１９３＞＜０５３＞＜２５５＞＜２５４＞ → ← ＜１９３＞＜０５３＞＜２５５＞＜２５４＞ ← ＜１９５＞＜０５３＞＜２５５＞＜２５４＞

【０１９７】 モードはＩＮＰＵＴである。ＤＴＥがＰＤＥをサポートするが、ＤＣＥはサポ
ートしない。 ＜１９５＞＜０５３＞＜２５５＞＜２５４＞ → ← ＜１９４＞＜０５３＞＜２５５＞＜２５４＞

【０１９８】 ３．０６ ＲＲＥＦ ［受信側参照］ 識別 名前：ＲＲＥＦ、コード＝５４ 依存性：ＭＯＤＥ、ＮＯＲＥＰＬＹ

【０１９９】 [概要] 受信側参照（ＲＲＥＦ）プロトコル・オプションを用いると、メッセージの送
信側が、送信したメッセージのそれぞれの受信側から一意の識別子を得ることが
できるようになる。これは、調査および調停の補助になる。合意された後に、メ
ッセージ受信側は、すべてのメッセージについて、ＭＥＳＳＡＧＥ−ＲＥＰＬＹ
パケットを使用して一意のメッセージ参照を返す。

【０２００】 一意のメッセージ参照を返すために、Ｆ２４が、ＭＥＳＳＡＧＥ−ＲＥＰＬＹ
パケットに含まれる。Ｆ２４には、１個から６４個までのＡＳＣＩＩ文字すなわ
ち、両端を含めて値が３２から１２６までのバイトを含めることができる。よい
習慣の問題として、参照を、先頭または末尾の空白を含まない英数字文字にする
ことが推奨される。例を示す。 ＜２０１＞＜２５５＞＜０２４＞ＤＥＦ２００１０５１０６Ｅ０５９＜２５
５＞＜２５４＞

【０２０１】 このＭＥＳＳＡＧＥ−ＲＥＰＬＹパケットのＦ２４には、受信されたメッセー
ジを一意に識別する「ＤＥＦ２００１０５１０６Ｅ０５９」が含まれる。

【０２０２】 メッセージが拒絶される場合に、やはり一意のメッセージ参照が期待される。
受信するアプリケーションが、拒絶されるメッセージに参照を割り振らない場合
には、擬似参照を使用しなければならない。たとえば、日付と、その日にわたり
、接続に固有のカウンタを使用する。参照は、複数のアプリケーション・インス
タンスが使用される場合であっても、異なる接続で同一のアプリケーションが共
用される場合であっても、一意でなければならない。

【０２０３】 応答が使用不能にされている場合には、このオプションは効果がない。

【０２０４】 [動機づけ] 多くのアプリケーションが、主キーまたはトランザクション参照番号を使用し
てトランザクションを保管する。時には、後続の調査および調停のために、送信
するアプリケーションがこの情報を必要とする。一意のメッセージ参照は、メッ
セージ転送が行われたことの証拠である。

【０２０５】 [ネゴシエーション] ＲＲＥＦは、入力と出力のメッセージ転送について別々にネゴシエートされる
。 ＤＴＥが、ＲＲＥＦの受信を望む（入力ストリームについて）場合には、ＤＴ
Ｅは、「ＤＯ ＲＲＥＦ」を送信する。 ＜１９３＞＜０５４＞＜２５５＞＜２５４＞ → ＤＣＥが、ＲＲＥＦを供給できる（入力ストリームについて）場合には、ＤＣ
Ｅは、「ＷＩＬＬ ＲＲＥＦ」を応答する。 ← ＜１９５＞＜０５４＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥがＲＲＥＦを供給できない（入力ストリームについて）
場合には、ＤＣＥは、「ＷＯＮＴ ＲＲＥＦ」を応答する。 ← ＜１９６＞＜０５４＞＜２５５＞＜２５４＞ ＤＴＥが、ＲＲＥＦを供給できる（出力ストリームについて）場合には、ＤＴ
Ｅは、「ＷＩＬＬ ＲＲＥＦ」を送信する。 ＜１９５＞＜０５４＞＜２５５＞＜２５４＞ → ＤＣＥが、ＲＲＥＦの受信を望む（出力ストリームについて）場合には、ＤＣ
Ｅは、「ＤＯ ＲＲＥＦ」を応答する。 ← ＜１９３＞＜０５４＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、ＲＲＥＦの受信を望まない（出力ストリームについ
て）場合には、ＤＣＥは、「ＤＯＮＴ ＲＲＥＦ」を応答する。 ← ＜１９４＞＜０５４＞＜２５５＞＜２５４＞

【０２０６】 [パラメータ] なし [例] モードはＢＩＤＩＲＥＣＴＩＯＮＡＬである。ＤＴＥは、ＲＲＥＦを求めるが
、それを提供することができない。ＤＣＥは、ＲＲＥＦを求めないが、それを提
供することができる。 ＜１９３＞＜０５４＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０５４＞＜２５５＞＜２５４＞ モードはＩＮＰＵＴである。ＤＴＥは、ＲＲＥＦを求める。ＤＣＥは、このオ
プションをサポートせず、提供することができない。 ＜１９３＞＜０５４＞＜２５５＞＜２５４＞ → ← ＜１９６＞＜０５４＞＜２５５＞＜２５４＞ モードはＯＵＴＰＵＴである。ＤＴＥは、ＲＲＥＦを提供することができる。
ＤＣＥは、ＲＲＥＦを求めない。 ＜１９５＞＜０５４＞＜２５５＞＜２５４＞ → ← ＜１９４＞＜０５４＞＜２５５＞＜２５４＞

【０２０７】 ３．０７ ＬＧＩＡＵＴＨ ［ログイン認証］ 識別 名前：ＬＧＩＡＵＴＨ、コード＝６５ 依存性： なし

【０２０８】 [概要] ログイン認証（ＬＧＩＡＵＴＨ）プロトコル・オプションを用いると、アプリ
ケーションが、接続をオープンする時にお互いを認証できるようになる。認証キ
ーおよび認証アルゴリズムの識別は、なんらかの他の手段によって合意され、配
布される。

【０２０９】 両方のアプリケーションを、別々に認証することができる。要求元のアプリケ
ーションは、他方のアプリケーションに認証のために文字列を送信する。他方の
アプリケーションは、認証コードを計算し、返す。要求元のアプリケーションは
、もう一度認証コードを計算し、受信した認証コードと比較する。コードが一致
する場合には、認証に合格する。

【０２１０】 認証に失敗する場合には、認証コードを受信すると期待されるアプリケーショ
ンが、接続を即座に打ち切る、またはネゴシエーションの終了まで待つのいずれ
かを行うことができる。どちらの場合でも、認証するアプリケーションは、コー
ドＬＧＩＦＡＩＬと共にＤＩＳＣＯＮＮＥＣＴを送信しなければならない。

【０２１１】 [動機づけ] デフォルトで、ＲＡＣＥ接続は保護されない。このオプションを用いると、２
つの協調動作するアプリケーションが、アクセスを認証できるようになる。

【０２１２】 [ネゴシエーション] ＤＴＥが、ログイン認証をサポートできる場合には、ＤＴＥは、「ＷＩＬＬ
ＬＧＩＡＵＴＨ」を送信する。 ＜１９５＞＜０６５＞＜２５５＞＜２５４＞ → ＤＣＥが、ログイン認証を受けることを望む場合には、ＤＣＥは、ＤＴＥが認
証する文字列と共に「ＤＯ ＬＧＩＡＵＴＨ」を応答する。 ← ＜１９３＞＜０６５＞｛ａｕｔｈ−ｓｔｒ｝＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、ログイン認証を受けることを望まない場合には、Ｄ
ＣＥは、「ＤＯＮＴ ＬＧＩＡＵＴＨ」を応答する。 ← ＜１９４＞＜０６５＞＜２５５＞＜２５４＞ ＤＣＥが、ログイン認証を受けることに合意した場合に、ＤＴＥは、供給され
た認証文字列について計算した認証コードと共に、「ＨＥＲＥ−ＩＳ ＬＧＩＡ
ＵＴＨ」を送信する。 ＜１９７＞＜０６５＞｛ａｕｔｈ−ｃｏｄｅ｝＜２５５＞＜２５４＞ → ＤＴＥが、ログイン認証を受けることを望む場合に、ＤＴＥは、ＤＣＥが認証
する文字列と共に「ＤＯ ＬＧＩＡＵＴＨ」を送信する。 ＜１９３＞＜０６５＞｛ａｕｔｈ−ｓｔｒ｝＜２５５＞＜２５４＞ → ＤＣＥが、ログイン認証を供給することができる場合に、ＤＣＥは、「ＷＩＬ
Ｌ ＬＧＩＡＵＴＨ」を応答し、その後、供給された認証文字列について計算し
た認証コードと共に「ＨＥＲＥ−ＩＳ ＬＧＩＡＵＴＨ」を送信する。 ← ＜１９５＞＜０６５＞＜２５５＞＜２５４＞ ← ＜１９７＞＜０６５＞＜｛ａｕｔｈ−ｃｏｄｅ｝＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、ログイン情報を供給できない場合には、ＤＣＥは、
「ＷＯＮＴ ＬＧＩＡＵＴＨ」を応答する。 ← ＜１９６＞＜０６５＞＜２５５＞＜２５４＞

【０２１３】 [パラメータ] ｛ａｕｔｈ−ｓｔｒ｝ 認証文字列には、認証アルゴリズムに応じて１個から１０２４個までの符号な
しバイトを含めることができる。データ・バイト２５５は、二重にしなければな
らない。 ｛ａｕｔｈ−ｃｏｄｅ｝ 認証コードには、認証アルゴリズムに応じて１個から６４個までの符号なしバ
イトを含めることができる。データ・バイト２５５は、二重にしなければならな
い。

【０２１４】 [例] ＤＴＥが、ログイン認証をＤＣＥに供給する。 ＜１９５＞＜０６５＞＜２５５＞＜２５４＞ → ← ＜１９３＞＜０６５＞ＴＯＤＡＹ ＩＳ ２００００８２８＜２５５＞
＜２５４＞ ＜１９７＞＜０６５＞Ｅ０６７２０５８７８０１Ｃ３３１＜２５５＞＜２５
４＞ → ＤＴＥが、ログイン認証をＤＣＥに供給するが、ＤＣＥがそれを望まない。 ＜１９５＞＜０６５＞＜２５５＞＜２５４＞ → ← ＜１９４＞＜０６５＞＜２５５＞＜２５４＞

【０２１５】 ３．０８ ＭＳＧＡＵＴＨ ［メッセージ認証］ 識別 名前：ＭＳＧＡＵＴＨ、コード＝６６ 依存性：ＭＯＤＥ

【０２１６】 [概要] メッセージ認証（ＭＳＧＡＵＴＨ）プロトコル・オプションを用いると、アプ
リケーションがメッセージを認証できるようになる。認証キーおよび認証アルゴ
リズムの識別は、なんらかの他の手段によって合意され、配布される。

【０２１７】 合意された後に、アプリケーションは、すべてのメッセージについて、メッセ
ージの内容、キー、およびアルゴリズムに基づいてメッセージ認証コード（ＭＡ
Ｃ）を計算する。送信と受信に、別のキーまたは同一のキーを使用することがで
きる。送信するアプリケーションは、ＭＡＣを計算し、これをＭＥＳＳＡＧＥパ
ケットに追加する。受信するアプリケーションは、もう一度ＭＡＣを計算し、受
信したＭＥＳＳＡＧＥパケット内のＭＡＣと比較する。これらが一致する場合に
は、メッセージが認証に合格する。そうでない場合には、メッセージは、認証に
失敗し、処理されない。ＭＡＣプロトコル・オプションを用いると、協調動作す
るアプリケーションが、メッセージの認証性および保全性を検査できるようにな
る。機密性は保証されない。

【０２１８】 認証コードを追加するために、Ｆ６６が、ＭＥＳＳＡＧＥパケットに含まれる
。Ｆ６６には、認証アルゴリズムに応じて１個から６４個までの符号なしバイト
が含まれる。例を示す。 ＜２００＞＜２５５＞＜０６４＞Ｈｅｌｌｏ Ｗｏｒｌｄ！ ＜２５５＞＜０６６＞＜１３４＞＜１６１＞＜００３＞＜２５５＞＜２
５５＞＜２０１＞＜１９３＞＜２５５＞＜２５４＞ このメッセージには、４８ビットの認証コード、１６進値「８６Ａ１０３ＦＦ
Ｃ９Ｃ１」が含まれる。

【０２１９】 認証に失敗する場合には、メッセージを処理してはならない。受信するアプリ
ケーションは、コードＡＵＴＦＡＩＬと共にＤＩＳＣＯＮＮＥＣＴを送信するこ
とによって接続を打ち切らなければならない。

【０２２０】 [動機づけ] デフォルトで、ＲＡＣＥ接続は保護されない。このオプションを用いると、２
つの協調動作するアプリケーションが、メッセージの認証性および保全性を検査
できるようになる。

【０２２１】 [ネゴシエーション] ＤＴＥが、メッセージ認証を供給できる（入力ストリームについて）場合に、
ＤＴＥは、「ＷＩＬＬ ＭＳＧＡＵＴＨ」を送信する。 ＜１９５＞＜０６６＞＜２５５＞＜２５４＞ → ＤＣＥが、メッセージを認証したい（入力ストリームについて）場合に、ＤＣ
Ｅは、「ＤＯ ＭＳＧＡＵＴＨ」を応答する。 ← ＜１９３＞＜０６６＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、メッセージの認証を望まない（入力ストリームにつ
いて）場合に、ＤＣＥは、「ＤＯＮＴ ＭＳＧＡＵＴＨ」を応答する。 ← ＜１９４＞＜０６６＞＜２５５＞＜２５４＞ ＤＴＥが、メッセージを認証したい（出力ストリームについて）場合に、ＤＴ
Ｅは、「ＤＯ ＭＳＧＡＵＴＨ」を送信する。 ＜１９３＞＜０６６＞＜２５５＞＜２５４＞ → ＤＣＥが、メッセージ認証を供給できる（出力ストリームについて）場合に、
ＤＣＥは、「ＷＩＬＬ ＭＳＧＡＵＴＨ」を応答する。 ← ＜１９５＞＜０６６＞＜２５５＞＜２５４＞ そうではなく、ＤＴＥが、メッセージ認証を供給できない（出力ストリームに
ついて）場合に、ＤＴＥは、「ＷＯＮＴ ＭＳＧＡＵＴＨ」を応答する。 ← ＜１９６＞＜０６６＞＜２５５＞＜２５４＞ [パラメータ] なし [例] ＤＴＥとＤＣＥが、入力ストリームについてメッセージを認証することに合意
する。 ＜１９５＞＜０６６＞＜２５５＞＜２５４＞ → ← ＜１９３＞＜０６６＞＜２５５＞＜２５４＞

【０２２２】 ＤＴＥとＤＣＥが、両方向でメッセージを認証することに合意する。 ＜１９５＞＜０６６＞＜２５５＞＜２５４＞ → ＜１９３＞＜０６６＞＜２５５＞＜２５４＞ → ← ＜１９３＞＜０６６＞＜２５５＞＜２５４＞ ← ＜１９５＞＜０６６＞＜２５５＞＜２５４＞

【０２２３】 ＤＴＥが、両方向でメッセージを認証することを望むが、ＤＣＥが、このオプ
ションを理解しない。 ＜１９５＞＜０６６＞＜２５５＞＜２５４＞ → ＜１９３＞＜０６６＞＜２５５＞＜２５４＞ → ← ＜１９４＞＜０６６＞＜２５５＞＜２５４＞ ← ＜１９６＞＜０６６＞＜２５５＞＜２５４＞

【０２２４】 ３．０９ ＬＧＲＰ ［論理グループ化］ 識別 名前：ＬＧＲＰ、コード＝７２ 依存性：ＭＯＤＥ

【０２２５】 [概要] 論理グループ化（ＬＧＲＰ）プロトコル・オプションを用いると、メッセージ
をグループ化し、単一の作業単位として処理することができるようになる。使用
可能にされた後に、送信側は、連続するメッセージを一緒にグループ化するか、
基本プロトコルの場合のように個別のメッセージを送信することを継続すること
ができる。

【０２２６】 論理グループ化情報を追加するために、Ｆ６７が、ＭＥＳＳＡＧＥパケットに
含まれる。Ｆ６７には、符号なしバイトとして、論理グループ位置が含まれる。
これは、グループの先頭と終りを区切るために、最初のメッセージと最後のメッ
セージに含まれる。最初のメッセージは、位置１を割り当てられ、最後のメッセ
ージは、位置２を割り当てられる。Ｆ６７は、中間のメッセージには使用されな
い。論理グループ内のシーケンス番号付けは、信頼性のある接続が仮定されるの
で、使用されない。例を示す。 ＜２００＞＜２５５＞＜０６４＞ＭＳＧ−１＜２５５＞＜０６７
＞＜００１＞＜２５５＞＜２５４＞ ＜２００＞＜２５５＞＜０６４＞ＭＳＧ−２＜２５５＞＜２５４＞ ＜２００＞＜２５５＞＜０６４＞ＭＳＧ−３＜２５５＞＜２５４＞ ＜２００＞＜２５５＞＜０６４＞ＭＳＧ−４＜２５５＞＜０６７＞＜００２
＞＜２５５＞＜２５４＞ ＜２００＞＜２５５＞＜０６４＞ＭＳＧ−５＜２５５＞＜２５４＞ ＜２００＞＜２５５＞＜０６４＞ＭＳＧ−６＜２５５＞＜０６７＞＜００１
＞＜２５５＞＜２５４＞ ＜２００＞＜２５５＞＜０６４＞ＭＳＧ−７＜２５５＞＜２５４＞ ＜２００＞＜２５５＞＜０６４＞ＭＳＧ−８＜２５５＞＜０６７＞＜００２
＞＜２５５＞＜２５４＞

【０２２７】 この入力には、３つの論理グループが含まれる。第１のグループには、４つの
メッセージ（ＭＳＧ−１、ＭＳＧ−２、ＭＳＧ−３、およびＭＳＧ−４）が含ま
れる。第２のグループには、１つのメッセージ（ＭＳＧ−５）だけが含まれる。
第３のグループには、３つのメッセージ（ＭＳＧ−６、ＭＳＧ−７、およびＭＳ
Ｇ−８）が含まれる。

【０２２８】 論理グループに、１つのメッセージだけが含まれる場合には、Ｆ６７は使用さ
れず、単一のメッセージが、基本プロトコルに従ってｐｕｔされる。メッセージ
応答は、使用可能にされている場合に、送信されるすべてのメッセージについて
期待される。ウィンドウイングが許容される。論理グループは、グループ内の最
後のメッセージが肯定応答された後に肯定応答される。その後、グループは、単
一の作業単位として処理される。論理グループ内の１つまたは複数のメッセージ
が拒絶される場合には、グループ全体が拒絶され、その後は処理されない。ＬＧ
ＲＰプロトコル・オプションは、ＳＥＱＮＯプロトコル・オプションの使用に影
響しない。

【０２２９】 [動機づけ] メッセージを論理的な全体として処理するために、メッセージを一緒にグルー
プ化することが必要または実用的である場合がある。たとえば、メッセージをバ
ッチ・ファイルから読み取る場合には、それらを一緒に配布することが望ましい
。メッセージのグループがトランザクションを形成する場合には、これらを一緒
に処理する必要があり、その結果、ある部分で障害が発生した場合に、トランザ
クション全体をロール・バックすることができるようにする必要がある。

【０２３０】 [ネゴシエーション] 論理グループ化の使用は、入力と出力のメッセージ転送について別々にネゴシ
エートされる。

【０２３１】 ＤＴＥが、論理グループ化を使用することを望む（入力ストリームについて）
場合には、ＤＴＥは、「ＤＯ ＬＧＲＰ」を送信する。 ＜１９３＞＜０７２＞＜２５５＞＜２５４＞ → ＤＣＥが、論理グループ化をサポートする（入力ストリームについて）場合に
は、ＤＣＥは、「ＷＩＬＬ ＬＧＲＰ」を応答する。 ← ＜１９５＞＜０７２＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、論理グループ化をサポートしない（入力ストリーム
について）場合には、ＤＣＥは、「ＷＯＮＴ ＬＧＲＰ」を応答する。 ← ＜１９６＞＜０７２＞＜２５５＞＜２５４＞ ＤＴＥが、論理グループ化をサポートする（出力ストリームについて）場合に
は、ＤＴＥは、「ＷＩＬＬ ＬＧＲＰ」を送信する。 ＜１９５＞＜０７２＞＜２５５＞＜２５４＞ → ＤＣＥが、論理グループ化を使用することを望む（出力ストリームについて）
場合には、ＤＣＥは、「ＤＯ ＬＧＲＰ」を応答する。 ← ＜１９３＞＜０７２＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、論理グループ化を使用することを望まない（出力ス
トリームについて）場合には、ＤＣＥは、「ＤＯＮＴ ＬＧＲＰ」を応答する。 ← ＜１９４＞＜０７２＞＜２５５＞＜２５４＞

【０２３２】 [パラメータ] なし [例] モードはＢＩＤＩＲＥＣＴＩＯＮＡＬである。ＤＴＥとＤＣＥの両方が、ＬＧ
ＲＰをサポートする。 ＜１９３＞＜０７２＞＜２５５＞＜２５４＞ → ＜１９５＞＜０７２＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０７２＞＜２５５＞＜２５４＞ ← ＜１９３＞＜０７２＞＜２５５＞＜２５４＞

【０２３３】 モードはＩＮＰＵＴである。ＤＴＥは、ＬＧＲＰをサポートするが、ＤＣＥは
サポートしない。 ＜１９３＞＜０７２＞＜２５５＞＜２５４＞ → ← ＜１９６＞＜０７２＞＜２５５＞＜２５４＞

【０２３４】 ３．１０ ＭＳＧＬＥＮ ［メッセージ長］ 識別 名前：ＭＳＧＬＥＮ、コード＝７８ 依存性：ＭＯＤＥ

【０２３５】 [概要] メッセージ長（ＭＳＧＬＥＮ）プロトコル・オプションを用いると、ＭＥＳＳ
ＡＧＥパケットにメッセージ長を含めることができるようになる。ネゴシエーシ
ョンに応じて、メッセージ長を、Ｆ６４（メッセージ内容）の前または後のいず
れかに含めることができる。

【０２３６】 メッセージ長を追加するために、Ｆ６３が、ＭＥＳＳＡＧＥパケットに含まれ
る。Ｆ６３は、ネットワーク・バイト順の符号なし長整数（ｕｎｓｉｇｎｅｄ
ｌｏｎｇ ｉｎｔｅｇｅｒ）である。したがって、最大メッセージ長は、このオ
プションが有効である時に、４２９４９６７２９５バイト（４ＧＢ）になる。例
を示す。

【０２３７】 メッセージ長がプレフィックスになっている。 ＜２００＞＜２５５＞＜０６３＞＜０００＞＜０００＞＜０００＞＜０１６
＞ ＜２５５＞＜０６４＞Ｉ ＨＡＶＥ １６ ＢＹＴＥＳ．＜２５５＞＜
２５４＞

【０２３８】 メッセージ長がサフィックスになっている。 ＜２００＞＜２５５＞＜０６４＞Ｉ ＨＡＶＥ １６ ＢＹＴＥＳ． ＜２５５＞＜０６３＞＜０００＞＜０００＞＜０００＞＜０１６＞＜２
５５＞＜２５４＞ メッセージ受信側が、実際のメッセージ長がＦ６３で指定されたメッセージ長
と一致しないことを検出した場合には、受信側が、コードＩＮＶＭＳＧＬＥＮを
用いて切断しなければならない。

【０２３９】 [動機づけ] メッセージ長が、メッセージと共に送信される場合には、受信するアプリケー
ションが、実際のメッセージ長を検査することができる。メッセージ長が、メッ
セージ内容の前に含まれる場合には、受信するアプリケーションが、前もってメ
ッセーのためのスペースを割り振ることができる。大きいメッセージを転送する
場合、受信するアプリケーションが連続したスペースを事前に割り振ることがで
きるので、これによって性能を高めることができる。

【０２４０】 しかし、送信するアプリケーションが、前もってメッセージ長を知ることが困
難であるか、送信するアプリケーションが前もってメッセージ長を判定すること
が性能の妨げになる場合がある。さらに、多数の小さいメッセージが転送される
時には、Ｆ６３のサイズが性能低下を引き起こす可能性がある。

【０２４１】 [ネゴシエーション] ＤＴＥが、メッセージ長を供給することができる（入力ストリームについて）
場合に、ＤＴＥは、「ＷＩＬＬ ＭＳＧＬＥＮ」と、それをプレフィックスとサ
フィックスのどちらにすることができるか（１、２）を送信する。 ＜１９５＞＜０７８＞｛ｐｒｅｆｉｘ−ｓｕｆｆｉｘ｝＜２５５＞＜２５４
＞ →

【０２４２】 ＤＣＥが、メッセージ長を受信することを望む（入力ストリームについて）場
合に、ＤＣＥは、「ＤＯ ＭＳＧＬＥＮ」と、それをプレフィックスとサフィッ
クスのどちらにするか（１、２）を応答する。ＤＣＥは、ＤＴＥがプレフィック
スにすることを提供する場合にかぎって、メッセージ長をプレフィックスにする
ことを要求することができる。ＤＣＥは、どの場合でもメッセージ長をサフィッ
クスにすることを要求することができる。 ← ＜１９３＞＜０７８＞｛ｐｒｅｆｉｘ−ｓｕｆｆｉｘ｝＜２５５＞＜２
５４＞

【０２４３】 そうではなく、ＤＣＥが、メッセージ長を受信することを望まない（入力スト
リームについて）場合に、ＤＣＥは、「ＤＯＮＴ ＭＳＧＬＥＮ」を応答する。 ← ＜１９４＞＜０７８＞＜２５５＞＜２５４＞ ＤＴＥが、メッセージ長を受信することを望む（出力ストリームについて）場
合に、ＤＴＥは、「ＤＯ ＭＳＧＬＥＮ」と、それをプレフィックスとサフィッ
クスのどちらにするか（１、２）を送信する。 ＜１９３＞＜０７８＞｛ｐｒｅｆｉｘ−ｓｕｆｆｉｘ｝＜２５５＞＜２５４
＞ →

【０２４４】 ＤＣＥが、メッセージ長を提供することができる（出力ストリームについて）
場合に、ＤＣＥは、「ＷＩＬＬ ＭＳＧＬＥＮ」と、それをプレフィックスとサ
フィックスのどちらにすることができるか（１、２）を応答する。ＤＣＥは、Ｄ
ＴＥがプレフィックスにすることを要求した場合に限って、メッセージ長をプレ
フィックスにすることを申し出なければならない。ＤＴＥが、メッセージ長をプ
レフィックスにすることを要求し、ＤＣＥがサフィックスにすることしかできな
い場合には、ＤＴＥは、サフィックスにすることに合意しなければならない。そ
の後、ＤＴＥは、どのように進行することを望むかを決定することができる。 ← ＜１９５＞＜０７８＞＜｛ｐｒｅｆｉｘ−ｓｕｆｆｉｘ｝＜２５５＞＜
２５４＞

【０２４５】 そうではなく、ＤＣＥが、メッセージ長を提供することができない（出力スト
リームについて）場合に、ＤＣＥは、「ＷＯＮＴ ＭＳＧＬＥＮ」を応答する。 ← ＜１９６＞＜０７８＞＜２５５＞＜２５４＞

【０２４６】 [パラメータ] ｛ｐｒｅｆｉｘ−ｓｕｆｆｉｘ｝ ｐｒｅｆｉｘ−ｓｕｆｆｉｘパラメータは、プレフィックスの場合に１、サフ
ィックスの場合に２を含む、符号なしバイトである。

【０２４７】 [例] モードはＢＩＤＩＲＥＣＴＩＯＮＡＬである。ＤＴＥは、ＭＳＧＬＥＮをプレ
フィックスにすることができ、プレフィックスにされたＭＳＧＬＥＮを受信する
ことを望む。ＤＣＥは、ＭＳＧＬＥＮをプレフィックスにすることができるが、
それを受信するつもりがない。両者は、ＤＣＥからＤＴＥへのＭＳＧＬＥＮをプ
レフィックスにすることに合意する。 ＜１９５＞＜０７８＞＜００１＞＜２５５＞＜２５４＞ → ＜１９３＞＜０７８＞＜００１＞＜２５５＞＜２５４＞ → ← ＜１９４＞＜０７８＞＜２５５＞＜２５４＞ ← ＜１９５＞＜０７８＞＜００１＞＜２５５＞＜２５４＞

【０２４８】 モードはＩＮＰＵＴである。ＤＴＥは、ＭＳＧＬＥＮをサフィックスにするこ
とができる。ＤＣＥは、プレフィックスにされたＭＳＧＬＥＮを受信することを
望む。両者は、ＭＳＧＬＥＮを使用しないことに合意する（ＤＴＥがそれをプレ
フィックスにすることができないので）。 ＜１９５＞＜０７８＞＜００２＞＜２５５＞＜２５４＞ → ← ＜１９４＞＜０７８＞＜２５５＞＜２５４＞

【０２４９】 ３．１１ ＢＡＴＣＨ 識別 名前：ＢＡＴＣＨ、コード＝４１ 依存性：ＭＯＤＥ

【０２５０】 [概要] ＢＡＴＣＨプロトコル・オプションは、アプリケーション間のシーケンシャル
・データ・ファイルの転送をサポートする。通常、メッセージは、あるプログラ
ムによってバッチ・ファイルに書き込まれ、その後、そのバッチ・ファイルが、
もう１つのプログラムに転送される。

【０２５１】 ＢＡＴＣＨでは、標準のメッセージ転送が使用不能にされ、バッチ・ファイル
転送が使用可能にされる。ＭＥＳＳＡＧＥパケットが、バッチ・ファイルを運ぶ
のに使用され、ＭＥＳＳＡＧＥ−ＲＥＰＬＹパケットが、肯定応答に使用される
。内容は、Ｆ６４を使用して転送され、ヘッダは、Ｆ９１およびＦ９２を使用し
てプレフィックスを付けられる。Ｆ９１は、必須であり、ファイル名の詳細を示
す。Ｆ９２は、任意選択であり、グリニッジ標準時でのファイルの作成の日付お
よび時刻の詳細を示す。

【０２５２】 可能な場合には、Ｆ６３すなわちファイル・サイズを含めるために、ＭＳＧＬ
ＥＮプロトコル・オプションをネゴシエートしなければならない。Ｆ６３が含ま
れる場合には、受信するアプリケーションが、受信したファイルのサイズを検査
することができる。Ｆ６３が、ファイル内容の前に含まれる場合には、受信する
アプリケーションが、連続したスペースを事前に割り振ることができ、ファイル
転送を高速化することができる。最大ファイル・サイズは、４２９４９６７２９
５バイト（４ＧＢ）である。

【０２５３】 データ・ファイルには、どのようなバイナリ・データでも含めることができる
。データ・バイト２５５は、二重にしなければならない。しかし、アプリケーシ
ョンは、通常は、ＡＳＣＩＩを使用し、ＣＲＬＦを使用してレコードを分離する
ことに合意する。他のフォーマットはＢＡＴＣＨの範囲外であるから、シーケン
シャル・ファイルだけがサポートされる。

【０２５４】 たとえば、次のファイル転送では ＜２００＞＜２５５＞＜０９１＞ＰＸ２０６１．ＤＡＴ＜２５５＞＜０９２
＞２００２１０１５１０２４１６００ ＜２５５＞＜０６４＞ＨＥＲＥ ＡＲＥ ＴＨＥ ＦＩＬＥ ＣＯＮＴ
ＥＮＴＳ．＜２５５＞＜２５４＞ → ← ＜２０１＞＜２５５＞＜２５４＞

【０２５５】 ２００２年１０月１５日午前１０時２４分に作成されたファイルＰＸ２０６１
．ＤＡＴが転送される。

【０２５６】 ＢＡＴＣＨプロトコル・オプションは、ＭＯＤＥプロトコル・オプションの前
にネゴシエートされなければならない。

【０２５７】 [動機づけ] 多数の既存のシステムまたは単純なシステムが、メッセージの処理および転送
にバッチ・ファイルを使用する。

【０２５８】 [ネゴシエーション] ＢＡＴＣＨの使用法は、入力と出力のデータ転送で同一である。使用可能にさ
れた後に、バッチ・ファイル転送が、標準のメッセージ転送と入れ代わる。

【０２５９】 ＤＴＥが、バッチを使用することを望む場合に、ＤＴＥは、「ＤＯ ＢＡＴＣ
Ｈ」を送信する。 ＜１９３＞＜０４１＞＜２５５＞＜２５４＞ → ＤＣＥが、バッチをサポートする場合に、ＤＣＥは、「ＷＩＬＬ ＢＡＴＣＨ
」を応答する。 ← ＜１９５＞＜０４１＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、バッチをサポートしない場合には、ＤＣＥは、「Ｗ
ＯＮＴ ＢＡＴＣＨ」を応答する。 ← ＜１９６＞＜０４１＞＜２５５＞＜２５４＞ ＤＴＥが、バッチを提供できる場合には、ＤＴＥは、「ＷＩＬＬ ＢＡＴＣＨ
」を送信する。 ＜１９５＞＜０４１＞＜２５５＞＜２５４＞ → ＤＣＥが、バッチを使用することを望む場合には、ＤＣＥは「ＤＯ ＢＡＴＣ
Ｈ」を応答する。 ← ＜１９３＞＜０４１＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、バッチを使用することを望まない場合には、ＤＣＥ
は、「ＤＯＮＴ ＢＡＴＣＨ」を応答する。 ← ＜１９４＞＜０４１＞＜２５５＞＜２５４＞

【０２６０】 [パラメータ] なし [例] ＤＴＥが、ＢＡＴＣＨを使用することを望む。ＤＣＥは、ＢＡＴＣＨをサポー
トする。両者は、ＢＡＴＣＨを使用することに合意する。 ＜１９３＞＜０４１＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０４１＞＜２５５＞＜２５４＞ ＤＴＥが、ＢＡＴＣＨを使用することを望む。ＤＣＥは、ＢＡＴＣＨをサポー
トしない。両者は、ＢＡＴＣＨを使用しない。 ＜１９３＞＜０４１＞＜２５５＞＜２５４＞ → ← ＜１９６＞＜０４１＞＜２５５＞＜２５４＞

【０２６１】 ３．１２ ＮＯＭ ［メッセージ数］ 識別 名前：ＮＯＭ、コード＝４２ 依存性：ＭＯＤＥ

【０２６２】 [概要] メッセージ数（ＮＯＭ）オプションを用いると、一方の当事者が、ネゴシエー
ションの時点でダウンロードを待っているメッセージの数を判定できるようにな
る。

【０２６３】 ＤＴＥが、保留中のメッセージの数を知りたいか提供できる場合に、ＤＴＥは
、ＤＣＥとネゴシエートする。合意した場合に、ＤＴＥがその保留中のメッセー
ジ数を送信するか、ＤＣＥがその保留中のメッセージ数を送信するか、その両方
が行われる。

【０２６４】 このプロトコル・オプションを使用して返されるメッセージの数は、実際に転
送されるメッセージの数より多い場合も少ない場合もあることに留意されたい。

【０２６５】 [動機づけ] 実際にダウンロードする前に、ダウンロードを待っているメッセージの数を表
示するか知ることが望ましい場合がある。このオプションを用いると、データ転
送に合意し、転送に入る前に、メッセージの数を知ることができる。保留中のメ
ッセージがない場合には、このオプションによって他の当事者がすばやく切断で
きるようになる。そうでなければ、その当事者はタイマが満了するまで待たなけ
ればならないはずである。

【０２６６】 たとえば、ユーザの介入を伴うメッセージ出力プログラムを検討されたい。こ
のメッセージ出力プログラムは、出力メッセージ・キューに接続し、保留中のメ
ッセージの数を取り出す。このプログラムは、メッセージの数をユーザに表示し
、ユーザがそれらのメッセージをダウンロードしたいかどうかを尋ねる。ユーザ
が合意する場合に、このプログラムは、メッセージ転送に入る。そうでない場合
には、このプログラムは切断する。この例では、プログラムは、ユーザが即座に
応答しない場合に、接続がタイムアウトになっていないことを監視する必要があ
る。

【０２６７】 [ネゴシエーション] ＤＴＥが、保留中のメッセージの数を知りたい（出力ストリームについて）場
合に、ＤＴＥは、「ＤＯ ＮＯＭ」を送信する。 ＜１９３＞＜０４２＞＜２５５＞＜２５４＞ → ＤＣＥが、保留中のメッセージの数を提供できる（出力ストリームについて）
場合に、ＤＣＥは、「ＷＩＬＬ ＮＯＭ」を応答し、その後、「ＨＥＲＥ−ＩＳ
ＮＯＭ」を送信する。 ← ＜１９５＞＜０４２＞＜２５５＞＜２５４＞ ← ＜１９７＞＜０４２＞｛ｎｕｍｂｅｒ−ｏｆ−ｍｅｓｓａｇｅｓ｝＜２
５５＞＜２５４＞ そうではなく、ＤＣＥが、保留中のメッセージの数を提供できない（出力スト
リームについて）場合に、ＤＣＥは、「ＷＯＮＴ ＮＯＭ」を応答する。 ← ＜１９６＞＜０４２＞＜２５５＞＜２５４＞ ＤＴＥが、保留中のメッセージの数を提供できる（入力ストリームについて）
場合に、ＤＴＥは、「ＷＩＬＬ ＮＯＭ」を送信する。 ＜１９５＞＜０４２＞＜２５５＞＜２５４＞ → ＤＣＥが、保留中のメッセージの数を知りたい（入力ストリームについて）場
合に、ＤＣＥは、「ＤＯ ＮＯＭ」を応答する。 ← ＜１９３＞＜０４２＞＜２５５＞＜２５４＞ その後、ＤＴＥが、メッセージの数と共に「ＨＥＲＥ−ＩＳ ＮＯＭ」を送信
する。 ＜１９７＞＜０４２＞＜｛ｎｕｍｂｅｒ−ｏｆ−ｍｅｓｓａｇｅｓ｝＜２５
５＞＜２５４＞ そうではなく、ＤＣＥが、保留中のメッセージの数を知りたくない（入力スト
リームについて）場合に、ＤＣＥは、「ＤＯＮＴ ＮＯＭ」を応答する。 ← ＜１９４＞＜０４２＞＜２５５＞＜２５４＞

【０２６８】 [パラメータ] ｛ｎｕｍｂｅｒ−ｏｆ−ｍｅｓｓａｇｅｓ｝ 保留中のメッセージの数は、ネットワーク・バイト順の符号なし長整数である
。ある当事者が、このオプションをサポートするが、メッセージの数を判定でき
ない場合には、その当事者は、保留中のメッセージの数として−１（４２９４９
６７２９５）の値を返す。当事者が送信すべきメッセージを有しない、キューが
空である、またはモードがメッセージの送信を許容しない場合には、保留中のメ
ッセージの数として０の値を返す。当事者が、送信すべきメッセージを４２９４
９６７２９５個以上有する場合には、保留中のメッセージの数として４２９４９
６７２９５の値を返す。すなわち、当事者は、保留中のメッセージの数を判定す
ることができない。データ・バイト２５５は、二重にしなければならない。

【０２６９】 [例] モードはＯＵＴＰＵＴである。ＤＣＥは、ＤＴＥに保留中のメッセージの数を
与えることに合意する。 ＜１９３＞＜０４２＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０４２＞＜２５５＞＜２５４＞ ・ ・ ・ ← ＜１９７＞＜０４２＞＜０００＞＜０００＞＜０００＞＜０００＞＜２
５５＞＜２５４＞ この場合、ＤＣＥは、ＤＴＥに転送するメッセージを有しない。

【０２７０】 ３．１３ ＢＩＧＦＯＯＴ ［ビッグ・コード番号付け］ 識別 名前：ＢＩＧＦＯＯＴ、コード＝８２ 依存性： なし

【０２７１】 [概要] ビッグ・コード番号付け（ＢＩＧＦＯＯＴ）プロトコル・オプションによって
、より多数のパケット、フィールド、およびオプション・コードをサポートする
ために基本プロトコルが拡張される。

【０２７２】 このオプションが有効である時には、パケット、フィールド、およびオプショ
ンの識別が、１バイトまたは２バイトにまたがることができる。第１バイトの２
５３の値は、次の２バイトに、ネットワーク・バイト順のコード番号が含まれる
ことを示す。

【０２７３】 たとえば、次のＷＩＬＬパケットを検討されたい。 ＜１９５＞＜２５３＞＜００３＞＜００２＞＜２５５＞＜２５４＞ このＷＩＬＬパケットでは、オプション・コード７７０が識別され、パラメー
タ・データは全く含まれない。

【０２７４】 たとえば、次のＭＥＳＳＡＧＥパケットを検討されたい。 ＜２００＞＜２５５＞＜０６４＞ＨＥＬＬＯ＜２５５＞＜２５３＞＜２０１
＞＜２５５＞Ｃ２５６＜２５５＞＜２５４＞ このＭＥＳＳＡＧＥパケットには、２つのフィールドｉｄすなわち、６４およ
び５１７１１が含まれる。フィールド６４には、「ＨＥＬＬＯ」が含まれる。フ
ィールド５１７１１には、「Ｃ２５６」が含まれる。

【０２７５】 たとえば、次のパケットを検討されたい。 ＜２５３＞＜００１＞＜０２１＞＜２５５＞＜２５４＞

【０２７６】 このパケットは、パケットｉｄ７２２を有するが、フィールドまたはデータは
含まれない。

【０２７７】 この方式の下で、コード値２５３、２５４、および２５５を、２バイト・コー
ド値を使用して表すことができる。たとえば、＜２５３＞＜０００＞＜２５３＞
。

【０２７８】 このオプションによって、フィールド、オプション、およびパケット用に６５
５３６個の可能なコード値がもたらされる。２バイト・コード値内で、バイト値
２５５を二重にしてはならない。

【０２７９】 [動機づけ] 単一バイトによって提供されるコードの数が、将来に使い果たされることは大
いにありえる。このオプションでは、より多数のコード番号付けの好ましい方法
が推奨される。

【０２８０】 [ネゴシエーション] ＤＴＥが、ビッグ・コード番号付けを提供できる場合に、ＤＴＥは、「ＷＩＬ
Ｌ ＢＩＧＦＯＯＴ」を送信する。 ＜１９５＞＜０８２＞＜２５５＞＜２５４＞ → ＤＣＥが、ビッグ・コード番号付けを使用したい場合に、ＤＣＥは、「ＤＯ
ＢＩＧＦＯＯＴ」を応答する。 ← ＜１９３＞＜０８２＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、ビッグ・コード番号付けを使用したくない場合に、
ＤＣＥは、「ＤＯＮＴ ＢＩＧＦＯＯＴ」を応答する。 ← ＜１９４＞＜０８２＞＜２５５＞＜２５４＞ ＤＴＥが、ビッグ・コード番号付けを使用したい場合には、ＤＴＥは、「ＤＯ
ＢＩＧＦＯＯＴ」を送信する。 ＜１９３＞＜０８２＞＜２５５＞＜２５４＞ → ＤＣＥが、ビッグ・コード番号付けを提供できる場合には、ＤＣＥは、「ＷＩ
ＬＬ ＢＩＧＦＯＯＴ」を応答する。 ← ＜１９５＞＜０８２＞＜２５５＞＜２５４＞ そうではなく、ＤＣＥが、ビッグ・コード番号付けを提供できない場合には、
ＤＣＥは、「ＷＯＮＴ ＢＩＧＦＯＯＴ」を応答する。 ← ＜１９６＞＜０８２＞＜２５５＞＜２５４＞ ＤＴＥは、より大きい番号のコードを使用する計画がある場合に限って、この
オプションをネゴシエートする必要がある。

【０２８１】 [パラメータ] なし [例] ＤＴＥとＤＣＥが、ビッグ・コード番号付けを使用することに合意する。 ＜１９３＞＜０８２＞＜２５５＞＜２５４＞ → ← ＜１９５＞＜０８２＞＜２５５＞＜２５４＞

【０２８２】 [パケットの構文] 下記のパケット・コードが定義されている。 名前 コード 意味 ＣＯＮＮＥＣＴ １９２ 接続要求 ＤＯ １９３ プロトコル・オプションの要求／合意 ＤＯＮＴ １９４ プロトコル・オプションの否定 ＷＩＬＬ １９５ プロトコル・オプションの提供／合意 ＷＯＮＴ １９６ プロトコル・オプションの拒否 ＨＥＲＥ−ＩＳ １９７ サブ・ネゴシエーション ＲＥＡＤＹ １９８ レディ ＤＩＳＣＯＮＮＥＣＴ １９９ 終了／要求のシャットダウン ＭＥＳＳＡＧＥ ２００ データ・メッセージ ＭＥＳＳＡＧＥ−ＲＥＰＬＹ ２０１ 論理応答

【０２８３】 この章では、各パケットを説明する。 他のすべてのコードが、将来の使用のために予約されている。 下記のコードは、ＲＡＣＥパケット内でＩＡＣバイトがプレフィックスになっ
ている時に特定の意味を有する。 名前 コード 意味 ＥＮＤ−ＯＦ−ＰＡＣＫＥＴ ２５４ パケットの終り（ＥＯＰ） ＩＡＣ ２５５ データ・バイト２５５ ＦＩＥＬＤ−ＩＤＥＮＴＩＴＹ ０００から２５３まで フィールドｉ
ｄおよびフィールド区切り（ＦＩＤ）

【０２８４】 次の章で、各フィールドを説明する すべてのフィールドｉｄコードが使用されているわけではない。未使用のフィ
ールドｉｄコードは、将来の使用のために予約されており、これには、フィール
ド識別以外の用途が含まれる。

【０２８５】 以下にパケットの説明を示す。

【０２８６】 [ＣＯＮＮＥＣＴ] ＣＯＮＮＥＣＴは、ターゲットＤＣＥサービスおよびターゲットＤＣＥアプリ
ケーションを指定し、それに接続するために、ＤＴＥが送信する。 構文 意味 −− −− ＜１９２＞ パケット（１９２）の開始 ＜２５５＞＜０３１＞｛ｓｅｒｖｉｃｅ−ｉｄ｝ Ｆ３１ − ターゲット・
サービス ［＜２５５＞＜０３２＞｛ａｐｐｌ−ｉｄ｝ Ｆ３２ − ターゲット・アプ
リケーション ［＜２５５＞＜０３３＞｛ａｐｐｌ−ｉｄ｝］］ Ｆ３３ − ユーザ識別子
＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り [説明] 基本プロトコルを参照されたい。

【０２８７】 [ＤＯ] ＤＯは、オプション仕様に従ってプロトコル・オプションを要求するためにＤ
ＴＥによって送信される。

【０２８８】 ＤＯは、ＷＩＬＬの受信の後に、オプション仕様に従ってプロトコル・オプシ
ョンを受け入れるかさらにネゴシエートするために、ＤＣＥによって送信される
。 構文 意味 −− −− ＜１９３＞ パケット（１９３）の開始 ｛ｏｐｔ−ｃｏｄｅ｝ オプション・コード ［｛ｏｐｔ−ｐａｒａｍｓ｝］ オプション・パラメータ ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０２８９】 [説明] ＤＴＥは、オプション仕様の対象になるオプション・ネゴシエーション中にＤ
Ｏを送信することができる。ＤＣＥは、ＤＴＥからＷＩＬＬを受信した後に限っ
てＤＯを送信することができる。

【０２９０】 このパケットでは、フィールド表記を使用しない。フィールド識別子が、オプ
ション・パラメータのために必要な場合には、ＩＡＣバイトを二重にしなければ
ならない。たとえば、フィールド２２は、＜２５５＞＜２５５＞＜０２２＞とし
て指定する。この場合、デフォルト・パーサは、このフィールド識別をデータと
して解釈し、次の解釈のためのデータとして＜２５５＞＜０２２＞を渡す。その
後、二次パーサが、＜２５５＞＜０２２＞を有効なフィールド識別子として解釈
することができる。 ｛ｏｐｔ−ｃｏｄｅ｝、位置による（第２バイト） 符号なしバイト、値０から２５５までとしてのオプション・コード。データ・
バイト２５５は二重にしなければならない。 ｛ｏｐｔ−ｐａｒａｍｓ｝、位置による（｛ｏｐｔ−ｃｏｄｅ｝の後） オプションのサブネゴシエーションのためのオプション固有パラメータ。オプ
ション仕様に応じて、この引数は任意選択であり、個数が変化するデータ・バイ
トが含まれる。データ・バイト＜２５５＞は二重にしなければならない。

【０２９１】 １．０１ ＤＯＮＴ ＤＯＮＴは、ＷＩＬＬの受信の後に、ＷＩＬＬによって指定されるオプション
を拒絶するために、ＤＣＥによって送信される。 構文 意味 −− −− ＜１９４＞ パケット（１９４）の開始 ｛ｏｐｔ−ｃｏｄｅ｝ オプション・コード ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０２９２】 [説明] このパケットでは、フィールド表記を使用しない。 ｛ｏｐｔ−ｃｏｄｅ｝、位置による（第２バイト） 符号なしバイト、値０から２５５までとしてのオプション・コード。データ・
バイト２５５は二重にしなければならない。

【０２９３】 [ＷＩＬＬ] ＷＩＬＬは、オプション仕様に従ってプロトコル・オプションを申し出るため
に、ＤＴＥによって送信される。

【０２９４】 ＷＩＬＬは、ＤＯの受信の後に、オプション仕様に従ってプロトコル・オプシ
ョンを受け入れるかさらにネゴシエートするために、ＤＣＥによって送信される
。 構文 意味 −− −− ＜１９５＞ パケット（１９５）の開始 ｛ｏｐｔ−ｃｏｄｅ｝ オプション・コード ［｛ｏｐｔ−ｐａｒａｍｓ｝］ オプション・パラメータ ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０２９５】 [説明] ＤＴＥは、オプション仕様の対象になるオプション・ネゴシエーション中にＷ
ＩＬＬを送信することができる。ＤＣＥは、ＤＴＥからＤＯを受信した後に限っ
てＷＩＬＬを送信することができる。

【０２９６】 このパケットでは、フィールド表記を使用しない。フィールド識別子が、オプ
ション・パラメータのために必要な場合には、ＩＡＣバイトを二重にしなければ
ならない。たとえば、フィールド２２は、＜２５５＞＜２５５＞＜０２２＞とし
て指定する。この場合、デフォルト・パーサは、このフィールド識別をデータと
して解釈し、次の解釈のためのデータとして＜２５５＞＜０２２＞を渡す。その
後、二次パーサが、＜２５５＞＜０２２＞を有効なフィールド識別子として解釈
することができる。 ｛ｏｐｔ−ｃｏｄｅ｝、位置による（第２バイト） 符号なしバイト、値０から２５５までとしてのオプション・コード。データ・
バイト２５５は二重にしなければならない。 ｛ｏｐｔ−ｐａｒａｍｓ｝、位置による（｛ｏｐｔ−ｃｏｄｅ｝の後） オプションのサブネゴシエーションのためのオプション固有パラメータ。オプ
ション仕様に応じて、この引数は任意選択であり、個数が変化するデータ・バイ
トが含まれる。データ・バイト＜２５５＞は二重にしなければならない。

【０２９７】 １．０１ ＷＯＮＴ ＷＯＮＴは、ＤＯの受信の後に、ＤＯによって指定されるオプションを拒絶す
るために、ＤＣＥによって送信される。 構文 意味 −− −− ＜１９６＞ パケット（１９６）の開始 ｛ｏｐｔ−ｃｏｄｅ｝ オプション・コード ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０２９８】 [説明] このパケットでは、フィールド表記を使用しない。 ｛ｏｐｔ−ｃｏｄｅ｝、位置による（第２バイト） 符号なしバイト、値０から２５５までとしてのオプション・コード。データ・
バイト２５５は二重にしなければならない。

【０２９９】 １．０１ ＨＥＲＥ−ＩＳ ＨＥＲＥ−ＩＳは、オプション仕様に従ってオプションをさらにネゴシエート
するために、ＤＴＥまたはＤＣＥによって送信される。そのオプションは、ＨＥ
ＲＥ−ＩＳを使用する前に合意されていなければならない。 構文 意味 −− −− ＜１９７＞ パケット（１９７）の開始 ｛ｏｐｔ−ｃｏｄｅ｝ オプション・コード ［｛ｏｐｔ−ｐａｒａｍｓ｝］ オプション・パラメータ ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０３００】 [説明] このパケットでは、フィールド表記を使用しない。フィールド識別子が、オプ
ション・パラメータのために必要な場合には、ＩＡＣバイトを二重にしなければ
ならない。たとえば、フィールド２２は、＜２５５＞＜２５５＞＜０２２＞とし
て指定する。この場合、デフォルト・パーサは、このフィールド識別をデータと
して解釈し、次の解釈のためのデータとして＜２５５＞＜０２２＞を渡す。その
後、二次パーサが、＜２５５＞＜０２２＞を有効なフィールド識別子として解釈
することができる。 ｛ｏｐｔ−ｃｏｄｅ｝、位置による（第２バイト）

【０３０１】 符号なしバイト、値０から２５５までとしてのオプション・コード。データ・
バイト２５５は二重にしなければならない。 ｛ｏｐｔ−ｐａｒａｍｓ｝、位置による（｛ｏｐｔ−ｃｏｄｅ｝の後）

【０３０２】 オプションのサブネゴシエーションのためのオプション固有パラメータ。オプ
ション仕様に応じて、この引数は任意選択であり、個数が変化するデータ・バイ
トが含まれる。データ・バイト＜２５５＞は二重にしなければならない。

【０３０３】 [ＲＥＡＤＹ] ＲＥＡＤＹは、ＣＯＮＮＥＣＴの受信の後に、接続を受け入れるために、ＤＣ
Ｅによって送信される。

【０３０４】 ＲＥＡＤＹは、ネゴシエーションの後に、それが終了し、オプション・ネゴシ
エーションに合意可能であることを示すために、ＤＴＥによって送信される。

【０３０５】 ＲＥＡＤＹは、ＲＥＡＤＹの受信の後に、ＤＣＥがオプション・ネゴシエーシ
ョンに合意可能であることを示すために、ＤＣＥによって送信される。ＤＴＥお
よびＤＣＥは、ネゴシエーションに続いてＤＣＥがこのパケットを送信した後に
、即座にデータ転送に入る。 構文 意味 −− −− ＜１９８＞ パケット（１９８）の開始 ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０３０６】 [説明] 基本プロトコルを参照されたい。

【０３０７】 [ＤＩＳＣＯＮＮＥＣＴ] ＤＩＳＣＯＮＮＥＣＴは、リンクのシャットダウンを要求するために、ＤＴＥ
またはＤＣＥによって送信される。

【０３０８】 ＤＩＳＣＯＮＮＥＣＴは、オプション・ネゴシエーションの最後に、ネゴシエ
ーションを拒絶し、リンクをクローズするために、ＤＴＥによって送信される。

【０３０９】 ＤＩＳＣＯＮＮＥＣＴは、ＣＯＮＮＥＣＴまたはＲＥＡＤＹの受信の後に、接
続要求またはネゴシエーションを拒絶し、リンクをクローズするために、ＤＣＥ
によって送信される。

【０３１０】 また、ＤＩＳＣＯＮＮＥＣＴは、プロトコル・エラーまたは予期されないエラ
ーの後に、ＤＴＥまたはＤＣＥによって送信される。 構文 意味 −− −− ＜１９９＞ パケット（１９９）の開始 ［＜２５５＞＜０２１＞｛ｃｏｄｅ｝ Ｆ２１ − 切断コード ［＜２５５＞＜０２３＞｛ｔｅｘｔ｝］］ Ｆ２３ − 追加情報 ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０３１１】 [説明] シャットダウンの開始または終了に使用される時には、ＤＩＳＣＯＮＮＥＣＴ
がＳＵＣＣＥＳＳ（０）を運ばなければならない。そうでない場合には、ＤＩＳ
ＣＯＮＮＥＣＴは、例外として解釈され、それ以降の通信がブロックされる。

【０３１２】 切断コード引数Ｆ２１は、その値がＳＵＣＣＥＳＳ（０）である時には省略す
ることができる。省略された時には、ＳＵＣＣＥＳＳ（０）が仮定される。Ｆ２
３が存在する場合には、Ｆ２１も存在しなければならない。

【０３１３】 [ＭＥＳＳＡＧＥ] ＭＥＳＳＡＧＥは、アプリケーション・データ・メッセージを転送するために
送信される。 構文 意味 −− −− ＜２００＞ パケット（２００）の開始 ［＜２５５＞＜０１０＞｛ｓｅｑｎｏ｝］ Ｆ１０ − シーケンス番号 ［＜２５５＞＜０９１＞｛ｆｎａｍｅ｝ Ｆ９１ − ファイル名 ［＜２５５＞＜０９２＞｛ｆｓｔａｍｐ｝］］ Ｆ９２ − ファイル作成日
時 ［＜２５５＞＜０６３＞｛ｍｓｇｌｅｎ｝］ Ｆ６３ − メッセージ長（プ
レフィックス） ＜２５５＞＜０６４＞｛ｍｓｇ｝ Ｆ６４ − メッセージ ［＜２５５＞＜０６３＞｛ｍｓｇｌｅｎ｝］ Ｆ６３ − メッセージ長（サ
フィックス） ［＜２５５＞＜０６５＞｛ｐｄｅ｝］ Ｆ６５ − ＰＤＥフラグ ［＜２５５＞＜０６６＞｛ｍａｃ｝］ Ｆ６６ − ＭＡＣ ［＜２５５＞＜０６７＞｛ｌｇｒｐ｝］ Ｆ６７ − ＬＧＲＰ位置 ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０３１４】 [説明] デフォルトで、メッセージはＤＴＥからＤＣＥに送信される。ＭＯＤＥプロト
コル・オプションで、出力（ＤＣＥからＤＴＥへ）および両方向メッセージ転送
を可能にすることによって、この挙動を変更する。

【０３１５】 ＳＥＱＮＯプロトコル・オプションによって、Ｆ１０の使用法が決定される。
ＳＥＱＮＯが使用可能にされている時には、Ｆ１０は必須である。そうでない場
合には、Ｆ１０が存在してはならない。

【０３１６】 ＰＤＥプロトコル・オプションによって、Ｆ６５の使用法が決定される。ＰＤ
Ｅが、メッセージ転送の方向について使用可能にされている時には、可能な重複
放出を示すために、Ｆ６５が存在する可能性がある。

【０３１７】 ＭＡＣプロトコル・オプションによって、Ｆ６６の使用法が決定される。ＭＡ
Ｃが、メッセージ転送の方向について使用可能にされている時には、Ｆ６６は必
須である。そうでない場合には、Ｆ６６が存在してはならない。

【０３１８】 ＬＧＲＰプロトコル・オプションによって、Ｆ６７の使用法が決定される。Ｌ
ＧＲＰが、メッセージ転送の方向について使用可能にされている時には、論理グ
ループの先頭または終りを示すためにＦ６７が存在する可能性がある。

【０３１９】 ＭＳＧＬＥＮプロトコル・オプションによって、Ｆ６３の使用法が決定される
。ＭＳＧＬＥＮが、メッセージ転送の方向について使用可能にされている時には
、Ｆ６３は必須であり、メッセージ長の詳細を示す。ＭＳＧＬＥＮのネゴシエー
ションに応じて、Ｆ６３は、メッセージ内容であるＦ６４の前または後のいずれ
かにあることが期待される。

【０３２０】 ＢＡＴＣＨプロトコル・オプションによって、Ｆ９１およびＦ９２の使用法が
決定される。ＢＡＴＣＨが使用可能にされている時には、Ｆ９１が必須であり、
Ｆ９２は、任意選択として存在する可能性がある。そうでない場合には、Ｆ９１
およびＦ９２が存在してはならない。ＢＡＴＣＨが使用可能にされている時には
、Ｆ６４は、特定のアプリケーション・メッセージではなく、ファイルの内容に
なる。

【０３２１】 [ＭＥＳＳＡＧＥ−ＲＥＰＬＹ] ＭＥＳＳＡＧＥ−ＲＥＰＬＹは、ＭＥＳＳＡＧＥの受信の後に、データ・メッ
セージの解釈の成功または不成功を示すために送信される。 構文 意味 −− −− ＜２０１＞ パケット（２０１）の開始 ［＜２５５＞＜０１０＞｛ｓｅｑｎｏ｝］ Ｆ１０ − シーケンス番号 ［＜２５５＞＜０２１＞｛ｃｏｄｅ｝ Ｆ２１ − 応答コード ［＜２５５＞＜０２３＞｛ｔｅｘｔ｝］］ Ｆ２３ − 追加情報 ［＜２５５＞＜０２４＞｛ｕｍｒ｝］ Ｆ２４ − ＲＲＥＦ ＜２５５＞＜２５４＞ ＥＯＰ − パケットの終り

【０３２２】 [説明] コードＳＵＣＣＥＳＳは、肯定のメッセージ応答を示し、メッセージが受け入
れられたことを示す。そうでない場合には、応答は否定であり、メッセージが受
け入れられなかった。

【０３２３】 デフォルトで、メッセージ応答が、ＤＣＥからＤＴＥに返される。ＮＯＲＥＰ
ＬＹプロトコル・オプションおよびＭＯＤＥプロトコル・オプションによって、
この挙動が変更される。ＮＯＲＥＰＬＹでは、メッセージ応答がオフになる。Ｍ
ＯＤＥでは、メッセージ転送の方向に応じて、メッセージ応答をＤＴＥからＤＣ
Ｅに返すか、両方向で返すことができる。

【０３２４】 ＲＲＥＦプロトコル・オプションによって、Ｆ２４の使用法が決定される。Ｒ
ＲＥＦが、メッセージ転送の方向について使用可能にされている時には、Ｆ２４
は必須であり、Ｆ２４に、一意のメッセージ参照が含まれる。そうでない場合に
は、Ｆ２４が存在してはならない。

【０３２５】 ＳＥＱＮＯプロトコル・オプションによって、Ｆ１０の使用法が決定される。
ＳＥＱＮＯが使用可能にされている時には、Ｆ１０は必須である。そうでない場
合には、Ｆ１０が存在してはならない。

【０３２６】 応答コード引数であるＦ２１は、性能を高めるために、その値がＳＵＣＣＥＳ
Ｓ（０）である時には省略することができる。省略された時には、ＳＵＣＣＥＳ
Ｓが仮定される。Ｆ２３が存在する場合には、Ｆ２１も存在しなければならない
。

【０３２７】 [フィールド構文] Ｆ１０、シーケンス番号 使用法：ＳＥＱＮＯ（ＭＥＳＳＡＧＥ、ＭＥＳＳＡＧＥ−ＲＥＰＬＹ） フォーマット：ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ｉｎｔ（ネットワーク・バイ
ト順）

【０３２８】 詳細：シーケンス番号は、メッセージとメッセージ応答の両方に適用される。
入力と出力のメッセージ転送について、別々のカウンタが使用される。シーケン
ス番号は、新しい接続の開始時に１から始まり、１つずつ増分され、６５５３６
に達した後に１にラップする（すなわち、６５５３６、１３１０７１、…が１に
なる）。０は、有効なシーケンス番号ではない。

【０３２９】 Ｆ２１、応答コードまたは切断コード 使用法：ＢＡＳＩＣ（ＤＩＳＣＯＮＮＥＣＴ、ＭＥＳＳＡＧＥ−ＲＥＰＬＹ） フォーマット：ｕｎｓｉｇｎｅｄ ｓｈｏｒｔ ｉｎｔ（ネットワーク・バイ
ト順） 詳細：応答コードおよび切断コードとその意味の詳細については、この文書の
後ろの部分を参照されたい。ＤＩＳＣＯＮＮＥＣＴまたはＭＥＳＳＡＧＥ−ＲＥ
ＰＬＹでＦ２１が省略された場合には、ＳＵＣＣＥＳＳが仮定される。

【０３３０】 Ｆ２３、追加情報 使用法：ＢＡＳＩＣ（ＤＩＳＣＯＮＮＥＣＴ、ＭＥＳＳＡＧＥ−ＲＥＰＬＹ） フォーマット：ｃｈａｒ［２５６］ 詳細：追加情報は、Ｆ２１のコードを補足するのに使用される。このフィール
ドには１バイトから２５６バイトまでが含まれ、このフィールドはアプリケーシ
ョン固有である。通常、両端を含むバイト値３２から１２６までのＡＳＣＩＩが
使用される。

【０３３１】 Ｆ２４、一意メッセージ参照（ＵＭＲ） 使用法：ＲＲＥＦ（ＭＥＳＳＡＧＥ−ＲＥＰＬＹ） フォーマット：ｃｈａｒ［３２］ 詳細：一意メッセージ参照（ＵＭＲ）は、１個から６４個までの、両端を含む
バイト値３２から１２６までのＡＳＣＩＩ文字からなる。よい習慣の問題として
、参照を、先頭、末尾または中間の空白を含まない英数字文字にすることが推奨
される。

【０３３２】 Ｆ３１、ターゲット・サービス 使用法：ＢＡＳＩＣ（ＣＯＮＮＥＣＴ） フォーマット：ｃｈａｒ［６４］ 詳細：ＤＣＥサービス識別子（プロトコル・タイプ）。識別子には、１個から
６４個までの、両端を含むバイト値３２から１２６までのＡＳＣＩＩ文字が含ま
れる。

【０３３３】 Ｆ３２、ターゲット・アプリケーション 使用法：ＢＡＳＩＣ（ＣＯＮＮＥＣＴ） フォーマット：ｃｈａｒ［６４］ 詳細：ＤＣＥアプリケーション名（デーモン、接続点、Ｉ／Ｏキュー名）。識
別子には、１個から６４個までの、両端を含むバイト値３２から１２６までのＡ
ＳＣＩＩ文字が含まれる。

【０３３４】 Ｆ３３、ユーザ識別子 使用法：ＢＡＳＩＣ（ＣＯＮＮＥＣＴ） フォーマット：ｃｈａｒ［６４］ 詳細：ＤＴＥアプリケーション名（ユーザ識別子、接続点、Ｉ／Ｏキュー名）
。Ｆ３２と同様に、識別子には、１個から６４個までの、両端を含むバイト値３
２から１２６までのＡＳＣＩＩ文字が含まれる。

【０３３５】 Ｆ６３、メッセージ長 使用法：ＭＳＧＬＥＮ（ＭＥＳＳＡＧＥ） フォーマット：ｕｎｓｉｇｎｅｄ ｌｏｎｇ ｉｎｔ（ネットワーク・バイト
順） 詳細：Ｆ６４（メッセージの内容）の長さ。

【０３３６】 Ｆ６４、アプリケーション・データ・メッセージ 使用法：ＢＡＳＩＣ（ＭＥＳＳＡＧＥ） フォーマット：ｕｎｓｉｇｎｅｄ ｃｈａｒ［］ 詳細：アプリケーション固有の、数が変化する符号なしバイト。ＭＳＧＬＥＮ
プロトコル・オプションが有効な場合には、最大メッセージ長は４２９４９６７
２９５バイト（４ＧＢ）である。

【０３３７】 Ｆ６５、可能な重複放出（ＰＤＥ）フラグ 使用法：ＰＤＥ（ＭＥＳＳＡＧＥ） フォーマット：ｕｎｓｉｇｎｅｄ ｃｈａｒ 詳細：Ｆ６５は、可能な重複放出（ＰＤＥ）を示す。これには、バイナリ値１
の単一のバイトが含まれなければならない。

【０３３８】 Ｆ６６、メッセージ認証コード（ＭＡＣ） 使用法：ＭＡＣ（ＭＥＳＳＡＧＥ） フォーマット：ｕｎｓｉｇｎｅｄ ｃｈａｒ［６４］ 詳細：Ｆ６６には、認証アルゴリズムに応じて１個から６４個までの符号なし
バイトが含まれる。

【０３３９】 Ｆ６７、論理グループ化（ＬＧＲＰ）位置 使用法：ＬＧＲＰ（ＭＥＳＳＡＧＥ） フォーマット：ｕｎｓｉｇｎｅｄ ｃｈａｒ 詳細：論理グループの最初のメッセージに、位置１が割り当てられ、最後のメ
ッセージに、位置２が割り当てられる。Ｆ６７は、中間のメッセージには使用さ
れない。論理グループに１つのメッセージだけが含まれる場合には、Ｆ６７は使
用されず、単一のメッセージが、基本プロトコルに従ってｐｕｔされる。

【０３４０】 Ｆ９１、ファイル名 使用法：ＢＡＴＣＨ（ＭＥＳＳＡＧＥ） フォーマット：ｃｈａｒ［６４］ 詳細：バッチ・ファイルのファイル名。Ｆ９１には、英語の小文字および大文
字；数字；ドル記号；下線文字；ピリオド（終止符）文字に制限される、１個か
ら６４個までのＡＳＣＩＩ文字が含まれる。ピリオド文字は、ファイル名に１回
だけ現れることができ、名前をタイプ・サフィックスから分離するのに使用され
る。

【０３４１】 Ｆ９２、ファイル作成日時スタンプ 使用法：ＢＡＴＣＨ（ＭＥＳＳＡＧＥ） フォーマット：ｃｈａｒ［１６］ 詳細：グリニッジ標準時でのバッチ・ファイルの作成日時スタンプ。スタンプ
は、１６個のＡＳＣＩＩ数字で、フォーマットはＹＹＹＹＭＭＤＤＨＨＭＭＳＳ
ＮＮであり、ここで、ＹＹＹＹＭＭＤＤは、年月日を表し、ＨＨＭＭＳＳＮＮは
、時、分、秒、１／１００秒を表す。スタンプの一部、たとえば１／１００秒を
判定できない場合には、その部分にＡＳＣＩＩの０を書き込まなければならない
。

【０３４２】 データ・バイト＜２５５＞を二重にしなければならないことに注意されたい。

【０３４３】 [応答コード] 下記のコードが、ＭＥＳＳＡＧＥ−ＲＥＰＬＹのために定義されている。ユー
ザ・アプリケーションは、このプロトコルの将来のバージョンをサポートするた
めに、まだ定義されていない他のコードをサポートする準備ができていなければ
ならない。

【０３４４】 ０ ＳＵＣＣＥＳＳ、通常の成功裡の完了 説明：有効なメッセージが、受信され、解釈され、処理された。これには、後
続処理のための安全な保管を含めることができる。ＭＥＳＳＡＧＥ−ＲＥＰＬＹ
に応答コードが含まれない時には、ＳＵＣＣＥＳＳが仮定される。

【０３４５】 アクション：送信するアプリケーションは、送信済みとしてメッセージを更新
することができる。メッセージに関する責任は、受信するアプリケーションに渡
される。

【０３４６】 １００１ ＥＲＲＯＲ、エラー 説明：このエラー・コードは、ＭＥＳＳＡＧＥ−ＲＥＰＬＹで送信してはなら
ない。そうではなく、これは、ユーザまたは呼出し元ソフトウェアに未知のエラ
ー・コード（この節で現在定義されていない）を説明するのに使用される。

【０３４７】 アクション：最新のプロトコル・バージョンをサポートするようにユーザ・ソ
フトウェアをアップデートすることを検討する。

【０３４８】 ２００１ ＩＮＶＭＳＧ、無効なメッセージ 説明：無効なメッセージが、受信され、したがって、処理できなかった。

【０３４９】 アクション：エラーについてメッセージを検査する。問題ない場合には、受信
するアプリケーションのロジックを再検討する。追加情報についてＦ２３を調べ
る。 切断コード 下記のコードが、ＤＩＳＣＯＮＮＥＣＴのために定義されている。ユーザ・ア
プリケーションは、このプロトコルの将来のバージョンをサポートするために、
まだ定義されていない他のコードをサポートする準備ができていなければならな
い。

【０３５０】 ０ ＳＵＣＣＥＳＳ、通常の成功裡の完了 説明：ＤＴＥまたはＤＣＥのいずれかが、その処理を完了し、リンクのシャッ
トダウンを要求または確認している。ＤＩＳＣＯＮＮＥＣＴに切断コードが含ま
れない時には、ＳＵＣＣＥＳＳが仮定される。

【０３５１】 アクション：シャットダウンを開始する場合には、リンクをクローズするため
に、対応するＤＩＳＣＯＮＮＥＣＴパケットを待つ。シャットダウン要求を受信
した後には、すべての処理を完了し、対応するＤＩＳＣＯＮＮＥＣＴパケットを
返す。その後、リンクをクローズすることができる。

【０３５２】 １００１ ＥＲＲＯＲ、エラー 説明：このエラー・コードは、ＤＩＳＣＯＮＮＥＣＴで送信してはならない。
そうではなく、これは、ユーザまたは呼出し元ソフトウェアに未知のエラー・コ
ード（この節で現在定義されていない）を説明するのに使用する。

【０３５３】 アクション：最新のプロトコル・バージョンをサポートするようにユーザ・ソ
フトウェアをアップデートすることを検討する。

【０３５４】 ３０１４ ＳＲＶＮＯＴＡＶＬ、サービス使用不能 説明：ＤＣＥが、ＣＯＮＮＥＣＴ要求を受信したが、要求されたサービスが、
使用不能であるかサポートされていない。

【０３５５】 アクション：サービスの名前を検査し、それがサポートされているかどうかを
検査する。

【０３５６】 ３０２５ ＡＰＰＮＯＴＡＶＬ、アプリケーション使用不能 説明：ＤＣＥが、ＣＯＮＮＥＣＴ要求を受信したが、要求されたアプリケーシ
ョンが、使用不能であるかサポートされていない。

【０３５７】 アクション：ターゲット・アプリケーションの名前を検査する。

【０３５８】 ３０３６ ＡＰＰＢＵＳＹ、アプリケーション使用中、後に再試行せよ 説明：ＤＣＥが、ＣＯＮＮＥＣＴ要求を受信したが、要求されたアプリケーシ
ョンが、現在使用中である。

【０３５９】 アクション：ＤＣＥアプリケーションが共用される場合には、リンクをクロー
ズし、再試行（おそらくは短い遅延の後に）する。ＤＣＥアプリケーションが共
用されない場合には、別のＤＴＥインスタンスが走行中でないことを検査する。

【０３６０】 ３０４７ ＡＰＰＮＯＴＲＤＹ、アプリケーション作動不能、後に再試行せ
よ 説明：ＤＣＥが、ＣＯＮＮＥＣＴ要求を受信したが、要求されたアプリケーシ
ョンが、現在、新しい接続をリスンしていない。

【０３６１】 アクション：接続をクローズし、再試行する（短い遅延と再試行の最大回数を
使用する）。

【０３６２】 ３０５８ ＬＧＩＦＡＩＬ、ログイン失敗 説明：ログイン情報が正しくないか不十分であったので、ＤＴＥまたはＤＣＥ
のいずれかが、継続することができない。

【０３６３】 アクション：ログイン情報、認証キー、認証アルゴリズム、およびサポートさ
れるプロトコル・オプションを検査する。

【０３６４】 ３０６９ ＡＵＴＦＡＩＬ、認証失敗 説明：メッセージ認証に失敗したので、ＤＴＥまたはＤＣＥのいずれかが、継
続することができない。

【０３６５】 アクション：認証キー、アルゴリズム、およびサポートされるプロトコル・オ
プションを検査する。

【０３６６】 ３０８０ ＩＮＳＮＥＧＯＰＴ、ネゴシエートされたオプションが不十分 説明：ＤＴＥまたはＤＣＥが、ネゴシエートされたプロトコル・オプションを
用いて継続することができない。すなわち、一方の当事者が、１つまたは複数の
プロトコル機能を必要としたが、他方の当事者がそれをサポートしなかった。

【０３６７】 アクション：アプリケーションが非互換である。アプリケーションの一方を変
更する。

【０３６８】 ３０９１ ＲＥＳＦＡＩＬ、リソース障害 説明：メッセージが受信されたが、リソースに障害が発生し、メッセージを処
理できなくなった。たとえば、受信するアプリケーションが、ディスク・スペー
スまたはメモリを使い果たした可能性がある。メッセージは、有効である場合と
そうでない場合がある。メッセージは、処理されている場合とそうでない場合が
ある。

【０３６９】 アクション：オペレータは、受信するアプリケーションが障害を発生した理由
を調査する必要がある可能性が高い。受信するアプリケーションを修復した後に
、リンクを再オープンする。

【０３７０】 ３１０２ ＰＲＴＣＯＬＥＲＲ、プロトコル・エラー 説明：アプリケーションが、既知のパケット・タイプを受信したが、パケット
が予期されないものであった。たとえば、ＤＴＥが、ＲＥＡＤＹまたはＤＩＳＣ
ＯＮＮＥＣＴを期待していたが、ＭＥＳＳＡＧＥを受信した場合に、これがプロ
トコル・エラーを構成するはずである。

【０３７１】 アクション：プログラミング・エラーについてユーザ・アプリケーションを検
査する。

【０３７２】 ３１１３ ＩＮＶＰＫＴＴＹＰ、無効なパケット・タイプ 説明：アプリケーションが、無効なパケット・タイプを受信した。すなわち、
パケットの第１バイトが、有効なパケット識別子ではなかった。

【０３７３】 アクション：プログラミング・エラーについてユーザ・アプリケーションを検
査する。基礎となるトランスポートに信頼性があることを検査する。

【０３７４】 ３１２４ ＰＫＴＯＶＦＢＵＦ、パケットがバッファをオーバーフローした 説明：アプリケーションがパケットを受信し、そのパケットが、内部バッファ
・サイズを超えた。

【０３７５】 アクション：より小さいパケットを指定するか、アプリケーションの内部バッ
ファ・サイズを増やす。メッセージが、最大メッセージ長（アプリケーション・
レベルで定義される）より大きい場合には、ＤＩＳＣＯＮＮＥＣＴによってＰＫ
ＴＯＶＦＢＵＦを返すのではなく、ＭＥＳＳＡＧＥ−ＲＥＰＬＹによってＩＮＶ
ＭＳＧを返さなければならない。理想的には、アプリケーションが、パケット・
サイズを制限してはならない。

【０３７６】 ３１３５ ＴＯＯＭＡＮＦＬＤ、パケット内のフィールドが多すぎる 説明：他方のアプリケーションがパケットを受信したが、そのパケットが、内
部バッファに対して多すぎるパケット・フィールドを有していた。

【０３７７】 アクション：通常、これは、プログラミング・エラーを示し、そのエラーが多
すぎるフィールドをもたらした。ユーザ・アプリケーションを検査する。パケッ
トが正しい場合には、他方のアプリケーションの内部バッファを増やす。

【０３７８】 ３１４６ ＩＮＶＰＫＴＦＩＤ、無効なパケット・フィールド識別子 説明：他方のアプリケーションがパケットを受信したが、そのパケットに無効
なフィールド識別子が含まれていた。

【０３７９】 アクション：プログラミング・エラーについてアプリケーションを検査する。
基礎となるトランスポートに信頼性があることを検査する。

【０３８０】 ３１５７ ＩＮＶＰＫＴＳＹＮ、無効なパケット構文 説明：他方のアプリケーションがパケットを受信したが、そのパケットが無効
な構文を有していた。たとえば、あるフィールドが、正しくフォーマットされて
いなかった、順序がずれていた、または脱落していた。

【０３８１】 アクション：プログラミング・エラーについてアプリケーションを検査する。

【０３８２】 ３１６８ ＴＩＭＥＯＵＴ、タイムアウト 説明：他方のアプリケーションがパケットを期待していたが、タイムアウト期
間内にパケットを受信しなかった。

【０３８３】 アクション：プログラミング・エラーについてユーザ・アプリケーションを検
査する。タイムアウト期間が、アプリケーション、基礎となるトランスポート、
およびネットワークについて十分であることを検査する。

【０３８４】 ３１７９ ＩＮＶＳＥＱＮＯ、無効なシーケンス番号 説明：ＳＥＱＮＯプロトコル・オプションが合意され、メッセージまたはメッ
セージ応答に遭遇したが、それが無効なシーケンス番号を有した。

【０３８５】 アクション：シーケンシング・エラーについてアプリケーションを検査する。

【０３８６】 ３１９０ ＩＮＶＭＳＧＬＥＮ、無効なメッセージ長 説明：ＭＳＧＬＥＮプロトコル・オプションが合意され、Ｆ６３のメッセージ
長が、Ｆ６４の実際のメッセージ長と一致しなかった。

【０３８７】 アクション：プログラミング・エラーについて検査する。基礎となるトランス
ポートに信頼性があることを検査する。メッセージが、最大メッセージ長（アプ
リケーション・レベルで定義される）より大きい場合には、ＤＩＳＣＯＮＮＥＣ
ＴによってＩＮＶＭＳＧＬＥＮを返すのではなく、ＭＥＳＳＡＧＥ−ＲＥＰＬＹ
によってＩＮＶＭＳＧを返さなければならない。

【０３８８】 [送信の例] ２つのアプリケーションの間の通信の例を示す。ＤＴＥが、出力メッセージ転
送のために接続し、１メッセージをダウンロードする。その後、ＤＴＥは、安全
シャットダウンを開始する。 ｔ１： ＜１９２＞＜２５５＞＜０３１＞ｒａｃｅ＄ｇｅｎｅｒｉｃ＜２５
５＞＜０３２＞ＴＥＳＴＡＰＰＬ＜２５５＞＜２５４＞ ｃ１： ＜１９８＞＜２５５＞＜２５４＞ ｔ２： ＜１９３＞＜０３３＞＜００２＞＜２５５＞＜２５４＞ ＜１９３＞＜０５３＞＜２５５＞＜２５４＞ ＜１９５＞＜０５４＞＜２５５＞＜２５４＞ ｃ２： ＜１９５＞＜０３３＞＜００２＞＜２５５＞＜２５４＞ ＜１９５＞＜０５３＞＜２５５＞＜２５４＞ ＜１９４＞＜０５４＞＜２５５＞＜２５４＞ ｔ３： ＜１９８＞＜２５５＞＜２５４＞ ｃ３： ＜１９８＞＜２５５＞＜２５４＞ ｃ４： ＜２００＞＜２５５＞＜０６４＞ＨＥＬＬＯ ＷＯＲＬＤ．＜２５
５＞＜２５４＞ ｔ４： ＜２０１＞＜２５５＞＜２５４＞ ｔ５： ＜１９９＞＜２５５＞＜２５４＞ ｃ５： ＜１９９＞＜２５５＞＜２５４＞ これは、次のように要約することができる。 ｔ１： ＤＴＥが、ＣＯＮＮＥＣＴ、ターゲット・サービス「ｒａｃｅ＄ｇ
ｅ ｎｅｒｉｃ」、ターゲット・アプリケーション「ＴＥＳＴＡＰＰＬ」を送信
する ｃ１： ＤＣＥが、ＲＥＡＤＹを応答する ｔ２： ＤＴＥが、ＤＯ ＭＯＤＥ ＯＵＴＰＵＴ、ＤＯ ＰＤＥ、ＷＩＬ
Ｌ ＲＲＥＦを送信する ｃ２： ＤＣＥが、ＷＩＬＬ ＭＯＤＥ ＯＵＴＰＵＴ、ＷＩＬＬ ＰＤＥ、
ＤＯＮＴ ＲＲＥＦを応答する ｔ３： ＤＴＥが、ＲＲＥＦありまたはなしで継続することができるので、Ｄ
ＴＥが、ＲＥＡＤＹを送信する ｃ３： ＤＣＥが、ＲＥＡＤＹを応答する ｃ４： ＤＣＥが、その最初のＭＥＳＳＡＧＥ（「ＨＥＬＬＯ ＷＯＲＬＤ．
」）を送信する ｔ４： ＤＴＥが、肯定の肯定応答を返す。 ｔ５： ｋｅｅｐ ａｌｉｖｅタイマが満了した後に、ＤＴＥが、シャットダ
ウンを要求する ｃ５： ＤＣＥが、シャットダウンを確認する

───────────────────────────────────────────────────── フロントページの続き (71)出願人 Ｔｈｅ Ｌｅｙｓ， ２Ｃ Ｌｅｙｔｏｎ Ｒｏａｄ， Ｈａｒｐｅｎｄｅｎ， Ｈ ｅｒｔｓ ＡＬ５ ２ＴＬ， Ｕｎｉｔｅ ｄ Ｋｉｎｇｄｏｍ

Claims (24)

【特許請求の範囲】
1. 【請求項１】 第１コンピュータ・アプリケーションから第２コンピュータ
   ・アプリケーションにメッセージを通信する方法であって、 前記第１アプリケーションと前記第２アプリケーションとの間のメッセージン
   グ互換性が、所定の種類のオプションのイニシエーションとネゴシエーションと
   を含むプロトコルを使用して確立され、 前記オプションが、追加オプションを含むように拡張可能であるオプションの
   組に属することを特徴とする方法。
2. 【請求項２】 第１コンピュータ・アプリケーションから第２コンピュータ
   ・アプリケーションにメッセージを通信する方法であって、 前記第１アプリケーションと前記第２アプリケーションとの間のメッセージン
   グ互換性が、所定の種類のオプションのネゴシエーションだけに制限される必須
   要素を有する言語を含むプロトコルを使用して確立され、 前記オプションが、追加オプションを含むように拡張可能であるオプションの
   組に属することを特徴とする方法。
3. 【請求項３】 前記第１アプリケーション又は前記第２アプリケーション、
   もしくはその両方が、前記プロトコルに対する属性を宣言することを特徴とする
   、請求項１又は請求項２に記載の第１コンピュータ・アプリケーションから第２
   コンピュータ・アプリケーションにメッセージを通信する方法。
4. 【請求項４】 前記ネゴシエーションが、所定のオプションの許容可能なパ
   ラメータの範囲内で行われることを特徴とする請求項１乃至請求項３のいずれか
   １項に記載の方法。
5. 【請求項５】 前記ネゴシエーション・パラメータが、ネゴシエート要求に
   含まれることを特徴とする請求項４に記載の方法。
6. 【請求項６】 アプリケーションがオプションを実行できる場合に、前記ア
   プリケーションが、他方のアプリケーションがそのオプションをサポートするか
   どうかを最初に尋ねることを特徴とする請求項１乃至請求項５のいずれか１項に
   記載の方法。
7. 【請求項７】 アプリケーションが、自由裁量のオプション・パラメータ値
   を述べるメッセージを他方のアプリケーションに送信することを特徴とする請求
   項６に記載の方法。
8. 【請求項８】 他方のアプリケーションが、そのオプションをサポートしな
   い場合には、前記他方のアプリケーションが、それに応じて若しくは代替的に応
   答し、前記他方のアプリケーションがそのオプションをサポートする場合には、
   前記他方のアプリケーションが、受け入れ可能な前記自由裁量のパラメータ値を
   述べて応答し、前記２つのアプリケーションが、前記オプションを想定すること
   、若しくはさらにネゴシエートすることを可能にすることを特徴とする請求項６
   に記載の方法。
9. 【請求項９】 ネゴシエーションが、前記２つのアプリケーションの間の会
   話の初期の限られた発生回数でのみ許容されることを特徴とする請求項１乃至請
   求項８のいずれか１項に記載の方法。
10. 【請求項１０】 追加オプションを含むための拡張が、通信中に発生しても
    よいことを特徴とする請求項１または請求項２に記載の方法。
11. 【請求項１１】 前記第１アプリケーションまたは前記第２アプリケーショ
    ンもしくはその両方が、その属性を宣言し、かつ、あらゆる関連するオプション
    が、ネゴシエートされた結果に達するためにネゴシエートされることを特徴とす
    る請求項３に記載の方法。
12. 【請求項１２】 前記ネゴシエートされた結果が、前記アプリケーションの
    一方若しくは双方によって宣言された前記属性に従うように検証されることを特
    徴とする請求項１１に記載の方法。
13. 【請求項１３】 接続するアプリケーションが、全くネゴシエートしないこ
    とを特徴とする請求項１または請求項２に記載の方法。
14. 【請求項１４】 接続されるアプリケーションが、それが提案されるオプシ
    ョンをサポートしない場合に、 ＤＯＮＴタイプまたはＷＯＮＴタイプのメッセージを用いて応答することを特徴
    とする請求項１または請求項２に記載の方法。
15. 【請求項１５】 サービス識別子およびアプリケーション識別子を、接続要
    求内に追加することができることを特徴とする請求項１または請求項２に記載の
    方法。
16. 【請求項１６】 一意の識別子が、各オプションに割り当てられることを特
    徴とする請求項１または請求項２に記載の方法。
17. 【請求項１７】 請求項１乃至請求項１６のいずれか１項に記載の方法のい
    ずれかを使用することを特徴とするアプリケーション統合の方法。
18. 【請求項１８】 請求項１乃至請求項１７のいずれか１項に記載の方法を使
    用するポリシ、アダプタ、またはエージェントを追加または使用する方法。
19. 【請求項１９】 請求項１乃至請求項１８のいずれか１項に記載の方法を使
    用する標準ＡＰＩを確立または使用する方法。
20. 【請求項２０】 アプリケーション、サービス、接続、またはメッセージの
    アドレスの一部として名前を割り当てる、若しくは使用する方法であって、前記
    メッセージが、請求項１乃至請求項１９のいずれか１項に記載の方法を使用して
    通信されることを特徴とする方法。
21. 【請求項２１】 前記アプリケーションの１または両方が、実際に使用する
    通信プロトコルに合意するためにネゴシエートまたは妥協するように、前記第１
    アプリケーションまたは前記第２アプリケーションのいずれかによってサポート
    される複数の通信プロトコルを使用可能にするプロトコルを利用して、前記第１
    アプリケーションと前記第２アプリケーションとの間のメッセージング互換性が
    確立されることを特徴とする請求項１乃至請求項１６のいずれか１項に記載の方
    法。
22. 【請求項２２】 請求項１乃至請求項１９のいずれか１項に記載の方法を実
    行するようにプログラムされたコンピュータ・ハードウェア装置。
23. 【請求項２３】 コンピュータ・ハードウェアに請求項１乃至請求項１９の
    いずれか１項に記載の方法を実行させることを可能とする、ソフトウェアがプロ
    グラムされた記憶媒体。
24. 【請求項２４】 請求項１乃至請求項１９のいずれか１項に記載の方法を利
    用して若しくは、前記方法によって交換されるアプリケーション・メッセージ。