RFC4823 日本語訳
4823 FTP Transport for Secure Peer-to-Peer Business Data Interchangeover the Internet. T. Harding, R. Scott. April 2007. (Format: TXT=80992 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Harding
Request for Comments: 4823 R. Scott
Category: Informational Axway
April 2007
コメントを求めるワーキンググループT.ハーディング要求をネットワークでつないでください: 4823年のR.スコットカテゴリ: 情報のAxway2007年4月
FTP Transport for Secure Peer-to-Peer
Business Data Interchange over the Internet
インターネットの上の安全なピアツーピア業務データ置き換えのためのFTP輸送
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This Applicability Statement (AS) describes how to exchange structured business data securely using the File Transfer Protocol (FTP) for XML, Binary, Electronic Data Interchange (EDI - ANSI X12 or UN/EDIFACT), or other data used for business-to-business data interchange for which MIME packaging can be accomplished using standard MIME content types. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax (S/MIME) security body parts. Authenticated acknowledgements employ multipart/signed replies to the original message.
このApplicability Statement(AS)は、標準のMIME content typeを使用することでMIMEパッケージを達成できるXML、Binary、Electronic Data Interchange(エディ--ANSI X12か国連/EDIFACT)、または企業間電子商取引データ置き換えに使用される他のデータにFile Transferプロトコル(FTP)を使用することでしっかりと構造化された業務データを交換する方法を説明します。 Cryptographic Message Syntax(S/MIME)セキュリティ身体の部分を使用することによって、認証とデータの機密性を得ます。 認証された承認は複合の、または、署名している回答をオリジナルのメッセージに使います。
Harding & Scott Informational [Page 1] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[1ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Overview ........................................................4
2.1. Overall Operations .........................................4
2.2. Purpose of a Security Guideline for MIME EDI ...............5
2.3. Definitions ................................................5
2.3.1. Terms ...............................................5
2.3.2. The Secure Transmission Loop ........................6
2.3.3. Definition of Receipts ..............................7
2.4. Operational Assumptions and Options ........................8
2.4.1. EDI/EC Process Assumptions ..........................8
2.4.2. Process Options .....................................8
2.4.2.1. Security Options ...........................8
2.4.2.2. Compression Options .......................10
3. Referenced RFCs and Their Contribution .........................10
3.1. RFC 959: File Transfer Protocol [3] .......................10
3.2. RFC 2228: FTP Security Extensions [4] .....................10
3.3. RFC 1847: MIME Security Multiparts [7] ....................10
3.4. RFC 3462: Multipart/Report [12] ...........................11
3.5. RFC 1767: EDI Content [2] .................................11
3.6. RFCs 2045, 2046, and 2049: MIME [1] .......................11
3.7. RFC 3798: Message Disposition Notification [6] ............11
3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1
Message Specification [10] ................................11
3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling [11] ....11
3.10. RFC 3274: Compressed Data Content Type for
Cryptographic Message Syntax (CMS) [17] ..................11
3.11. RFC 3023: XML Media Types [16] ...........................12
4. Structure of an AS3 Message ....................................12
4.1. Introduction ..............................................12
4.2. Structure of an Internet EDI MIME Message .................12
5. AS3-Specific Headers ...........................................13
5.1. AS3-From and AS3-To Headers ...............................13
5.2. AS3-Version Header ........................................14
6. FTP Considerations .............................................15
6.1. FTP Security Requirements .................................15
6.2. Large File Transfers ......................................15
6.3. MIME Considerations for FTP ...............................15
6.3.1. Required/Optional Headers ..........................15
6.3.2. Content-Transfer-Encoding ..........................16
6.3.3. Epilogue Must Be Empty .............................16
6.3.4. Message-Id and Original-Message-Id .................16
7. Structure and Processing of an MDN Message .....................17
7.1. Introduction ..............................................17
7.2. Message Disposition Notifications (MDN) ...................19
7.3. Requesting a Signed Receipt ...............................19
7.3.1. Signed Receipt Considerations ......................22
1. 序論…4 2. 概要…4 2.1. 総合的な操作…4 2.2. MIME EDIのための安全ガイドラインの目的…5 2.3. 定義…5 2.3.1. 用語…5 2.3.2. 安全なトランスミッション輪…6 2.3.3. 領収書の定義…7 2.4. 操作上の仮定とオプション…8 2.4.1. EDI/ECは仮定を処理します…8 2.4.2. オプションを処理してください…8 2.4.2.1. セキュリティオプション…8 2.4.2.2. 圧縮オプション…10 3. RFCsと彼らの貢献に、参照をつけます…10 3.1. RFC959: ファイル転送プロトコル[3]…10 3.2. RFC2228: FTPセキュリティ拡大[4]…10 3.3. RFC1847: セキュリティMultiparts[7]をまねてください…10 3.4. RFC3462: 複合/レポート[12]…11 3.5. RFC1767: EDI内容[2]…11 3.6. RFCs2045、2046、および2049: MIME[1]…11 3.7. RFC3798: メッセージ気質通知[6]…11 3.8. RFC3852: cm[9]とRFC3851: S/MIMEバージョン3.1メッセージ仕様[10]…11 3.9. RFC3850: S/MIMEバージョン3.1は取り扱[11]いを証明します…11 3.10. RFC3274: 暗号のメッセージ構文(cm)[17]のためにデータcontent typeを圧縮します…11 3.11. RFC3023: XMLメディアは[16]をタイプします…12 4. AS3メッセージの構造…12 4.1. 序論…12 4.2. インターネットエディMIMEメッセージの構造…12 5. AS3特有のヘッダー…13 5.1. そして、AS3、-、AS3、-、ヘッダー…13 5.2. AS3-バージョンヘッダー…14 6. FTP問題…15 6.1. FTPセキュリティ要件…15 6.2. 大きいファイル転送…15 6.3. FTPのために問題をまねてください…15 6.3.1. 必要であるか任意のヘッダー…15 6.3.2. 満足している転送コード化…16 6.3.3. エピローグは空であるに違いありません…16 6.3.4. メッセージイドとオリジナルのメッセージイド…16 7. MDNメッセージを構造化して、処理してください…17 7.1. 序論…17 7.2. メッセージ気質通知(MDN)…19 7.3. 署名している領収書を要求します…19 7.3.1. 領収書問題であると署名されます…22
Harding & Scott Informational [Page 2] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[2ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
7.4. MDN Format and Value ......................................23
7.4.1. AS3-MDN General Formats ............................23
7.4.2. AS3-MDN Construction ...............................24
7.4.3. AS3-MDN Fields .....................................25
7.4.4. Additional AS3-MDN Programming Notes ...............26
7.5. Disposition Mode, Type, and Modifier ......................29
7.5.1. Disposition Mode Overview ..........................29
7.5.2. Successful Processing Status Indication ............29
7.5.3. Unsuccessful Processed Content .....................29
7.5.4. Unsuccessful Non-Content Processing ................30
7.5.5. Processing Warnings ................................31
8. Public Key Certificate Handling ................................32
9. Security Considerations ........................................33
10. References ....................................................34
10.1. Normative References .....................................34
10.2. Informative References ...................................36
Appendix A. Message Examples ......................................37
A.1. Signed Message Requesting a Signed Receipt ................37
A.2. MDN for Message A.1 Above .................................37
7.4. MDN形式と値…23 7.4.1. AS3-MDN一般形式…23 7.4.2. AS3-MDN工事…24 7.4.3. AS3-MDN分野…25 7.4.4. 追加AS3-MDNプログラミング上の注意…26 7.5. 気質モード、タイプ、および修飾語…29 7.5.1. 気質モード概要…29 7.5.2. うまくいっている処理状態指示…29 7.5.3. 失敗の処理内容…29 7.5.4. 失敗の非内容処理…30 7.5.5. 処理警告…31 8. 公開鍵証明書取り扱い…32 9. セキュリティ問題…33 10. 参照…34 10.1. 標準の参照…34 10.2. 有益な参照…36 付録A.メッセージの例…37 A.1。 メッセージ要求が署名している領収書であると署名します…37 A.2。 メッセージA.1のための上のMDN…37
Harding & Scott Informational [Page 3] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[3ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
1. Introduction
1. 序論
Previous work on Internet EDI focused on specifying MIME content types for EDI data [2] and extending this work to support secure EC/EDI transport over SMTP [5]. This document expands on RFC 1767 to specify a comprehensive set of data security features, specifically, data privacy, data integrity, authenticity, non-repudiation of origin, and non-repudiation of receipt over FTP. This document also recognizes contemporary RFCs and is attempting to "re-invent" as little as possible. While this document focuses on EDI data, any other data type describable in a MIME format is also supported.
インターネットEDIへの前の作業は、EDIデータ[2]にMIME content typeを指定して、安全なEC/EDIが輸送であるとサポートするためにこの仕事を広げるのはSMTP[5]の上に焦点を合わせました。 このドキュメントはFTPの上で領収書の明確に包括的なセットのデータ機密保護機能、データプライバシー、データ保全、信憑性、発生源の非拒否、および非拒否を指定するRFC1767について詳述します。 このドキュメントも、現代のRFCsを認めて、できるだけ少ししか「再発明しないこと」を試みています。 また、このドキュメントがEDIデータに焦点を合わせている間、MIME形式のいかなる他のデータ型説明可能もサポートされます。
Internet MIME-based EDI can be accomplished by using and complying with the following documents:
以下のドキュメントを使用して、従うことによって、インターネットのMIMEベースのEDIを達成できます:
- RFC 959: File Transfer Protocol
- RFC 2228: FTP Security Extensions
- RFC 1767: EDI Content Type
- RFC 3023: XML Media Types
- RFC 1847: Security Multiparts for MIME
- RFC 3462: Multipart/Report
- RFCs 2045 to 2049: MIME
- RFC 3798: Message Disposition Notification
- RFCs 3850, 3851, and 3852: S/MIME v3.1 Specifications
- RFC 3274: Compressed Data Content for Cryptographic Message
Syntax
- RFC 4217: Securing FTP with TLS
- "Compressed Data for EDIINT" by T. Harding
- RFC959: ファイル転送プロトコル--RFC2228: FTPセキュリティ拡大--RFC1767: EDI content type--RFC3023: XMLメディアタイプ--RFC1847: MIMEのためのセキュリティMultiparts--RFC3462: 複合/レポート--RFCs2045年から2049: MIME--RFC3798: RFCs3850、3851、およびメッセージ気質通知--3852: S/MIME v3.1 Specifications--RFC3274: 暗号のメッセージ構文のための圧縮されたデータ内容--RFC4217: TLSと共にFTPを保証します--T.ハーディングが「EDIINTのための圧縮されたデータ」
Our intent here is to define clearly and precisely how these are used together, and what is required by user agents to be compliant with this document.
ここの私たちの意図はこれらがどのように一緒に使用されるか、そして、何がこのドキュメントで言いなりになるためにユーザエージェントによって必要とされるかを明確に、正確に定義することです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [19].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[19]で説明されるように本書では解釈されることであるべきですか?
2. Overview
2. 概要
2.1. Overall Operations
2.1. 総合的な操作
An FTP upload operation is used to send appropriately packaged EDI, XML, or other business data. The receiving application will poll the FTP server for inbound messages, unpackage and handle the message data, and generate a reply for the originator that contains a message disposition acknowledgement within a multipart/report that is signed or unsigned. This request/reply transactional interchange provides secure, reliable, and authenticated transport for EDI or other
FTPアップロード操作は、適切にパッケージされたEDI、XML、または他の業務データを送るのに使用されます。 受信アプリケーションは、署名しているか、または未署名であることの複合/レポートの中にメッセージ気質承認を含む創始者のために、本国行きのメッセージ、非パッケージのためにFTPサーバに投票して、メッセージデータを処理して、回答を生成するでしょう。 取引の置き換えが何らかのEDIのための安全で、信頼できて、認証された輸送を提供するこの要求/回答
Harding & Scott Informational [Page 4] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[4ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
business data using FTP. The security protocols and structures used also support auditable records of these transmissions.
FTPを使用する業務データ。 また、セキュリティプロトコルと構造はこれらのトランスミッションに関するサポート監査可能記録を使用しました。
2.2. Purpose of a Security Guideline for MIME EDI
2.2. MIME EDIのための安全ガイドラインの目的
The purpose of these specifications is to ensure interoperability between B2B Electronic Commerce user agents, invoking some or all of the commonly expected security features. This document is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner.
これらの仕様の目的はB2B電子通商ユーザエージェントの間の相互運用性を確実にすることです、一般的に予想されたセキュリティ機能のいくつかかすべてを呼び出して。 このドキュメントは、また、厳しいEDI使用に制限されませんが、業務データが安全な方法でインターネットの上と交換される必要があるどんな電子商取引アプリケーションにも適用されます。
2.3. Definitions
2.3. 定義
2.3.1. Terms
2.3.1. 用語
AS3 Applicability Statement 3. This is the third
applicability statement produced by the IETF
EDIINT working group.
AS3適用性証明3。 これはIETF EDIINTワーキンググループによって製作された3番目の適用性証明です。
EDI Electronic Data Interchange
EDI電子データ交換
EC Business-to-Business Electronic Commerce
ECの企業対企業の電子商取引電子通商
B2B Business to Business
B2B企業対企業の電子商取引
Receipt The functional message that is sent from a
receiver to a sender to acknowledge receipt of
an EDI/EC interchange.
EDI/ECの置き換えの領収書を受け取ったことを知らせるために受信機から送付者に送られる機能的なメッセージを領収書を出させてください。
Signed Receipt A receipt containing a digital signature.
デジタル署名を含むReceipt A領収書であると署名されます。
Message Disposition The Internet messaging format used to convey a
Notification (MDN) receipt. This term is used interchangeably with
receipt. An MDN is a receipt.
書式を通信させるメッセージDispositionインターネットは以前はよくNotification(MDN)領収書を伝えていました。 今期は領収書で互換性を持って使用されます。 MDNは領収書です。
Non-repudiation of NRR is a "legal event" that occurs when the
receipt (NRR) original sender of an EDI/EC interchange has
verified the signed receipt coming back from the
receiver. NRR IS NOT a functional or a
technical message.
NRRの非拒否はEDI/ECの置き換えの領収書(NRR)であるときに起こる「法的なイベント」元の送り主が. 受信機NRR IS NOTから機能的なメッセージか技術的なメッセージを支持しに来る署名している領収書を確かめたということです。
S/MIME A format and protocol for adding Cryptographic
signature and/or encryption services to Internet
MIME messages.
Cryptographic署名を加えるためのS/MIME A形式とプロトコル、そして/または、暗号化はインターネットMIMEにメッセージを修理します。
Harding & Scott Informational [Page 5] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[5ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
NOTE: While the S/MIME specification describes
more than one format for a signed message,
all signed messages or receipts used with
AS3 MUST utilize the multipart/signed
format.
以下に注意してください。 S/MIME仕様が署名しているメッセージのために1つ以上の形式について説明している間、AS3 MUSTと共に使用されるメッセージか領収書であると署名されるすべてが複合の、または、署名している形式を利用します。
SHA-1 A secure, one-way hash algorithm used in
conjunction with digital signature. SHA-1 is
the recommend algorithm for AS3.
SHA-1のA安全で、一方向のハッシュアルゴリズムはデジタルに関連して署名を使用しました。 SHA-1がそう、AS3のためにアルゴリズムを推薦してください。
MD5 A secure, one-way hash algorithm used in
conjunction with digital signature. This
algorithm is acceptable but not recommended due
to its short key length and known weaknesses.
MD5のA安全で、一方向のハッシュアルゴリズムはデジタルに関連して署名を使用しました。 このアルゴリズムは、その短いキー長と知られている弱点のために許容できますが、お勧めではありません。
MIC The message integrity check (MIC) is a
representation of the message digest, which
results from the application of the selected
hash algorithm to the content to be signed. Of
particular interest is the digital signature,
which includes an encrypted copy of the digest.
Additionally, an MDN containing a Received-
content-MIC header will also contain (as that
header's value) a base-64-encoded representation
of the digest.
MICメッセージの保全チェック(MIC)はメッセージダイジェストの表現です。(それは、選択されたハッシュアルゴリズムの適用から署名される内容に生じます)。 特別の関心はデジタル署名(ダイジェストの暗号化されたコピーを含んでいる)です。 また、さらに、Received内容-MICヘッダーを含むMDNはダイジェストの64がコード化したベース表現を含むでしょう(そのヘッダーの値として)。
User Agent (UA) The application that handles and processes the
AS3 request.
ユーザエージェント、(UA) AS3要求を処理して、処理するアプリケーション。
STL Secure Transmission Loop, described in the next
section.
次のセクションで説明されたSTL Secure Transmission Loop。
2.3.2. The Secure Transmission Loop
2.3.2. 安全なトランスミッション輪
This document's focus is on the formats and protocols for exchanging EDI/EC content to which security services have been applied using the File Transmission Protocol (FTP) as the transport.
このドキュメントの焦点がセキュリティー・サービスが輸送としてFile Transmissionプロトコル(FTP)を使用することで適用されたEDI/EC内容を交換するための形式とプロトコルにあります。
The "Secure Transmission Loop" (STL) comprises the following two steps:
「安全なトランスミッション輪」(STL)は以下の2ステップを包括します:
a) The originator sends a signed and encrypted document with a
request for a signed receipt.
a) 創始者は署名している領収書を求める要求と共に署名していて暗号化されたドキュメントを送ります。
b) The recipient decrypts the document, verifies the signature, and
returns a signed receipt to the sender.
b) 受取人は、送付者にドキュメントを解読して、署名について確かめて、署名している領収書を返します。
Harding & Scott Informational [Page 6] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[6ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
In other words, the following events occur during the execution of the STL:
言い換えれば、以下のイベントはSTLの実行の間、起こります:
- The organization sending EDI/EC data signs and encrypts the data
using S/MIME. In addition, the message will request a signed
receipt to be returned to the sender of the message.
- 組織送付EDI/ECデータは、S/MIMEを使用することでデータに署名して、暗号化します。 さらに、メッセージは、メッセージ送信者に返されるよう署名している領収書に要求するでしょう。
- The receiving organization decrypts the message and verifies the
signature, resulting in verified integrity of the data and
authenticity of the sender.
- 受信組織は、メッセージを解読して、署名について確かめます、データの確かめられた保全と送付者の信憑性をもたらして。
- The receiving organization then returns a signed receipt, as
requested to the sending organization in the form of a message
disposition notification. This signed receipt will contain the
hash of the signature from the received message, indicating to the
sender that the received message was verified and/or decrypted
properly.
- そして、受信組織は要求された通りメッセージ気質通知の形の送出し機関に署名している領収書を返します。 領収書であると署名されるこれは受信されたメッセージからの署名のハッシュを含むでしょう、受信されたメッセージが適切に確かめられる、そして/または、解読されたのを送付者に示して。
The above describes functionality that, if implemented, will satisfy all security requirements and provide non-repudiation of receipt for the exchange. While trading partners will usually want to utilize the STL, this specification does not require it.
上記は実装されるなら、交換にすべてのセキュリティ要件を満たして、領収書の非拒否を提供する機能性について説明します。 通常、貿易相手国がSTLを利用したい間、この仕様はそれを必要としません。
2.3.3. Definition of Receipts
2.3.3. 領収書の定義
The term used for both the functional activity and the message for acknowledging delivery of an EDI/EC interchange is "receipt" or "signed receipt". The term receipt is used if the acknowledgment is for an interchange resulting in a receipt that is NOT signed. The term signed receipt is used if the acknowledgment is for an interchange resulting in a receipt that IS signed. A term often used in combination with receipts is non-repudiation of receipt. NRR refers to a legal event that occurs only when the original sender of an interchange has verified the signed receipt coming back from the recipient of the message. Note that NRR is not possible without signatures.
EDI/ECの置き換えの配送を承諾するための機能的活動とメッセージの両方に使用される用語は、「領収書」であるか「領収書に署名しました」。 用語領収書は承認が署名されない領収書をもたらす置き換えのためのものであるなら使用されています。 領収書であるのに調印された期間は承認が署名される領収書をもたらす置き換えのためのものであるなら使用されています。 領収書と組み合わせてしばしば使用される用語は領収書の非拒否です。 NRRは置き換えの元の送り主がメッセージの受取人から戻る署名している領収書を確かめたときだけ起こる法的なイベントについて言及します。 NRRが署名なしで可能でないことに注意してください。
For additional information on formatting and processing receipts in AS3, refer to Section 7.
AS3の領収書をフォーマットして、処理する追加情報について、セクション7を参照してください。
Harding & Scott Informational [Page 7] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[7ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
2.4. Operational Assumptions and Options
2.4. 操作上の仮定とオプション
2.4.1. EDI/EC Process Assumptions
2.4.1. EDI/ECのプロセス仮定
- Encrypted object is an EDI/EC Interchange.
- 暗号化されたオブジェクトはEDI/EC Interchangeです。
This specification assumes that a typical EDI/EC interchange is the
lowest level object that will be subject to the application of
security services.
この仕様は、典型的なEDI/ECの置き換えがセキュリティー・サービスの応用を受けることがある平らな最も低いオブジェクトであると仮定します。
Specifically, for EDI ANSI X12, the entire document (including the
ISA and IEA segments) is the atom to which security is applied.
For EDIFACT, the corresponding definition includes the segments
UNA/UNB and UNZ. In other words, EDI/EC interchanges including
envelope segments remain intact and unreadable during secure
transport.
明確に、EDI ANSI X12に関して、全体のドキュメント(ISAとIEAセグメントを含んでいる)はセキュリティが適用されている原子です。 EDIFACTに関しては、対応する定義はセグメントのUNA/UNBとUNZを含んでいます。 言い換えれば、封筒セグメントを含むEDI/ECの置き換えが安全な輸送の間、完全であって、読みにくいままで残っています。
- EDI envelope headers are encrypted.
- EDI封筒ヘッダーは暗号化されています。
Congruent with the above statement, EDI envelope headers are NOT
visible in the MIME package. In order to optimize routing from
existing commercial EDI networks (called Value Added Networks or
VANs) to the Internet, work may need to be done in the future to
define ways to extract some elements of the envelope to make them
visible; however, that is beyond the scope of this specification.
上の声明について一致していて、EDI封筒ヘッダーはMIMEパッケージの中に目に見えません。 既存の商業EDIネットワーク(付加価値通信網かVANと呼ばれる)からインターネットまでルーティングを最適化するために、仕事は、将来それらを目に見えるようにするように封筒のいくつかの要素を抜粋する方法を定義するためにする必要があるかもしれません。 しかしながら、それはこの仕様の範囲を超えています。
- X12.58 and UN/EDIFACT security considerations
- X12.58と国連/EDIFACTセキュリティ問題
The most common EDI standards bodies, ANSI X12 and EDIFACT, have
defined internal provisions for security. X12.58 is the security
mechanism for ANSI X12, and AUTACK provides security for EDIFACT.
This specification DOES NOT dictate use or non-use of these
security standards. They are both fully compatible, though
possibly redundant, with this specification.
最も一般的なEDI標準化団体(ANSI X12とEDIFACT)は、セキュリティのための内部の条項を定義しました。 X12.58はANSI X12のためのセキュリティー対策です、そして、AUTACKはセキュリティをEDIFACTに供給します。 この仕様DOES NOTはこれらの機密保護基準の使用か非使用を書き取ります。 それらは、この仕様でともに完全に互換性があって、もっとも、ことによると余分です。
2.4.2. Process Options
2.4.2. プロセスオプション
2.4.2.1. Security Options
2.4.2.1. セキュリティオプション
- Encrypted or un-encrypted data
- 暗号化されたか不-暗号化されたデータ
This specification allows for EDI/EC message exchange where the
EDI/EC data can be either un-protected or protected by means of
encryption.
この仕様は、暗号化EDI/ECデータが保護がない場合があるEDI/EC交換処理のために許容したか、または保護されました。
Harding & Scott Informational [Page 8] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[8ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
- Signed or unsigned data
- 署名しているか未署名のデータ
This specification allows for EDI/EC message exchange with or
without digital signature of the original EDI transmission.
この仕様はオリジナルのEDIトランスミッションのデジタル署名のあるなしにかかわらずEDI/EC交換処理を考慮します。
- Use of receipt or not
- 領収書の使用です。
This specification allows for EDI/EC message transmission with or
without a request for receipt notification. If a signed receipt
notification is requested, however, a MIC value is REQUIRED as part
of the returned receipt, unless an error condition occurs that
results in the inability to compute a valid digest. (Such a case
would result, for instance, if an encrypted message could not be
decrypted.) Under such circumstances, an unsigned receipt (MDN)
SHOULD be returned with the correct "disposition modifier" error
value.
この仕様は領収書通知に関する要求のあるなしにかかわらずEDI/ECのメッセージ送信を考慮します。 しかしながら、署名している領収書通知が要求されるなら、MIC値は返された領収書の一部としてREQUIREDです、有効なダイジェストを計算できないことをもたらすエラー条件が起こらない場合。 (例えば、暗号化メッセージを解読することができないなら、そのような場合は結果として生じるでしょうに。) (MDN)SHOULDを領収書を出させてください。そのような状況で未署名、正しい「気質修飾語」誤り価値と共に返します。
- Security formatting
- セキュリティ形式
This specification relies on the guidelines set forth in RFCs 3852
[9] and 3851 [10]. The first of these RFCs describes the
Cryptographic Message Syntax (CMS), and the second contains the
S/MIME Version 3.1 Message Specification describing a MIME
container for CMS objects. Whenever the term S/MIME is used in
this document, it refers to Version 3.1 as described therein.
この仕様はRFCs3852[9]と3851[10]に詳しく説明されたガイドラインを当てにします。 これらのRFCsの1番目はCryptographic Message Syntax(CMS)について説明します、そして、2番目はCMSオブジェクトのためにMIMEコンテナについて説明するS/MIMEバージョン3.1Message Specificationを含んでいます。 用語S/MIMEが本書では使用されるときはいつも、それはそこに説明されるバージョン3.1を示します。
- Hash function, message digest choices
- ハッシュ関数、メッセージダイジェスト選択
When a signature is used, it is RECOMMENDED that the SHA-1 hash
algorithm be used for all outgoing messages; however, both MD5 and
SHA-1 MUST be supported for incoming messages.
署名が使用されているとき、SHA-1ハッシュアルゴリズムがすべての送信されるメッセージに使用されるのは、RECOMMENDEDです。 しかしながら、MD5とSHA-1 MUSTの両方、入力メッセージには、サポートされてください。
- Permutation summary
- 順列概要
In summary, the following twelve security permutations are possible
in any given trading relationship:
概要では、取り引き関係を考えて、以下の12のセキュリティ順列がいずれでも可能です:
1. Sender sends un-encrypted data, does NOT request a receipt.
1. 領収書は、送付者が不-暗号化されたデータを送るよう要求しません。
2. Sender sends un-encrypted data, requests an unsigned receipt.
The receiver sends back the unsigned receipt.
2. 未署名の領収書は、送付者が不-暗号化されたデータを送るよう要求します。 受信機は未署名の領収書を返送します。
3. Sender sends un-encrypted data, requests a signed receipt. The
receiver sends back the signed receipt.
3. 署名している領収書は、送付者が不-暗号化されたデータを送るよう要求します。 受信機は署名している領収書を返送します。
4. Sender sends encrypted data, does NOT request a receipt.
4. 領収書は、送付者が暗号化されたデータを送るよう要求しません。
Harding & Scott Informational [Page 9] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[9ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
5. Sender sends encrypted data, requests an unsigned receipt. The
receiver sends back the unsigned receipt.
5. 未署名の領収書は、送付者が暗号化されたデータを送るよう要求します。 受信機は未署名の領収書を返送します。
6. Sender sends encrypted data, requests a signed receipt. The
receiver sends back the signed receipt.
6. 署名している領収書は、送付者が暗号化されたデータを送るよう要求します。 受信機は署名している領収書を返送します。
7. Sender sends signed data, does NOT request a receipt.
7. 領収書は、送付者が署名しているデータを送るよう要求しません。
8. Sender sends signed data, requests an unsigned receipt.
Receiver sends back the unsigned receipt.
8. 未署名の領収書は、送付者が署名しているデータを送るよう要求します。 受信機は未署名の領収書を返送します。
9. Sender sends signed data, requests a signed receipt. Receiver
sends back the signed receipt.
9. 署名している領収書は、送付者が署名しているデータを送るよう要求します。 受信機は署名している領収書を返送します。
10. Sender sends encrypted and signed data, does NOT request a
receipt.
10. 領収書は、送付者が暗号化されて署名しているデータを送るよう要求しません。
11. Sender sends encrypted and signed data, requests an unsigned
receipt. Receiver sends back the unsigned receipt.
11. 未署名の領収書は、送付者が暗号化されて署名しているデータを送るよう要求します。 受信機は未署名の領収書を返送します。
12. Sender sends encrypted and signed data, requests a signed
receipt. Receiver sends back the signed receipt. This case
represents the Secure Transmission Loop described above.
12. 署名している領収書は、送付者が暗号化されて署名しているデータを送るよう要求します。 受信機は署名している領収書を返送します。 本件は上で説明されたSecure Transmission Loopを表します。
2.4.2.2. Compression Options
2.4.2.2. 圧縮オプション
The AS3 specification supports compression of transmitted data directly through the application of RFC 3274. Implementation details may be found in that RFC and in Harding's document, "Compressed Data for EDIINT".
AS3仕様は直接RFC3274のアプリケーションによる伝えられたデータの要約をサポートします。 実装の詳細はそのRFC、およびハーディングのドキュメントの「EDIINTのための圧縮されたデータ」で見つけられるかもしれません。
3. Referenced RFCs and Their Contribution
3. 参照をつけられたRFCsと彼らの貢献
3.1. RFC 959: File Transfer Protocol [3]
3.1. RFC959: ファイル転送プロトコル[3]
RFC 959 specifies how data is transferred using the File Transfer Protocol (FTP)
RFC959はデータがFile Transferプロトコルを使用することでどうわたっているかを指定します。(FTP)
3.2. RFC 2228: FTP Security Extensions [4]
3.2. RFC2228: FTPセキュリティ拡大[4]
This RFC describes a framework for providing security services to FTP.
このRFCは、FTPへのセキュリティー・サービスを提供するためにフレームワークについて説明します。
3.3. RFC 1847: MIME Security Multiparts [7]
3.3. RFC1847: MIMEセキュリティMultiparts[7]
This document defines security multiparts for MIME: multipart/encrypted and multipart/signed.
このドキュメントはMIMEのためにセキュリティの「マルチ-部品」を定義します: 暗号化された複合/と複合/は署名しました。
Harding & Scott Informational [Page 10] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[10ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
3.4. RFC 3462: Multipart/Report [12]
3.4. RFC3462: 複合/レポート[12]
RFC 3462 defines the use of the multipart/report content type, upon which RFC 3798 builds to define the Message Disposition Notification.
RFC3462は複合/レポートcontent typeの使用を定義します。(そこでは、RFC3798は、Message Disposition Notificationを定義するために建てます)。
3.5. RFC 1767: EDI Content [2]
3.5. RFC1767: EDI内容[2]
This RFC defines the use of content type "application" for ANSI X12 (application/EDI-X12), EDIFACT (application/EDIFACT), and mutually defined EDI (application/EDI-Consent).
このRFCはcontent type「アプリケーション」のANSI X12(エディアプリケーション/X12)、EDIFACT(アプリケーション/EDIFACT)、および互いに定義されたEDI(EDIアプリケーション/同意)の使用を定義します。
3.6. RFCs 2045, 2046, and 2049: MIME [1]
3.6. RFCs2045、2046、および2049: MIME[1]
These are the basic MIME standards, upon which all MIME-related RFCs build, including this one. Key contributions include definitions of "content type", "sub-type", and "multipart", as well as encoding guidelines, which establish 7-bit US-ASCII as the canonical character set to be used in Internet messaging.
これらは基本的なMIME規格です。(そこでは、これを含んでいて、すべてのMIME関連のRFCsが建てます)。 主要な貢献はインターネットメッセージングで使用されるために正準な文字集合と7ビットの米国-ASCIIを書き立てる「サブタイプ」の、そして、ガイドラインをコード化することと同様に「複合」の「content type」の定義を含んでいます。
3.7. RFC 3798: Message Disposition Notification [6]
3.7. RFC3798: メッセージ気質通知[6]
This Internet RFC defines how a Message Disposition Notification (MDN)is requested, as well as the format and syntax of the MDN. The MDN is the vehicle used by this specification to provide both signed and unsigned receipts.
このインターネットRFCはMessage Disposition Notification(MDN)がどう要求されているかを定義します、MDNの形式と構文と同様に。 MDNは署名しているものと同様に未署名の領収書を提供するのにこの仕様で使用される乗り物です。
3.8. RFC 3852: CMS [9] and RFC 3851: S/MIME Version 3.1 Message
Specification [10]
3.8. RFC3852: cm[9]とRFC3851: S/MIMEバージョン3.1メッセージ仕様[10]
This specification describes how MIME shall carry Cryptographic Message Syntax (CMS) Objects.
この仕様はMIMEがどうCryptographic Message Syntax(CMS)オブジェクトを運ぶだろうかを説明します。
3.9. RFC 3850: S/MIME Version 3.1 Certificate Handling [11]
3.9. RFC3850: S/MIMEバージョン3.1証明書取り扱い[11]
RFC 3850 describes certificate handling in the context of CMS and S/MIME.
RFC3850はCMSとS/MIMEの文脈で証明書取り扱いについて説明します。
3.10. RFC 3274: Compressed Data Content Type for Cryptographic Message
Syntax (CMS) [17]
3.10. RFC3274: 暗号のメッセージ構文(cm)のための圧縮されたデータcontent type[17]
This specification provides a mechanism to wrap compressed data within a CMS object.
この仕様は、CMSオブジェクトの中に圧縮されたデータに身を包ませるためにメカニズムを提供します。
Harding & Scott Informational [Page 11] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[11ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
3.11. RFC 3023: XML Media Types [16]
3.11. RFC3023: XMLメディアタイプ[16]
This RFC defines the use of content type "application" for XML. Note that while conforming implementations SHOULD support the expanded syntax that RFC 3023 introduces for the "+xml" suffix, no support for external parsed entity types is anticipated (as it adds significant complexity to signature processing).
このRFCはcontent type「アプリケーション」のXMLの使用を定義します。 「SHOULDがRFC3023が導入する拡張構文をサポートする実装を従わせている間、それに注意してください、」 + xmlは予期されます(署名処理に重要な複雑さを加えるとき)」 接尾語、外部の解析対象実体のどんなサポートも、タイプしない。
4. Structure of an AS3 Message
4. AS3メッセージの構造
4.1. Introduction
4.1. 序論
The basic structure of AS3 messages comprises MIME encapsulated data with both customary MIME headers and a few additional AS3-specific outer headers. The structures below are described hierarchically in terms of which RFCs have been applied to form the specific structure. The reader is referred directly to the referenced RFCs for implementation details.
AS3メッセージの基本構造は通例のMIMEヘッダーといくつかの追加AS3特有の外側のヘッダーの両方でデータであるとカプセル化されたMIMEを包括します。 どのRFCsが特定の構造を形成するために適用されたかに関して以下の構造は階層的で説明されます。 読者は実装の詳細について直接参照をつけられたRFCsを参照されます。
Any additional restrictions imposed by this AS are specifically discussed in the sections that follow.
従うセクションでこのASによって課されたどんな追加制限についても明確に議論します。
4.2. Structure of an Internet EDI MIME Message
4.2. インターネットエディMIMEメッセージの構造
No encryption, no signature
暗号化がない、署名がありません。
-RFC822/2045
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC822/2045 -RFC1767/RFC2376(アプリケーション/EDIxxxxか/xml)
No encryption, signature
暗号化がない、署名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)
-RFC3851 (application/pkcs7-signature)
-RFC822/2045 -RFC1847(複合か署名される)の-RFC1767/RFC2376(アプリケーション/EDIxxxxか/xml)-RFC3851(pkcs7アプリケーション/署名)
Encryption, no signature
暗号化、署名がありません。
-RFC822/2045
-RFC3851 (application/pkcs7-mime)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC822/2045 -RFC3851(pkcs7アプリケーション/パントマイム)-RFC1767/RFC2376(アプリケーション/EDIxxxxか/xml)(暗号化されます)
Harding & Scott Informational [Page 12] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[12ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
Encryption, signature
暗号化、署名
-RFC822/2045
-RFC3851 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC2376 (application/EDIxxxx or /xml)(encrypted)
-RFC3851 (application/pkcs7-signature)(encrypted)
-RFC822/2045 -RFC3851(pkcs7アプリケーション/パントマイム)-RFC1847(複合か署名される)(暗号化された)の-RFC1767/RFC2376(アプリケーション/EDIxxxxか/xml)(暗号化される)-RFC3851(pkcs7アプリケーション/署名)(暗号化されます)
MDN, no signature
MDN、署名がありません。
-RFC822/2045
-RFC3798 (message/disposition-notification)
-RFC822/2045 -RFC3798(気質メッセージ/通知)
MDN, signature
MDN、署名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
-RFC822/2045 -RFC1847(複合か署名される)の-RFC3798(気質メッセージ/通知)-RFC3851(pkcs7アプリケーション/署名)
While all MIME content types SHOULD be supported, the following MIME content types MUST be supported:
すべてのMIME content type SHOULDである間、サポートされてください、そして、以下のMIME content typeをサポートしなければなりません:
Content-Type: multipart/signed
Content-Type: multipart/report
Content-type: message/disposition-notification
Content-Type: application/PKCS7-signature
Content-Type: application/PKCS7-mime
Content-Type: application/EDI-X12
Content-Type: application/EDIFACT
Content-Type: application/edi-consent
Content-Type: application/XML
コンテントタイプ: 複合の、または、署名しているコンテントタイプ: 複合/レポート文書内容: 気質メッセージ/通知コンテントタイプ: PKCS7アプリケーション/署名コンテントタイプ: PKCS7アプリケーション/パントマイムコンテントタイプ: アプリケーション/EDI-X12コンテントタイプ: アプリケーション/EDIFACTコンテントタイプ: ediアプリケーション/同意コンテントタイプ: アプリケーション/XML
5. AS3-Specific Headers
5. AS3特有のヘッダー
5.1. AS3-From and AS3-To Headers
5.1. そして、AS3、-、AS3、-、ヘッダー
The AS3-From and AS3-To headers have been provided to assist the sender and the recipient of an EC document to identify each other:
そして、AS3、-、AS3、-、ECドキュメントの送付者と受取人が互いを特定するのを補助するためにヘッダーを提供しました:
AS3-From: < AS3-name >
AS3-To: < AS3-name >
AS3-From: <AS3-名前>AS3-To: <AS3-名前>。
These headers contain textual values, described by the ABNF [22] below, identifying the sender/receiver of a data exchange. A value may be company specific (e.g., a Data Universal Numbering System (DUNS) number), or it may be simply some string mutually acceptable to both trading partners used to identify each to the other.
これらのヘッダーはデータ交換の送付者/受信機を特定する以下でABNF[22]によって説明された原文の値を含んでいます。 値は会社の特有であるかもしれませんか(例えば、Data Universal Numbering System(DUNS)番号)、それは単に互いにもう片方にそれぞれを特定するのに使用される両方の貿易相手国に許容できる何らかのストリングであるかもしれません。
Harding & Scott Informational [Page 13] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[13ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
AS3-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS3-テキストは“!"と等しいです。 / ; 印刷可能なASCII文字%d35-91/。 二重引用文(%d34)の%d93-126を除いて。 または、バックスラッシュ(%d92)
AS3-qtext = AS3-text / SP ; allow space only in quoted text
AS3-qtextはAS3-テキスト/SPと等しいです。 引用されたテキストだけで紙面を割いてください。
AS3-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS3が組を引用している=「\」DQUOTE/。 「\」か「\」「\」。 \\
AS3-quoted-name = DQUOTE 1*128( AS3-qtext /
AS3-quoted-pair) DQUOTE
AS3が名前を引用している=DQUOTE1*128の(AS3-qtext / AS3は組を引用していました)のDQUOTE
AS3-atomic-name = 1*128AS3-text
AS3の原子名=1*128AS3-テキスト
AS3-name = AS3-atomic-name / AS3-quoted-name
AS3は名前を=AS3原子AS3-名前名/引用していました。
Note: SP and DQUOTE are defined in [ABNF]RFC 4234.
以下に注意してください。 SPとDQUOTEは[ABNF]RFC4234で定義されます。
The AS3-From header value and the AS3-To header value MUST each be an AS3-name comprising 1 to 128 printable ASCII characters. The header MUST NOT be folded, and the value for each of these headers is case- sensitive.
そして、AS3、-、ヘッダー値、AS3、-、ヘッダー値、AS3名義の包括の1〜128が印刷可能なASCII文字であったならそれぞれそうしなければなりません。 ヘッダーを折り重ねてはいけません、そして、これらのヘッダー各人のための値はケース敏感です。
The AS3-quoted-name SHOULD be used only if the AS3-name does not conform to AS3-atomic-name.
AS3が名前を引用しているSHOULD、AS3-名前がAS3の原子名に従わない場合にだけ、使用されてください。
The AS3-To and AS3-From header fields MUST be present in all AS3 messages and AS3 MDNs.
そして、AS3、-、AS3、-、ヘッダーフィールド、AS3が通信させるすべてでのプレゼントとAS3 MDNsはそうであるに違いありません。
Implementations that map entities such as EDI identifiers/qualifiers to AS3 identifiers may choose to constrain the set of AS3-To/AS3-From text values to a subset of the full set defined above, but they may not extend that set.
セットを抑制する、AS3識別子へのEDI識別子/資格を与える人などの実体を写像する実装が、選ぶかもしれないAS3、-、/、AS3、-、上で定義されたフルセットの部分集合へのテキスト値、それらだけがそのセットを広げないかもしれません。
If the AS3-From or the AS3-To or the association of the two header values is determined to be invalid or unknown to the receiving system, the receiving system MAY respond with an unsigned MDN containing an explanation of the error if the sending system requested an MDN, but it is not required to return an MDN under those circumstances.
または、AS3、-、AS3、-、または、ヘッダーが受電方式において無効であるか、または未知であるために、送付システムがMDNを要求したなら未署名のMDNが誤りに関する説明を含んでいて受電方式が反応するかもしれませんが、それはそれらの状況の下にMDNを返すのに必要でないことを決定しているのを評価する2つのものの協会。
5.2. AS3-Version Header
5.2. AS3-バージョンヘッダー
The AS3-Version header is a header that is required only if the value of the header is not "1.0". Its purpose is to allow systems to determine which version of this specification (should the specification evolve over time) the sender of a document has used to
AS3-バージョンヘッダーはヘッダーの値が「1インチ」でない場合にだけ必要であるヘッダーです。 目的はシステムが、ドキュメントの送付者にはこの仕様(仕様が時間がたつにつれて発展するなら)のどのバージョンがあるかは以前はよくそうしていたことを決定するのを許容することです。
Harding & Scott Informational [Page 14] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[14ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
package the document. A user agent MUST NOT reject a message if the version header is missing.
ドキュメントをパッケージしてください。 バージョンヘッダーが行方不明であるなら、ユーザエージェントはメッセージを拒絶してはいけません。
AS3-Version: 1*DIGIT . 1*DIGIT
AS3-バージョン: 1*ケタ. 1*ケタ
A version header value of "1.1" indicates an implementation can support EDIINT data compression [20]. A user agent MUST NOT send compressed messages to trading partners who do not use a version header of "1.1" or greater.
「1.1インチは、実装が、EDIINTがデータ圧縮[20]であるとサポートすることができるのを示す」バージョンヘッダー価値。 ユーザエージェントは「1.1インチか、よりすばらしいこと」のバージョンヘッダーを使用しない貿易相手国に圧縮されたメッセージを送ってはいけません。
6. FTP Considerations
6. FTP問題
6.1. FTP Security Requirements
6.1. FTPセキュリティ要件
FTP has long been viewed as an insecure protocol primarily because of its use of cleartext authentication [3]. This is addressed by RFC 2228 [4], and the use of one of the security mechanisms described therein is strongly encouraged. Specifically, conforming implementations of AS3 SHALL employ FTP client/servers that support the AUTH command described within [4]. While any authentication mechanism based upon [4] MAY be utilized, AUTH TLS (as described in [18]) MUST be supported. (Note that [18] relies on TLS Version 1.0 [13], not Version 1.1 [23].)
FTPは主としてcleartext認証[3]の使用のために長い間、不安定なプロトコルとして見なされます。 これはRFC2228[4]によって記述されます、そして、そこに説明されたセキュリティー対策の1つの使用は強く奨励されます。 明確に、AS3 SHALLの従う実現は[4]の中で説明されたAUTHコマンドをサポートするFTPクライアント/サーバを使います。 AUTH TLS、どんな認証機構も5月を[4]に基礎づけていた間、利用されてください。([18])で説明されるように、支持しなければなりません。 ([18]がバージョン1.1[23]ではなく、TLSバージョン1.0[13]を当てにすることに注意してください。)
6.2. Large File Transfers
6.2. 大きいファイル転送
Large files are handled correctly by the TCP layer. However, the mechanism for compressing data, referenced in Section 2.4.2.2, efficiently reduces transmission requirements for many data types (including both XML and traditional EDI data). Additionally, some FTP implementations support compression as well.
大きいファイルはTCP層によって正しく扱われます。 しかしながら、メカニズム、データを圧縮して、セクション2.4.2で.2に参照をつけて、多くのデータ型のために効率的にトランスミッション要件を減らします(XMLと伝統的なEDIデータの両方を含んでいます)。 さらに、いくつかのFTP実現がまた、圧縮を支持します。
6.3. MIME Considerations for FTP
6.3. FTPのために問題をまねてください。
6.3.1. Required/Optional Headers
6.3.1. 必要であるか任意のヘッダー
An AS3 message MUST contain the following outer headers:
AS3メッセージは以下の外側のヘッダーを含まなければなりません:
AS3-To
AS3-From
Date
Message-ID
Content-Type
AS3、-、AS3、-、Message IDのコンテントタイプと日付を入れてください。
Harding & Scott Informational [Page 15] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[15ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
An AS3 message OPTIONALLY MAY contain the following outer headers:
OPTIONALLY MAYが以下の外側のヘッダーを含んでいるというAS3メッセージ:
Subject
AS3-Version (assumed to be 1.0 if not present)
Content-Length
対象のAS3-バージョン(1.0かプレゼントであると思われる)の満足している長さ
An AS3 message requesting a receipt MUST contain a Disposition- Notification-To header and MAY contain a Disposition-Notification- Options header (if the receipt is to be signed).
ヘッダーと5月はDisposition-通知オプションを含んでいます。領収書を要求するAS3メッセージがDispositionを含まなければならない、通知、-、ヘッダー(領収書がサインされることであるなら)。
Additional headers MAY be present but are ignored.
追加ヘッダーは、存在しているかもしれませんが、無視されます。
6.3.2. Content-Transfer-Encoding
6.3.2. 満足している転送コード化
FTP defines several data structures and character encodings via the STRU[cture] and TYPE commands. AS3 requires the file-structure (default) and the image type. The Content-Transfer-Encoding header SHOULD NOT be used; if the header is present, it SHOULD have a value of binary or 8-bit. The absence of this header or the use of alternate values such as "base64" or "quoted-printable" MUST NOT result in transaction failure. Content transfer encoding of MIME parts within the AS3 message are similarly constrained.
FTPはSTRU[cture]とTYPEコマンドでいくつかのデータ構造とキャラクタencodingsを定義します。 AS3はファイル構造(デフォルト)とイメージタイプを必要とします。 Contentがコード化を移しているヘッダーSHOULD NOT、使用されてください。 ヘッダーは出席していて、それはSHOULDです。バイナリーか8ビットの価値を持ってください。 「base64"か「引用されて印刷可能」が取引失敗をもたらしてはいけない」間、このヘッダーの不在か補欠の使用がそのようなものを評価します。 AS3メッセージの中のMIMEの部品の満足している転送コード化は同様に抑制されます。
6.3.3. Epilogue Must Be Empty
6.3.3. エピローグは空であるに違いありません。
A MIME message containing an epilogue [1] SHALL NOT be used.
エピローグ[1]SHALL NOTを含んでいて、MIMEは通信します。使用されます。
6.3.4. Message-Id and Original-Message-Id
6.3.4. メッセージイドとオリジナルのメッセージイド
Message-Id and Original-Message-Id are formatted as defined in Section 3.6.4 of RFC 2822 [15]: "<" id-left "@" id-right ">". Message-Id length is a maximum of 998 characters. Message-Id SHOULD be globally unique; id-right should be something unique to the sending host environment (e.g., a host name). When sending a message, always include the angle brackets. Angle brackets are not part of the Message-Id value.
メッセージイドとOriginalメッセージイドは.4セクション3.6RFC2822[15]で定義されるようにフォーマットされます: "<"はイド正しい">"に"@"をイドで残しました。 メッセージイドの長さは最大998のキャラクタです。 メッセージイドSHOULDがグローバルにそうである、ユニーク。 イド権利は送付ホスト環境(例えば、ホスト名)に何かユニークなものであるべきです。 メッセージを送るときには、いつも角ブラケットを含めてください。 角ブラケットはMessage-イド価値の一部ではありません。
NOTE: When creating the Original-Message-Id header in an MDN, always
use the exact syntax contained in the original message: do not
strip or add "angle brackets".
以下に注意してください。 MDNでOriginalメッセージイドヘッダーを創造するときには、いつもオリジナルのメッセージに含まれた正確な構文を使用してください: 「角ブラケット」を剥取らないでください、または加えないでください。
Harding & Scott Informational [Page 16] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[16ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
7. Structure and Processing of an MDN Message
7. MDNメッセージの構造と処理
7.1. Introduction
7.1. 序論
In order to support non-repudiation of receipt, a signed receipt, based on digitally signing a message disposition notification, is to be implemented by a receiving trading partner's UA. The message disposition notification specified by RFC 3798 is digitally signed by a receiving trading partner as part of a multipart/signed MIME message.
領収書の非拒否を支持するために、メッセージ気質通知にデジタルにサインするのに基づくサインされた領収書は受信貿易相手国のUAによって実行されることです。 RFC3798によって指定されたメッセージ気質通知は複合の、または、サインされたMIMEメッセージの一部として受信貿易相手国によってデジタルにサインされます。
The following support for signed receipts is REQUIRED:
サインされた領収書の以下のサポートはREQUIREDです:
1) The ability to create a multipart/report; where the report-type =
disposition-notification.
1) 複合/レポートを作成する能力。 レポートタイプが気質通知と等しいところ。
2) The ability to calculate a message integrity check (MIC) on the
received message. The calculated MIC value will be returned to
the sender of the message inside the signed receipt.
2) 受信されたメッセージでメッセージの保全チェック(MIC)について計算する能力。 計算されたMIC値をサインされた領収書におけるメッセージ送信者に返すでしょう。
3) The ability to create a multipart/signed content with the message
disposition notification as the first body part, and the signature
as the second body part.
3) 最初の身体の部分としてのメッセージ気質通知、および2番目の身体の部分としての署名で複合の、または、サインされた内容を作成する能力。
4) The ability to return the signed receipt to the sending trading
partner.
4) サインされた領収書を送付貿易相手国に返す能力。
The signed receipt is used to notify a sending trading partner that requested the signed receipt that:
サインされた領収書は、以下のことようにサインされた領収書を要求した送付貿易相手国に通知するのに使用されます。
1) The receiving trading partner acknowledges receipt of the sent EC
Interchange.
1) 受信貿易相手国は送られたEC Interchangeの領収書を受け取ったことを知らせます。
2) If the sent message was signed, then the receiving trading partner
has authenticated the sender of the EC Interchange.
2) 送信されたメッセージがサインされたなら、受信貿易相手国はEC Interchangeの送付者を認証しました。
3) If the sent message was signed, then the receiving trading partner
has verified the integrity of the sent EC Interchange.
3) 送信されたメッセージがサインされたなら、受信貿易相手国は送られたEC Interchangeの保全について確かめました。
Regardless of whether the EDI/EC Interchange was sent in S/MIME format or not, the receiving trading partner's UA MUST provide the following basic processing:
S/MIME形式でEDI/EC Interchangeを送ったかどうかにかかわらず、受信貿易相手国のUaは以下の基本的な処理を提供しなければなりません:
1) If the sent EDI/EC Interchange is encrypted, then the encrypted
symmetric key, and initialization vector (if applicable) is
decrypted using the receiver's private key.
1) 送られたEDI/ECであるなら、Interchangeはコード化されていて、その時はコード化された対称鍵です、そして、初期化ベクトル(適切であるなら)は、受信機の秘密鍵を使用することで解読されます。
Harding & Scott Informational [Page 17] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[17ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
2) The decrypted symmetric encryption key is then used to decrypt the
EDI/EC Interchange.
2) そして、解読された左右対称の暗号化キーは、EDI/EC Interchangeを解読するのに使用されます。
3) The receiving trading partner authenticates signatures in a
message using the sender's public key.
3) 受信貿易相手国は、送付者の公開鍵を使用することでメッセージにおける署名を認証します。
The authentication algorithm performs the following:
認証アルゴリズムは以下を実行します:
a) The message integrity check (MIC or Message Digest) is
decrypted using the sender's public key.
a) メッセージの保全チェック(MICかMessage Digest)は、送付者の公開鍵を使用することで解読されます。
b) A MIC on the signed contents (the MIME header and encoded EDI
object, as per RFC 1767) in the message received is calculated
using the same one-way hash function that the sending trading
partner used.
b) メッセージのコンテンツ(RFC1767に従ってMIMEヘッダーとコード化されたEDI物)が受けたサインのMICは、送付貿易相手国が使用したのと同じ片道ハッシュ関数を使用することで計算されます。
c) The MIC extracted from the message that was sent and the MIC
calculated using the same one-way hash function that the
sending trading partner used are compared for equality.
c) 送られたメッセージから抽出されたMICと送付貿易相手国が使用したのと同じ片道ハッシュ関数を使用することで計算されたMICは平等のために比較されます。
4) The receiving trading partner formats the MDN and sets the
calculated MIC into the "Received-content-MIC" extension field.
4) 受信貿易相手国は、「容認された満足しているMIC」拡大分野にMDNをフォーマットして、計算されたMICを設定します。
5) The receiving trading partner creates a multipart/signed MIME
message according to RFC 1847.
5) RFC1847によると、受信貿易相手国は複合の、または、サインされたMIMEメッセージを作成します。
6) The MDN is the first part of the multipart/signed message, and the
digital signature is created over this MDN, including its MIME
headers.
6) MDNは複合の、または、サインされたメッセージの最初の部分です、そして、デジタル署名はこのMDNの上に作成されます、MIMEヘッダーを含んでいて。
7) The second part of the multipart/signed message contains the
digital signature. The "protocol" option specified in the second
part of the multipart/signed is as follows: S/MIME: protocol =
"application/pkcs7-signature".
7) 複合の、または、サインされたメッセージの第二部はデジタル署名を含んでいます。 複合かサインにされるのの第二部で指定された「プロトコル」オプションは以下の通りです: S/MIME: =「pkcs7アプリケーション/署名」について議定書の中で述べてください。
8) The signature information is formatted according to S/MIME
specifications. The EC Interchange and the RFC 1767 MIME EDI
content header can actually be part of a multipart MIME content
type. When the EDI Interchange is part of a multipart MIME
content type, the MIC MUST be calculated across the entire
multipart content, including the MIME headers.
8) 署名情報はS/MIME仕様通りにフォーマットされます。 EC InterchangeとRFC1767のMIME EDIの満足しているヘッダーは実際にMIMEの複合内容タイプの一部であるかもしれません。 EDI InterchangeがMIMEの複合内容タイプの一部であるときに、全体の複合内容の向こう側にミックについて計算しなければなりません、MIMEヘッダーを含んでいて。
The signed MDN, when received by the sender of the EDI Interchange can be used by the sender:
サインされたMDNであり、送付者はEDI Interchangeの送付者によって受け取られたいつを使用できるか:
1) As an acknowledgment that the EDI Interchange was sent, and then
was delivered and acknowledged by the receiving trading partner.
1) 次に、EDI Interchangeが受信貿易相手国が送られて、届けられて、承認されたという承認として。
Harding & Scott Informational [Page 18] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[18ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
The receiver does this by returning the original-message-id of the
sent message in the MDN portion of the signed receipt.
受信機は、サインされた領収書のMDN部分で送信されたメッセージのオリジナルのメッセージイドを返すことによって、これをします。
2) As an acknowledgment that the integrity of the EDI Interchange was
verified by the receiving trading partner. The receiver does this
by returning the calculated MIC of the received EC Interchange
(and 1767 MIME headers) in the "Received-content-MIC" field of the
signed MDN.
2) EDI Interchangeの保全が受信貿易相手国によって確かめられたという承認として。 受信機は、サインされたMDNの「容認された満足しているMIC」分野で容認されたEC Interchange(そして、1767個のMIMEヘッダー)の計算されたMICを返すことによって、これをします。
3) As an acknowledgment that the receiving trading partner has
authenticated the sender of the EDI Interchange.
3) 受信貿易相手国がEDI Interchangeの送付者を認証したという承認として。
4) As a non-repudiation of receipt when the signed MDN is
successfully verified by the sender with the receiving trading
partner's public key and the returned MIC value inside the MDN is
the same as the digest of the original message.
4) サインされたMDNが受信貿易相手国の公開鍵で送付者によって首尾よく確かめられるときの領収書の非拒否と返されたMICが内部を評価するとき、MDNはオリジナルのメッセージのダイジェストと同じです。
7.2. Message Disposition Notifications (MDN)
7.2. メッセージ気質通知(MDN)
The AS3-MDNs are returned on a separate FTP TCP/IP connection and are a response to an AS3 message.
AS3-MDNsは別々のFTP TCP/IP接続で返されて、AS3メッセージへの応答です。
The following diagram illustrates the delivery of an AS3-MDN delivery:
以下のダイヤグラムはAS3-MDN配送の配送を例証します:
AS3-MDN
[S] ----( connect )----> [R] [FTP Server]
[S] ----( send )-------> [R] [AS3-Message]
[S] ----( disconnect )-> [R] [FTP Server]
AS3-MDN[S]----(接続します)---->[R][FTPサーバ][S]----(発信します)------->[R][AS3-メッセージ][S]----(分離)->[R][FTPサーバ]
[S] <---( connect )----- [R] [FTP Server]
[S] <---( send )-------- [R] [AS3-MDN]]
[S] <---( disconnect )-- [R] [FTP Server]
[S] <。---(接続します)----- [S] [R][FTPサーバ]<。---(発信します)-------- [R][AS3-MDN] [S] <--(分離)-- [R] [FTPサーバ]
Note: Refer to Section 7.4.4 for additional
programming notes.
以下に注意してください。 追加プログラミング上の注意についてセクション7.4.4を参照してください。
7.3. Requesting a Signed Receipt
7.3. サインされた領収書を要求します。
Message Disposition Notifications are requested as per RFC 3798. A request that the receiving user agent issue a message disposition notification is made by placing the following header into the message to be sent:
メッセージDisposition NotificationsはRFC3798に従って要求されています。 送られるべきメッセージに以下のヘッダーを置くことによって、受信ユーザエージェントがメッセージ気質通知を発行するという要求をします:
MDN-request-header = "Disposition-notification-to" ":" ftpurl
「MDN要求ヘッダー=、「気質通知、」、」、:、」 ftpurl
This syntax is a residual of the use of MDN's in an SMTP transfer. Since this specification is adjusting the functionality from SMTP to
この構文はSMTP転送におけるMDNのものの使用の残差です。 以来、この仕様はSMTPからの機能性を調整しています。
Harding & Scott Informational [Page 19] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[19ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
FTP and retaining as much as possible from the [5] functionality, the ftpurl must be present.
FTPと[5]から機能性をできるだけ保有するftpurlは存在していなければなりません。
The ftpurl field is specified as an RFC 1738 <URL:"ftp://" login [ "/" fpath [ ";type=" ftptype ]]>, and while it MUST be present, it may be ignored if the ftpurl points to an unknown location. If the ftpurl points to an unknown location, it is RECOMMENDED that the mdn is returned back to a known ftpurl for the sender of the received message.
ftpurl分野はRFC1738<URL: 「ftp://」ログイン[「/」fpath[「; =をタイプしてください」というftptype]]>として指定されます、そして、ftpurlが未知の位置を示すなら、それは存在していなければならない間、無視されるかもしれません。 ftpurlが未知の位置を示すなら、受信されたメッセージの送付者のために知られているftpurlにmdnを返して戻すのは、RECOMMENDEDです。
For requesting MDN-based receipts, the originator supplies the required extension headers that precede the message body.
MDNベースの領収書を要求するために、創始者はメッセージ本体に先行する必要な拡張ヘッダーを供給します。
The header "tags" are as follows:
ヘッダー「タグ」は以下の通りです:
A Disposition-notification-to header is added to indicate that a message disposition notification is requested. This header is specified in [6].
Disposition通知、ヘッダーは、メッセージ気質通知が要求されているのを示すために加えられます。 このヘッダーは[6]で指定されます。
A Message-ID header is added to support message reconciliation, so that an Original-Message-Id value can be returned in the body part of the MDN.
Message-IDヘッダーはメッセージ和解を支持するために加えられます、MDNの身体の部分でOriginalメッセージイド値を返すことができるように。
Other headers, especially "Date", SHOULD be supplied; the values of these headers are often mentioned in the human-readable section of an MDN to aid in identifying the original message.
他のヘッダー、特に「日付」、SHOULD、供給してください。 MDNの人間読み込み可能なセクションでこれらのヘッダーの値は、オリジナルのメッセージを特定する際に支援するためにしばしば言及されます。
Disposition-notification-options identifies characteristics of the message.
気質通知オプションはメッセージの特性を特定します。
The following Disposition notification is in accordance with [6].
[6]によると、以下のDisposition通知はあります。
EXAMPLE:
Disposition-notification-to: // Requests the MDN
ftp://host:port/inbox // Location to return MDN
Disposition-notification-options: // The signing options for
MDN
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
例: 気質通知、: //は、MDN Disposition通知オプションを返すようMDN ftp://host:port/inbox //位置に要求します: //、MDNのサインされた領収書プロトコル=に、任意の調印オプション、pkcs7-署名。 サインされた領収書micalg=任意である、sha1、md5
Disposition-notification-options syntax:
気質通知オプション構文:
Disposition-notification-options =
"Disposition-Notification-Options:"
disposition-notification-parameters
気質通知オプションが等しい、「気質通知オプション:」 気質通知パラメタ
disposition-notification-parameters =
parameter *(";" parameter)
気質通知パラメタはパラメタ*と等しいです。(「」、;、パラメタ)
Harding & Scott Informational [Page 20] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[20ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
parameter = attribute "=" importance ", " value *("," value)
「パラメタ=属性「=」重要性」、「値の*」(「」、値)
importance = "required" / "optional"
重要性=「必要」/「任意です」。
attribute = "signed-receipt-protocol" / "signed-receipt-micalg"
属性=「サインされた領収書プロトコル」/「サインされた領収書micalg」
So the Disposition-notification-options string could be:
それで、Disposition通知オプションストリングは以下の通りであるかもしれません。
signed-receipt-protocol=optional, <protocol symbol>;
signed-receipt-micalg=optional, <micalg1>, <micalg2>,...;
サインされた領収書プロトコルは任意の<プロトコルシンボル>と等しいです。 サインされた領収書-micalgは任意の<micalg1>、<micalg2>と等しいです…;
The currently supported value for <protocol symbol> is "pkcs7- signature" for the S/MIME detached signature format.
<プロトコルシンボル>のための現在支持された値はS/MIMEの離れている署名形式のための「pkcs7署名」です。
The currently supported values for MIC algorithm <micalg> values are:
MICアルゴリズム<micalg>値のための現在支持された値は以下の通りです。
Algorithm Value
Used
-------- -------
MD5 md5
SHA-1 sha1
値が使用したアルゴリズム-------- ------- MD5 md5 SHA-1 sha1
Receiving agents SHOULD be able to recover gracefully from a <micalg> parameter value that they do not recognize.
エージェントSHOULDを受けて、彼らが認識しない<micalg>パラメタ価値から優雅に回復できてください。
The semantics of the "signed-receipt-protocol" parameter is as follows:
「サインされた領収書プロトコル」パラメタの意味論は以下の通りです:
1) The "signed-receipt-protocol" parameter is used to request a
signed receipt from the recipient trading partner. The "signed-
receipt-protocol" parameter also specifies the format in which the
signed receipt should be returned to the requester.
1) 「サインされた領収書プロトコル」パラメタは、受取人貿易相手国からサインされた領収書を要求するのに使用されます。 また、「サインされた領収書プロトコル」パラメタはサインされた領収書がリクエスタに返されるべきである形式を指定します。
The "signed-receipt-micalg" parameter is a list of MIC algorithms
preferred by the requester for use in signing the returned receipt
and calculating the micalg in the Received-content-MIC header.
「サインされた領収書micalg」パラメタはReceivedの満足しているMICヘッダーで返された領収書にサインして、micalgについて計算することにおける使用のためにリクエスタによって好まれたMICアルゴリズムのリストです。
The list of MIC algorithms should be honored by the recipient from
left to right. Both the "signed-receipt-protocol" and the
"signed-receipt-micalg" option parameters are REQUIRED when
requesting a signed receipt.
MICアルゴリズムのリストは左から右まで受取人によって光栄に思われるべきです。 サインされた領収書を要求するとき、「サインされた領収書プロトコル」と「サインされた領収書micalg」オプションパラメタの両方がREQUIREDです。
2) The "importance" attribute of "Optional" is defined in RFC 3798,
Section 2.2, and has the following meaning:
2) 「任意」の「重要性」属性は、RFC3798、セクション2.2で定義されて、以下の意味を持っています:
Parameters with an importance of "Optional" permit a UA that does
not understand the particular options parameter to still generate
an MDN in response to a request for an MDN. A UA that does not
「任意」の重要性があるパラメタは特定のオプションパラメタがMDNを求める要求に対応してMDNをまだ発生させているのを理解していないUAを可能にします。 そうしないUA
Harding & Scott Informational [Page 21] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[21ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
understand the "signed-receipt-protocol" parameter, or the
"signed-receipt-micalg" parameter, will obviously not return a
signed receipt.
「サインされた領収書プロトコル」パラメタ、または「サインされた領収書micalg」パラメタが明らかにサインされた領収書を返さないのを理解してください。
The importance of "Optional" is used for the signed receipt
parameters because it is RECOMMENDED that an MDN be returned to
the requesting trading partner even if the recipient could not
sign it.
受取人がそれにサインできないでも要求貿易相手国にMDNを返すのが、RECOMMENDEDであるので、「任意」の重要性はサインされた領収書パラメタに使用されます。
The returned MDN will contain information on the disposition of
the message as well as on why the MDN could not be signed. See
the Disposition field in Section 7.5 for more information.
返されたMDNはメッセージの気質とMDNにサインできなかった理由の情報を含むでしょう。 セクション7.5で詳しい情報に関してDisposition分野を見てください。
Within an EDI trading relationship, if a signed receipt is expected and is not returned, then the validity of the transaction must be determined by the trading partners. Typically, if a signed receipt is required by the trading relationship and is not received, the transaction will likely not be considered valid.
EDIの取り引き関係の中では、署名している領収書が予想されて、返されないなら、貿易相手国はトランザクションの正当性を決定しなければなりません。 署名している領収書が取り引き関係が必要であり、受け取られていないと、通常、トランザクションは有効であるとおそらく考えられないでしょう。
7.3.1. Signed Receipt Considerations
7.3.1. 領収書問題であると署名されます。
The method used to request a receipt or a signed receipt is defined in RFC 3798, "An Extensible Message Format for Message Disposition Notifications".
メソッドは、以前はよくRFC3798、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」で領収書か署名している領収書が定義されるよう要求していました。
The "rules" for processing a receipt-request follow:
領収書要求を処理するための「規則」は続きます:
1) When a receipt is requested, explicitly specifying that the
receipt be signed, then the receipt MUST be returned with a
signature unless conditions (2) or (3) below are applicable.
1) 領収書が署名されると明らかに指定して、領収書を要求して、以下の状態(2)か(3)が適切でない場合、署名と共に領収書を返さなければなりません。
2) When a receipt is requested, explicitly specifying that the
receipt be signed, but the recipient cannot support either the
requested protocol format, or requested MIC algorithms, then
either a signed or unsigned receipt SHOULD be returned.
2) 領収書が署名されると明らかに指定して、領収書がいつ、要求されるか、しかし、受取人は、要求されたプロトコルが形式であるとサポートすることができませんでしたし、MICアルゴリズム、次に署名しているか未署名の領収書SHOULDが返されるよう要求もしました。
3) When a receipt is requested, explicitly specifying that the
receipt be signed, but the recipient is unable to compute the
digest (e.g., message was encrypted, and recipient unable to
decrypt), then the recipient SHOULD NOT return "Received-content-
MIC" in the MDN to the requestor. If the MDN sets the disposition
(e.g., "processed/error: decryption-failed") appropriately, then
the "Received-content-MIC" may be returned, but the value must be
discarded.
3) 領収書が署名されると明らかに指定して、領収書がいつ要求されるか、しかし、受取人はダイジェストを計算できません。そして、(例えばメッセージが暗号化された、解読することができない受取人)、そして、要請者へのMDNの「受け取られていている内容-MIC」の受取人SHOULD NOTリターン。 MDNが気質を設定する、(例えば、「処理/誤り:」 「復号化で失敗される」) 適切に、次に、「容認された満足しているMIC」を返すかもしれませんが、値を捨てなければなりません。
Harding & Scott Informational [Page 22] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[22ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
4) When a signature is not explicitly requested, or if the signed
receipt request parameter is not recognized by the UA, then no
receipt, an unsigned receipt, or a signed receipt MAY be returned
by the recipient.
4) 署名している領収書要求パラメタがUAによって認識されないで、また署名が明らかに要求されない場合、どんな領収書も、未署名の領収書、または署名している領収書も受取人によって返されないかもしれません。
5) If a message is received without a request for a receipt, then a
receipt (signed or unsigned) MAY be returned.
5) 次に、領収書、領収書(署名しているか未署名の)を求める要求なしでメッセージを受け取るなら 返すかもしれません。
The "Received-content-MIC" MUST be calculated as follows:
以下の通り「容認された満足しているミック」について計算しなければなりません:
- For any signed messages, the MIC to be returned is calculated on
the RFC 1767 MIME header and content. Canonicalization as
specified in RFC 1848 MUST be performed before the MIC is
calculated, since the sender requesting the signed receipt was
also REQUIRED to canonicalize.
- どんな署名しているメッセージに関してはも、返されるべきMICはRFC1767MIMEヘッダーと内容で計算されます。 MICが計算される前にRFC1848の指定されるとしてのCanonicalizationを実行しなければなりません、また、署名している領収書を要求した送付者がcanonicalizeするREQUIREDであったので。
- For encrypted, unsigned messages, the MIC to be returned is
calculated on the decrypted RFC 1767 MIME header and content.
The content after decryption MUST be canonicalized before the
MIC is calculated.
- 暗号化されて、未署名のメッセージに関しては、返されるべきMICは解読されたRFC1767MIMEヘッダーと内容で計算されます。 MICが計算される前に復号化の後の内容をcanonicalizedしなければなりません。
- For unsigned, un-encrypted messages, the MIC MUST be calculated
over the message contents prior to Content-Transfer-Encoding and
without the MIME or any other RFC 822 [14] headers, since these
are sometimes altered or reordered by message transfer agents
(MTAs).
- 未署名の不-暗号化メッセージに関しては、メッセージ内容に関してContent転送コード化の前とMIMEかいかなる他のRFC822[14]ヘッダーなしでもミックについて計算しなければなりません、メッセージ転送エージェント(MTAs)によって、これらが時々変更されるか、または再命令されるので。
7.4. MDN Format and Value
7.4. MDN形式と値
This section defines the format of the AS3 Message Disposition Notification (AS3-MDN).
このセクションはAS3 Message Disposition Notification(AS3-MDN)の書式を定義します。
7.4.1. AS3-MDN General Formats
7.4.1. AS3-MDN一般形式
The AS3-MDN follows the MDN specification [6] except where noted in this section. The modified entity definitions in this document use the vertical-bar character, '|', to denote a logical "OR" construction. Refer to RFC 2045 for the format of MIME-message- headers.
このセクションで有名であるところを除いて、AS3-MDNはMDN仕様[6]に従います。 '変更された実体定義は本書では縦棒キャラクタを使用します'|'論理的な「OR」工事を指示します' MIMEメッセージヘッダーの形式についてRFC2045を参照してください。
The format of the AS3-MDN is
AS3-MDNの形式はそうです。
MDN, no signature
MDN、署名がありません。
-RFC822/2045
-RFC3798 (message/disposition-notification)
-RFC822/2045 -RFC3798(気質メッセージ/通知)
Harding & Scott Informational [Page 23] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[23ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
MDN, signature
MDN、署名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
-RFC822/2045 -RFC1847(複合か署名される)の-RFC3798(気質メッセージ/通知)-RFC3851(pkcs7アプリケーション/署名)
7.4.2. AS3-MDN Construction
7.4.2. AS3-MDN工事
The AS3-MDN-body is formatted as a MIME multipart/report with a report-type of "disposition-notification".
AS3-MDN-ボディーはMIME複合/レポートとして「気質通知」のレポートタイプでフォーマットされます。
When unsigned, the transfer-layer ("outermost") entity-headers of the
AS3-MDN contain the Content-Type header that specifies a content type
of "multipart/report", parameters indicating the report-type, and the
value of the outermost multipart boundary.
未署名であるときに、AS3-MDNの転送層の(「一番はずれ」)の実体ヘッダーは「複合/レポート」のcontent type、レポートタイプを示すパラメタ、および一番はずれの複合境界の値を指定するコンテントタイプヘッダーを含んでいます。
When the AS3-MDN is signed, the transfer-layer ("outermost") entity-
headers of the AS3-MDN contain a Content-Type header that specifies a
content type of "multipart/signed", parameters indicating the
algorithm used to compute the message digest, the signature
formatting protocol (e.g., pkcs7-signature), and the value of the
outermost multipart boundary. The first part of the MIME
multipart/signed message is an imbedded MIME multipart/report of type
"disposition-notification". The second part of the multipart/signed
message contains a MIME application/pkcs7-signature message.
AS3-MDNが署名されるとき、AS3-MDNの層を移している(「一番はずれ」の)実体ヘッダーは「複合か署名されること」のcontent type(アルゴリズムが以前はよくメッセージダイジェスト、署名形式プロトコル(例えば、pkcs7-署名)、および一番はずれの複合境界の値を計算していたのを示すパラメタ)を指定するコンテントタイプヘッダーを含んでいます。 MIMEの複合の、または、署名しているメッセージの最初の部分はタイプ「気質通知」の埋め込まれたMIME複合/レポートです。 複合の、または、署名しているメッセージの第二部はMIME pkcs7アプリケーション/署名メッセージを含んでいます。
The first part of the MIME multipart/report is a "human-readable" portion that contains a general description of the message disposition. The second part of the MIME multipart/report is a "machine-readable" portion that is defined as
MIME複合/レポートの最初の部分はメッセージ気質の概説を含む「人間読み込み可能な」部分です。 MIME複合/レポートの第二部はそれが定義される「機械可読な」部分です。
AS3-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
[ original-recipient-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS3-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS3-received-content-MIC-field CRLF ]
AS3気質通知内容は最終受理者分野CRLF[元のメッセージイド分野CRLF]AS3気質分野CRLF*(失敗分野CRLF)*(誤り分野CRLF)*(警告分野CRLF)*(拡大分野CRLF)と等しいです[報告しているua分野CRLF][mdnゲートウェイ分野CRLF][元の受取人分野CRLF]。[AS3がMICがさばく内容を受け取っているCRLF]
It is noted that several of the optional fields defined by RFC 3798 and shown above are not relevant to a point-to-point transport such as FTP and would not normally appear in an AS3 MDN.
RFC3798によって定義されて、上に示されたいくつかの任意の分野がFTPなどの二地点間輸送に関連していなくて、また通常、AS3 MDNに現れないことに注意されます。
Harding & Scott Informational [Page 24] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[24ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
7.4.3. AS3-MDN Fields
7.4.3. AS3-MDN分野
The rules for constructing the AS3-disposition-notification-content are identical to the rules for constructing the disposition- notification-content as defined in Section 7 of RFC 3798 [6] except that the RFC 3798 disposition-field has been replaced with the AS3- disposition-field and that the AS3-received-content-MIC field has been added. The differences between the RFC 3798 disposition-field and the AS3-disposition-field are described below. Where there are differences between this document and RFC 3798, those entity names have been changed by prepending "AS3-". Entities below that do not differ from RFC 3798 are not necessarily further defined in this document.
AS3気質通知内容を構成するための規則は3798年のRFC気質野原をAS3気質分野とそれに取り替えたのを除いて、RFC3798[6]のセクション7で定義されて、AS3が内容MICを受けている分野が加えられるので気質通知内容を構成するための規則と同じです。 3798年のRFC気質分野とAS3気質分野の違いは以下で説明されます。 このドキュメントとRFC3798の間には、違いがあるところでは、"AS3"をprependingすることによって、それらの実体名を変えました。 以下のRFC3798と異なっていない実体が必ずより詳しく本書では定義されません。
Refer to RFC 3798 [6] and RFC 4234 [22] for entities that are not further defined in this document.
さらに本書では定義されない実体についてRFC3798[6]とRFC4234[22]を参照してください。
AS3-disposition-field = "Disposition:" disposition-mode ";"
AS3-disposition-type [ "/" AS3-disposition-modifier]
AS3気質分野=、「気質:」 「気質モード」;、」 AS3気質タイプ[「/」AS3気質修飾語]
disposition-mode = action-mode "/" sending-mode
「気質モード=動作モード」/、」 発信モード
action-mode = "manual-action" / "automatic-action"
動作モードは「手動の動き」/「自動動作」と等しいです。
sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"
発信モードは「手動で送られたMDN」/「自動的に送られたMDN」と等しいです。
AS3-disposition-type = "processed" / "failed"
AS3気質タイプ=は、「処理する」か、または「失敗しました」。
AS3-disposition-modifier = ( "error" / "warning" ) /
AS3-disposition-modifier-extension
AS3気質修飾語AS3気質修飾語=(「誤り」/「警告」)/拡張子
AS3-disposition-modifier-extension =
"error: authentication-failed" /
"error: decompression-failed" /
"error: decryption-failed" /
"error: insufficient-message-security" /
"error: integrity-check-failed" /
"error: unexpected-processing-error" /
"warning: " AS3-MDN-warning-description /
"failure: " AS3-MDN-failure-description
AS3気質修飾語拡張子が等しい、「誤り:」 /に「認証して失敗する」、「誤り:」 /に「減圧で失敗する」、「誤り:」 /に「復号化で失敗する」、「誤り:」 「不十分なメッセージセキュリティ」/、「誤り:」 「失敗された保全チェック」/、「誤り:」 「予期していなかった整理過程の誤差」/、「警告:」 「AS3-MDNの警告の記述/、「失敗:」 「AS3-MDN失敗記述」
AS3-MDN-warning-description = *( TEXT )
AS3-MDN警告記述は*と等しいです。(テキスト)
AS3-MDN-failure-description = *( TEXT )
AS3-MDN失敗記述は*と等しいです。(テキスト)
AS3-received-content-MIC-field =
"Received-content-MIC:" encoded-message-digest
"," digest-alg-id CRLF
AS3がMICがさばく内容を受け取った、= 「受け取って、MICを満足させてください」 」 「コード化されたメッセージダイジェスト」、ダイジェストalgイドCRLF
Harding & Scott Informational [Page 25] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[25ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
encoded-message-digest =
1*( ALPHA / DIGIT / "/" / "+" ) *3"="
;( i.e. base64( message-digest ) )
「コード化されたメッセージダイジェスト=1*、(アルファー/ DIGIT /、」 /」 /「+」) *3インチ=、」、。(すなわち、base64(メッセージダイジェスト))
digest-alg-id = "sha1" / "md5"
ダイジェストalgイド=、「sha1"/"md5""
The "Received-content-MIC" extension field is set after the integrity of the received message is verified. The MIC is the base64-encoded message-digest computed over the received message with a hash function. This field is required for signed receipts but optional for unsigned receipts. For details defining the specific content over which the message-digest is to be computed, see Section 7.3.1 of this document.
受信されたメッセージの保全が確かめられた後に「容認された満足しているMIC」拡大分野は設定されます。 MICはハッシュ関数で受信されたメッセージに関して計算されたbase64によってコード化されたメッセージダイジェストです。 この分野は、署名している領収書に必要であり、未署名の領収書に、任意です。 計算されるメッセージダイジェストがことである特定の内容を定義する詳細に関しては、この.1通のセクション7.3ドキュメントを見てください。
The algorithm used to calculate the message digest MUST be the same as the "micalg" value used by the sender in the multipart/signed message. When no signature is received, the message-digest MUST be calculated using the algorithm specified by the "micalg" value in the Disposition-Notification-Options header. When no signature is received and no micalg parameter is provided, then the SHA-1 algorithm MUST be used to calculate the digest. This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the recipient's signature on the MDN in order for the sender to verify non-repudiation of receipt.
アルゴリズムは、以前はよくメッセージダイジェストが複合の、または、署名しているメッセージの送付者によって使用された"micalg"値と同じであるに違いないと見込んでいました。 どんな署名も受け取られていないとき、Disposition通知オプションヘッダーの"micalg"値によって指定されたアルゴリズムを使用して、メッセージダイジェストを計算しなければなりません。 どんな署名も受け取られていないで、またmicalgパラメタを全く提供しないと、ダイジェストについて計算するのにSHA-1アルゴリズムを使用しなければなりません。 メッセージの内容が首尾よく処理されるときだけ、この分野は設定されます。 送付者が領収書の非拒否について確かめるのにこの分野はMDNにおける受取人の署名に関連して使用されます。
AS3-MDN field names (e.g., "Disposition:", "Final-Recipient:") are case-insensitive (cf. RFC 3798, Section 3.1.1).
AS3-MDNフィールド名、(例えば、「気質:」、「最終受理者:」、)、大文字と小文字を区別しないです。(Cf。 RFC3798、セクション3.1.1).
AS3-MDN action-modes, sending-modes, AS3-disposition-types, and AS3- disposition-modifier values that are defined above, and user-supplied *( TEXT ) values are also case-insensitive. AS3 implementations MUST NOT make assumptions regarding the values supplied for AS3-MDN- warning-description or AS3-MDN-failure-description or for the values of any (optional) error, warning, or failure fields.
また、AS3-MDN動作モード、発信モード、AS3気質タイプ、上で定義されるAS3気質修飾語値、およびユーザによって供給された*(TEXT)値も大文字と小文字を区別しないです。 AS3実装はAS3-MDN警告記述かAS3-MDN失敗記述かどんな(任意)の誤りの値にも供給された値、警告、または失敗に関する仮定を分野にしてはいけません。
7.4.4. Additional AS3-MDN Programming Notes
7.4.4. 追加AS3-MDNプログラミング上の注意
1. Unlike SMTP, for FTP transactions, Original-Recipient and Final
Recipient SHOULD NOT be different. The value in Original-
Message-ID MUST match the original Message-ID header value.
1. SMTPと異なって、FTPトランザクション、Original-受取人、およびFinal Recipient SHOULD NOTにおいて、異なってください。 Original Message IDの値は元のMessage-IDヘッダー価値に合わなければなりません。
2. Refer to RFC 3462 and RFC 3798 for the formatting of the
Content-Type entity-headers for the MDN.
2. MDNのためにコンテントタイプ実体ヘッダーの形式についてRFC3462とRFC3798を参照してください。
3. Use an action-mode of "automatic-action" when the disposition
described by the disposition type was a result of an automatic
action, rather than an explicit instruction by the user for this
message.
3. 気質タイプによって説明された気質がこのメッセージのためのユーザによる明白な指示よりむしろ自動動作の結果であったときには「自動動作」の動作モードを使用してください。
Harding & Scott Informational [Page 26] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[26ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
4. Use an action-mode of "manual-action" when the disposition
described by the disposition type was a result of an explicit
instruction by the user rather than some sort of automatically
performed action.
4. 気質タイプによって説明された気質がある種の自動的に実行された動作よりむしろユーザによる明白な指示の結果であったときには「手動の動き」の動作モードを使用してください。
5. Use a sending-mode of "MDN-sent-automatically" when the MDN is
sent because the UA had previously been configured to do so.
5. UAが以前にそうするために構成されたのでMDNを送るときには「自動的に送られたMDN」の発信モードを使用してください。
6. Use a sending-mode of "MDN-sent-manually" when the user
explicitly gave permission for this particular MDN to be sent.
6. ユーザが明らかにこの特定のMDNが送られる許可を与えたときには「手動で送られたMDN」の発信モードを使用してください。
7. The sending-mode "MDN-sent-manually" is ONLY meaningful with
"manual-action", not with "automatic-action".
7. 「自動動作」ゆえ重要であるのではなく、発信モード「手動で送られたMDN」は「手動の動き」ゆえ重要であるだけです。
8. The "failed" disposition type MAY NOT be used for the situation
in which there is some problem in processing the message other
than interpreting the request for an MDN. The "processed" or
other disposition type with appropriate disposition modifiers is
to be used in such situations.
8. 「失敗した」気質タイプはMDNを求める要求を解釈する以外のメッセージを処理するのにおいて何らかの問題がある状況に使用されないかもしれません。 適切な気質修飾語がある「処理された」か他の気質タイプはそのような状況で使用されることになっています。
9. An AS3 implementation MUST present to its trading partners an
FTP-compliant server interface where inbound documents and MDNs
are received.
9. AS3実装は本国行きのドキュメントとMDNsが受け取られているFTP対応することのサーバインタフェースを貿易相手国に提示しなければなりません。
10. An AS3 implementation MUST be able to retrieve inbound messages
from its currently configured FTP server interface.
10. AS3実装は現在構成されたFTPサーバインタフェースからの本国行きのメッセージを検索できなければなりません。
Note: Programming Notes 9 and 10 do not imply any specific method for
supplying the FTP server interface. But, they do allow for
several different types of implementations. Some vendors may
choose to imbed an FTP-compliant server interface within their
product, and others may choose to utilize off-the-shelf FTP
servers to supply the required FTP server interface. Some may
choose to utilize hosting services provided by their trading
partner or by a third-party hosting service. Whichever method
is utilized, an AS3 implementation MUST support rules 9 and 10.
以下に注意してください。 プログラミングNotes9と10はFTPサーバインタフェースを供給するための少しの特定のメソッドも含意しません。 しかし、彼らはいくつかの異なったタイプの実装を考慮します。 いくつかのベンダーが、それらの製品の中にFTP対応することのサーバインタフェースを埋め込むのを選ぶかもしれません、そして、他のものは必要なFTPサーバインタフェースを供給するのにすぐ入手できるFTPサーバを利用するのを選ぶかもしれません。 或るものは、それらの貿易相手国か第三者ホスティングサービスで提供されたホスティングサービスを利用するのを選ぶかもしれません。 どのメソッドが利用されていても、AS3実装は、規則が9と10であるとサポートしなければなりません。
11. AS3 implementations MAY imbed an FTP server interface within
their product.
11. AS3実装はそれらの製品の中にFTPサーバインタフェースを埋め込むかもしれません。
12. AS3 implementations MUST be configurable to allow the use of an
external FTP hosting service.
12. AS3実装は外部のFTPホスティングサービスの使用を許すのにおいて構成可能であるに違いありません。
Note: An external FTP hosting service may be hosted by a third-party
or possibly hosted by your trading partner.
以下に注意してください。 外部のFTPホスティングサービスは、第三者によって主催されるか、またはことによるとあなたの貿易相手国によって主催されるかもしれません。
Harding & Scott Informational [Page 27] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[27ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
13. An AS3 implementation MUST be able to send business documents and
MDNs to a trading partner's currently configured FTP server
interface.
13. AS3実装は貿易相手国の現在構成されたFTPサーバインタフェースに業務用書類とMDNsを送ることができなければなりません。
14. An AS3 implementation may imbed FTP client code into their
product or use a third-party FTP client.
14. AS3実装は、FTPクライアントコードをそれらの製品の中に埋め込むか、または第三者FTPクライアントを使用するかもしれません。
15. Example Configurations
15. 例の構成
1. Peer to Peer
Trading Partner A (TPA) is using a local FTP server, and
Trading Partner B (TPB) is using an imbedded FTP server.
1. Peer Trading Partner A(TPA)への同輩はローカルのFTPサーバを使用しています、そして、Trading Partner B(TPB)は埋め込まれたFTPサーバを使用しています。
[A Client] ----( connect )----> [B Server]
[A Client] ----( send )-------> [B Server] [AS3-Message]
[A Client] ----( disconnect )-> [B Server]
[クライアント]----(接続します)---->[Bサーバ][クライアント]----(発信します)------->[Bサーバ][AS3-メッセージ][クライアント]----(分離)->。[Bサーバ]
[A Server] <---( connect )----- [B Client]
[A Server] <---( send )-------- [B Client] [AS3-MDN]]
[A Server] <---( disconnect )-- [B Server]
[A Client] <---( GET )--------- [A Server]
[サーバ] <。---(接続します)----- [Bクライアント] [サーバ]<。---(発信します)-------- [Bクライアント][AS3-MDN] [サーバ] <--(分離)-- [Bサーバ] [クライアント] <--(得ます)--------- [サーバ]
2. Third-Party Hosting
Both parties are using the same third-party-hosted FTP server.
2. 第3パーティHosting Bothパーティーはパーティーが接待した同じ3番目のFTPサーバを使用しています。
[A Client] ----( connect )----> [Hosted Server]
[A Client] ----( send )-------> [Hosted Server] [AS3-Message]
[A Client] ----( disconnect )-> [Hosted Server]
[Hosted Server]( GET )--------> [B Client]
[クライアント]----(接続します)---->[サーバをホスティングします][クライアント]----(発信します)------->[サーバをホスティングします][AS3-メッセージ][クライアント]----(分離)->[サーバをホスティングします][サーバをホスティングします](得ます)-------->。[Bクライアント]
[Hosted Server] <---( connect )----- [B Client]
[Hosted Server] <---( send )-------- [B Client] [AS3-MDN]]
[Hosted Server] <---( disconnect )-- [B Client]
[A Client] <---( GET )--------- [Hosted Server]
[サーバをホスティングします] <。---(接続します)----- [Bクライアント] [サーバをホスティングします]<。---(発信します)-------- [Bクライアント][AS3-MDN] [接待されたサーバ] <--(分離)-- [Bクライアント] [クライアント] <--(得ます)--------- [接待されたサーバ]
3. Trading Partner Hosting
TPA is using the imbedded FTP server hosted by TPB.
3. 取り引きPartner Hosting TPAはTPBによってホスティングされた埋め込まれたFTPサーバを使用しています。
[A Client] ----( connect )----> [B Server]
[A Client] ----( send )-------> [B Server] [AS3-Message]
[A Client] ----( disconnect )-> [B Server]
[クライアント]----(接続します)---->[Bサーバ][クライアント]----(発信します)------->[Bサーバ][AS3-メッセージ][クライアント]----(分離)->。[Bサーバ]
[B Server] <---( connect )----- [B Client]
[B Server] <---( send )-------- [B Client] [AS3-MDN]]
[B Server] <---( disconnect )-- [B Client]
[A Client] <---( GET )--------- [B Server]
[Bサーバ] <。---(接続します)----- [Bクライアント] [Bサーバ]<。---(発信します)-------- [Bクライアント][AS3-MDN] [Bサーバ] <--(分離)-- [Bクライアント] [クライアント] <--(得ます)--------- [Bサーバ]
Harding & Scott Informational [Page 28] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[28ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
7.5. Disposition Mode, Type, and Modifier
7.5. 気質モード、タイプ、および修飾語
7.5.1. Disposition Mode Overview
7.5.1. 気質モード概要
This section will provide a brief overview of how processed, error, failure, or warning notifications are used.
このセクションは処理されていて、誤り、失敗、または警告通知がどう使用されているかに関する簡潔な概要を提供するでしょう。
7.5.2. Successful Processing Status Indication
7.5.2. うまくいっている処理状態指示
When a receipt or signed receipt is requested, and the received message contents are successfully processed by the receiving EDI UA, a receipt or MDN SHOULD be returned with the "disposition-type" set to "processed". When the MDN is sent automatically by the EDI UA, and there is no explicit way for a user to control the sending of the MDN, then the first part of the "disposition-mode" should be set to "automatic-action".
領収書か署名している領収書がいつ要求されるか、そして、受信されたメッセージ内容はそうです。首尾よく処理されて、受信EDI UA、領収書またはMDN SHOULDによって、「気質タイプ」セットで「処理されること」に返されてください。 MDNがEDI UAによって自動的に送られて、ユーザがMDNの発信を制御するどんな明白な方法もないと、「気質モード」の最初の部分は「自動動作」に設定されるべきです。
When the MDN is being sent under user-configurable control, then the first part of the "disposition-mode" should be set to "manual- action". Since a request for a signed receipt should always be honored, the user MUST not be allowed to configure the UA not to send a signed receipt when the sender requests one.
ユーザ構成可能なコントロールの下でMDNを送ると、「気質モード」の最初の部分を「マニュアル動作」に設定するべきです。 署名している領収書を求める要求がいつも光栄に思うべきであるので、ユーザに送付者が1つを要求するとき、署名している領収書を送らないようにUAを構成させてはいけません。
The second part of the "disposition-mode" is set to "MDN-sent- manually" if the user gave explicit permission for the MDN to be sent. Again, the user MUST not be allowed to explicitly refuse to send a signed receipt when the sender requests one. The second part of the "disposition-mode" is set to "MDN-sent-automatically" whenever the EDI UA sends the MDN automatically, regardless of whether the sending was under a user's, an administrator's, or software control.
「気質モード」の第二部は設定されます。ユーザがMDNが送られる明白な許可を与えたなら、「-手動でMDN発信しました」。 一方、ユーザに送付者が1つを要求するとき、署名している領収書を送るのを明らかに拒否させてはいけません。 EDI UAが自動的にMDNを送るときはいつも、「気質モード」の第二部は「自動的に送られたMDN」に設定されます、発信がユーザのもの、アドミニストレータ、またはソフトウェア制御装置の下にあったことにかかわらず。
Since EDI content is generally handled automatically by the EDI UA, a request for a receipt or signed receipt will generally return the following in the "disposition-field":
EDI内容がEDI UAによって一般に自動的に扱われるので、一般に、領収書か署名している領収書を求める要求は「気質分野」で以下を返すでしょう:
Disposition: automatic-action/MDN-sent-automatically; processed
気質: MDNは自動的に自動動作/発信していました。 処理されます。
Note this specification does not restrict the use of the "disposition-mode" to just automatic actions. Manual actions are valid as long as it is kept in mind that a request for a signed receipt MUST be honored.
この仕様が「気質モード」の使用をまさしく自動動作に制限しないことに注意してください。 署名している領収書を求める要求が光栄に思うに違いないのが覚えておかれる限り、手動の動きは有効です。
7.5.3. Unsuccessful Processed Content
7.5.3. 失敗の処理内容
The request for a signed receipt requires the use of two "disposition-notification-options", which specify the protocol format of the returned signed receipt, and the MIC algorithm used to calculate the MIC over the message contents. The "disposition-field"
署名している領収書を求める要求は返された署名している領収書のプロトコル形式を指定する2「気質通知オプション」とメッセージ内容に関してMICについて計算するのに使用されるMICアルゴリズムの使用を必要とします。 「気質分野」
Harding & Scott Informational [Page 29] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[29ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
values that should be used in the case where the message content is being rejected or ignored should be specified in the MDN "disposition-field" as below. (An example of this case is when the EDI UA determines that a signed receipt cannot be returned because it does not support the requested protocol format, so the EDI UA chooses not to process the message contents itself.)
メッセージ内容が拒絶されるか、または無視されて、MDN「気質分野」で指定されるべきであるという以下の同じくらいことである場合に使用されるべきである値。 (本件に関する例がEDI UAが要求されたプロトコルが形式であるとサポートしないので署名している領収書を返すことができないことを決定する時であるので、EDI UAは、メッセージコンテンツ自体を処理しないのを選びます。)
Disposition: "disposition-mode"; failed/Failure: unsupported Format
気質: 「気質モード」。 失敗した/失敗: サポートされないFormat
The "failed" AS3-disposition-type should be used when a failure occurs that prevents the proper generation of an MDN.
MDNの適切な世代を防ぐ失敗が起こるとき、「失敗した」AS3気質タイプは使用されるべきです。
For example, this disposition-type would apply if the sender of the message requested the application of an unsupported message- integrity-check (MIC) algorithm.
例えば、メッセージ送信者がサポートされないメッセージ保全チェック(MIC)アルゴリズムの申込み書を要求するなら、この気質タイプは当てはまるでしょうに。
The "failure:" AS3-disposition-modifier-extension should be used with an implementation-defined description of the failure.
「失敗:」 AS3気質修飾語拡張子は失敗の実装で定義された記述と共に使用されるべきです。
Further information about the failure may be contained in a failure- field. The syntax of the "failed" "disposition-type" is general, allowing the sending of any textual information along with the "failed" "disposition-type". Implementations WILL support any printable textual characters after the Failure disposition-type.
失敗に関する詳細は失敗分野に保管されるかもしれません。 「失敗した」「気質タイプ」に伴うどんな文字情報の発信も許して、「失敗した」「気質タイプ」の構文は一般的です。 実装はFailure気質タイプの後にどんな印刷可能な原文のキャラクタもサポートするでしょう。
For use in Internet EDI, the following "failed" values are pre- defined and MUST be supported:
インターネットEDIにおける使用において、以下の「失敗した」値をあらかじめ定義されて、サポートしなければなりません:
"Failure: unsupported format"
"Failure: unsupported MIC-algorithms"
「失敗:」 「サポートされない形式」、「失敗:」 「サポートされないMIC-アルゴリズム」
7.5.4. Unsuccessful Non-Content Processing
7.5.4. 失敗の非内容処理
When errors occur in processing the received message, other than content, the "disposition-field" should be set to the "processed" "disposition-type" value and the "error" "disposition-modifier" value.
誤りが受信されたメッセージを処理する際に発生するとき、内容を除いて、「気質分野」は「処理された」「気質タイプ」値と「誤り」「気質修飾語」価値に設定されるべきです。
The "error" AS3-disposition-modifier with the "processed" disposition-type should be used to indicate that an error of some sort occurred that prevented successful processing of the message.
「処理された」気質タイプとの「誤り」AS3気質修飾語は、メッセージのうまくいっている処理を防いだある種の誤りが発生したのを示すのに使用されるべきです。
Further information may be contained in an error-field.
詳細は誤り分野に保管されるかもしれません。
An "error:" AS3-disposition-modifier-extension should be used to combine the indication of an error with a pre-defined description of a specific, well-known error. Further information about the error may be contained in an error-field.
「誤り:」 AS3気質修飾語拡張子は、特定の、そして、よく知られる誤りの事前に定義された記述に誤りのしるしを結合するのに使用されるべきです。 誤りに関する詳細は誤り分野に保管されるかもしれません。
Harding & Scott Informational [Page 30] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[30ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
For use in Internet EDI, the following "error" "disposition-modifier" values are defined:
インターネットEDIにおける使用において、以下の「誤り」「気質修飾語」値は定義されます:
"Error: decryption-failed"
The receiver could not decrypt the message contents.
「誤り:」 「復号化で失敗にされる」受信機がメッセージ内容を解読することができなかった。
"Error: authentication-failed"
The receiver could not authenticate the sender.
「誤り:」 「認証で失敗される」、受信機が認証できなかった送付者。
"Error: integrity-check-failed"
The receiver could not verify content integrity.
「誤り:」 「保全チェックは失敗したこと」の受信機が確かめることができなかった満足している保全。
"Error: insufficient-message-security"
The security level of the message did not match the agreed level
between TPs.
「誤り:」 セキュリティが平らにするメッセージの「不十分なメッセージセキュリティ」はTPsの間の同意されたレベルに合っていませんでした。
"Error: decompression-failed"
The receiver could not decompress the message contents.
「誤り:」 「減圧で失敗される」、受信機が減圧できなかったメッセージ内容。
"Error: unexpected-processing-error"
A catch-all for any additional processing errors.
「誤り:」 どんな追加整理過程の誤差のための「予期していなかった整理過程の誤差」Aキャッチすべて。
An example of how the "disposition-field" would look when processing errors, other than content, are detected is as follows:
内容を除いて、整理過程の誤差が検出されるとき、「気質分野」がどう見えるだろうかに関する例は以下の通りです:
EXAMPLE
Disposition: "disposition-mode";
processed/Error: decryption-failed
例の気質: 「気質モード」。 処理/誤り: 復号化で、失敗されています。
7.5.5. Processing Warnings
7.5.5. 処理警告
Situations arise in EDI where even if a trading partner cannot be authenticated correctly, the trading partners still agree to continue processing the EDI transactions. Transaction reconciliation is done between the trading partners at a later time. In the content processing warning situations described above, the "disposition- field" SHOULD be set to the "processed" "disposition-type" value, and the "warning" "disposition-modifier" value.
状況は正しく貿易相手国を認証できないでも、貿易相手国がEDIトランザクションを処理し続けているのにまだ同意しているEDIに起こります。 後で貿易相手国の間でトランザクション和解をします。 上で説明された状況、「気質分野」SHOULDが「処理された」「気質タイプ」値、および「警告」「気質修飾語」価値に用意ができていると警告しながら処理される内容で。
The "warning" AS3-disposition-modifier should be used with the "processed" disposition-type to indicate that the message was successfully processed but that an exceptional condition occurred.
「警告」AS3気質修飾語は、メッセージが首尾よく処理されましたが、例外的な状態が現れたのを示すのに「処理された」気質タイプで使用されるべきです。
Further information may be contained in a warning-field.
詳細は警告分野に保管されるかもしれません。
Harding & Scott Informational [Page 31] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[31ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
A "warning:" AS3-disposition-modifier-extension should be used to combine the indication of a warning with an implementation-defined description of the warning. Further information about the warning may be contained in a warning-field.
「警告:」 AS3気質修飾語拡張子は、警告の実装で定義された記述による警告のしるしを結合するのに使用されるべきです。 警告に関する詳細は警告分野に保管されるかもしれません。
For use in Internet EDI, the following "warning" "disposition- modifier" values are defined:
インターネットEDIにおける使用において、以下の「警告」「気質修飾語」値は定義されます:
"Warning: authentication-failed, processing continued"
「警告:」 「認証によって失敗されていて、処理は続きました」
An example of how the "disposition-field" would look when processing warnings, other than content, are detected is as follows:
内容を除いて、処理警告が検出されるとき、「気質分野」がどう見えるだろうかに関する例は以下の通りです:
EXAMPLE
Disposition: "disposition-mode"; processed/Warning:
authentication-failed, processing continued
例の気質: 「気質モード」。 処理されるか、または警告します: 認証によって失敗されていて、処理は続きました。
8. Public Key Certificate Handling
8. 公開鍵証明書取り扱い
In the near term, the exchange of public keys and certification of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, in addition to the mapping between EDI trading partner ID and FTP URL/URI. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages.
近いうちに、商事組合を確立するプロセスの一部として公開鍵の交換とこれらのキーの証明を扱わなければなりません。 UA、そして/または、EDIアプリケーション・インターフェースは暗号化に使用される公開鍵に関するデータベースかEDI貿易相手国IDとFTP URL/URIの間のマッピングに加えた署名を維持しなければなりません。 商事組合、安全なEDIメッセージシステムが貿易相手国の中で異なるかもしれないのを構成して、およびソフトウェアパッケージを確立するための手順。
X.509 certificates are REQUIRED. It is RECOMMENDED that trading partners self-certify each other if an agreed-upon certification authority is not used. This applicability statement does NOT require the use of a certification authority.
X.509証明書はREQUIREDです。 同意している証明権威が使用されていないなら貿易相手国が自己に互いを公認するのは、RECOMMENDEDです。 この適用性証明は証明権威の使用を必要としません。
The use of a certification authority is therefore OPTIONAL. Certificates may be self-signed. It is RECOMMENDED that when trading partners are using S/MIME, that they also exchange public key certificates using the recommendations specified in the S/MIME Version 3.1 Message Specification.
したがって、証明権威の使用はOPTIONALです。 証明書は自己に署名されるかもしれません。 それが貿易相手国であるときにS/MIMEを使用しているRECOMMENDEDである、また、推薦を使用することで公開鍵証明書を交換するのがS/MIMEでバージョン3.1Message Specificationを指定しました。
The message formats and S/MIME conformance requirements for certificate exchange are specified in this document. In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third-party authentication of trading partners, as well as attributes of the trading relationship.
証明書交換のためのメッセージ・フォーマットとS/MIME順応要件は本書では指定されます。 長期で、追加インターネット-EDI規格は商事組合を確立するプロセスを簡素化するために開発されるかもしれません、貿易相手国の第三者認証を含んでいて、取り引き関係の属性と同様に。
Harding & Scott Informational [Page 32] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[32ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
9. Security Considerations
9. セキュリティ問題
This entire document is concerned with secure transport of business- to-business data, and it considers both privacy and authentication issues.
ビジネスの安全な輸送が業務データであることでこの全体のドキュメントは関係があります、そして、それはプライバシーと認証問題の両方を考えます。
Extracted from S/MIME Version 2 Message Specification [21]:
S/MIMEバージョン2メッセージ仕様[21]から抽出される:
40-bit encryption is considered weak by most cryptographers.
Using weak cryptography in S/MIME offers little actual security
over sending plaintext. However, other features of S/MIME, such
as the specification of tripleDES and the ability to announce
stronger cryptographic capabilities to parties with whom you
communicate, allow senders to create messages that use strong
encryption. Using weak cryptography is never recommended unless
the only alternative is no cryptography. When feasible, sending
and receiving agents should inform senders and recipients the
relative cryptographic strength of messages.
40ビットの暗号化は弱いとほとんどの暗号使用者によって考えられます。 S/MIMEに弱い暗号を使用するのはほとんど送付平文の上に実際のセキュリティを提供しません。 しかしながら、tripleDESの仕様などのS/MIMEの他の特徴とあなたと交信するパーティーへの、より強い暗号の能力を発表する能力で、送付者は強い暗号化を使用するメッセージを作成できます。 弱い暗号を使用するのは唯一の選択肢が暗号であるなら決してお勧めではありません。 可能であるときに、送受信エージェントはメッセージの相対的な暗号の強さの送付者と受取人に知らせるべきです。
Extracted from S/MIME Version 3.1 Certificate Handling [11]:
S/MIMEバージョン3.1証明書取り扱[11]いから抽出される:
When processing certificates, there are many situations where the
processing might fail. Because the processing may be done by a
user agent, a security gateway, or other program, there is no
single way to handle such failures. Just because the methods to
handle the failures has not been listed, however, the reader
should not assume that they are not important. The opposite is
true: if a certificate is not provably valid and associated with
the message, the processing software should take immediate and
noticeable steps to inform the end user about it.
証明書を処理するとき、多くの状況が処理が失敗するかもしれないところにあります。 ユーザエージェント、セキュリティゲートウェイ、または他のプログラムで処理をするかもしれないので、そのような失敗を扱うどんなただ一つの方法もありません。 失敗を扱うメソッドが記載されているだけではないので、しかしながら、読者は、それらが重要でないと仮定するべきではありません。 正反対は本当です: 証明書がメッセージに有効であって、関連していて、証明可能に、処理ソフトウェアがそれに関してエンドユーザに知らせるために即座の、そして、めぼしい方法を採るはずであるということでないなら。
Some of the many places where signature and certificate checking
might fail include:
署名と証明書の照合が失敗するかもしれない多くの場所のいくつかは:
- no Internet mail addresses in a certificate matches the sender
of a message, if the certificate contains at least one mail
address
- no certificate chain leads to a trusted CA
- no ability to check the Certificate Revocation List (CRL) for a
certificate
- an invalid CRL was received
- the CRL being checked is expired
- the certificate is expired
- the certificate has been revoked
- メールが証明書で扱わないインターネットは全くメッセージの送付者に合っています、証明書が少なくとも1つの郵便の宛先を含んでいるなら--信じられたカリフォルニアへの証明書チェーン先導がありません--証明書がないかどうかCertificate Revocation List(CRL)をチェックする能力がありません--無効のCRLを受け取りました--チェックされるCRLは満期です--証明書は満期です--証明書は取り消されました。
Harding & Scott Informational [Page 33] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[33ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
There are certainly other instances where a certificate may be
invalid, and it is the responsibility of the processing software
to check them all thoroughly, and to decide what to do if the
check fails.
確かに、チェックが失敗するなら、他のインスタンスが証明書が無効であるかもしれなく、それらを皆、徹底的にチェックして、何をしたらよいかを決めるのが、処理ソフトウェアの責任であるところにあります。
The following certificate types MUST be supported.
With URL
Without URL
Self Certified
Certification Authority Certified
以下の証明書タイプをサポートしなければなりません。 公認された認証局が公認したURL自己のいないURLで
The complete certification chain MUST be included in all certificates. All certificate verifications MUST "chain to root". Additionally, the certificate hash should match the hash recomputed by the receiver.
すべての証明書に完全な証明チェーンを含まなければなりません。 すべての証明書検証が「根づくために、鎖を作らなければなりません」。 さらに、証明書ハッシュは受信機によって再計算されたハッシュに合うべきです。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[1]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
N.とN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996.
N.とN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は5を分けます」。 「順応評価基準と例」、RFC2049、11月1996日
[2] Crocker, D., "MIME Encapsulation of EDI Objects", RFC 1767,
March 1995.
[2] クロッカー、D.、「EDIオブジェクトのMIMEカプセル化」、RFC1767、1995年3月。
[3] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9,
RFC 959, October 1985.
[3] ポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、1985年10月。
[4] Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC 2228,
October 1997.
[4] ホロビッツとM.とS.ラント、「FTPセキュリティ拡大」、RFC2228、1997年10月。
[5] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure
Peer-to-Peer Business Data Interchange over the Internet", RFC
3335, September 2002.
[5] ハーディング、T.、ドラモンド、R.、およびC.Shih、「MIMEベースの安全なピアツーピア業務データはインターネットの上で交換します」、RFC3335、2002年9月。
[6] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[6] ハンセン、T.、およびG.ボードルイ(「メッセージ気質通知」、RFC3798)は2004がそうするかもしれません。
Harding & Scott Informational [Page 34] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[34ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
[7] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[7] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[8] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[8]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[9]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[10] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
[10]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」、RFC3851、2004年7月。
[11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850, July
2004.
[11]Ramsdell、B.、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書取り扱い」、RFC3850、2004年7月。
[12] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 3462,
January 2003.
[12] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポート満足しているタイプ」、RFC3462、2003年1月。
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[13] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[14] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
MESSAGES", STD 11, RFC 822, August 1982.
[14] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[15] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[15] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[16] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[16] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[17] Gutmann, P., "Compressed Data Content Type for Cryptographic
Message Syntax (CMS)", RFC 3274, June 2002.
[17] ガットマン、P.、「暗号のメッセージ構文(cm)のためのデータの圧縮された内容タイプ」、RFC3274、2002年6月。
[18] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, October
2005.
[18] フォード-ハッチンソン、P.、「TLSと共にFTPを保証します」、RFC4217、2005年10月。
[19] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[19] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Harding & Scott Informational [Page 35] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[35ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
10.2. Informative References
10.2. 有益な参照
[20] Harding, T., "Compressed Data for EDIINT", Work in Progress,
January 2007.
[20] ハーディング、T.、「EDIINTのための圧縮されたデータ」が進歩、2007年1月に働いています。
[21] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L.
Repka, "S/MIME Version 2 Message Specification", RFC 2311,
March 1998.
[21]Dusse、S.、ホフマン、P.、Ramsdell、B.、Lundblade、L.、およびL.Repka、「S/MIMEバージョン2メッセージ仕様」、RFC2311(1998年3月)。
[22] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[22] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[23] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[23] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
Harding & Scott Informational [Page 36] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[36ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
Appendix A. Message Examples
付録A.メッセージの例
NOTE: All examples are provided as an illustration only, and are not
considered part of the protocol specification. If an example
conflicts with the protocol definitions specified above or with
that of a referenced RFC, the example is wrong.
以下に注意してください。 すべての例が、イラストだけとして前提とされて、プロトコル仕様の一部であると考えられるというわけではありません。 例がものの上、または、参照をつけられたRFCのもので指定されるプロトコル定義と闘争するなら、例は間違っています。
A.1. Signed Message Requesting a Signed Receipt
A.1。 サインされた領収書を要求するサインされたメッセージ
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-Version: 1.0
AS3-From: cyclone
AS3-To: "trading partner"
Message-Id: <200207310834482A70BF63@host.com>
Disposition-Notification-To: ftp://host:port/mdnbox
Disposition-Notification-Options: signed-receipt-
protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as3BouNdary1as3";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 3075
日付: グリニッジ標準時2002年7月31日水曜日13時34分50秒のAS3-バージョン: 1.0 AS3-From: 低気圧、AS3-To: 「貿易相手国」Message-イド: <200207310834482A70BF63@host.com>気質通知To: ftp://host:port/mdnbox 気質通知オプション: サインされた領収書プロトコル=任意である、pkcs7-署名。 サインされた領収書-micalgは任意のsha1コンテントタイプと等しいです: 複合かサインされる。 境界は"as3BouNdary1as3""と等しいです。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1 Content-長さ: 3075
--as3BouNdary1as3 Content-Type: application/edi-x12 Content-Disposition: Attachment; filename=rfc1767.dat
--as3BouNdary1as3コンテントタイプ: edi-x12 Contentアプリケーション/気質: 付属。 ファイル名=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
[ISA…EDI変更用データ… IEA]
--as3BouNdary1as3 Content-Type: application/pkcs7-signature
--as3BouNdary1as3コンテントタイプ: pkcs7アプリケーション/署名
[omitted binary pkcs7 signature data]
--as3BouNdary1as3--
[省略された2進のpkcs7署名データ]--as3BouNdary1as3--
A.2. MDN for Message A.1 Above
A.2。 上のメッセージA.1のためのMDN
Date: Wed, 31 Jul 2002 13:34:50 GMT
AS3-From: "trading partner"
AS3-To: cyclone
AS3-Version: 1.0
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Content-Length: 1024
日付: グリニッジ標準時2002年7月31日水曜日13時34分50秒、AS3-From: 「貿易相手国」AS3-To: 低気圧AS3-バージョン: 1.0Message ID: <709700825.1028122454671.JavaMail@ediXchange>コンテントタイプ: 複合かサインされる。 micalg=sha1。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 「境界=」----=_「パート_57_648441049.1028122454671」コンテンツの長さ: 1024
------=_Part_57_648441049.1028122454671
------=_パート_57_648441049.1028122454671
Harding & Scott Informational [Page 37] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[37ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
& Content-Type: multipart/report; & Report-Type=disposition-notification; & boundary="----=_Part_56_1672293592.1028122454656" & &------=_Part_56_1672293592.1028122454656 &Content-Type: text/plain &Content-Transfer-Encoding: 7bit & &MDN for - & Message ID: <200207310834482A70BF63@host.com> & From: cyclone & To: "trading partner" & Received on: 2002-07-31 at 09:34:14 (EDT) & Status: processed & Comment: This is not a guarantee that the message has been & completely processed or understood by the receiving translator & &------=_Part_56_1672293592.1028122454656 & Content-Type: message/disposition-notification & Content-Transfer-Encoding: 7bit & & Reporting-UA: AS3 Server & Original-Recipient: rfc822; "trading partner" & Final-Recipient: rfc822; "trading partner" & Original-Message-ID: <200207310834482A70BF63@host.com> & Received-content-MIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=, sha1 & Disposition: automatic-action/MDN-sent-automatically; processed & &------=_Part_56_1672293592.1028122454656--
コンテントタイプ: 複合/レポート。 気質レポートタイプ=通知。 「境界=」----=_「パート_56_1672293592.1028122454656」------=__56_1672293592.1028122454656とコンテントタイプを分けてください: テキスト/明瞭でContent-転送をコード化しています: 7に噛み付いた、MDN、--Message ID: <200207310834482A70BF63@host.com>とFrom: 低気圧とTo: 「貿易相手国」と以下のReceived (東部夏時間)09:34:14の2002年7月31日と状態: 処理、Comment: これはメッセージが受信翻訳者によって完全にいて、処理されるか、または理解されているという保証ではありません。------=__56_1672293592.1028122454656とコンテントタイプを分けてください: 気質メッセージ/通知とContent転送コード化: 7に噛み付いた、UAです報告している: AS3サーバとオリジナルの受取人: rfc822。 「貿易相手国」とFinal-受取人: rfc822。 「貿易相手国」とOriginal Message ID: <200207310834482A70BF63@host.com>と容認された満足しているMIC: 7v7F++fQaNB1sVLFtMRp+dF+eG4=、sha1、およびDisposition: MDNは自動的に自動動作/発信していました。 処理------=__56_1672293592.1028122454656を分けてください--
------=_Part_57_648441049.1028122454671
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
------=__57_648441049.1028122454671コンテントタイプを分けてください: pkcs7アプリケーション/署名。 =smime.p7s Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7s
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA ------=_Part_57_648441049.1028122454671--
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQ cp24hMJNbxDKHnlB9jTiQzLwSwo+/90Pc87x+Sc6EpFSUYWGAAAAAAAA------=__57_648441049.1028122454671を分けてください--
Notes:
注意:
1. The lines proceeded with "&" are what the signature is
calculated over.
1. “&"で続く線は署名が何に関して計算されるかということです。
2. For details on how to prepare the multipart/signed with
protocol="application/pkcs7-signature", see RFC 3851 [10],
"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version
3.1 Message Specification".
2. どう複合の、または、プロトコル=を契約された「pkcs7アプリケーション/署名」を準備するかに関する詳細に関しては、RFC3851[10]、「安全な/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様」を見てください。
Harding & Scott Informational [Page 38] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[38ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
3. Note that the textual first body part of the multipart/report
can be used to include a more detailed explanation of the error
conditions reported by the disposition headers. The first body
part of the multipart/report, when used in this way, allows a
person to better diagnose a problem in detail.
3. 気質ヘッダーによって報告されたエラー条件の、より詳細な説明を含むのに複合/レポートの原文の最初の身体の部分を使用できることに注意してください。 複合/レポートの最初の身体の部分で、このように使用されると、人は詳細に問題をより診断できます。
4. As specified by RFC 3462 [12], returning the original or
portions of the original message in the third body part of the
multipart/report is not required. This is an optional body
part. However, it is RECOMMENDED that this body part be
omitted or left blank.
4. オリジナルを返して、RFC3462[12]で指定するか、または必要でないように複合/の3番目の身体の部分のオリジナルのメッセージの部分が、報告する。 これは任意の身体の部分です。 しかしながら、この身体の部分が省略されるか、または空白のままにされるのが、RECOMMENDEDです。
Authors' Addresses
作者のアドレス
Terry Harding Axway 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
テリーハーディングAxway8388E.ハートフォードドライブ、Suite100スコッツデール、アリゾナ85255米国
EMail: tharding@us.axway.com
メール: tharding@us.axway.com
Richard Scott Axway 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
リチャードスコットAxway8388E.ハートフォードドライブ、Suite100スコッツデール、アリゾナ85255米国
EMail: rscott@us.axway.com
メール: rscott@us.axway.com
Harding & Scott Informational [Page 39] RFC 4823 AS3 Data Interchange for EDIINT April 2007
ハーディングとスコット情報[39ページ]のRFC4823AS3Dataは2007年4月にEDIINTのために交換されます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Harding & Scott Informational [Page 40]
ハーディングとスコットInformationalです。[40ページ]
一覧
スポンサーリンク
