RFC2156 Network Working Group S. Kille Request for Comments: 2156 Isode Ltd. Obsoletes: 987, 1026, 1138, 1148, 1327, 1495 January 1998 Updates: 822 Category: Standards Track MIXER (Mime Internet X.400 Enhanced Relay): X.400 と RFC 822/MIME とのマッピングについて このメモの位置づけ このドキュメントはインターネット社会のための、インターネット標準トラック プロトコルを記載するものであり、改良するための議論および提案を要求する ものである。標準化のための“インターネットの公式プロトコル規格”(STD1) の現在の版、およびこのプロトコルの状態を参照してください。 このメモの配布は無制限である。 Copyright Notice 著作権表示 Copyright (C) The Internet Society (1998). All Rights Reserved. 目次 1 - 背景 .......................................... 3 1.1 - X.400 ......................................... 3 1.2 - RFC 822 と MIME ............................... 3 1.3 - 変換の必要性 .................................. 4 1.4 - 一般的なアプローチ ............................ 4 1.5 - Gateway のモデル .............................. 5 1.6 - X.400 (1984) のサポート ....................... 8 1.7 - X.400 (1992) .................................. 8 1.8 - MIME .......................................... 8 1.9 - ボディパート .................................. 8 1.10 - Local と Global なシナリオ .................... 9 1.11 - 以前のバージョンとの互換性 .................... 10 1.12 - Aspects not covered ........................... 10 1.13 - サブセット .................................... 11 1.14 - 言語の仕様 .................................... 11 1.15 - 関連する仕様 .................................. 11 1.16 - 文書構造 ...................................... 12 1.17 - 承認 .......................................... 12 2 - サービス要素 .................................. 13 2.1 - ゲートウェイを通過するサービスの概念 .......... 13 2.2 - RFC 822 ....................................... 15 2.3 - X.400 ......................................... 18 3 - 基本的なマッピング ............................ 27 3.1 - 表記法 ........................................ 27 Kille Standards Track [Page 1] RFC 2156 MIXER January 1998 3.2 - ASCII と IA5 .................................. 29 3.3 - 標準のタイプ .................................. 29 3.4 - ASCII の印字可能文字のエンコード .............. 33 3.5 - RFC 1522 ...................................... 34 4 - アドレスとメッセージID ........................ 35 4.1 - MTS.ORAddress の本文の表現 .................... 36 4.2 - グローバルアドレスのマッピング ................ 43 4.3 - EBNF.822-address <-> MTS.ORAddress ............ 46 4.4 - 繰り返されたマッピング ........................ 59 4.5 - ディレクトリの名前 ............................ 62 4.6 - MTS のマッピング .............................. 62 4.7 - IPMS のマッピング ............................. 67 5 - 詳細なマッピング............................... 71 5.1 - RFC 822 -> X.400: 詳細なマッピング ............ 71 5.2 - 内容の復帰 .................................... 86 5.3 - X.400 -> RFC 822: 詳細なマッピング. ........... 86 Appendix A - SMTP に特有なマッピング ....................... 114 1 - 調査 .......................................... 114 2 - 長い行 ........................................ 114 3 - SMTP の拡張 ................................... 114 3.1 - X.400 への SMTP 拡張のマッピング .............. 114 3.2 - SMTP 拡張への X.400 のマッピング .............. 115 Appendix B - X.400(1984) とのマッピング .................... 116 Appendix C - RFC 822 拡張の X.400 へのアクセス ............. 118 Appendix D - オブジェクト識別子の割り当て .................. 119 Appendix E - BNF サマリ .................................... 120 Appendix F - MCGAM distribution へのテキストフォーマット ... 127 1 - テキストフォーマット .......................... 127 2 - MCGAMs のレジスタと distribute のメカニズム ... 127 3 - Syntax 定義 ................................... 128 4 - テーブルルックアップ .......................... 129 5 - Domain -> OR Address MCGAM format ............. 129 6 - OR Address -> Domain MCGAM format ............. 129 7 - Domain -> 優先する Gateway テーブルの OR Addresse ................................... 130 8 - OR Addresss -> 優先する Gateway テーブルの domain ........................................ 130 Appendix G - 準拠 .......................................... 131 Appendix H - 変更履歴: RFC 987, 1026, 1138, 1148 ............................................... 133 1 - イントロダクション ............................ 133 2 - サービス要素 .................................. 133 3 - 基本的なマッピング ............................ 133 4 - アドレス ...................................... 134 5 - 詳細なマッピング .............................. 134 6 - 付録 .......................................... 134 Appendix I - 変更履歴: RFC 1148 to RFC 1327 ................ 135 Kille Standards Track [Page 2] RFC 2156 MIXER January 1998 1 - 一般 .......................................... 135 2 - 基本的なマッピング ............................ 135 3 - アドレス ...................................... 135 4 - 詳細なマッピング .............................. 135 5 - 付録 .......................................... 136 Appendix J - 変更履歴: RFC 1327 to this Document ............................................... 137 1 - 一般 .......................................... 137 2 - サービス要素 .................................. 137 3 - 基本的なマッピング ............................ 137 4 - アドレス ...................................... 137 5 - 詳細なマッピング .............................. 138 6 - 付録 .......................................... 138 Appendix L - ASN.1 サマリ .................................. 139 セキュリティの考察 ......................................... 141 著者 Address ............................................... 141 参考文献 ................................................... 141 Full Copyright Statement ................................... 144 第一章 -- 背景 1.1. X.400 この文書は、第1に ITU-T に推薦された 1988 および 1992 X.400 シリーズ / ISO IEC 10021 国際規格 に関連する。この ISO/ITU-T 規格はこの文書中で “X.400”と言う風に短く呼ばれている。1984 版勧告への様々なリファレンス は明示的であろう。様々なマッピングは要素に関連があり、その要素は 1992 版に示されており、1988 版には明示されていないであろう。X.400 は Interpersonal (相互個人) なメッセージングシステム (IPMS) を定義し、 蓄積交換メッセージ交換システムを使う為に作られている。この文書は、IPMS に関連し、X.435 の中で定義されているような EDI の様な広義の X.400 アプリケーションには関連しない。 1.2. RFC 822 と MIME RFC822 は DARPA (the US Defense Advanced Research Projects Agency) Internet 上のメッセージング規格として発展した。RFC822 の仕様はエンドトゥエンドの メッセージ形式であり、ヘッダと構造化されていないテキストホディから成る。 MIME (Multipurpose Internet Mail Extensions) の仕様は RFC822 と共に利用 する為の、構造化されたメッセージ形式である。用語 "RFC822" はこの文書内で、 MIME と RFC822 の組合わせを参照するために使うこととする。RFC822 と MIME は、多くの異なるメッセージトランスファープロトコル環境と共に使用される。 MIXER の仕様の核心は、任意のサポートされた、メッセージトランスファー プロトコル上で動作する様に設計されている。 Kille Standards Track [Page 3] RFC 2156 MIXER January 1998 トランスファープロトコルの一つである、SMTP は特別に重要であり、MIXER の中でもカバーされている。Internet と他の TCP/IP ネットワークにおいて、 RFC822 は RFC821 と共に利用されており、もちろん良く知られた Simple Mail Transfer Protocol (SMTP) [30]、the host requirements specification [10] と共に、（各々に）準拠した方法の中で使用されている。SMTP を備えた MIXER の使用は 付録A に定義されている。 1.3. 変換の必要性 メールサービスの為のプロトコルには、RFC822 の使用をベースとした大きな コミュニティがあり、これらは X.400 システムによって提供される RPMS の ユーザと通信をしたいであろう。これは、もちろんコミュニティが異なる技術間 の過渡期を作ろうとする何れの場合においても、変換が速やかなサービスの 推移を保証する為に必要であるのと同様、要求されるであろう。そこには１つ 以上のゲートウェイがあることが期待され、この仕様は一貫した方法の中での 振る舞いによってそれらを可能にするであろう。用語、ゲートウェイは RFC822 と X.400 間のマッピングを行うコンポーネントについて記述するために使用される ことに注意してください。これは、mail 設計者の標準の使用法であるが、 transport とネットワークサービスの設計者によって使用されるものとは異なる ものである。 ゲートウェイの一致を提供することが望ましい: 1. ユーザに対する一貫したサービス 2. メッセージが複数のゲートウェイを通過する場合には最も良いサービスとなる。 1.4. 一般的なアプローチ 仕様の詳細には多くの基本的な原理がある。これらの原理はゴールであり、 仕様の全容において達成されていない。 1. 仕様は実用的であるべきである。"学術的な" 理由によって複雑なマッピング の要求があってはならない。複雑なマッピングは重要でない付加的な機能性を サポートするための要求であってはならない。 2. 1) に従って、ゲートウェイを通過する機能性は、なるべく高くあるべきである。 3. 任意の変換の結果による情報の欠落は常に悪い考えである。その為、ゲート ウェイにとって、そのプロセスのオブジェクト内の情報の破棄は、悪い考え である。これは完全にマッピング出来るとは限らない、要求されたサービス を含んでいる。 Kille Standards Track [Page 4] RFC 2156 MIXER January 1998 4. メールゲートウェイは、マッピングを実行するレイヤの上のレベルで動作する。 ゲートウェイはゲートウェイレベルでのオブジェクトの意味の cognisant だけ でなく、より高レベルの意味の cognisant を意味する。もし、ゲートウェイが 動作する上で生じるオブジェクトの、意味のある変換ならば、その後、 ゲートウェイはオブジェクト自身以上に理解する必要がある。 5. 1) により、マッピングは可逆的であるべきである。すなわち、ダブルの変換は どこにあなたがスタートしたかを知らせるべきである。 1.5. ゲートウェイモデル 1.5.1. X.400 X.400 は X.420 内での IPMS 概要サービスを定義し、[11] それは 3 つの 基本的なサービスを含む。 1. Origination 2. Reception 3. Management Management はユーザと IPMS とのローカルな対話であるが故に、ゲートウェイ するには適切でない。最初の２つのサービスは、次の２つのオブジェクトによる、 発信者 と 受信者へのオペレーションから成り立つ。 1. IPM (Interpersonal Message). これは２つのコンポーネント: ヘッダと ボディ。ボディは、ボディパートの基本的なコンポーネントになるであろう (例: IA5 テキストボディ、または、G3 FAX) シーケンス、または Interpersonal Messages の転送のように構造化されている。ヘッダは、 subject や、主要な受取人 (To)、他重要なエンドトゥエンドのユーザ情報を 含むフィールドから作られている。 2. IPN (Inter Personal Notification). UA レベルの与えられた IPM の受信に 関する通知。 origination サービスはさらに、与えられた IPM が正確に受信可能か見分ける テストのためのオブジェクトであるプローブの origination も可能にする。 受信サービスはさらに、配信の成功または失敗を示す、配信通知 (DR) の受信も 可能にする。 Kille Standards Track [Page 5] RFC 2156 MIXER January 1998 これらの IPMS サービスはメッセージトランスファーシステム (MTS) Abstract Service [12] を利用する。MTS Abstract Service は以下の３つの 基本的なサービスを提供する。 1. Submission (IPMS Origination に使用される) 2. Delivery (IPMS Reception に使用される) 3. Administration (IPMS Management に使用される) Administration はローカルな問題であり、この規格には影響しない。 Submission と Delivery は第一に MTS メッセージ（Envelope と Content を含む） に関連し、それは IPM や IPN（または他の解釈されていない内容）を運ぶ。 Envelope は Message Identifier, 発信人, そして 受信人のリストを含む。 Submission はさらに MTS Probe をサポートした、Probe Service を含んでいる。 Delivery はさらに 与えられた MTS メッセージが配信されたかどうか（または、 配信が出来たかどうかを Probe するため）を示すレポートを含む。 MTS は MTA (Message Transfer Agent) サービスを利用して対話する MTAs に よって提供された。そして、分散型オペレーションの手続きと共に、MTA 間の対話 を定義する。このサービスは MTS Messages, Probes, およびレポートの配送のため に提供される。 1.5.2. RFC 822 RFC 822 は ここでは 822-MTS サービスと呼ばれる、本義のサービスがあるという 仮定に基づく。822-MTS サービスは３つの基本的な機能を提供する： 1. 受信者リストの識別 2. エラーリターンアドレスの識別 3. RFC 822 メッセージの転送 RFC 822 ヘッダ内の 2) を達成することは可能である。 この仕様は 822-MTS サービスとして SMTP と共に、最も一般的に使用されるで あろう。MIXER 仕様の核心は、基本的ではない 822-MTS サービスに依存しないよう に書かれている。非基礎的な SMTP サービスの利用は、Appendix A に後述されてい る。この文書の核心は、822-MTS サービス用の SMTP 用語を用いて書かれている。 RFC822 メッセージは、解釈されていない ASCII テキストのヘッダとコンテント から成り立つ。ヘッダはプロトコル要素のフィールドに分けられている。これらの フィールドのほとんどは、IPM ヘッダフィールドに類似しており、またいくつかは、 MTS または MTA サービス要素に類似している。 Kille Standards Track [Page 6] RFC 2156 MIXER January 1998 RFC 822 は NOTARY メカニズム [28] を利用してのデリバリーステータス通知を サポートしている。 1.5.3. ゲートウェイ ２つのサービスのゲートウェイ機能の記述が与えられ、ゲートウェイ機能の本質 を今考慮することができる。MTS サービス要素上の SMTP (822-MTS) サービス マッピングと、IPM 上の RFC 822 マッピングについての考慮はエレガントであろ う。しかし、それらのサービス間において、明確に一致することはない。ほかの エレガントなアプローチは、X.400 アクセスユニット (AU) の定義としてこの文書 を扱うことであろう。この場合、Abstraction レベルは非常に高すぎ、いくつかの 必要なマッピング機能は失われる。一つのサイド上での、IPM フォーマット定義、 IPMS サービス要素、MTS サービス要素、そして MTA サービス要素は、少々複雑な 方法におけるその他の上での RFC 822 + SMTP 内でマッピングされ、その考慮は 必要である。複雑な内容については、Chapter 5 において明確になるであろう。 MTA サービス要素へのアクセスについては、最小限とされる。 以下の基本的なマッピングはこのように定義される。RFC 822 から X.400 へ送信 するとき、RFC 822 メッセージおよび関連する SMTP 情報は常に IPM (MTA, MTS, および IPMS サービス) にマッピングされ、デリバリーステータス通知はレポート にマッピングされる。X.400 から RFC 822 への場合は、RFC 822 メッセージと 関連する SMTP 情報は以下のものから配信されるであろう： 1. An IPN (MTA, MTS, and IPMS services) 2. An IPM (MTA, MTS, and IPMS services) レポート（MTA および MTS サービス）はデリバリーステータス通知にマッピング される。 Probes (MTA Service) は Chapter 5 で議論されるように、ゲートウェイによって 処理されるものとする。IPMS によって定義されたそれら以外の Content Types を 含む MTS メッセージは、ゲートウェイによってマッピングされず、もしほかの ゲートウェイを行う procedure が定義されていないなら、ゲートウェイにおいて、 除外されるべきである、 この仕様は X.400 IPMS に関係がある。将来の仕様では、他の X.400 Content Types のためのマッピングについて定義されるであろう。 Kille Standards Track [Page 7] RFC 2156 MIXER January 1998 1.5.4. 繰り返されたマッピング この仕様の第一のゴールは、単一のマッピングをサポートすることであり、それに よりX.400 と RFC 822 ユーザは最大限の機能性をもってコミュニケートすること が出来る。 ここに規定されたマッピングは、メッセージが X.400 と RFC822 間で多回数行き 来する部分で動作するためにデザインされている。このことは、特にディストリ ビューションリストの場合において、しばしば不可欠である。しかし一般的に これは、最も低い共通の分母（ほぼ RFC 822 に提示されたサービス）である、 サービスのレベルに通じるであろう。 いくつかの RFC 822 ネットワークは相互接続メカニズム（典型的な政策理由のため） のために X.400 を使うことを望むであろう。そして、これは完全にサポート されている。 X.400 メッセージが RFC 822 へ、そしてその後 X.400 に戻ってくる転送の部分で、 保存されつつある標準 RFC 822 での同等なサービスを持たない場合、X.400 サービスの期待は無い。-- もっともこれはいくつかの場合においては可能であろう。 1.6. X.400 (1984) のサポート MIXER の定義は、X.400 と RFC 822 間のマッピングについて定義された RFC 987 およびそれに追加された RFC 1026 の初期の仕様をベースとされている。MIXER マッピングの核心は、完全な 1988 年バージョンの X.400 を利用する様に定義され ており、1984 コンパチブルなサブセットではない。X.400(1988) の新しい特徴は、 RFC 987 内に定義されているより非常にクリーンなマッピングを提供する為に、 使うことができる。1984 との相互動作については、Appendix B に続くものと する。 もし、メッセージが、X.400(1988) MTA 経由で X.400(1984) システムに 転送さる場合、それは、この知られた方法（X.400(1988) MTA）無しにダウン グレードするよりも、Appendix B に続くルールに従う、わずかなより良い サービスを与えるであろう。それらの X.400(X.419) での仕様追加である、ダウン グレードする仕様は、RFC1328 [22] と RFC 1496 (HARPOON) [5] によって与えら れる。 1.7. X.400 (1992) X.400(1992) の特徴は、このマッピングのコアな部分によって利用されておらず、 そのため、同様なダウングレードの問題はない。 1.8. MIME MIME フォーマットメッセージは、このマッピングによって作られている。MIME メッセージが完全に RFC 822 に準拠するように、これは有能な MIME ではない システムに関連する問題を引き起こさないであろう。 Kille Standards Track [Page 8] RFC 2156 MIXER January 1998 1.9. ボディパート MIME と X.400 IPMS は共に任意のボディパートを搬送出来る。MIME は、新しい ボディパートを追加するためのメカニズムを定義し、新しいボディパートは IANA と共に登録されている。X.400 は、たいていボディパート 15 と呼ばれる、新しい ボディパートを追加しながら、メカニズムを定義する。機能拡張は、オブジェクト 識別子によって定義されており、そのためセントラルボディパート登録権の必要 はない。The Electronic Messaging Association (EMA) は、いくつかの共通な 使われたボディパートを確保する。EMA は、メッセージアタッチメントをサポート する、より汎用的な手段として File Transfer Body Part (FTBP) を利用する メカニズムの仕様を持つ。このアプローチは広範囲な商用サポートを得ている。 X.400 と MIME ボディパート間のマッピングは、MIXER 同士の仕様の中で定義され ており、それは RFC 2157 [8] としてここに関連づけられる。 Editor's Note: 2157 を参照することは、これら２つの文書が同時に進歩するように期待されて いる様に、解決されるであろう。 これら２つの仕様は共に完全な MIXER マッピングを形成する。 1.10. ローカルおよびグローバルなシナリオ X.400/MIME 相互動作には２つの基本的なシナリオがある： グローバルシナリオ 多数のゲートウェイによって相互接続された、２つのグローバルなメールネット ワーク (Internet/MIME と X.400) がある。オブジェクトは、多数のゲートウェイ を介して転送される場合がある。従って、ゲートウェイが辻褄のあった方法の中で 動作することは重要である。MIXER がこのシナリオをサポートすることは危うい。 ローカルシナリオ ゲートウェイは、クローズドなコミュニティをグローバルなメールネットワーク （これは、コネクティビティまたは Gateway Authorisation Policy によって強化 されることがある）へ接続するために使われている。これは、共通な商用シナリオ である。サービスの工業的な規格準備を許可する様に、MIXER はこのシナリオを サポートするのに有用である。しかし、これは MIXER ライクないくつかのものに よって、サポートされることがある。 グローバルシナリオのソリューションはローカルシナリオで動作するであろう。 しかしながら、重要な実装あるいは deployments 努力 (グローバルマッピングは 主としたマッピングであるが、他の詳細もある) またはグローバルなシナリオを サポートすることを要求されることは、MIXER の局面である。しかし、それらは ローカルなシナリオでは不要である。 Kille Standards Track [Page 9] RFC 2156 MIXER January 1998 ローカルシナリオがほとんどの deployments のための駆動力であること、また グローバルシナリオのサポートは次の重要なゴールであることにに注意すること。 さらに推移効果がある。厳密なローカルシナリオの状況下で最初に展開するゲート ウェイは、グローバルシナリオの中でそれら自身を見つけることを始める。共通な ケースは ADMD が提供したゲートウェイであり、それらはローカルシナリオにおい て、厳密にターゲットとされている。実際に、それらはADMD の顧客ではない X.400 ユーザと共に、配布リストとメッセージ交換によって、グローバルシナリオ内で、 すぐに動作し始める。このポイントにおいて、ユーザは、ローカルシナリオゲート ウェイの制約事項により、失う。 MIXER への準拠は、単なる実装（もっとも、明白に実装は準拠する方法において 動作させられる、ということは、クリティカルである）ではなく、ゲートウェイの instantiation に当てはまるということに、注意すること。 MIXER の実装ターゲットは、グローバルシナリオであり、MIXER の仕様はこの方法 においての動作を定義する。 1.11. 前バージョンとの互換性 この文書と古いバージョンの文書との間の変更点は、Appendix H, I, J で与えら れる。これらは、RFC 987, 1026, 1138, 1148, 1327 である。この文書は RFC 1327 [21] の改版である。可能な限り、変更点は互換性のある方法によって作られている。 1.12. Aspects not covered この文書の前バージョンにはいくつかのケースがあり、それらは意図されなかった 方法で使われた。このセクションは、有効範囲のいくつかの制限を明らかにする。 この仕様は特に指定しない： - 全ての X.400 サービスへのアクセスが可能な RFC822 の機能拡張 - X.400 ユーザインタフェース定義 これらは現に対である。X.400 サービスにマッピングするために、この仕様は、 RFC 822 のいくつかの拡張機能を定義する。副作用として、これらはいくつかの X.400 サービスへの 822 ユーザアクセスを与える。しかしながら、RFC 822 側の 目的は、現在のサービスを保持することであり、またアクセスが全ての X.400 サービスに与えられないということは意図的である。従って、インタフェースと して MIXER を利用するための X.400 の実装にとって、貧弱な選択となるであろう。 Kille Standards Track [Page 10] RFC 2156 MIXER January 1998 - そのことによってアクセスできない、非常に多くの X.400 の様相がある。もし、 テキストインタフェースが要求されるなら、RFC 822 の制限無しで X.400 において ターゲットとされた仕様は、より適切であろう。いくつかのこのエリアにおいての 付随的で制限された機能拡張は、有用であることが証明されており、それらは Appendix C において定義されている。 1.13. Subsetting この提案は、現状の RFC 822 利用者でのサービスを保つのに適切である、マッピング の仕様である。この仕様のサブセットである、インプリメントおよび仕様は 非 conformant であり、強く落胆させた。 1.14. 仕様言語 ISO と Internet スタンダードは、使われている言語のスタイルに関して明確な、 定義を持つ。この仕様は、ISO/ITU-T プロトコルと Internet プロトコル間を マッピングする。この文書は、以下の理由により、ISO 用語を使用する： 1. これは前バージョンにおいて行われた。 2. ISO 言語は機械的に Internet 言語に変換される場合がある、しかし その反対ではない。 ISO ルールにおける要素のキーは： 1. 全ての命令の特徴は、命令ステートメント、または単語 "shall" または "shall not" によって、明確に示されるべきである。 2. オプショナルな特徴は、単語 "may" で示されるべきである。 3. 単語 "should" とフレーズ "may not" は使われるべきではない。 仕様のいくつかのケースにおいて、オプショナルな特徴を利用する上でのガイダンス を発行し、このフレーズや単語、"recommended" や "not recommended" を使うこと による。 interpet へのこの文書は Internet ルールより報告されており、全ての "must" と 共に発生する "shall" を置き換える。 1.15. 関連する仕様 Mail-11 と X.400 および Mail-11 と RFC 822 間のマッピングは、RFC 2162 におい て描かれており、マッピングを利用することは、ここで定義されたそれらに関連づけ られている [2]。 Kille Standards Track [Page 11] RFC 2156 MIXER January 1998 1.16. 文書の構造 この文書は５つの章を持つ： 1. Overview - この章 2. Service Elements - これは、（エンドユーザの）サービスは、ゲートウェイ による、マッピングであることを記述する。 3. Basic Mappings - これは、第３章から５章、キャラクタセット間のマッピング および、いくつかの基本的なプロトコル要素で使われる、 ある基本的な表記法を記述する。 4. Addressing - これは、X.400 OR 名と RFC 822 間のマッピングを考察する。 それは本格的なゲートウェイコンポーネントである。 5. Detailed Mappings - これは、他の全てのマッピングの詳細が記述される。 10 の付録が更にある。 警告： THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED. IT WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822 AND X.400 (1988). DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS YOU ARE FAMILIAR WITH THESE SPECIFICATIONS. 1.17. Acknowledgements この仕様においての動作は、実質的に RFC 987 および RFC 1148 をベースにされて おり、それらは、各々の文書においてクレジットされた、たくさんの人々によって 書かれたものである。 RFC1148 上の人々による多くのコメントは、RFC1327 への先駆けとなっている。特に 次の人々からコメントと提案があった： Maurice Abraham (HP); Harald Alvestrand (Sintef); Peter Cowen (X-Tel); Jim Craigie (JNT); Ella Gardner (MITRE); Christian Huitema (Inria); Erik Huizer (SURFnet); Neil Jones (DEC); Ignacio Martinez (IRIS); Julian Onions (X-Tel); Simon Poole (SWITCH); Clive Roberts (Data General); Pete Vanderbilt (SUN); Alan Young (Concurrent). RFC1327 は普遍的に採用され、レビューチームが整形した。これは、次の人々が 含まれている： Urs Eppenberger (SWITCH)(Chair); Claudio Allocchio (INFN); Harald Alvestrand (UNINETT); Dave Crocker (Brandenburg); Ned Freed (Innosoft); Erik Huizer (SURFnet); Steve Kille (Isode); Peter Sylvester (GC Tech). Kille Standards Track [Page 12] RFC 2156 MIXER January 1998 Harald Alvestrand は、X.400 コードと共に DSN ステータスコードのマッピングの テーブルをも供給した。Ned Freed は、File Transfer Body Part のマッピング部分 を定義した。 コメントと記述は以下の人々からも受け取られた。 Bengt Ackzell (Generic Systems); Samir Albadine (Transpac); Mark Boyes (DEC); Larry Campbell (Boston Software Works); Jacqui Caren (Cray); Allan Cargille (MCI); Kevin Carrosso (Innosoft); Charlie Combs (OIW); Jim Craigie (Net-Tel); Eamon Doyle (Isocor); Efifion Edem (SITA); Jyrki Heikkinen (ICL); Edward Hibbert (DCL); Jeroun Houttin (Terena); Kevin Jordan (CDS); Paul Kingsnorth (DEC); Carl-Uno Manros (Manros Consulting); Suzan Mendes (Telis); Robert Miles (Softswitch); Roger Mizumorri (Enterprise Solutions Ltd); Keith Moore (University of Tennessee); Ruth Moulton (Net-Tel) Michel Musy (Bull); Kenji Nonaka (NTT): The OIW MHSIG; Tom Oliphant (SWITCH); Julian Onions (NEXOR); Jacob Palme (KTH); Olivier Paridaens (ULB); Mary la Roche (Citicorp); John Setsaas (Maxware); Russell Sharpe (DCL); Patrick Soulier (CCETT); Eftimios Tsigros (Universite Libre de Bruxelles); Sean Turner (IECA); Mark Wahl (Isode); David Wilson (Isode); Bill Wohler (Worldtalk); Alan Young (Isode); Alain Zahm (Telis). 第二章 -- サービス要素 この章では、この仕様によると提供されたゲートウェイを通過して作られたサービス を考察する。それは、そのような逆ドメインのユーザとのコミュニケーションの為の ゲートウェイによって、機能性を提供されるということを与える。この章では、 SINGLE トランスファのみのコンテキストにおいてのサービスマッピングを考察する。 そして、マルチゲートウェイを通過するマッピングは繰り返さない。 2.1. ゲートウェイを通過するサービスの概念 RFC 822 と X.400 は、エンドユーザにいくつかのサービスを提供する。この章では、 それぞれのサービスで X.400 <-> RFC 822 ゲートウェイを通過する際にサポートで きる範囲を描く。考えられたケースにおいては、そのようなゲートウェイを一度通過 する。もちろん、複数通過の問題は適切に記述される 2.1.1. Origination of Messages ユーザはメッセージを作成する際、サービスのいくつかは使用可能である。