RFC1767 日本語訳
1767 MIME Encapsulation of EDI Objects. D. Crocker. March 1995. (Format: TXT=15293 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Crocker Request for Comments: 1767 Brandenburg Consulting Category: Standards Track March 1995
コメントを求めるワーキンググループD.医者要求をネットワークでつないでください: 1767年のブランデンブルクコンサルティングカテゴリ: 1995年の標準化過程行進
MIME Encapsulation of EDI Objects
EDIオブジェクトのMIMEカプセル化
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction........................................... 1 2. Application/EDIFACT specification...................... 2 3. Application/EDI-X12 specification...................... 3 4. Application/EDI-Consent specification.................. 4 5. Sample edi usage in MIME-based email................... 5 6. References............................................. 5 7. Security Considerations................................ 6 8. Acknowledgments........................................ 6 9. Author's Address....................................... 6 10. Appendix - MIME for EDI users......................... 7
1. 序論… 1 2. アプリケーション/EDIFACT仕様… 2 3. アプリケーション/EDI-X12仕様… 3 4. EDIアプリケーション/同意仕様… 4 5. MIMEベースのメールのedi用法を抽出してください… 5 6. 参照… 5 7. セキュリティ問題… 6 8. 承認… 6 9. 作者のアドレス… 6 10. 付録--、EDIユーザのためのMIME… 7
1. Introduction
1. 序論
Electronic Data Interchange (EDI) provides a means of conducting structured transactions between trading partners. The delivery mechanism for these types of transactions in a paper world has been the postal system, so it is to be expected that electronic mail would serve as a natural delivery mechanism for electronic transactions. This specification permits formatted electronic business interchanges to be encapsulated within MIME messages [Bore92]. For the specification effort, the basic building block from EDI is an interchange.
電子Data Interchange(EDI)は貿易相手国の間に仕組み取引を行う手段を提供します。 紙の世界のこれらのタイプのトランザクションのための排紙機構が郵便の制度であるので、電子メールが電子取引のための自然分娩メカニズムとして機能すると予想されることになっています。 この仕様は、フォーマットされた電子ビジネス置き換えがMIMEメッセージ[Bore92]の中でカプセル化されることを許可します。 仕様取り組みのために、EDIからの基本的なブロックは置き換えです。
This specification pertains only to the encapsulation of EDI objects within the MIME environment. It intends no changes in those objects from the primary specifications that define the syntax and semantics of them. EDI transactions take place through a variety of carriage and exchange mechanisms. This specification adds to that repertoire, by permitting convenient carriage through Internet email.
この仕様はMIME環境の中でEDIオブジェクトのカプセル化だけに関係します。 それはそれらの構文と意味論を定義するプライマリ仕様からそれらのオブジェクトにおける変化を全く意図しません。 EDIトランザクションはさまざまなキャリッジと交換メカニズムを通して行われます。この仕様はそのレパートリーに加えます、インターネットメールで便利なキャリッジを可能にすることによって。
Crocker [Page 1] RFC 1767 EDI in MIME March 1995
MIME行進1995年のクロッカー[1ページ]RFC1767EDI
Since there are many different EDI specifications, the current document defines three distinct categories as three different MIME content-types. One is Application/EDI-X12, indicating that the contents conform to the range of specifications developed through the X12 standards organization [X125, X126, X12V]. Another is Application/EDIFACT, indicating that the contents conform to the range of specifications developed by the United Nations Working Party 4 Group of Experts 1 EDIFACT boards [FACT, FACV]. The last category covers all other specifications; it is Application/EDI-consent.
多くの異なったEDI仕様があるので、現在のドキュメントは3つの異なったMIME content typeと3つの異なったカテゴリを定義します。 1つはApplication/EDI-X12です、内容がX12規格組織[X125、X126、X12V]で開発された仕様の範囲に従うのを示して。 別のものはApplication/EDIFACTです、内容がExperts1EDIFACTボード[FACT、FACV]の国連Workingパーティ4Groupによって開発された仕様の範囲に従うのを示して。 最後のカテゴリは他のすべての仕様をカバーしています。 それはApplication/EDI-同意です。
2. APPLICATION/EDIFACT SPECIFICATION
2. アプリケーション/EDIFACT仕様
The Application/EDIFACT MIME body-part contains data as specified for electronic data interchange by [FACT, FACV].
Application/EDIFACT MIME身体部分は[FACT、FACV]による電子データ交換のために指定されるとしてのデータを含んでいます。
Within EDIFACT, information is specified by:
EDIFACTの中では、情報は以下によって指定されます。
MIME type name: Application
MIMEの種類名: アプリケーション
MIME subtype name: EDIFACT
MIME「副-タイプ」は以下を命名します。 EDIFACT
Required parameters: none
必要なパラメタ: なし
Optional parameters: CHARSET, as defined for MIME
任意のパラメタ: CHARSET MIMEのために定義されて、
Encoding considerations: May need BASE64 or QUOTED-PRINTABLE
transfer encoding
問題をコード化します: 必要性BASE64かQUOTED-PRINTABLEがコード化を移しますように。
Security considerations: See separate section in the
document.
セキュリティ問題: ドキュメントの別々のセクションを見てください。
Published specification: Contained in the following section.
広められた仕様: 以下のセクションでは、含まれています。
Rationale: The EDIFACT specifications are
accepted standards for a class of
inter-organization transactions;
this permits their transmission
over the Internet, via email.
原理: EDIFACT仕様は相互組織トランザクションのクラスの受け入れられた規格です。 これはメールで彼らのインターネットを利用した伝送を可能にします。
Contact-info: See Contact section, below.
コンタクトインフォメーション: 下のContact部を見てください。
Detail specific to MIME-based usage:
MIMEベースの用法に特定の詳細:
This is a generic mechanism for sending any EDIFACT
interchange. The object is self-defining, in terms of
indicating which specific EDI objects are included. Most
EDI data is textual, but special characters such as some
delimiters may be non-printable ASCII or some data may be
これは、どんなEDIFACT置き換えも送るためのジェネリックメカニズムです。 オブジェクトは、どの特定のEDIオブジェクトが含まれているかを自己に表示で定義しています。 ほとんどのEDIデータが原文ですが、いくつかのデリミタなどの特殊文字は非印刷可能なASCIIであるかもしれませんかいくつかのデータがそのようなASCIIです。
Crocker [Page 2] RFC 1767 EDI in MIME March 1995
MIME行進1995年のクロッカー[2ページ]RFC1767EDI
pure binary. For EDI objects containing such data, the MIME
transfer mechanism may need to encode the object in Content-
Transfer-Encoding:quoted-printable or base64.
純粋なバイナリー。 そのようなデータを含むEDIオブジェクトに関しては、MIMEトランスファ・メカニズムは引用されて印刷可能な状態で以下を転送でコード化するContentのオブジェクトをコード化する必要性かbase64がそうするかもしれません。
3. APPLICATION/EDI-X12 SPECIFICATION
3. エディアプリケーション/X12仕様
The Application/EDI-X12 MIME body-part contains data as specified for electronic data interchange by [X125, X12.6, EDIV].
エディ-X12 MIME身体Application/部分は[X125、X12.6、EDIV]による電子データ交換のために指定されるとしてのデータを含んでいます。
Within MIME, EDI-X12 information is specified by:
MIMEの中では、EDI-X12情報は以下によって指定されます。
MIME type name: Application
MIMEの種類名: アプリケーション
MIME subtype name: EDI-X12
MIME「副-タイプ」は以下を命名します。 エディ-X12
Required parameters: none
必要なパラメタ: なし
Optional parameters: CHARSET, as defined for MIME
任意のパラメタ: CHARSET MIMEのために定義されて、
Encoding considerations: May need BASE64 or QUOTED-PRINTABLE
transfer encoding
問題をコード化します: 必要性BASE64かQUOTED-PRINTABLEがコード化を移しますように。
Security considerations: See separate section in the
document.
セキュリティ問題: ドキュメントの別々のセクションを見てください。
Published specification: Contained in the following section.
広められた仕様: 以下のセクションでは、含まれています。
Rationale: The ASC X12 EDI specifications are
accepted standards for a class of
inter-organization transactions;
this permits their transmission
over the Internet, via email.
原理: ASC X12 EDI仕様は相互組織トランザクションのクラスの受け入れられた規格です。 これはメールで彼らのインターネットを利用した伝送を可能にします。
Contact-info: See Contact section, below.
コンタクトインフォメーション: 下のContact部を見てください。
Detail specific to MIME-based usage:
MIMEベースの用法に特定の詳細:
This is a generic mechanism for sending any ASC X12
interchange. The object is self-defining, in terms of
indicating which specific EDI objects are included. Most
EDI data is textual, but special characters such as some
delimiters may be non-printable ASCII or some data may be
pure binary. For EDI objects containing such data, the MIME
transfer mechanism may need to encode the object in Content-
Transfer-Encoding:quoted-printable or base64.
これは、どんなASC X12置き換えも送るためのジェネリックメカニズムです。 オブジェクトは、どの特定のEDIオブジェクトが含まれているかを自己に表示で定義しています。 ほとんどのEDIデータが原文ですが、いくつかのデリミタなどの特殊文字は非印刷可能なASCIIであるかもしれませんかいくつかのデータが純粋なバイナリーであるかもしれません。 そのようなデータを含むEDIオブジェクトに関しては、MIMEトランスファ・メカニズムは引用されて印刷可能な状態で以下を転送でコード化するContentのオブジェクトをコード化する必要性かbase64がそうするかもしれません。
Crocker [Page 3] RFC 1767 EDI in MIME March 1995
MIME行進1995年のクロッカー[3ページ]RFC1767EDI
4. APPLICATION/EDI-CONSENT SPECIFICATION
4. エディアプリケーション/CONSENT仕様
The Application/EDI-consent MIME body-part contains data as specified for electronic data interchange with the consent of explicit, bilateral trading partner agreement exchanging the EDI-consent traffic. As such, use of EDI-consent only provides a standard mechanism for "wrapping" the EDI objects but does not specify any of the details about those objects.
Application/EDI-同意MIME身体部分は明白で、双方の貿易相手国協定の同意がEDI-同意トラフィックを交換している電子データ交換のための指定されるとしてのデータを含んでいます。 そういうものとして、EDI-同意だけの使用は、EDIオブジェクトが「包装」であるのに標準のメカニズムを提供しますが、それらのオブジェクトの周りで詳細のいずれも指定しません。
Within MIME, EDI-consent information is specified by:
MIMEの中では、EDI-同意情報は以下によって指定されます。
MIME type name: Application
MIMEの種類名: アプリケーション
MIME subtype name: EDI-consent
MIME「副-タイプ」は以下を命名します。 EDI-同意
Required parameters: none
必要なパラメタ: なし
Optional parameters: CHARSET, as defined for MIME
任意のパラメタ: CHARSET MIMEのために定義されて、
Encoding considerations: May need BASE64 or QUOTED-PRINTABLE
transfer encoding
問題をコード化します: 必要性BASE64かQUOTED-PRINTABLEがコード化を移しますように。
Security considerations: See separate section in the
document.
セキュリティ問題: ドキュメントの別々のセクションを見てください。
Published specification: Contained in the following section.
広められた仕様: 以下のセクションでは、含まれています。
Rationale: Existing practice for exchanging
EDI includes a very wide range of
specifications which are not part
of the usual, accredited standards
world. Nevertheless, this traffic
is substantial and well-
established. This content type
provides a means of delimiting such
content in a standard fashion.
原理: EDIを交換するための既存の習慣は普通の、そして、公認の規格世界の一部でない非常に広範囲の仕様を含んでいます。 それにもかかわらず、このトラフィックは、実質的であって、よく確立しています。 このcontent typeは一般的なファッションによるそのような内容を区切る手段を提供します。
Contact-info: See Contact section, below.
コンタクトインフォメーション: 下のContact部を見てください。
Detail specific to MIME-based usage:
MIMEベースの用法に特定の詳細:
This is a generic mechanism for sending any EDI object
explicitly agreed to by the trading partners. X12 and
EDIFACT object must be sent using their assigned MIME
content type. EDI-consent is for all other EDI objects, but
only according to trading partner agreements between the
originator and the recipient. Most EDI data is textual,
but special characters such as some delimiters may be non-
これはどんなEDIオブジェクトも貿易相手国で明らかに同意した送付のためのジェネリックメカニズムです。 X12とEDIFACTオブジェクトにそれらの割り当てられたMIME content typeを使用させなければなりません。 EDI-同意は、他のすべてのEDIオブジェクトのためにありますが、創始者と受取人との貿易相手国協定だけ通りにあります。 ほとんどのEDIデータが原文ですが、いくつかのデリミタなどの特殊文字が原文である、非
Crocker [Page 4] RFC 1767 EDI in MIME March 1995
MIME行進1995年のクロッカー[4ページ]RFC1767EDI
printable ASCII or some data may be pure binary. For EDI
objects containing such data, the MIME transfer mechanism
may need to encode the object in Content-Transfer-
Encoding:quoted-printable or base64.
印刷可能なASCIIかいくつかのデータが純粋なバイナリーであるかもしれません。 以下をコード化するのが引用されて印刷可能なオブジェクトが中にContent移すエンコードに必要である状態でそのようなデータ、トランスファ・メカニズムが含むMIMEを含むEDIオブジェクトかbase64のために。
5. SAMPLE EDI USAGE IN MIME-BASED EMAIL
5. MIMEベースのメールのサンプルエディ用法
Actual use of EDI within MIME-based mechanisms requires attention to considerable detail. This section is intended as an example of the gist of the formatting required to encapsulate EDI objects within Internet mail, using MIME. To send a single EDIFACT interchange:
MIMEベースのメカニズムの中のEDIの実際の使用はかなりの詳細に関する注意を必要とします。 形式の要点に関する例が、インターネット・メールの中でオブジェクトをEDIにカプセルに入れるのを必要としたようにこのセクションは意図します、MIMEを使用して。 独身のEDIFACTを送るには、交換してください:
To: <<recipient organization EDI email address>> Subject: From: <<sending organization EDI email address>> Date: Mime-Version: 1.0 Content-Type: Application/EDIFACT Content-Transfer-Encoding: QUOTED-PRINTABLE
To: <<受取人組織EDI Eメールアドレス>>Subject: From: <<送出し機関EDI Eメールアドレス>>日付: パントマイムバージョン: 1.0コンテントタイプ: EDIFACTの満足している転送アプリケーション/コード化: 引用されて印刷可能です。
<<standard EDIFACT Interchange goes here>>
<の<の標準のEDIFACT Interchangeがここに行く、>>。
6. REFERENCES
6. 参照
[Bore92] Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet Message
Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
解放された[Bore92]Borenstein、N.、およびN.、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。
[Brad89] Braden, R., Editor, "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Internet
Engineering Task Force, October 1989.
[Brad89]ブレーデン、R.、エディタ、「STD3、RFC1123、インターネットが特別委員会を設計することでの10月1989日アプリケーションとサポート」インターネットホストのための要件--
[Croc82] Crocker, D., "Standard for the Format of Internet
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[Croc82] クロッカー、D.、「インターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[Rose93] Rose, M., "The Internet Message: Closing the Book
with Electronic Mail", PTR Prentice Hall, Englewood
Cliffs, N.J., 1993.
[Rose93] バラ、M.、「インターネットは以下を通信します」。 「電子メールがある決算」、PTRの新米のホール、イングルウッドがけ、ニュージャージー州、1993。
[Post82] Postel, J., "Simple Mail Transfer Protocol".
STD 10, RFC 821, USC/Information Sciences Institute,
August 1982.
[Post82] ポステル、J.、「簡単なメール転送プロトコル。」 STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[X12V] Data Interchange Standards Association; sets of
specific EDI standards are ordered by their version
number; Washington D.C.
[X12V]データは規格協会を交換します。 それらのバージョン番号で特定のEDI規格のセットを注文します。 ワシントンDC
Crocker [Page 5] RFC 1767 EDI in MIME March 1995
MIME行進1995年のクロッカー[5ページ]RFC1767EDI
[X125] ANSI X12.5 Interchange Control Structure for
Electronic Data Interchange, Washington D.C.: DISA
[X126] ANSI X12.6 Applications Control Structures for
Electronic Data Interchange, Washington D.C.: DISA
[X125]ANSI X12.5は電子データ交換、ワシントンDCに制御構造を交換します: DISA[X126]ANSI X12.6アプリケーションは電子データ交換、ワシントンDCに構造を制御します: DISA
[FACT] United Nations Economic Commission (UN/EC)
Electronic Data Interchange For Administration,
Commerce and Transport (EDIFACT) - Application Level
Syntax Rules (ISO 9735), 1991.
[事実]国連経済委員会(国連/EC)の電子データは政権、商業、および輸送(EDIFACT)のために交換されます--アプリケーションレベルシンタックス・ルール(ISO9735)、1991。
[FACV] Version sets contains the specific syntax documents,
the element and segment dictionaries, and the
transaction/message specifications.
[FACV]バージョンセットは特定の構文ドキュメント、要素、セグメント辞書、およびトランザクション/メッセージ仕様を含んでいます。
7. SECURITY CONSIDERATIONS
7. セキュリティ問題
EDI transactions typically include sensitive data, so that transmission often needs to attend to authentication, data integrity, privacy, access control and non-repudiation concerns. This specification permits transmission of such sensitive data via Internet mail and other services which support MIME object encapsulation. For transmission of sensitive data, it is essential that appropriate security services, such as authentication, privacy and/or non-repudiation be provided.
EDIトランザクションは極秘データを通常含んでいます、トランスミッションが、しばしば認証に気を配る必要があるように、データ保全、プライバシー、アクセス制御と非拒否関心。 この仕様はMIMEがオブジェクトカプセル化であるとサポートするインターネット・メールと他のサービスでそのような極秘データの伝達を可能にします。 極秘データの伝達において、認証、プライバシー、そして/または、非拒否などの適切なセキュリティー・サービスを提供するのは不可欠です。
This specification does NOT, itself, provide any security-related mechanisms. As needed and appropriate, such mechanisms MUST be added, either via Internet MIME-based security services or any other services which are appropriate to the user requirements, such as those provided by EDI-based standards.
この仕様はそうします。必要であるAs、および適切で、そのようなメカニズムを加えなければなりません、インターネットのMIMEベースのセキュリティー・サービスかEDIベースの規格で提供されたものなどのユーザ要件に適切ないかなる他のサービスでも。NOT(それ自体)はどんなセキュリティ関連のメカニズムも提供します。
8. ACKNOWLEDGMENTS
8. 承認
Tom Jones offered introductory text and descriptions of candidate header options. Numerous working group participants provided review and comment, especially Walt Houser, Gail Jackson, and Jim Amster.
トム・ジョーンズは候補ヘッダーオプションの紹介しているテキストと記述を提供しました。 多数のワーキンググループの関係者はレビュー、コメント、特にウォルト・ハウザー、ゲイル・ジャクソン、およびジムAmsterを提供しました。
9. AUTHOR'S ADDRESS
9. 作者のアドレス
David H. Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 USA
デヴィッドH.医者ブランデンブルクのコンサルティング675はサニーベルカリフォルニア94086博士(米国)を小綺麗にします。
Phone: +1 408 246 8253 Fax: +1 408 249 6205 EMail: dcrocker@mordor.stanford.edu
以下に電話をしてください。 +1 408 246、8253Fax: +1 6205年の408 249メール: dcrocker@mordor.stanford.edu
Crocker [Page 6] RFC 1767 EDI in MIME March 1995
MIME行進1995年のクロッカー[6ページ]RFC1767EDI
10. APPENDIX - MIME FOR EDI USERS
10. 付録--エディUSERSには、まねてください。
To assist those familiar with EDI but not with Internet electronic mail, this Appendix is provided as a very brief introduction, primarily to give pointers to the relevant specifications. This section is in no way intended to be a thorough introduction. An excellent introductory text is [Rose93].
EDIになじみ深いそれらを補助しますが、インターネット電子メールで補助するというわけではないなら、主として関連仕様に指針を与えるために非常に簡潔な序論としてこのAppendixを提供します。 このセクションは徹底的な序論であることを決して意図しません。 素晴らしい紹介しているテキストは[Rose93]です。
Internet electronic mail follows the classic user agent/mail transfer agent model. In this model, user software produces a standardized object which is transferred via standard exchange protocols.
インターネット電子メールは古典的なユーザエージェント/メール転送エージェントモデルに従います。 このモデルでは、ユーザソフトウェアは標準の交換プロトコルで移される標準化されたオブジェクトを作り出します。
An Internet electronic mail object comprises a collection of headers, followed by a (possibly structured) body. The headers specify such information as author and recipient addresses, subject summary, creation date, handling node names, and so on, and are defined by RFC822 and RFC1123 [Croc82, Brad89]. If the body is structured, it conforms to the rules of the Multipurpose Internet Message Exchange (MIME) [Bore92]. A structured body may have parts encoded in different text character sets, or even of entirely different types of data, such as voice or graphics.
インターネット電子メールオブジェクトは(ことによると構造化されています)のボディーがあとに続いたヘッダーの収集を含みます。 ヘッダーは、作者のような情報、受取人アドレス、対象の概要、作成日付、取り扱いノード名などを指定して、RFC822とRFC1123[Croc82、Brad89]によって定義されます。 ボディーが構造化されるなら、それはMultipurposeインターネットMessage Exchange(MIME)[Bore92]の規則に従います。 構造化されたボディーで完全に異なったタイプに関するデータについてさえ部品をコード化するかもしれません、声やグラフィックスのように。
The Simple Mail Transfer Protocol (SMTP) [Post82, Brad89] performs the primary task of message transmission. User posting and delivery interactions, between the user agent and the message transfer agent, on the same machine, are not standardized and are platform-specific.
シンプルメールトランスファプロトコル(SMTP)[Post82、Brad89]はメッセージ送信のプライマリタスクを実行します。 ユーザ任命と配送相互作用は、ユーザエージェントと同じマシンの上のメッセージ転送エージェントの間で標準化されないで、プラットホーム特有です。
An EDI-related use of Internet Mime email will have (at least) the following components:
インターネットMimeメールのEDI関連の使用には、(少なくとも)以下のコンポーネントがあるでしょう:
Business Program/Data base -> EDI Translator ->
-> MIME encapsulation -> RFC822 packaging -> mail
submission ->
-> SMTP relaying ->
-> mail delivery -> RFC822 & Mime stripping ->
-> EDI Translator -> Business processing
->->EDI Translator->Business処理を剥取る->->郵便配達->RFC822&MimeをリレーするビジネスProgram/データベース->EDI Translator->->MIMEカプセル化->RFC822パッケージ->メール提案->->SMTP
The first and last lines show components normal to all EDI activities, so that it is only the EDI "transmission" components that are replaced with Internet modules.
1番目と最終ラインはすべてのEDI活動に正常なコンポーネントを示しています、唯一のそれがインターネット・モジュールに取り替えられるEDI「トランスミッション」コンポーネントであるように。
Crocker [Page 7]
クロッカー[7ページ]
一覧
スポンサーリンク
