RFC4130 日本語訳
4130 MIME-Based Secure Peer-to-Peer Business Data Interchange UsingHTTP, Applicability Statement 2 (AS2). D. Moberg, R. Drummond. July 2005. (Format: TXT=99857 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Moberg
Request for Comments: 4130 Cyclone Commerce
Category: Standards Track R. Drummond
Drummond Group Inc.
July 2005
コメントを求めるワーキンググループD.モーベリの要求をネットワークでつないでください: 4130年の低気圧商業カテゴリ: 標準化過程R.ドラモンドドラモンドグループ株式会社2005年7月
MIME-Based Secure Peer-to-Peer
Business Data Interchange Using HTTP,
Applicability Statement 2 (AS2)
HTTP、適用性証明2を使用するMIMEベースの安全なピアツーピア業務データ置き換え(AS2)
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document provides an applicability statement (RFC 2026, Section 3.2) that describes how to exchange structured business data securely using the HTTP transfer protocol, instead of SMTP; the applicability statement for SMTP is found in RFC 3335. Structured business data may be XML; Electronic Data Interchange (EDI) in either the American National Standards Committee (ANSI) X12 format or the UN Electronic Data Interchange for Administration, Commerce, and Transport (UN/EDIFACT) format; or other structured data formats. The data is packaged using standard MIME structures. Authentication and data confidentiality are obtained by using Cryptographic Message Syntax with S/MIME security body parts. Authenticated acknowledgements make use of multipart/signed Message Disposition Notification (MDN) responses to the original HTTP message. This applicability statement is informally referred to as "AS2" because it is the second applicability statement, produced after "AS1", RFC 3335.
このドキュメントはHTTP転送プロトコルを使用することでしっかりと構造化された業務データを交換する方法を説明する適用性証明(RFC2026、セクション3.2)を提供します、SMTPの代わりに。 SMTPのための適用性証明はRFC3335で見つけられます。 構造化された業務データはXMLであるかもしれません。 政権、Commerce、およびTransport(国連/EDIFACT)形式のための規格委員会(ANSI)X12形式か国連Electronic Data Interchangeのどちらかの電子Data Interchange(EDI)。 または、他の構造化されたデータ形式。 データは、標準のMIME構造を使用することでパッケージされます。 S/MIMEセキュリティ身体の部分があるCryptographic Message Syntaxを使用することによって、認証とデータの機密性を得ます。 認証された承認はオリジナルのHTTPメッセージへの複合の、または、署名しているMessage Disposition Notification(MDN)応答を利用します。 この適用性証明が非公式に呼ばれる、「AS2"、それは「AS1"(RFC3335)」の後に製作された2番目の適用性証明です。
Moberg & Drummond Standards Track [Page 1] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[1ページ]RFC4130AS2
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicable RFCs ............................................3
1.2. Terms ......................................................3
2. Overview ........................................................5
2.1. Overall Operation ..........................................5
2.2. Purpose of a Security Guideline for MIME EDI ...............5
2.3. Definitions ................................................5
2.4. Assumptions ................................................7
3. Referenced RFCs and Their Contributions .........................9
3.1. RFC 2616 HTTP v1.1 [3] .....................................9
3.2. RFC 1847 MIME Security Multiparts [6] ......................9
3.3. RFC 3462 Multipart/Report [8] .............................10
3.4. RFC 1767 EDI Content [2] ..................................10
3.5. RFC 2045, 2046, and 2049 MIME [1] .........................10
3.6. RFC 3798 Message Disposition Notification [5] .............10
3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message
Specifications and Cryptographic Message Syntax (CMS) [7]..10
3.8. RFC 3023 XML Media Types [10] .............................10
4. Structure of an AS2 Message ....................................10
4.1. Introduction ..............................................10
4.2. Structure of an Internet EDI MIME Message .................11
5. HTTP Considerations ............................................12
5.1. Sending EDI in HTTP POST Requests .........................12
5.2. Unused MIME Headers and Operations ........................12
5.3. Modification of MIME or Other Headers or Parameters Used ..13
5.4. HTTP Response Status Codes ................................14
5.5. HTTP Error Recovery .......................................14
6. Additional AS2-Specific HTTP Headers ...........................14
6.1. AS2 Version Header ........................................15
6.2. AS2 System Identifiers ....................................15
7. Structure and Processing of an MDN Message .....................17
7.1. Introduction ..............................................17
7.2. Synchronous and Asynchronous MDNs .........................19
7.3. Requesting a Signed Receipt ...............................21
7.4. MDN Format and Values .....................................25
7.5. Disposition Mode, Type, and Modifier ......................30
7.6. Receipt Reply Considerations in an HTTP POST ..............35
8. Public Key Certificate Handling ................................35
9. Security Considerations ........................................36
9.1. NRR Cautions ..............................................37
9.2. HTTPS Remark ..............................................38
9.3. Replay Remark .............................................39
10. IANA Considerations ...........................................39
10.1. Registration ............................................39
11. Acknowledgements ..............................................40
12. References ....................................................40
1. 序論…3 1.1. 適切なRFCs…3 1.2. 用語…3 2. 概要…5 2.1. 総合的な操作…5 2.2. MIME EDIのための安全ガイドラインの目的…5 2.3. 定義…5 2.4. 仮定…7 3. RFCsと彼らの貢献に、参照をつけます…9 3.1. RFC2616HTTP v1.1[3]…9 3.2. RFC1847はセキュリティMultiparts[6]をまねます…9 3.3. RFC3462複合/レポート[8]…10 3.4. RFC1767EDI内容[2]…10 3.5. RFC2045、2046、および2049は[1]をまねます…10 3.6. RFC3798メッセージ気質通知[5]…10 3.7. RFC3851と3852秒間/MIMEのバージョン3.1メッセージ仕様と暗号のメッセージ構文(cm。)[7]10 3.8. RFC3023XMLメディアは[10]をタイプします…10 4. AS2メッセージの構造…10 4.1. 序論…10 4.2. インターネットエディMIMEメッセージの構造…11 5. HTTP問題…12 5.1. HTTPにおける送付EDIは要求を掲示します…12 5.2. 未使用のMIMEヘッダーと操作…12 5.3. MIME、他のヘッダーまたは使用されるパラメタの変更。13 5.4. HTTP応答ステータスコード…14 5.5. HTTPエラー回復…14 6. 追加AS2特有のHTTPヘッダ…14 6.1. AS2バージョンヘッダー…15 6.2. AS2システム識別子…15 7. MDNメッセージを構造化して、処理してください…17 7.1. 序論…17 7.2. 同時の、そして、非同期なMDNs…19 7.3. 署名している領収書を要求します…21 7.4. MDN形式と値…25 7.5. 気質モード、タイプ、および修飾語…30 7.6. HTTPポストによる回答問題を領収書を出させてください…35 8. 公開鍵証明書取り扱い…35 9. セキュリティ問題…36 9.1. NRR警告…37 9.2. HTTPS注意…38 9.3. 注意を再演してください…39 10. IANA問題…39 10.1. 登録…39 11. 承認…40 12. 参照…40
Moberg & Drummond Standards Track [Page 2] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[2ページ]RFC4130AS2
12.1. Normative References ....................................40
12.2. Informative References ..................................41
Appendix A: Message Examples ......................................42
12.1. 標準の参照…40 12.2. 有益な参照…41 付録A: メッセージの例…42
1. Introduction
1. 序論
1.1. Applicable RFCs
1.1. 適切なRFCs
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 [4]. This document expands on RFC 1767 to specify a comprehensive set of data security features, specifically data confidentiality, data integrity/authenticity, non-repudiation of origin, and non-repudiation of receipt over HTTP. This document also recognizes contemporary RFCs and is attempting to "re-invent" as little as possible. Although this document focuses on EDI data, any other data types describable in a MIME format are also supported.
インターネットEDIへの前の作業は、EDIデータ[2]にMIME content typeを指定して、安全なEC/EDIが輸送であるとサポートするためにこの仕事を広げるのはSMTP[4]の上に焦点を合わせました。 このドキュメントはHTTPの上で領収書の包括的なセットのデータ機密保護機能、明確にデータの機密性、データ保全/信憑性、発生源の非拒否、および非拒否を指定するRFC1767について詳述します。 このドキュメントも、現代のRFCsを認めて、できるだけ少ししか「再発明しないこと」を試みています。 このドキュメントはEDIデータに焦点を合わせますが、また、MIME形式で説明可能ないかなる他のデータ型もサポートされます。
Internet MIME-based EDI can be accomplished by using and complying with the following RFCs:
以下のRFCsを使用して、従うことによって、インターネットのMIMEベースのEDIを達成できます:
o RFC 2616 Hyper Text Transfer Protocol
o RFC 1767 EDI Content Type
o RFC 3023 XML Media Types
o RFC 1847 Security Multiparts for MIME
o RFC 3462 Multipart/Report
o RFC 2045 to 2049 MIME RFCs
o RFC 3798 Message Disposition Notification
o RFC 3851, 3852 S/MIME v3.1 Specification
o MIME○RFC3462Multipart/レポートo RFC2045年から2049MIME RFCs o RFC3798Message Disposition Notification o RFC3851、3852秒間/MIMEのv3.1 SpecificationのためのRFC2616Hyper Text Transferプロトコルo RFC1767EDI Content Type o RFC3023XMLメディアTypes o RFC1847Security Multiparts
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 [13].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[13]で説明されるように本書では解釈されることであるべきですか?
1.2. Terms
1.2. 用語
AS2: Applicability Statement 2 (this document); see RFC 2026
[11], Section 3.2
AS2: 適用性Statement2(このドキュメント)。 RFC2026[11]、セクション3.2を見てください。
EDI: Electronic Data Interchange
エディ: 電子データ交換
EC: Business-to-Business Electronic Commerce
EC: 企業対企業の電子商取引電子通商
B2B: Business to Business
B2B: 企業対企業の電子商取引
Moberg & Drummond Standards Track [Page 3] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[3ページ]RFC4130AS2
Receipt: The functional message that is sent from a receiver to a
sender to acknowledge receipt of an EDI/EC interchange.
This message may be either synchronous or asynchronous in
nature.
領収書: EDI/ECの置き換えの領収書を受け取ったことを知らせるために受信機から送付者に送られる機能的なメッセージ。 このメッセージは、同時であるか、または現実に非同期であるかもしれません。
Signed Receipt: A receipt with a digital signature.
署名している領収書: デジタル署名がある領収書。
Synchronous Receipt: A receipt returned to the sender during the same
HTTP session as the sender's original message.
同期領収書: 領収書は送付者のオリジナルのメッセージと同じHTTPセッションの間、送付者に戻りました。
Asynchronous Receipt: A receipt returned to the sender on a different
communication session than the sender's original message
session.
非同期な領収書: 領収書は送付者のオリジナルのメッセージセッションと異なったコミュニケーションセッションのときに送付者に戻りました。
Message Disposition Notification (MDN): The Internet messaging format
used to convey a receipt. This term is used interchangeably
with receipt. A MDN is a receipt.
メッセージ気質通知(MDN): インターネットメッセージング形式は以前はよく領収書を伝えていました。 今期は領収書で互換性を持って使用されます。 MDNは領収書です。
Non-repudiation of receipt (NRR): A "legal event" that occurs when
the original sender of an signed EDI/EC interchange has
verified the signed receipt coming back from the receiver.
The receipt contains data identifying the original message
for which it is a receipt, including the message-ID and a
cryptographic hash (MIC). The original sender must retain
suitable records providing evidence concerning the message
content, its message-ID, and its hash value. The original
sender verifies that the retained hash value is the same as
the digest of the original message, as reported in the
signed receipt. NRR is not considered a technical message,
but instead is thought of as an outcome of possessing
relevant evidence.
領収書(NRR)の非拒否: 署名しているEDI/ECの置き換えの元の送り主であるときに起こる「法的なイベント」は受信機から戻る署名している領収書を確かめました。領収書はそれが領収書であるオリジナルのメッセージを特定するデータを含んでいます、メッセージIDと暗号のハッシュ(MIC)を含んでいて。 元の送り主はメッセージ内容、メッセージID、およびそのハッシュ値に関して証拠を提供する適当な記録を保有しなければなりません。 元の送り主は、保有されたハッシュ値がオリジナルのメッセージのダイジェストと同じであることを確かめます、署名している領収書で報告されるように。 NRRは技術的なメッセージであることは考えられませんが、代わりに関連証拠を持つ結果として考えられます。
S/MIME: A format and protocol for adding cryptographic signature
and/or encryption services to Internet MIME messages.
S/MIME: 暗号の署名を加えるための形式とプロトコル、そして/または、インターネットMIMEメッセージに対する暗号化サービス。
Cryptographic Message Syntax (CMS): An encapsulation syntax used to
digitally sign, digest, authenticate, or encrypt arbitrary
messages.
暗号のメッセージ構文(cm): カプセル化構文は、任意のメッセージをデジタルに署名するか、読みこなすか、認証するか、または以前はよく暗号化していました。
SHA-1: A secure, one-way hash algorithm used in conjunction with
digital signature. This is the recommended algorithm for
AS2.
SHA-1: 安全で、一方向のハッシュアルゴリズムはデジタルに関連して署名を使用しました。 これはAS2におけるお勧めのアルゴリズムです。
MD5: A secure, one-way hash algorithm used in conjunction with
digital signature. This algorithm is allowed in AS2.
MD5: 安全で、一方向のハッシュアルゴリズムはデジタルに関連して署名を使用しました。 このアルゴリズムはAS2に許容されています。
Moberg & Drummond Standards Track [Page 4] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[4ページ]RFC4130AS2
MIC: The message integrity check (MIC), also called the message
digest, is the digest output of the hash algorithm used by
the digital signature. The digital signature is computed
over the MIC.
ミック: また、メッセージダイジェストと呼ばれたメッセージの保全チェック(MIC)はデジタル署名で使用されるハッシュアルゴリズムのダイジェスト出力です。 デジタル署名はMICの上で計算されます。
User Agent (UA): The application that handles and processes the AS2
request.
ユーザエージェント(UA): AS2要求を処理して、処理するアプリケーション。
2. Overview
2. 概要
2.1. Overall Operation
2.1. 総合的な操作
A HTTP POST operation [3] is used to send appropriately packaged EDI, XML, or other business data. The Request-URI ([3], Section 9.5) identifies a process for unpacking and handling the message data and for generating a reply for the client that contains a message disposition acknowledgement (MDN), either signed or unsigned. The MDN is either returned in the HTTP response message body or by a new HTTP POST operation to a URL for the original sender.
HTTPポストの操作[3]は、適切にパッケージされたEDI、XML、または他の業務データを送るのに使用されます。 Request-URI([3]、セクション9.5) メッセージデータをアンパックして、扱って、署名しているか、未署名のメッセージ気質承認(MDN)を含むクライアントのために回答を生成するためにプロセスを特定します。 MDNがHTTP応答メッセージ本体で返すか、元の送り主のためのURLへの新しいHTTPポストの操作のどちらかであります。
This request/reply transactional interchange can provide secure, reliable, and authenticated transport for EDI or other business data using HTTP as a transfer protocol.
取引の置き換えがEDIのための安全で、信頼できて、認証された輸送を提供できるこの要求/回答か転送プロトコルとしてHTTPを使用する他の業務データ。
The security protocols and structures used also support auditable records of these document data transmissions, acknowledgements, and authentication.
また、セキュリティプロトコルと構造はこれらのドキュメントデータ伝送、承認、および認証に関するサポート監査可能記録を使用しました。
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 EC user agents, invoking some or all of the commonly expected security features. This document is also NOT limited to strict EDI use; it applies to any electronic commerce application for which business data needs to be exchanged over the Internet in a secure manner.
これらの仕様の目的はB2B ECのユーザエージェントの間の相互運用性を確実にすることです、一般的に予想されたセキュリティ機能のいくつかかすべてを呼び出して。 また、このドキュメントは厳しいEDI使用に制限されません。 それは業務データが安全な方法でインターネットの上と交換される必要があるどんな電子商取引アプリケーションにも適用されます。
2.3. Definitions
2.3. 定義
2.3.1. The Secure Transmission Loop
2.3.1. 安全なトランスミッション輪
This document's focus is on the formats and protocols for exchanging EDI/EC content securely in the Internet's HTTP environment.
このドキュメントの焦点がインターネットのHTTP環境でしっかりとEDI/EC内容を交換するための形式とプロトコルにあります。
In the "secure transmission loop" for EDI/EC, one organization sends a signed and encrypted EDI/EC interchange to another organization and
そしてEDI/ECのための「安全なトランスミッション輪」では1つの組織が署名していて暗号化されたEDI/ECの置き換えを別の組織に送る。
Moberg & Drummond Standards Track [Page 5] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[5ページ]RFC4130AS2
requests a signed receipt, and later the receiving organization sends this signed receipt back to the sending organization. In other words, the following transpires:
要求aは領収書に署名しました、そして、後で、受信組織は領収書であると署名されるこれを送出し機関に送り返します。 言い換えれば、以下は蒸散します:
o The organization sending EDI/EC data signs and encrypts the
data using S/MIME. In addition, the message will request that
a signed receipt be returned to the sender. To support NRR,
the original sender retains records of the message, message-ID,
and digest (MIC) value.
o 組織送付EDI/ECデータは、S/MIMEを使用することでデータに署名して、暗号化します。 さらに、メッセージは、署名している領収書が送付者に返されるよう要求するでしょう。 NRRをサポートするために、元の送り主はメッセージ、メッセージID、およびダイジェスト(MIC)価値に関する記録を保有します。
o The receiving organization decrypts the message and verifies
the signature, resulting in verified integrity of the data and
authenticity of the sender.
o 受信組織は、メッセージを解読して、署名について確かめます、データの確かめられた保全と送付者の信憑性をもたらして。
o The receiving organization then returns a signed receipt using
the HTTP reply body or a separate HTTP POST operation to the
sending organization in the form of a signed message
disposition notification. This signed receipt will contain the
hash of the received message, allowing the original sender to
have evidence that the received message was authenticated
and/or decrypted properly by the receiver.
o 次に組織が署名しているメッセージ気質通知の形でHTTP回答本体か別々のHTTPポストの操作を送出し機関に使用する署名している領収書を返す受信。 領収書であると署名されるこれは受信されたメッセージのハッシュを含むでしょう、元の送り主には受信されたメッセージが受信機によって適切に認証される、そして/または、解読されたという証拠があるのを許容して。
The above describes functionality that, if implemented, will satisfy all security requirements and implement non-repudiation of receipt for the exchange. This specification, however, leaves full flexibility for users to decide the degree to which they want to deploy those security features with their trading partners.
上記は実装されるなら、交換のためにすべてのセキュリティ要件を満たして、領収書の非拒否を実装する機能性について説明します。 しかしながら、この仕様は、彼らが自分達の貿易相手国と共にそれらのセキュリティ機能を配布したがっている度合いについて決めるために完全な柔軟性をユーザに残します。
2.3.2. Definition of Receipts
2.3.2. 領収書の定義
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 first term is used if the acknowledgment is for an interchange resulting in a receipt that is NOT signed. The second term is used if the acknowledgement is for an interchange resulting in a receipt that IS signed.
EDI/ECの置き換えの配送を承諾するための機能的活動とメッセージの両方に使用される用語は、「領収書」であるか「領収書に署名しました」。 前期は承認が署名されない領収書をもたらす置き換えのためのものであるなら使用されています。 2番目の期間は承認が署名される領収書をもたらす置き換えのためのものであるなら使用されています。
The term non-repudiation of receipt (NRR) is often used in combination with receipts. NRR refers to a legal event that occurs only when the original sender of an interchange has verified the signed receipt coming back from recipient of the message, and has verified that the returned MIC value inside the MDN matches the previously recorded value for the original message.
領収書(NRR)の用語非拒否は領収書と組み合わせてしばしば使用されます。 NRRは置き換えの元の送り主が、メッセージの受取人から戻る署名している領収書を確かめて、MDNの中の返されたMIC値がオリジナルのメッセージのための以前に記録された値に合っていることを確かめたときだけ起こる法的なイベントについて言及します。
NRR is best established when both the original message and the receipt make use of digital signatures. See the Security Considerations section for some cautions regarding NRR.
オリジナルのメッセージと領収書の両方がデジタル署名を利用するとき、NRRは最もよく確立しています。 いくつかの警告に関してNRRに関してSecurity Considerations部を見てください。
Moberg & Drummond Standards Track [Page 6] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[6ページ]RFC4130AS2
For information on how to format and process receipts in AS2, refer to Section 7.
AS2の領収書をフォーマットして、どう処理するかの情報について、セクション7を参照してください。
2.4. Assumptions
2.4. 仮定
2.4.1. EDI/EC Process Assumptions
2.4.1. EDI/ECのプロセス仮定
o Encrypted object is an EDI/EC Interchange.
o 暗号化されたオブジェクトはEDI/EC Interchangeです。
This specification assumes that a typical EDI/EC interchange is the lowest-level object that will be subject to security services.
この仕様は、典型的なEDI/ECの置き換えがセキュリティー・サービスを受けることがある最も低いレベルオブジェクトであると仮定します。
Specifically, in EDI ANSI X12, this means that anything between and including, segments ISA and IEA is secured. In EDIFACT, this means that anything between, and including, segments UNA/UNB and UNZ is secured. In other words, the EDI/EC interchanges including envelope segments remain intact and unreadable during fully secured transport.
明確にEDI ANSI X12のこれはその何でも意味して、包含、セグメントISA、およびIEAは機密保護されます。 EDIFACTでは、この手段のセグメントの間のその何、包含、UNA/UNB、およびUNZでも固定されています。 言い換えれば、封筒セグメントを含むEDI/ECの置き換えは完全に機密保護している輸送の間、完全であって、読みにくいままで残っています。
o EDI envelope headers are encrypted.
o EDI封筒ヘッダーは暗号化されています。
Congruent with the above statement, EDI envelope headers are NOT visible in the MIME package.
上の声明について一致していて、EDI封筒ヘッダーはMIMEパッケージの中に目に見えません。
In order to optimize routing from existing commercial EDI networks (called Value Added Networks or VANs) to the Internet, it would be useful to make some envelope information visible. This specification, however, provides no support for this optimization.
既存の商業EDIネットワーク(付加価値通信網かVANと呼ばれる)からインターネットまでルーティングを最適化するために、何らかの封筒情報を目に見えるようにするのは役に立つでしょう。 しかしながら、この仕様はこの最適化のサポートを全く提供しません。
o X12.58 and UN/EDIFACT Security Considerations
o 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に供給します。 この仕様はこれらの機密保護基準の使用か非使用を決めません。 それらは、この仕様でともに完全に互換性があって、もっとも、ことによると余分です。
2.4.2. Flexibility Assumptions
2.4.2. 柔軟性仮定
o Encrypted or Unencrypted Data
o 暗号化されるかUnencryptedデータ
This specification allows for EDI/EC message exchange in which the EDI/EC data can be either unprotected or protected by means of encryption.
この仕様は、暗号化EDI/ECデータが保護がない場合があるEDI/EC交換処理のために許容したか、または保護されました。
Moberg & Drummond Standards Track [Page 7] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[7ページ]RFC4130AS2
o Signed or Unsigned Data
o 署名しているか未署名のデータ
This specification allows for EDI/EC message exchange with or without digital signature of the original EDI transmission.
この仕様はオリジナルのEDIトランスミッションのデジタル署名のあるなしにかかわらずEDI/EC交換処理を考慮します。
o Optional Use of Receipt
o 領収書の任意の使用
This specification allows for EDI/EC message transmission with or without a request for receipt notification. A signed receipt notification is requested; however, a MIC value is REQUIRED as part of the returned receipt, except when a severe error condition prevents computation of the digest value. In the exceptional case, a signed receipt should be returned with an error message that effectively explains why the MIC is absent.
この仕様は領収書通知に関する要求のあるなしにかかわらずEDI/ECのメッセージ送信を考慮します。 署名している領収書通知は要求されています。 しかしながら、MIC値は返された領収書の一部としてREQUIREDです、厳しいエラー条件がダイジェスト価値の計算を防ぐ時を除いて。 例外的な場合では、事実上、MICがなぜ欠けているかがわかるエラーメッセージと共に署名している領収書を返すべきです。
o Use of Synchronous or Asynchronous Receipts
o 同時の、または、非同期な領収書の使用
In addition to a receipt request, this specification allows the specification of the type of receipt that should be returned. It supports synchronous or asynchronous receipts in the MDN format specified in Section 7 of this document.
領収書要求に加えて、この仕様は返されるべきである領収書のタイプの仕様を許容します。 それはこのドキュメントのセクション7で指定されたMDN形式で同時の、または、非同期な領収書を支えます。
o Security Formatting
o セキュリティ形式
This specification relies on the guidelines set forth in RFC 3851/3852 [7] "S/MIME Version 3.1 Message Specification; Cryptographic Message Syntax".
この仕様はRFC3851/3852[7]「S/MIMEバージョン3.1メッセージ仕様」で先へ設定されたガイドラインを当てにします。 「暗号のメッセージ構文。」
o Hash Function, Message Digest Choices
o ハッシュ関数、メッセージダイジェスト選択
When a signature is used, it is RECOMMENDED that the SHA-1 hash algorithm be used for all outgoing messages, and that both MD5 and SHA-1 be supported for incoming messages.
署名が使用されているとき、SHA-1ハッシュアルゴリズムがすべての送信されるメッセージに使用されて、MD5とSHA-1の両方が入力メッセージのためにサポートされるのは、RECOMMENDEDです。
o Permutation Summary
o 順列概要
In summary, the following twelve security permutations are possible in any given trading relationship:
概要では、取り引き関係を考えて、以下の12のセキュリティ順列がいずれでも可能です:
1. Sender sends un-encrypted data and does NOT request a receipt.
1. 送付者は、不-暗号化されたデータを送って、領収書を要求しません。
2. Sender sends un-encrypted data and requests an unsigned receipt.
Receiver sends back the unsigned receipt.
2. 送付者は、不-暗号化されたデータを送って、未署名の領収書を要求します。 受信機は未署名の領収書を返送します。
3. Sender sends un-encrypted data and requests a signed receipt.
Receiver sends back the signed receipt.
3. 送付者は、不-暗号化されたデータを送って、署名している領収書を要求します。 受信機は署名している領収書を返送します。
4. Sender sends encrypted data and does NOT request a receipt.
4. 送付者は、暗号化されたデータを送って、領収書を要求しません。
Moberg & Drummond Standards Track [Page 8] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[8ページ]RFC4130AS2
5. Sender sends encrypted data and requests an unsigned receipt.
Receiver sends back the unsigned receipt.
5. 送付者は、暗号化されたデータを送って、未署名の領収書を要求します。 受信機は未署名の領収書を返送します。
6. Sender sends encrypted data and requests a signed receipt.
Receiver sends back the signed receipt.
6. 送付者は、暗号化されたデータを送って、署名している領収書を要求します。 受信機は署名している領収書を返送します。
7. Sender sends signed data and does NOT request a signed or
unsigned receipt.
7. 送付者は、署名しているデータを送って、署名しているか未署名の領収書を要求しません。
8. Sender sends signed data and requests an unsigned receipt.
Receiver sends back the unsigned receipt.
8. 送付者は、署名しているデータを送って、未署名の領収書を要求します。 受信機は未署名の領収書を返送します。
9. Sender sends signed data and requests a signed receipt.
Receiver sends back the signed receipt.
9. 送付者は、署名しているデータを送って、署名している領収書を要求します。 受信機は署名している領収書を返送します。
10. Sender sends encrypted and signed data and does NOT request a
signed or unsigned receipt.
10. 送付者は、暗号化されて署名しているデータを送って、署名しているか未署名の領収書を要求しません。
11. Sender sends encrypted and signed data and requests an unsigned
receipt. Receiver sends back the unsigned receipt.
11. 送付者は、暗号化されて署名しているデータを送って、未署名の領収書を要求します。 受信機は未署名の領収書を返送します。
12. Sender sends encrypted and signed data and requests a signed
receipt. Receiver sends back the signed receipt.
12. 送付者は、暗号化されて署名しているデータを送って、署名している領収書を要求します。 受信機は署名している領収書を返送します。
Users can choose any of the twelve possibilities, but only the last example (12), when a signed receipt is requested, offers the whole suite of security features described in Section 2.3.1, "The Secure Transmission Loop".
ユーザは12の可能性のどれかを選ぶことができますが、署名している領収書が要求されているとき、最後の例(12)だけがセクション2.3.1で説明された、セキュリティ機能の全体のスイート、「安全なトランスミッション輪」を提供します。
Additionally, the receipts discussed above may be either synchronous or asynchronous depending on the type requested. The use of either the synchronous or asynchronous receipts does not change the nature of the secure transmission loop in support of NRR.
要求されたタイプに頼っていて、上で議論した領収書は、さらに、同時であるか、または非同期であるかもしれません。 同時の、または、非同期な領収書の使用はNRRを支持して安全なトランスミッション輪の本質を変えません。
3. Referenced RFCs and Their Contributions
3. 参照をつけられたRFCsと彼らの貢献
3.1. RFC 2616 HTTP v1.1 [3]
3.1. RFC2616HTTP v1.1[3]
This document specifies how data is transferred using HTTP.
このドキュメントはデータがHTTPを使用することでどうわたっているかを指定します。
3.2. RFC 1847 MIME Security Multiparts [6]
3.2. RFC1847MIMEセキュリティMultiparts[6]
This document defines security multipart for MIME: multipart/encrypted and multipart/signed.
このドキュメントはMIMEにおける、複合のセキュリティを定義します: 暗号化された複合/と複合/は署名しました。
Moberg & Drummond Standards Track [Page 9] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[9ページ]RFC4130AS2
3.3. RFC 3462 Multipart/Report [8]
3.3. RFC3462複合/レポート[8]
This RFC defines the use of the multipart/report content type, something that the MDN RFC 3798 builds upon.
このRFCは複合/レポートcontent typeの使用、MDN RFC3798が当てにする何かを定義します。
3.4. RFC 1767 EDI Content [2]
3.4. RFC1767EDI内容[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.5. RFC 2045, 2046, and 2049 MIME [1]
3.5. RFC2045、2046、および2049はまねられます。[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.6. RFC 3798 Message Disposition Notification [5]
3.6. RFC3798メッセージ気質通知[5]
This Internet RFC defines how an MDN is requested, and the format and syntax of the MDN. The MDN is the basis upon which receipts and signed receipts are defined in this specification.
このインターネットRFCはMDNがMDNの要求されていて形式とどう構文であるかを定義します。 MDNは領収書と署名している領収書がこの仕様に基づき定義される基礎です。
3.7. RFC 3851 and 3852 S/MIME Version 3.1 Message Specifications and
Cryptographic Message Syntax (CMS) [7]
3.7. RFC3851と3852秒間/MIMEのバージョン3.1メッセージ仕様と暗号のメッセージ構文(cm)[7]
This specification describes how S/MIME will carry CMS Objects.
この仕様はS/MIMEがどうCMS Objectsを運ぶかを説明します。
3.8. RFC 3023 XML Media Types [10]
3.8. RFC3023XMLメディアタイプ[10]
This RFC defines the use of content type "application" for XML (application/xml).
このRFCはcontent type「アプリケーション」のXML(アプリケーション/xml)の使用を定義します。
4. Structure of an AS2 Message
4. AS2メッセージの構造
4.1. Introduction
4.1. 序論
The basic structure of an AS2 message consists of MIME format inside an HTTP message with a few additional specific AS2 headers. The structures below are described hierarchically in terms of which RFCs are applied to form the specific structure. For details of how to code in compliance with all RFCs involved, turn directly to the RFCs referenced. Any difference between AS2 implantations and RFCs are mentioned specifically in the sections below.
AS2メッセージの基本構造はいくつかの追加特定のAS2ヘッダーと共にHTTPメッセージでMIME形式から成ります。 どのRFCsが特定の構造を形成するために適用されるかに関して以下の構造は階層的で説明されます。 RFCsがかかわったすべてに従ってコードへのどのようにに関する詳細に関しては、直接参照をつけられるRFCsに変わってくださいか。 特に下のセクションでAS2移植とRFCsのどんな違いも言及されます。
Moberg & Drummond Standards Track [Page 10] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[10ページ]RFC4130AS2
4.2. Structure of an Internet EDI MIME Message
4.2. インターネットエディMIMEメッセージの構造
No encryption, no signature
-RFC2616/2045
-RFC1767/RFC3023 (application/EDIxxxx or /xml)
暗号化がない、署名がない-RFC2616/2045 -RFC1767/RFC3023(アプリケーション/EDIxxxxか/xml)
No encryption, signature
-RFC2616/2045
-RFC1847 (multipart/signed)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)
-RFC3851 (application/pkcs7-signature)
暗号化がない、署名-RFC2616/2045 -RFC1847(複合か署名される)の-RFC1767/RFC3023(アプリケーション/EDIxxxxか/xml)-RFC3851(pkcs7アプリケーション/署名)
Encryption, no signature
-RFC2616/2045
-RFC3851 (application/pkcs7-mime)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
暗号化、署名がない-RFC2616/2045 -RFC3851(pkcs7アプリケーション/パントマイム)-RFC1767/RFC3023(アプリケーション/EDIxxxxか/xml)(暗号化されます)
Encryption, signature
-RFC2616/2045
-RFC3851 (application/pkcs7-mime)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767/RFC3023 (application/EDIxxxx or /xml)(encrypted)
-RFC3851 (application/pkcs7-signature)(encrypted)
暗号化、署名-RFC2616/2045 -RFC3851(pkcs7アプリケーション/パントマイム)-RFC1847(複合か署名される)(暗号化された)の-RFC1767/RFC3023(アプリケーション/EDIxxxxか/xml)(暗号化される)-RFC3851(pkcs7アプリケーション/署名)(暗号化されます)
MDN over HTTP, no signature
-RFC2616/2045
-RFC3798 (message/disposition-notification)
HTTPの上のMDN、署名がない-RFC2616/2045 -RFC3798(気質メッセージ/通知)
MDN over HTTP, signature
-RFC2616/2045
-RFC1847 (multipart/signed)
-RFC3798 (message/disposition-notification)
-RFC3851 (application/pkcs7-signature)
HTTPの上のMDN、署名-RFC2616/2045 -RFC1847(複合か署名される)の-RFC3798(気質メッセージ/通知)-RFC3851(pkcs7アプリケーション/署名)
MDN over SMTP, no signature
MDN over SMTP, signature
Refer to the EDI over SMTP standard [4].
SMTPの上のMDN、SMTPの上の署名がないMDN、EDIへのSMTP規格[4]の上の署名Refer。
Although 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
文書内容: 複合の、または、署名しているコンテントタイプ: 複合/レポート文書内容: 気質メッセージ/通知コンテントタイプ: PKCS7アプリケーション/署名コンテントタイプ: PKCS7アプリケーション/パントマイムコンテントタイプ: アプリケーション/EDI-X12
Moberg & Drummond Standards Track [Page 11] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[11ページ]RFC4130AS2
Content-Type: application/EDIFACT
Content-Type: application/edi-consent
Content-Type: application/XML
コンテントタイプ: アプリケーション/EDIFACTコンテントタイプ: ediアプリケーション/同意コンテントタイプ: アプリケーション/XML
5. HTTP Considerations
5. HTTP問題
5.1. Sending EDI in HTTP POST Requests
5.1. HTTPポスト要求でEDIを送ります。
The request line will have the form: "POST Request-URI HTTP/1.1", with spaces and followed by a CRLF. The Request URI is typically exchanged out of band, as part of setting up a bilateral trading partner agreement. Applications SHOULD be prepared to deal with an initial reply containing a status indicating a need for authentication of the usual types used for authorizing access to the Request-URI ([3], Section 10.4.2 and elsewhere).
要求線には、フォームがあるでしょう: 「ポスト、空間であってa CRLFによって続かれるのがあるRequest-URI HTTP/1.1インチ、」 双方の貿易相手国協定をセットアップする一部としてバンドからRequest URIを通常交換します。 アプリケーションSHOULD、ほかの場所でRequest-URI([3]へのアクセスを認可するのに使用される普通のタイプ、セクション10.4.2の認証の必要性を示す状態を含む初期の回答に対処するように用意してください、)
The request line is followed by entity headers specifying content length ([3], Section 14.14) and content type ([3], Section 14.18). The Host request header ([3], Sections 9 and 14.23) is also included.
要求線が従われている、コンテンツの長さ([3]を指定する実体ヘッダー、セクション14.14) そして、満足しているタイプ([3]、セクション14.18) Host要求ヘッダー([3]、セクション9、および14.23) また、含まれています。
When using Transport Layer Security [15] or SSLv3, the request-URI SHOULD indicate the appropriate scheme value, HTTPS. Usually only a multipart/signed message body would be sent using TLS, as encrypted message bodies would be redundant. However, encrypted message bodies are not prohibited.
HTTPS Transport Layer Security[15]かSSLv3を使用するURI SHOULDを要求するのが適切な計画値を示すときだけ、通常、ボディーを送るだろうという暗号化メッセージ本体は余分でしょう、したがって、TLSを使用する複合の、または、サインされたメッセージです。 しかしながら、暗号化メッセージ本体は禁止されていません。
The receiving AS2 system MAY disconnect from the sending AS2 system before completing the reception of the entire entity if it determines that the entity being sent is too large to process.
送られる実体が処理できないくらい大きいことを決定するなら全体の実体のレセプションを終了する前にAS2システムが送付AS2システムから外すかもしれない受信。
For HTTP version 1.1, TCP persistent connections are the default, ([3] Sections 8.1.2, 8.2, and 19.7.1). A number of other differences exist because HTTP does not conform to MIME [1] as used in SMTP transport. Relevant differences are summarized below.
HTTPバージョン1.1のために、TCPパーシステントコネクションはデフォルト、([3]セクション8.1.2、8.2、および19.7.1です)。 HTTPが[1] SMTP輸送に使用されるようにMIMEに従わないので、他の多くの違いが存在しています。 関連違いは以下へまとめられます。
5.2. Unused MIME Headers and Operations
5.2. 未使用のMIMEヘッダーと操作
5.2.1. Content-Transfer-Encoding Not Used in HTTP Transport
5.2.1. HTTP輸送に使用されない満足している転送コード化
HTTP can handle binary data and so there is no need to use the content transfer encodings of MIME [1]. This difference is discussed in [3], Section 19.4.5. However, a content transfer encoding value of binary or 8-bit is permissible but not required. The absence of this header MUST NOT result in transaction failure. Content transfer encoding of MIME bodyparts within the AS2 message body is also allowed.
HTTPはあることができます。2進のデータを扱うので、MIME[1]の満足している転送encodingsを使用する必要は、全くありません。 [3]、セクション19.4.5でこの違いについて議論します。 しかしながら、2進か8ビットの価値をコード化する満足している転送は、許されますが、必要ではありません。 このヘッダーの不在は取引失敗をもたらしてはいけません。 また、AS2メッセージボディーの中のMIME bodypartsの満足している転送コード化は許されています。
Moberg & Drummond Standards Track [Page 12] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[12ページ]RFC4130AS2
5.2.2. Message Bodies
5.2.2. メッセージ本体
In [3], Section 3.7.2, it is explicitly noted that multiparts MUST have null epilogues.
[3]、セクション3.7.2では、明らかに「マルチ-部品」にはヌルエピローグがなければならないことに注意されます。
In [4], Section 5.4.1, options for large file processing are discussed for SMTP transport. For HTTP, large files SHOULD be handled correctly by the TCP layer. However, in [3], Sections 3.5 and 3.6 discuss some options for compressing or chunking entities to be transferred. In [3], Section 8.1.2.2 discusses a pipelining option that is useful for segmenting large amounts of data.
[4]、セクション5.4.1では、SMTP輸送のために大きいファイル処理のためのオプションについて議論します。 HTTPのために、多大はSHOULDをファイルします。TCP層によって正しく扱われます。 しかしながら、[3]では、セクション3.5と3.6は、圧縮か分魂化実体を移すためにいくつかのオプションについて議論します。 [3]、.2が議論するセクション8.1.2では、大きい状態で区分の役に立つパイプライン処理オプションはデータを達させます。
5.3. Modification of MIME or Other Headers or Parameters Used
5.3. MIME、他のヘッダーまたは使用されるパラメタの変更
5.3.1. Content-Length
5.3.1. コンテンツの長さ
The use of the content-length header MUST follow the guidelines of [3], specifically Sections 4.4 and 14.13.
コンテンツの長さヘッダーの使用は[3]のガイドライン、明確にセクション4.4と14.13に続かなければなりません。
5.3.2. Final Recipient and Original Recipient
5.3.2. 最終的な受取人とオリジナルの受取人
The final and original recipient values SHOULD be the same value. These values MUST NOT be aliases or mailing lists.
最終的でオリジナルの受取人は同じくらいが値であったならSHOULDを評価します。 これらの値は、別名かメーリングリストであるはずがありません。
5.3.3. Message-Id and Original-Message-Id
5.3.3. メッセージイドとオリジナルのメッセージイド
Message-Id and Original-Message-Id is formatted as defined in RFC 2822 [9]:
メッセージイドとOriginalメッセージイドはRFC2822[9]で定義されるようにフォーマットされます:
"<" id-left "@" id-right ">" (RFC 2822, 3.6.4)
"<"イドによる左の"@"イド権利">"(RFC2822、3.6.4)
Message-Id length is a maximum of 998 characters. For maximum backward compatibility, Message-Id length SHOULD be 255 characters or less. Message-Id SHOULD be globally unique, and id-right SHOULD be something unique to the sending host environment (e.g., a host name).
メッセージイドの長さは最大998のキャラクタです。 最大の後方の互換性、Message-イドの長さのSHOULD、255以下のキャラクタになってください。 メッセージイドSHOULDはグローバルにユニークであり、ものが送付ホスト環境に何かユニークであったなら、SHOULDをイドでまっすぐにします(例えば、ホスト名)。
When sending a message, always include the angle brackets. Angle brackets are not part of the Message-Id value. For maximum backward compatibility, when receiving a message, do not check for angle brackets. When creating the Original-Message-Id header in an MDN, always use the exact syntax as received on the original message; don't strip or add angle brackets.
メッセージを送るときには、いつも角ブラケットを含めてください。 角ブラケットはMessage-イド価値の一部ではありません。 最大の後方の互換性には、メッセージを受け取るときには、角ブラケットがないかどうかチェックしないでください。 MDNでOriginalメッセージイドヘッダーを創造するときには、オリジナルのメッセージに受け取るようにいつも正確な構文を使用してください。 角ブラケットを剥取らないでください、または加えないでください。
Moberg & Drummond Standards Track [Page 13] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[13ページ]RFC4130AS2
5.3.4. Host Header
5.3.4. ホストヘッダー
The host request header field MUST be included in the POST request made when sending business data. This field is intended to allow one server IP address to service multiple hostnames, and potentially to conserve IP addresses. See [3], Sections 14.23 and 19.5.1.
業務データを送るときされたポストの要求にホスト要求ヘッダーフィールドを含まなければなりません。 この分野が、1つのサーバIPアドレスが複数のホスト名を修理して、潜在的にIPアドレスを保存するのを許容することを意図します。 [3]、セクション14.23と19.5.1を見てください。
5.4. HTTP Response Status Codes
5.4. HTTP応答ステータスコード
The status codes return status concerning HTTP operations. For example, the status code 401, together with the WWW-Authenticate header, is used to challenge the client to repeat the request with an Authorization header. Other explicit status codes are documented in [3], Section 6.1.1 and throughout Section 10.
ステータスコードはHTTP操作に関して状態を返します。 例えば、ステータスコード401、ヘッダーをWWW認証してください、Authorizationヘッダーと共に要求を繰り返すようにクライアントに挑むには、使用されます。 他の明白なステータスコードは、記録されたコネ[3]、セクション6.1.1であり、セクション10中でそうです。
For errors in the request-URI, 400 ("Bad Request"), 404 ("Not
Found"), and similar codes are appropriate status codes. These codes
and their semantics are specified by [3]. A careful examination of
these codes and their semantics should be made before implementing
any retry functionality. Retries SHOULD NOT be made if the error is
not transient or if retries are explicitly discouraged.
要求URIにおける誤りのために、400(「悪い要求」)、404(「見つけられない」)、および同様のコードは適切なステータスコードです。 これらのコードとそれらの意味論は[3]によって指定されます。 どんな再試行の機能性も実行する前に、これらのコードとそれらの意味論の慎重な調査は作られるべきです。 誤りが一時的でないなら作られるか、または再試行が明らかに妨げるなら、再試行SHOULD NOTはそうです。
5.5. HTTP Error Recovery
5.5. HTTPエラー回復
If the HTTP client fails to read the HTTP server response data, the POST operation with identical content, including same Message-ID, SHOULD be repeated, if the condition is transient.
HTTPクライアントが失敗するなら、同じMessage-ID、SHOULDを含む同じ内容でHTTPサーバ応答データ、ポストの操作を読むために、繰り返されてください、状態が一時的であるなら。
The Message-ID on a POST operation can be reused if and only if all of the content (including the original Date) is identical.
そして、ポストの操作でのMessage-IDを再利用できる、内容(オリジナルのDateを含んでいる)のすべてが同じである場合にだけ。
Details of the retry process (including time intervals to pause, number of retries to attempt, and timeouts for retrying) are implementation dependent. These settings are selected as part of the trading partner agreement.
再試行の過程(ポーズする時間間隔、試みる再試行の数、および再試行するためのタイムアウトを含んでいる)の詳細は実現に依存しています。 これらの設定は貿易相手国協定の一部として選定されます。
Servers SHOULD be prepared to receive a POST with a repeated Message-ID. The MIME reply body previously sent SHOULD be resent, including the MDN and other MIME parts.
サーバSHOULD、繰り返されたMessage-IDと共にポストを受けるように用意してください。 MIME回答本体は以前に、再送されて、MDNと他のMIMEの部品を含むSHOULDを送りました。
6. Additional AS2-Specific HTTP Headers
6. 追加AS2特有のHTTPヘッダ
The following headers are to be included in all AS2 messages and all AS2 MDNs, except for asynchronous MDNs that are sent using SMTP and that follow the AS1 semantics[4].
以下のヘッダーはすべてのAS2メッセージとすべてのAS2 MDNsに含まれることになっています、SMTPが使用させられて、AS1意味論[4]に従う非同期なMDNsを除いて。
Moberg & Drummond Standards Track [Page 14] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[14ページ]RFC4130AS2
6.1. AS2 Version Header
6.1. AS2バージョンヘッダー
To promote backward compatibility, AS2 includes a version header:
後方の互換性を促進するために、AS2はバージョンヘッダーを含んでいます:
AS2-Version: 1.0 - Used in all implementations of this
specification. 1.x will be interpreted as 1.0 by
all implementations with the "AS2 Version: 1.0"
header. That is, only the most significant digit
is used as the version identifier for those not
implementing additional non-AS2-specified
functionality. "AS2-Version: 1.0 through 1.9" MAY
be used. All implementations MUST interpret "1.0
through 1.9" as implementing this specification.
However, an implementation MAY extend this
specification with additional functionality by
specifying versions 1.1 through 1.9. If this
mechanism is used, the additional functionality
MUST be completely transparent to implementations
with the "AS2-Version: 1.0" designation.
AS2-バージョン: 1.0--この仕様のすべての実現では、使用されています。 1. xが1.0としてすべての実現で解釈される、「AS2バージョン:」 1インチのヘッダー。 すなわち、最も重要なケタだけが追加非AS2が指定している機能性を実行しないものにバージョン識別子として使用されます。 「AS2-バージョン:」 1.9インチを通した1.0は使用されるかもしれません。 すべての実現が「この仕様を履行するとしての1.9インチを通した1.0」を解釈しなければなりません。 しかしながら、実現は、追加機能性でバージョン1.1〜1.9を指定することによって、この仕様を広げるかもしれません。 このメカニズムが使用されているなら、追加機能性が実現に完全に見え透かなければならない、「AS2-バージョン:」 1インチの名称。
AS2-Version: 1.1 - Designates those implementations that support
compression as defined by RFC 3274.
AS2-バージョン: 1.1--RFC3274によって定義されるように圧縮を支持するそれらの実現を指定します。
Receiving systems MUST NOT fail due to the absence of the AS2-Version header. Its absence would indicate that the message is from an implementation based on a previous version of this specification.
受電方式はAS2-バージョンヘッダーの不在のため失敗してはいけません。 不在は、メッセージがこの仕様の旧バージョンに基づく実現から来ているのを示すでしょう。
6.2. AS2 System Identifiers
6.2. AS2システム識別子
To aid the receiving system in identifying the sending system, AS2-From and AS2-To headers are used.
そして、送付システムを特定する際に受電方式を支援するためにAS2、-、AS2、-、ヘッダーは使用されています。
AS2-From: < AS2-name >
AS2-To: < AS2-name >
AS2-From: <AS2-名前>AS2-To: <AS2-名前>。
These AS2 headers contain textual values, as described below, identifying the sender/receiver of a data exchange. Their values may be company specific, such as Data Universal Numbering System (DUNS) numbers, or they may be simply identification strings agreed upon between the trading partners.
データ交換の送付者/受信機を特定して、これらのAS2ヘッダーは以下で説明されるように原文の値を含んでいます。 それらの値は会社の特定(DUNS)のData Universal Numbering Systemなどのように番号であるかもしれませんかそれらが単に貿易相手国の間で同意された識別ストリングであるかもしれません。
Moberg & Drummond Standards Track [Page 15] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[15ページ]RFC4130AS2
AS2-text = "!" / ; printable ASCII characters
%d35-91 / ; except double-quote (%d34)
%d93-126 ; or backslash (%d92)
AS2-テキストは“!"と等しいです。 / ; 印刷可能なASCII文字%d35-91/。 二重引用文(%d34)の%d93-126を除いて。 または、バックスラッシュ(%d92)
AS2-qtext = AS2-text / SP ; allow space only in quoted text
AS2-qtextはAS2-テキスト/SPと等しいです。 引用されたテキストだけで紙面を割いてください。
AS2-quoted-pair = "\" DQUOTE / ; \" or
"\" "\" ; \\
AS2が組を引用している=「\」DQUOTE/。 「\」か「\」「\」。 \\
AS2-quoted-name = DQUOTE 1*128( AS2-qtext /
AS2-quoted-pair) DQUOTE
AS2が名前を引用している=DQUOTE1*128の(AS2-qtext / AS2は組を引用していました)のDQUOTE
AS2-atomic-name = 1*128AS2-text
AS2の原子名=1*128AS2-テキスト
AS2-name = AS2-atomic-name / AS2-quoted-name
AS2は名前を=AS2原子AS2-名前名/引用していました。
The AS2-From header value and the AS2-To header value MUST each be an AS2-name, MUST each be comprised of from 1 to 128 printable ASCII characters, and MUST NOT be folded. The value in each of these headers is case-sensitive. The string definitions given above are in ABNF format [14].
そして、AS2、-、ヘッダー値、AS2、-、ヘッダー値、それぞれAS2-名前でなければならなく、1〜128人の印刷可能なASCII文字からそれぞれ成らなければならなくて、折り重ねられてはいけません。 これらのヘッダー各人の値は大文字と小文字を区別しています。 ABNF形式[14]には上に与えられたストリング定義があります。
The AS2-quoted-name SHOULD be used only if the AS2-name does not conform to AS2-atomic-name.
AS2が名前を引用しているSHOULD、AS2-名前がAS2の原子名に従わない場合にだけ、使用されてください。
The AS2-To and AS2-From header fields MUST be present in all AS2 messages and AS2 MDNs whether asynchronous or synchronous in nature, except for asynchronous MDNs, which are sent using SMTP.
そして、AS2、-、AS2、-、ヘッダーフィールド、非同期であるか、または非同期なMDNs(SMTPが使用させられるもの)を除いて、現実に同時であることにかかわらずすべてのAS2メッセージとAS2 MDNsに存在していなければなりません。
The AS2-name for the AS2-To header in a response or MDN MUST match the AS2-name of the AS2-From header in the corresponding request message. Likewise, the AS2-name for the AS2-From header in a response or MDN MUST match the AS2-name of the AS2-To header in the corresponding AS2 request message.
AS2-名前、AS2、-、ヘッダー、a応答かMDN MUSTがAS2-名前に合っているコネ、AS2、-、ヘッダー、対応する要求メッセージで。 同様にAS2-名前、AS2、-、ヘッダー、a応答かMDN MUSTがAS2-名前に合っているコネ、AS2、-、ヘッダー、対応するAS2では、メッセージを要求してください。
The sending system may choose to limit the possible AS2-To/AS2-From textual values but MUST not exceed them. The receiving system MUST make no restrictions on the textual values and SHOULD handle all possible implementations. However, implementers must be aware that older AS2 products may not adhere to this convention. Trading partner agreements should be made to ensure that older products can support the system identifiers that are used.
送付システムが、有り得るのを制限するのを選ぶかもしれない、AS2、-、/、AS2、-、原文、それらを超えてはいけないのを除いて、評価します。 受電方式は原文の値とSHOULDにおけるどんな制限もすべての可能な実現を扱うというわけではないのをさせなければなりません。 しかしながら、implementersは、より古いAS2製品がこのコンベンションを固く守らないかもしれないのを意識しているに違いありません。 より古い製品が使用されたシステム識別子を支持できるのを保証するのを貿易相手国協定をするべきです。
There is no required response to a client request containing invalid or unknown AS2-From or AS2-To header values. The receiving AS2 system MAY return an unsigned MDN with an explanation of the error, if the sending system requested an MDN.
または、病人か未知を含むクライアント要求へのどんな必要な応答もない、AS2、-、AS2、-、ヘッダー値。 送付システムがMDNを要求したならAS2システムが誤りに関する説明で無記名のMDNを返すかもしれない受信。
Moberg & Drummond Standards Track [Page 16] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[16ページ]RFC4130AS2
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. サインされた領収書を送付貿易相手国に返す能力。
5. The ability to return either a synchronous or an asynchronous
receipt as the sending party requests.
5. 送付パーティーが要求するように同期領収書か非同期な領収書を返す能力。
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の保全について確かめました。
Moberg & Drummond Standards Track [Page 17] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[17ページ]RFC4130AS2
Regardless of whether the EDI/EC Interchange was sent in S/MIME format, 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がコード化されているなら、コード化された対称鍵と初期化ベクトル(適切であるなら)は、受信機の秘密鍵を使用することで解読されます。
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. The authentication
algorithm performs the following:
3. 受信貿易相手国は、送付者の公開鍵を使用することでメッセージにおける署名を認証します。 認証アルゴリズムは以下を実行します:
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:
7. 複合の、または、サインされたメッセージの第二部はデジタル署名を含んでいます。 複合かサインにされるのの第二部で指定された「プロトコル」オプションは以下の通りです:
S/MIME: protocol = "application/pkcs-7-signature"
S/MIME: =「pkcs7アプリケーション/署名」について議定書の中で述べてください。
8. The signature information is formatted according to S/MIME
specifications.
8. 署名情報はS/MIME仕様通りにフォーマットされます。
Moberg & Drummond Standards Track [Page 18] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[18ページ]RFC4130AS2
The EC Interchange and the RFC 1767 MIME EDI content header can actually be part of a multi-part MIME content-type. When the EDI Interchange is part of a multi-part MIME content-type, the MIC MUST be calculated across the entire multi-part content, including the MIME headers.
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 as follows:
EDI Interchangeの送付者によって受け取られると、以下の送付者はサインされたMDNを使用できます:
o As an acknowledgement that the EDI Interchange sent was
delivered and acknowledged by the receiving trading partner.
The receiver does this by returning the original-message-id
of the sent message in the MDN portion of the signed receipt.
o EDI Interchangeが発信したという承認が受信貿易相手国によって提供されて、承諾されたので。 受信機は、サインされた領収書のMDN部分で送信されたメッセージのオリジナルのメッセージイドを返すことによって、これをします。
o As an acknowledgement 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.
o EDI Interchangeの保全が受信貿易相手国によって確かめられたという承認として。 受信機は、サインされたMDNの「容認された満足しているMIC」分野で容認されたEC Interchange(そして、1767個のMIMEヘッダー)の計算されたMICを返すことによって、これをします。
o As an acknowledgement that the receiving trading partner has
authenticated the sender of the EDI Interchange.
o 受信貿易相手国がEDI Interchangeの送付者を認証したという承認として。
o 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.
o サインされたMDNが受信貿易相手国の公開鍵で送付者によって首尾よく確かめられるときの領収書の非拒否と返されたMICが内部を評価するとき、MDNはオリジナルのメッセージのダイジェストと同じです。
7.2. Synchronous and Asynchronous MDNs
7.2. 同時の、そして、非同期なMDNs
The AS2-MDN exists in two varieties: synchronous and asynchronous.
AS2-MDNは2つのバラエティーで存在しています: 同時であって、非同期です。
The synchronous AS2-MDN is sent as an HTTP response to an HTTP POST or as an HTTPS response to an HTTPS POST. This form of AS2-MDN is called synchronous because the AS2-MDN is returned to the originator of the POST on the same TCP/IP connection.
HTTPポストへのHTTP応答として、または、HTTPS POSTへのHTTPS応答として同期AS2-MDNを送ります。同じTCP/IP接続のポストの創始者にAS2-MDNを返すので、AS2-MDNのこのフォームを同時であると呼びます。
The asynchronous AS2-MDN is sent on a separate HTTP, HTTPS, or SMTP TCP/IP connection. Logically, the asynchronous AS2-MDN is a response to an AS2 message. However, at the transfer-protocol layer, assuming that no HTTP pipelining is utilized, the asynchronous AS2-MDN is delivered on a unique TCP/IP connection, distinct from that used to deliver the original AS2 message. When handling an asynchronous request, the HTTP response MUST be sent back before the MDN is processed and sent on the separate connection.
別々のHTTP、HTTPS、またはSMTP TCP/IP接続で非同期なAS2-MDNを送ります。 非同期なAS2-MDNはAS2メッセージへの論理的に、応答です。 しかしながら、転送プロトコル層でどんなHTTPパイプライン処理も利用されていないと仮定して、ユニークなTCP/IP接続で非同期なAS2-MDNを届けます、オリジナルのAS2メッセージを送るのに使用されるそれと、異なります。 非同期要求を扱うとき、HTTP応答をMDNを処理する前に送って、別々の接続に送らなければなりません。
Moberg & Drummond Standards Track [Page 19] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[19ページ]RFC4130AS2
When an asynchronous AS2-MDN is requested by the sender of an AS2 message, the synchronous HTTP or HTTPS response returned to the sender prior to terminating the connection MUST be a transfer-layer response indicating the success or failure of the data transfer. The format of such a synchronous response MAY be the same as that response returned when no AS2-MDN is requested.
非同期なAS2-MDNがAS2メッセージの送付者によって要求されているとき、接続を終える前に送付者に返された同期HTTPかHTTPS応答がデータ転送の成否を示す転送層の応答であるに違いありません。 そのような同期応答の形式はAS2-MDNが全く要求されていないとき、その応答が戻ったのと同じであるかもしれません。
The following diagram illustrates the synchronous versus asynchronous varieties of AS2-MDN delivery using HTTP:
以下のダイヤグラムはHTTPを使用することでAS2-MDNの非同期なバラエティーに対して同期の配送を例証します:
Synchronous AS2-MDN
同期AS2-MDN
[Peer1] ----( connect )----> [Peer2] [Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]] [Peer1] <---( receive )----- [Peer2] [HTTP Response [AS2-MDN]]
[Peer1]----(接続します)---->[Peer2][Peer1]-----(発信します)------>[Peer2][HTTP要求[AS2-メッセージ]][Peer1]<。---(受信します)----- [Peer2][HTTP応答[AS2-MDN]]
Asynchronous AS2-MDN
非同期なAS2-MDN
[Peer1] ----( connect )----> [Peer2] [Peer1] -----( send )------> [Peer2] [HTTP Request [AS2-Message]] [Peer1] <---( receive )----- [Peer2] [HTTP Response]
[Peer1]----(接続します)---->[Peer2][Peer1]-----(発信します)------>[Peer2][HTTP要求[AS2-メッセージ]][Peer1]<。---(受信します)----- [Peer2][HTTP応答]
[Peer1]*<---( connect )----- [Peer2] [Peer1] <--- ( send )------- [Peer2] [HTTP Request [AS2-MDN]] [Peer1] ----( receive )----> [Peer2] [HTTP Response]
[Peer1]*<。---(接続します)----- [Peer2][Peer1]<。--- (発信します)------- [Peer2][HTTP要求[AS2-MDN]][Peer1]----(受信します)---->[Peer2][HTTP応答]
* Note: An AS2-MDN may be directed to a host different from that of the sender of the AS2 message. It may utilize a transfer protocol different from that used to send the original AS2 message.
* 以下に注意してください。 AS2-MDNはAS2メッセージの送付者のものと異なったホストにあてられるかもしれません。 それはオリジナルのAS2メッセージを送るのに使用されるそれと異なった転送プロトコルを利用するかもしれません。
The advantage of the synchronous MDN is that it can provide the sender of the AS2 Message with a verifiable confirmation of message delivery within a synchronous logic flow. However, if the message is relatively large, the time required to process this message and to return an AS2-MDN to the sender on the same TCP/IP connection may exceed the maximum configured time permitted for an IP connection.
同期MDNの利点は同期論理の流れの中でメッセージ配送の証明可能な確認をAS2 Messageの送付者に提供できるということです。 しかしながら、メッセージが比較的大きいなら、このメッセージを処理して、同じTCP/IP接続の送付者にAS2-MDNを返すのに必要である時間はIP接続のために受入れられた最大の構成された時間を超えるかもしれません。
The advantage of the asynchronous MDN is that it provides for the rapid return of a transfer-layer response from the receiver, confirming the receipt of data, therefore not requiring that a TCP/IP connection necessarily remain open for very long. However, this design requires that the asynchronous AS2-MDN contain enough information to identify the original message uniquely so that, when received by the AS2 Message originator, the status of the original AS2 Message can be properly updated based on the contents of the AS2-MDN.
非同期なMDNの利点は受信機から転送層の応答の急速な復帰に備えるということです、データの領収書を確認して、したがって、TCP/IP接続が必ず非常に長い間開いたままで残るのが必要ではありません。 しかしながら、このデザインは、AS2 Message創始者が受け取ると、AS2-MDNのコンテンツに基づいて適切にオリジナルのAS2 Messageの状態をアップデートできるように非同期なAS2-MDNが唯一オリジナルのメッセージを特定できるくらいの情報を含むのを必要とします。
Moberg & Drummond Standards Track [Page 20] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[20ページ]RFC4130AS2
Synchronous or asynchronous HTTP or HTTPS MDNs are handled according to the requirements of this specification.
この仕様の要件に従って、同時の、または、非同期なHTTPかHTTPS MDNsが扱われます。
However, SMTP MDNs are formatted according to the requirements of RFC 3335 [4].
しかしながら、RFC3335[4]の要件に従って、SMTP MDNsはフォーマットされます。
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:
メッセージ気質通知はRFC3798に従って要求されています。 送られるべきメッセージに以下のヘッダーを置くことによって、受信ユーザエージェントがメッセージ気質通知を発行するという要求をします:
MDN-request-header = "Disposition-notification-to"
":" mail-address
「MDN要求ヘッダー=、「気質通知、」、」、:、」 郵便の宛先
The following example is for requesting an MDN:
以下の例はMDNを要求するものです:
Disposition-notification-to: xxx@example.com
気質通知、: xxx@example.com
This syntax is a residue of the use of MDNs using SMTP transfer. Because this specification is adjusting the functionality from SMTP to HTTP while retaining as much as possible from the [4] functionality, the mail-address MUST be present. The mail-address field is specified as an RFC 2822 localpart@domain [addr-spec] address. However, the address is not used to identify where to return the MDN. Receiving applications MUST ignore the value and MUST not complain about RFC 2822 address syntax violations.
この構文はSMTP転送を使用するMDNsの使用の残りです。 この仕様が[4]から機能性をできるだけ保有している間、SMTPからHTTPに機能性を調整しているので、郵便の宛先は存在していなければなりません。 郵便の宛先分野はRFC2822 localpart@domain [addr-仕様]アドレスとして指定されます。 しかしながら、アドレスは、MDNをどこに返すかを特定するのに使用されません。 申し込みを受け付けるのは、値を無視しなければならなくて、RFC2822アドレス構文違反に関して不平を言ってはいけません。
When requesting MDN-based receipts, the originator supplies additional extension headers that precede the message body. These header "tags" are as follows:
MDNベースの領収書を要求するとき、創始者はメッセージ本体に先行する追加拡張ヘッダーを供給します。 これらのヘッダー「タグ」は以下の通りです:
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 MDN. Other headers, especially "Subject" and "Date", SHOULD be supplied; the values of these headers are often mentioned in the human-readable section of a MDN to aid in identifying the original message.
Message-IDヘッダーはメッセージ和解を支持するために加えられます、MDNの身体の部分でOriginalメッセージイド値を返すことができるように。 他のヘッダーと特に「対象」と「日付」、SHOULD、供給してください。 MDNの人間読み込み可能なセクションでこれらのヘッダーの値は、オリジナルのメッセージを特定する際に支援するためにしばしば言及されます。
MDNs will be returned in the HTTP response when requested, unless an asynchronous return is requested.
要求して、非同期なリターンは要求しないと、HTTP応答でMDNsを返すでしょう。
To request an asynchronous message disposition notification, the following header is placed into the message that is sent:
非同期なメッセージ気質通知を要求するために、以下のヘッダーは送られるメッセージに置かれます:
Receipt-Delivery-Option: return-URL
領収書配送オプション: リターンURL
Moberg & Drummond Standards Track [Page 21] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[21ページ]RFC4130AS2
Here is an example requesting that the MDN be asynchronous:
ここに、MDNが非同期であるよう要求しながら、例があります:
Receipt-Delivery-Option: http://www.example.com/Path
領収書配送オプション: http://www.example.com/Path
Receipt-delivery-option syntax allows return-url to use some schemes other than HTTP using the POST method.
領収書配送オプション構文で、リターン-urlは、ポスト方法を使用することでHTTP以外のいくつかの計画を使用できます。
The "receipt-delivery-option: return-url" string indicates the URL to use for an asynchronous MDN. This header is NOT present if the receipt is to be synchronous. The email value in Disposition- notification-to is not used in this specification because it was limited to RFC 2822 addresses; the extension header "Receipt- delivery-option" has been introduced to provide a URL for the MDN return by several transfer options.
「配送オプションを領収書を出させてください」 「リターン-url」ストリングは非同期なMDNに使用するURLを示します。 このヘッダーは領収書が同時であることであるなら出席していません。 Dispositionのメール値、通知、-、この仕様では、それがRFC2822アドレスに制限されたので、使用されません。 「領収書配送オプション」が紹介された拡張ヘッダーはいくつかの転送オプションでMDNリターンにURLを提供します。
The receipt-delivery-option's value MUST be a URL indicating the delivery transport destination for the receipt.
領収書配送オプションの値は領収書のために配送輸送の目的地を示すURLでなければなりません。
An example request for an asynchronous MDN via an HTTP transport:
HTTP輸送を通した非同期なMDNを求める例の要求:
Receipt-delivery-option: http://www.example.com
領収書配送オプション: http://www.example.com
An example request for an asynchronous MDN via an HTTP/S transport:
HTTP/S輸送を通した非同期なMDNを求める例の要求:
Receipt-delivery-option: https://www.example.com
領収書配送オプション: https://www.example.com
An example request for an asynchronous MDN via an SMTP transport:
SMTP輸送を通した非同期なMDNを求める例の要求:
Receipt-delivery-option: mailto:as2@example.com
領収書配送オプション: mailto: as2@example.com
For more information on requesting SMTP MDNs, refer to RFC 3335 [4].
SMTP MDNsを要求する詳しい情報について、RFC3335[4]を参照してください。
Finally, the header, Disposition-notification-options, identifies characteristics of message disposition notification as in [5]. The most important of these options is for indicating the signing options for the MDN, as in the following example:
最終的に、ヘッダー(Disposition通知オプション)は[5]のようにメッセージ気質通知の特性を特定します。 これらのオプションで最も重要なことはMDNのために以下の例のように調印オプションを示すものです:
Disposition-notification-options:
signed-receipt-protocol=optional,pkcs7-signature;
signed-receipt-micalg=optional,sha1,md5
気質通知オプション: サインされた領収書プロトコル=任意である、pkcs7-署名。 サインされた領収書micalg=任意である、sha1、md5
For signing options, consider the disposition-notification-options syntax:
オプションに調印するには、気質通知オプション構文を考えてください:
Disposition-notification-options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
「気質通知オプションは「気質通知オプション」と等しい」:、」 気質通知パラメタ
Moberg & Drummond Standards Track [Page 22] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[22ページ]RFC4130AS2
where
disposition-notification-parameters =
parameter *(";" parameter)
気質通知パラメタがパラメタ*と等しいところ(「」、;、パラメタ)
where
parameter = attribute "=" importance ", " 1#value"
「パラメタ=属性が重要性と「等しい」ところ」と「1#、は評価します」。
where
importance = "required" | "optional"
重要性=が「必要である」ところ| 「任意です」。
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 used 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
--------- -------
SHA-1 sha1
MD5 md5
値が使用したアルゴリズム--------- ------- SHA-1 sha1 MD5 md5
The semantics of the "signed-receipt-protocol" and the "signed- receipt-micalg" parameters are as follows:
「サインされた領収書プロトコル」の意味論と「サインされた領収書-micalg」パラメタは以下の通りです:
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. 「サインされた領収書プロトコル」パラメタは、受取人貿易相手国からサインされた領収書を要求するのに使用されます。 また、「サインされた領収書プロトコル」パラメタはサインがSHOULDを領収書を出させる形式を指定します。リクエスタに返されます。
The "signed-receipt-micalg" parameter is a list of MIC algorithms
preferred by the requester for use in signing the returned
receipt. The list of MIC algorithms SHOULD be honored by the
recipient from left to right.
「サインされた領収書micalg」パラメタは返された領収書にサインすることにおける使用のためにリクエスタによって好まれたMICアルゴリズムのリストです。 記載してください。MICアルゴリズムSHOULDを受取人によって左から右まで光栄に思われてください。
Both the "signed-receipt-protocol" and the "signed- receipt-
micalg" option parameters are REQUIRED when requesting a signed
receipt.
サインされた領収書を要求するとき、「サインされた領収書プロトコル」と「サインされた領収書micalg」オプションパラメタの両方がREQUIREDです。
The lack of the presence of the "Receipt-Delivery-Option"
indicates that a receipt is synchronous in nature. The presence
of the "Receipt-Delivery-Option: return-url" indicates that an
asynchronous receipt is requested and SHOULD be sent to the
"return-url".
「領収書配送オプション」の存在の不足は、領収書が現実に同時であることを示します。 存在、「配送オプションを領収書を出させてください」 「リターン-url」が、非同期な領収書が要求されているのを示す、SHOULD、「リターン-url」に送ってください。
Moberg & Drummond Standards Track [Page 23] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[23ページ]RFC4130AS2
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 a MDN.
「任意」の重要性があるパラメタは特定のオプションパラメタがMDNを求める要求に対応してMDNをまだ発生させているのを理解していないUAを可能にします。
A UA that does not understand the "signed-receipt-protocol"
parameter or the "signed-receipt-micalg" will obviously not return
a signed receipt.
「サインされた領収書プロトコル」パラメタを理解していないUAか「サインされた領収書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 and 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
is up to the trading partners to resolve.
EDIの取り引き関係の中では、サインされた領収書が予想されて、返されないなら、取引の正当性は決議する貿易相手国次第です。
In general, if a signed receipt is required in the trading
relationship and is not received, the transaction will likely not
be considered valid.
一般に、サインされた領収書が取り引き関係で必要であり、受け取られていないと、取引は有効であるとおそらく考えられないでしょう。
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" are as follows:
「規則」は以下の通りです:
1. When a receipt is requested, explicitly specifying that the
receipt be signed, then the receipt MUST be returned with a
signature.
1. 領収書がサインされると明らかに指定して、領収書を要求すると、署名と共に領収書を返さなければなりません。
2. When a receipt is requested, explicitly specifying that the
receipt be signed, but the recipient cannot support either the
requested protocol format or the requested MIC algorithms, then
either a signed or unsigned receipt SHOULD be returned.
2. 領収書がサインされると明らかに指定して、領収書がいつ要求されるか、しかし、受取人は要求されたプロトコル形式か要求されたMICアルゴリズムのどちらか、次にサインされたか無記名の領収書SHOULDを支持できません。返します。
Moberg & Drummond Standards Track [Page 24] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[24ページ]RFC4130AS2
3. 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.
3. サインされた領収書要求パラメタがUAによって認識されないで、また署名が明らかに要求されない場合、どんな領収書も、無記名の領収書、またはサインされた領収書も受取人によって返されないかもしれません。
NOTE: For Internet EDI, it is RECOMMENDED that when a signature is not explicitly requested, or if parameters are not recognized, the UA send back, at a minimum, an unsigned receipt. If, however, a signed receipt was always returned as a policy, whether requested or not, then any false unsigned receipts can be repudiated.
以下に注意してください。 インターネットEDIに関しては、署名が明らかに要求されていないとき、パラメタが認識されないなら、UAが発信して戻るのは、RECOMMENDEDです、最小限で、無記名の領収書。 しかしながら、要求されているか否かに関係なく、方針としていつもサインされた領収書を返したなら、どんな偽の無記名の領収書も否認できます。
When a request for a signed receipt is made, but there is an error in processing the contents of the message, a signed receipt MUST still be returned. The request for a signed receipt SHALL still be honored, though the transaction itself may not be valid. The reason why the contents could not be processed MUST be set in the "disposition-field".
サインされた領収書を求める要求をしますが、メッセージのコンテンツを処理するのにおいて誤りがあるとき、まだサインされた領収書を返さなければなりません。 取引自体は有効でないかもしれませんが、サインされた領収書SHALLを求める要求がまだ光栄に思われていて、有効であってください。 「気質分野」にコンテンツを処理できなかった理由を設定しなければなりません。
When a signed receipt request is made, the "Received-content-MIC" MUST always be returned to the requester (except when corruption prevents computation of the digest in accordance with the following specification). The "Received-content-MIC" MUST be calculated as follows:
サインされた領収書要求をするとき、いつもリクエスタ(不正が以下の仕様通りにダイジェストの計算を防ぐ時を除いた)に「容認された満足しているミック」を返さなければなりません。 以下の通り「容認された満足しているミック」について計算しなければなりません:
o For any signed messages, the MIC to be returned is calculated
on the RFC1767/RFC3023 MIME header and content.
Canonicalization on the MIME headers MUST be performed before
the MIC is calculated, since the sender requesting the signed
receipt was also REQUIRED to canonicalize.
o どんなサインされたメッセージに関してはも、返されるべきMICはRFC1767/RFC3023 MIMEヘッダーと内容で計算されます。 MICが計算される前にMIMEヘッダーの上のCanonicalizationを実行しなければなりません、また、サインされた領収書を要求した送付者がcanonicalizeするREQUIREDであったので。
o For encrypted, unsigned messages, the MIC to be returned is
calculated on the decrypted RFC 1767/RFC3023 MIME header and
content. The content after decryption MUST be canonicalized
before the MIC is calculated.
o コード化されて、無記名のメッセージに関しては、返されるべきMICは解読されたRFC1767/RFC3023MIMEヘッダーと内容で計算されます。 MICが計算される前に復号化の後の内容をcanonicalizedしなければなりません。
o For unsigned, unencrypted messages, the MIC MUST be calculated
over the message contents without the MIME or any other RFC
2822 headers, since these are sometimes altered or reordered by
Mail Transport Agents (MTAs).
o 無記名の、そして、非コード化されたメッセージに関しては、これらが時々変更されて、MIMEもRFCなしでいかなる他のも2822個のヘッダーを満足させるか、またはメールTransportエージェント(MTAs)によって再命令されて、メッセージに関してミックについて計算しなければなりません。
7.4. MDN Format and Values
7.4. MDN形式と値
This section defines the format of the AS2 Message Disposition Notification (AS2-MDN).
このセクションはAS2 Message Disposition Notification(AS2-MDN)の書式を定義します。
Moberg & Drummond Standards Track [Page 25] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[25ページ]RFC4130AS2
7.4.1. AS2-MDN General Formats
7.4.1. AS2-MDN一般形式
The AS2-MDN follows the MDN specification [5] except where noted in this section. The modified ABNF definitions in this document use the vertical-bar character, '|', to denote a logical "OR" construction. This usage follows RFC 2616 [3]. HTTP entities referred to below are not further defined in this document. Refer to RFC 2616 [3] for complete definitions of HTTP entities. The format of the AS2-MDN is:
このセクションで有名であるところを除いて、AS2-MDNはMDN仕様[5]に従います。 '変更されたABNF定義は本書では縦棒キャラクタを使用します'|'論理的な「OR」工事を指示します' この用法はRFC2616[3]に続きます。 以下と呼ばれたHTTP実体はさらに本書では定義されません。 HTTP実体の完全な定義のためのRFC2616[3]を参照してください。 AS2-MDNの形式は以下の通りです。
AS2-MDN = AS2-sync-MDN | AS2-async-http-MDN |
AS2-async-smtp-MDN
AS2-MDNはAS2同時性MDNと等しいです。| AS2-async-http-MDN| AS2-async-smtp-MDN
AS2-sync-MDN =
Status-Line
*(( general-header | response-header | entity-header )
CRLF )
CRLF
AS2-MDN-body
AS2同時性MDNは状態線*((一般的なヘッダー| 応答ヘッダ| 実体ヘッダー)CRLF)CRLF AS2-MDN-ボディーと等しいです。
Status-Line =
HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状況表示行=HTTPバージョンSPステータスコードSP理由句のCRLF
AS2-async-http-MDN =
Request-Line
*(( general-header | request-header | entity-header )
CRLF )
CRLF
AS2-MDN-body
AS2-async-http-MDNは要求線*((一般的なヘッダー| 要求ヘッダー| 実体ヘッダー)CRLF)CRLF AS2-MDN-ボディーと等しいです。
Request-Line =
Method SP Request-URI SP HTTP-Version CRLF
方法SP要求URI SP HTTPバージョン要求線=CRLF
AS2-async-smtp-MDN =
*(( general-header | request-header | entity-header )
CRLF )
CRLF
AS2-MDN-body
AS2-async-smtp-MDNは*((一般的なヘッダー| 要求ヘッダー| 実体ヘッダー)CRLF)CRLF AS2-MDN-ボディーと等しいです。
AS2-MDN-body =
AS2-signed-MDN-body | AS2-unsigned-MDN-body
MDNボディーがAS2がサインされていた状態で、=をAS2-MDN具体化させてください。| AS2の無記名のMDNボディー
7.4.2. AS2-MDN Construction
7.4.2. AS2-MDN工事
The AS2-MDN-body is formatted as a MIME multipart/report with a
report-type of "disposition-notification". When the message is
unsigned, the transfer-layer ("outermost") entity-headers of the
AS2-MDN contain the content-type header that specifies a content-type
AS2-MDN-ボディーはMIME複合/レポートとして「気質通知」のレポートタイプでフォーマットされます。 メッセージが無記名であるときに、AS2-MDNの転送層の(「一番はずれ」)の実体ヘッダーは満足しているタイプを指定する満足しているタイプヘッダーを含んでいます。
Moberg & Drummond Standards Track [Page 26] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[26ページ]RFC4130AS2
of "multipart/report" and parameters indicating the report-type, and the value of the outermost multipart boundary.
「複合/レポート」とパラメタがレポートタイプ、および一番はずれの複合境界の値を示すのについて。
When the AS2-MDN is signed, the transfer-layer ("outermost") entity-
headers of the AS2-MDN contain a content-type header that specifies a
content-type of "multipart/signed" and 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 embedded MIME multipart/report of type
"disposition-notification". The second part of the multipart/signed
message contains a MIME application/pkcs7-signature message.
AS2-MDNがサインされるとき、AS2-MDNの層を移している(「一番はずれ」の)実体ヘッダーは「複合かサインされること」の満足しているタイプを指定する満足しているタイプヘッダーとアルゴリズムが以前はよくメッセージダイジェスト、署名形式プロトコル(例えば、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複合/レポートの第二部は以下と定義される「機械可読な」部分です。
AS2-disposition-notification-content =
[ reporting-ua-field CRLF ]
[ mdn-gateway-field CRLF ]
final-recipient-field CRLF
[ original-message-id-field CRLF ]
AS2-disposition-field CRLF
*( failure-field CRLF )
*( error-field CRLF )
*( warning-field CRLF )
*( extension-field CRLF )
[ AS2-received-content-MIC-field CRLF ]
AS2気質通知内容は最終受理者分野CRLF[元のメッセージイド分野CRLF]AS2気質分野CRLF*(失敗分野CRLF)*(誤り分野CRLF)*(警告分野CRLF)*(拡大分野CRLF)と等しいです[報告しているua分野CRLF][mdnゲートウェイ分野CRLF]。[AS2がMICがさばく内容を受け取っているCRLF]
7.4.3. AS2-MDN Fields
7.4.3. AS2-MDN分野
The rules for constructing the AS2-disposition-notification content are identical to the disposition-notification-content rules provided in Section 7 of RFC 3798 [5], except that the RFC 3798 disposition- field has been replaced with the AS2-disposition-field and that the AS2-received-content-MIC field has been added. The differences between the RFC 3798 disposition-field and the AS2-disposition-field are described below. Where there are differences between this document and RFC 3798, those entity names have been changed by pre- pending "AS2-". Entities that do not differ from RFC 3798 are not necessarily further defined in this document; refer to RFC 3798, Section 7, "Collected Grammar", for the original grammar.
RFC3798気質野原をAS2気質分野とそれに取り替えたのを除いて、AS2が内容MICを受けている分野がRFC3798[5]のセクション7で加えられるなら、AS2気質通知内容を構成するための規則は気質通知内容規則と同じです。 3798年のRFC気質分野とAS2気質分野の違いは以下で説明されます。 このドキュメントとRFC3798の間には、違いがあるところでは、それらの実体名はプレ未定の"AS2"によって変えられました。 RFC3798と異なっていない実体が必ずより詳しく本書では定義されません。 RFC3798、オリジナルの文法のために「文法を集める」というセクション7を参照してください。
Moberg & Drummond Standards Track [Page 27] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[27ページ]RFC4130AS2
AS2-disposition-field =
"Disposition" ":" disposition-mode ";"
AS2-disposition-type [ '/' AS2-disposition-modifier ]
「AS2気質分野=「気質」」:、」 「気質モード」;、」 AS2気質タイプ['/'AS2気質修飾語]
disposition-mode =
action-mode "/" sending-mode
「気質モード=動作モード」/、」 発信モード
action-mode =
"manual-action" | "automatic-action"
動作モードは「手動の動き」と等しいです。| 「自動動作」
sending-mode =
"MDN-sent-manually" | "MDN-sent-automatically"
発信モードは「手動で送られたMDN」と等しいです。| 「自動的に送られたMDN」
AS2-disposition-type =
"processed" | "failed"
AS2気質タイプ=は「処理されました」。| 「失敗されます」。
AS2-disposition-modifier =
( "error" | "warning" ) | AS2-disposition-modifier-extension
AS2気質修飾語=(「誤り」| 「警告」)| AS2気質修飾語拡張子
AS2-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: " AS2-MDN-warning-description |
"failure: " AS2-MDN-failure-description
AS2気質修飾語拡張子が等しい、「誤り:」 「認証で、失敗されています」。| 「誤り:」 「減圧で、失敗されています」。| 「誤り:」 「復号化で、失敗されています」。| 「誤り:」 「不十分なメッセージセキュリティ」| 「誤り:」 「保全チェックは失敗しました」| 「誤り:」 「予期していなかった整理過程の誤差」| 「警告:」 「AS2-MDN警告記述」| 「失敗:」 「AS2-MDN失敗記述」
AS2-MDN-warning-description = *( TEXT )
AS2-MDN警告記述は*と等しいです。(テキスト)
AS2-MDN-failure-description = *( TEXT )
AS2-MDN失敗記述は*と等しいです。(テキスト)
AS2-received-content-MIC-field =
"Received-content-MIC" ":" encoded-message-digest ","
digest-alg-id CRLF
「MICがさばくAS2の受信された内容は「容認された満足しているMIC」と等しい」:、」 」 「コード化されたメッセージダイジェスト」、ダイジェストalgイドCRLF
encoded-message-digest =
1*( 'A'-Z' | 'a'-'z' | '0'-'9' | '/' | '+' | '=' ) (
i.e. base64( message-digest ) )
'コード化されたメッセージダイジェスト=1*(''-Z'| 'a'--'z'| '0'--'9'| '/'| '+ '|'=')(すなわち、base64(メッセージダイジェスト))
digest-alg-id = "sha1" | "md5"
ダイジェストalgイド="sha1""| "md5""
"Insufficient-message-security" and "decompression-failed" are new error codes that are not mentioned in the AS1 RFC 3335, and may not be compatible with earlier implementations of AS2.
「不十分なメッセージセキュリティ」で「減圧で失敗されること」は、AS1 RFC3335で言及されない新しいエラーコードであり、AS2の以前の実現と互換性がないかもしれません。
Moberg & Drummond Standards Track [Page 28] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[28ページ]RFC4130AS2
The "Received-content-MIC" extension field is set when 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ドキュメントを見てください。
For signed messages, the algorithm used to calculate the MIC MUST be the same as that used on the message that was signed. If the message is not signed, then the SHA-1 algorithm SHOULD be used. 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 so that the sender can verify non-repudiation of receipt.
サインされたメッセージに関しては、アルゴリズムは、以前はよくミックがサインされたメッセージで使用されるそれと同じであるに違いないと見込んでいました。 メッセージはサインされないで、次に、SHA-1アルゴリズムはSHOULDです。使用されます。 メッセージの内容が首尾よく処理されるときだけ、この分野は設定されます。 この分野は、送付者が領収書の非拒否について確かめることができるように、MDNにおける受取人の署名に関連して使用されます。
AS2-MDN field names (e.g., "Disposition:", "Final-Recipient:") are case insensitive (cf. RFC 3798, Section 3.1.1). AS2-MDN action- modes, sending-modes, AS2-disposition-types, and AS2-disposition- modifier values, which are defined above, and user-supplied *( TEXT ) values are also case insensitive. AS2 implementations MUST NOT make assumptions regarding the values supplied for AS2-MDN-warning- description or AS2-MDN-failure-description, or for the values of any (optional) error, warning, or failure fields.
AS2-MDNフィールド名、(例えば、「気質:」、「最終受理者:」、)、大文字と小文字を区別しないです。(Cf。 RFC3798、セクション3.1.1). AS2-MDN動作また、モード、発信モード、AS2気質タイプ、およびAS2-気質修飾語値、およびユーザによって供給された*(TEXT)値も大文字と小文字を区別しないです。(値は上で定義されます)。 AS2実現はAS2-MDN-警告記述かAS2-MDN失敗記述に供給された値、またはいずれの値のための仮定を(任意)の誤り、警告、または失敗分野にしてはいけません。
7.4.4. Additional AS2-MDN Programming Notes
7.4.4. 追加AS2-MDNプログラミング上の注意
o Unlike SMTP, for HTTP transactions, Original-Recipient and Final-
Recipient SHOULD not be different. The value in Original-
Message-ID SHOULD match the original Message-ID header value.
o HTTP取引、Original-受取人、およびFinal受取人SHOULDのためのSMTP、異なってください。 Originalメッセージ-ID SHOULDの値は元のMessage-IDヘッダー価値に合っています。
o Refer to RFC 3798 for the formatting of the MDN, except for the
specific deviations mentioned above.
o 前記のように特定の逸脱以外のMDNの形式についてRFC3798を参照してください。
o Refer to RFC 3462 and RFC 3798 for the formatting of the content-
type entity-headers for the MDN.
o RFC3462を参照してください。そうすれば、内容の形式のためのRFC3798はMDNのために実体ヘッダーをタイプします。
o Use an action-mode of "automatic-action" when the disposition
described by the disposition type was a result of an automatic
action rather than that of an explicit instruction by the user for
this message.
o 気質タイプによって説明された気質がユーザによる明白な指示のものよりむしろこのメッセージのための自動動作の結果であったときには「自動動作」の動作モードを使用してください。
o 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.
o 気質タイプによって説明された気質がある種の自動的に実行された動作よりむしろユーザによる明白な指示の結果であったときには「手動の動き」の動作モードを使用してください。
Moberg & Drummond Standards Track [Page 29] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[29ページ]RFC4130AS2
o Use a sending-mode of "MDN-sent-automatically" when the MDN is
sent because the UA had previously been configured to do so.
o UAが以前にそうするために構成されたのでMDNを送るときには「自動的に送られたMDN」の発信モードを使用してください。
o Use a sending-mode of "MDN-sent-manually" when the user explicitly
gave permission for this particular MDN to be sent.
o ユーザが明らかにこの特定のMDNが送られる許可を与えたときには「手動で送られたMDN」の発信モードを使用してください。
o The sending-mode "MDN-sent-manually" is meaningful ONLY with
"manual-action", not with "automatic-action".
o 「自動動作」ゆえ重要であるのではなく、発信モード「手動で送られたMDN」は「手動の動き」だけゆえ重要です。
o The "failed" disposition type MUST 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.
o MDNを求める要求を解釈する以外のメッセージを処理するのにおいて何らかの問題がある状況に「失敗した」気質タイプを使用してはいけません。 適切な気質修飾語がある「処理された」か他の気質タイプはそのような状況で使用されることになっています。
7.5. Disposition Mode, Type, and Modifier
7.5. 気質モード、タイプ、および修飾語
7.5.1. Disposition Mode Overview
7.5.1. 気質モード概観
This section provides a brief overview of how "processed", "error", "failure", and "warning" are used.
このセクションは「処理されてい」て、「誤り」、「失敗」、および「警告」がどう使用されているかに関する簡潔な概観を提供します。
7.5.2. Successful Processing Status Indication
7.5.2. うまくいっている処理状態指示
When the request for a receipt or signed receipt, 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". 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.
首尾よく処理されて、受信EDI UA、領収書またはMDN SHOULDによって、領収書かサインされた領収書を求める要求、および受信されたメッセージ内容がそうであるときには気質タイプセットで「処理されること」に返されてください。 MDNがいつEDI UAによって自動的にそこに送られるかは、ユーザがMDNの発信を制御する明白な方法でなく、次に、「気質モード」の最初の部分はSHOULDです。「自動動作」に設定されます。 MDNであるときに、次に、ユーザの構成可能なコントロール、「気質モード」の最初の部分の下に送るのは、SHOULDです。「マニュアル動作」に設定されてください。 サインされた領収書を求める要求がいつも光栄に思うべきであるので、ユーザに送付者が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 the control of a user, administrator, or software.
ユーザがMDNが送られる明白な許可を与えたなら、気質モードの第二部は「手動で送られたMDN」に設定されます。 一方、ユーザに送付者が1つを要求するとき、サインされた領収書を送るのを明らかに拒否させてはいけません。 EDI UAが自動的にMDNを送るときはいつも、「気質モード」の第二部は「自動的に送られたMDN」に設定されます、発信がユーザ、管理者、またはソフトウェアのコントロールの下にあったことにかかわらず。
Because 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によって一般に自動的に扱われるので、一般に、領収書かサインされた領収書を求める要求は「気質分野」で以下を返すでしょう:
Moberg & Drummond Standards Track [Page 30] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[30ページ]RFC4130AS2
Disposition: automatic-action/MDN-sent-automatically; processed
気質: MDNは自動的に自動動作/発信していました。 処理されます。
Note that this specification does not restrict the use of the "disposition-mode" just to 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" values that should be used if the message content is being rejected or ignored (for instance, if the EDI UA determines that a signed receipt cannot be returned because it does not support the requested protocol format, the EDI UA chooses not to process the message contents itself) MUST be specified in the MDN "disposition-field" as follows:
サインされた領収書を求める要求は返されたサインされた領収書のプロトコル形式を指定する2「気質通知オプション」とメッセージ内容に関してMICについて計算するのに使用されるMICアルゴリズムの使用を必要とします。 以下のMDN「気質分野」でメッセージ内容が拒絶されるか、または無視されているなら(例えば、EDI UAが、要求されたプロトコル形式を支持しないのでサインされた領収書を返すことができないことを決定するなら、EDI UAは、メッセージコンテンツ自体を処理しないのを選びます)使用されるべきである「気質分野」値を指定しなければなりません:
Disposition: "disposition-mode"; failed/Failure:
unsupported format
気質: 「気質モード」。 失敗した/失敗: サポートされない形式
The "failed" AS2-disposition-type MUST be used when a failure occurs that prevents the proper generation of an MDN. For example, this disposition-type would apply if the sender of the message requested the application of an unsupported message-integrity-check (MIC) algorithm.
MDNの適切な世代を防ぐ失敗が起こるとき、「失敗した」AS2気質タイプを使用しなければなりません。 例えば、メッセージ送信者がサポートされないメッセージ保全チェック(MIC)アルゴリズムの申込み書を要求するなら、この気質タイプは当てはまるでしょうに。
The "failure:" AS2-disposition-modifier-extension SHOULD be used with an implementation-defined description of the failure. Further information about the failure may be contained in a failure-field.
「失敗:」 AS2気質修飾語拡張子SHOULD、失敗の実現で定義された記述と共に使用されてください。 失敗に関する詳細は失敗分野に保管されるかもしれません。
The syntax of the "failed" disposition-type is general, allowing the sending of any textual information along with the "failed" disposition-type. Implementations MUST support any printable textual characters after the Failure disposition-type. For use in Internet EDI, the following "failed" values are pre-defined and MUST be supported:
「失敗した」気質タイプに伴うどんな文字情報の発信も許して、「失敗した」気質タイプの構文は一般的です。 実現はFailure気質タイプの後にどんな印刷可能な原文のキャラクタも支持しなければなりません。 インターネットEDIにおける使用において、以下の「失敗した」値を事前に定義されて、支持しなければなりません:
"Failure: unsupported format"
「失敗:」 「サポートされない形式」
"Failure: unsupported MIC-algorithms"
「失敗:」 「サポートされないMIC-アルゴリズム」
Moberg & Drummond Standards Track [Page 31] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[31ページ]RFC4130AS2
7.5.4. Unsuccessful Non-Content Processing
7.5.4. 失敗の非内容処理
When errors occur in processing the received message (other than content), the "disposition-field" MUST be set to the "processed" value for disposition-type and the "error" value for disposition- modifier.
誤りが受信されたメッセージ(内容を除いた)を処理する際に発生するとき、「気質分野」は気質タイプのための「処理された」値と気質修飾語のための「誤り」値へのセットであるに違いありません。
The "error" AS2-disposition-modifier with the "processed" disposition-type MUST be used to indicate that an error of some sort occurred that prevented successful processing of the message. Further information may be contained in an error-field.
メッセージのうまくいっている処理を防いだある種の誤りが発生したのを示すのに「処理された」気質タイプとの「誤り」AS2気質修飾語を使用しなければなりません。 詳細は誤り分野に保管されるかもしれません。
An "error:" AS2-disposition-modifier-extension SHOULD be used to combine the indication of an error with a predefined description of a specific, well-known error. Further information about the error may be contained in an error field.
「誤り:」 AS2気質修飾語拡張子SHOULD、使用されて、特定の、そして、周知の誤りの事前に定義された記述に誤りのしるしを結合してください。 誤りに関する詳細は誤り分野に保管されるかもしれません。
For internet EDI use, the following "error" AS2-disposition-modifier values are defined:
インターネットEDI使用において、以下の「誤り」AS2気質修飾語値は定義されます:
o "Error: decryption-failed" - the receiver could not
decrypt the message
contents.
o 「誤り:」 「復号化で失敗される」--受信機は、メッセージがコンテンツであると解読することができませんでした。
o "Error: authentication-failed" - the receiver could not
authenticate the sender.
o 「誤り:」 「認証で失敗される」--受信機は送付者を認証できませんでした。
o "Error: integrity-check-failed" - the receiver could not
verify content integrity.
o 「誤り:」 「保全チェックは失敗しました」--受信機は満足している保全について確かめることができませんでした。
o "Error: unexpected-processing-error" - a catch-all for any
additional processing
errors.
o 「誤り:」 「予期していなかった整理過程の誤差」--どんな追加整理過程の誤差のためのキャッチすべて。
An example of how the "disposition-field" would look when errors other than those in content processing are detected is as follows:
満足している処理におけるそれら以外の誤りが検出されるとき、「気質分野」がどう見えるだろうかに関する例は以下の通りです:
Disposition: "disposition-mode"; processed/Error:
decryption-failed
気質: 「気質モード」。 処理/誤り: 復号化で、失敗されています。
7.5.5. Processing Warnings
7.5.5. 処理警告
Situations arise in EDI when, 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
正しく貿易相手国を認証できないでも、貿易相手国が、EDI取引を処理し続けているのにまだ同意しているとき、状況はEDIに起こります。 後で貿易相手国の間で取引和解をします。 内容で
Moberg & Drummond Standards Track [Page 32] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[32ページ]RFC4130AS2
processing warning situations as described above, the "disposition- field" MUST be set to the "processed" disposition-type value, and the "warning" to the "disposition-modifier" value.
上で説明される処理警告状況、「処理された」気質タイプ値、および「気質修飾語」値への「警告」に「気質分野」を設定しなければなりません。
The "warning" AS2-disposition-modifier MUST be used with the "processed" disposition-type to indicate that the message was successfully processed but that an exceptional condition occurred. Further information may be contained in a warning-field.
メッセージが首尾よく処理されましたが、例外的な状態が現れたのを示すのに「処理された」気質タイプで「警告」AS2気質修飾語を使用しなければなりません。 詳細は警告分野に保管されるかもしれません。
A "warning:" AS2-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.
「警告:」 AS2気質修飾語拡張子SHOULD、使用されて、警告の実現で定義された記述による警告のしるしを結合してください。 警告に関する詳細は警告分野に保管されるかもしれません。
For use in Internet EDI, the following "warning" disposition-modifier-extension value is defined:
インターネットEDIにおける使用において、以下の「警告」気質修飾語拡大価値は定義されます:
"Warning: authentication-failed, processing continued"
「警告:」 「認証によって失敗されていて、処理は続きました」
An example of how the "disposition-field" would look when warning other than those for content processing are detected is as follows:
内容のためのそれらを除いて、処理が検出されると警告するとき、「気質分野」がどう見えるだろうかに関する例は以下の通りです:
Example:
例:
Disposition: "disposition-mode"; processed/Warning:
authentication-failed, processing continued
気質: 「気質モード」。 処理されるか、または警告します: 認証によって失敗されていて、処理は続きました。
7.5.6. Backward Compatibility with Disposition Type, Modifier, and
Extension
7.5.6. 気質タイプ、修飾語、および拡大との後方の互換性
The following set of examples represents typical constructions of the Disposition field that have been in use by AS2 implementations. This is NOT an exhaustive list of possible constructions. However, AS2 implementations MUST accept constructions of this type to be backward compatible with earlier AS2 versions.
以下のセットの例はDisposition分野のAS2実現で使用中である典型的な構造を表します。 これは可能な構造に関する完全なりストではありません。 しかしながら、AS2実現は、このタイプの構造が以前のAS2バージョンと互換性があった状態で後方であると受け入れなければなりません。
Disposition: automatic-action/MDN-sent-automatically; processed
気質: MDNは自動的に自動動作/発信していました。 処理されます。
Disposition: automatic-action/MDN-sent-automatically;
processed/error: authentication-failed
気質: MDNは自動的に自動動作/発信していました。 処理/誤り: 認証で、失敗されています。
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
気質: MDNは自動的に自動動作/発信していました。 処理されるか、または警告します: 写しドキュメント
Disposition: automatic-action/MDN-sent-automatically;
failed/failure: sender-equals-receiver
気質: MDNは自動的に自動動作/発信していました。 失敗した/失敗: 送付者は受信機と等しいです。
Moberg & Drummond Standards Track [Page 33] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[33ページ]RFC4130AS2
The following set of examples represents allowable constructions of the Disposition field that combine the historic constructions above with optional RFC 3798 error, warning, and failure fields. AS2 implementations MAY produce these constructions. However, AS2 servers are not required to recognize or process optional error, warning, or failure fields at this time. Note that the use of the multiple error fields in the second example below provides for the indication of multiple error conditions.
以下のセットの例は3798年の任意のRFC誤り、警告、および失敗分野による上の歴史的な構造を結合するDisposition分野の許容できる構造を表します。 AS2実現はこれらの構造を発生させるかもしれません。 しかしながら、AS2サーバは、このとき任意の誤り、警告、または失敗分野を認識するか、または処理するのに必要ではありません。 以下の2番目の例における複数の誤り分野の使用が複数のエラー条件のしるしに備えることに注意してください。
Disposition: automatic-action/MDN-sent-automatically; processed
気質: MDNは自動的に自動動作/発信していました。 処理されます。
Disposition: automatic-action/MDN-sent-automatically;
processed/error: decryption-failed
Error: The signature did not decrypt into a valid PKCS#1
Type-2 block.
Error: The length of the decrypted key does not equal the
octet length of the modulus.
気質: MDNは自動的に自動動作/発信していました。 処理/誤り: 復号化で失敗したError: 署名は、#、が1つのType-2ブロックであると有効なPKCSに解読しませんでした。 誤り: 解読されたキーの長さは係数の八重奏の長さと等しくはありません。
Disposition: automatic-action/MDN-sent-automatically;
processed/warning: duplicate-document
Warning: An identical message already exists at the
destination server.
気質: MDNは自動的に自動動作/発信していました。 処理されるか、または警告します: 写しドキュメントWarning: 同じメッセージは目的地サーバで既に存在しています。
Disposition: automatic-action/MDN-sent-automatically;
failed/failure: sender-equals-receiver
Failure: The AS2-To name is identical to the AS2-From name.
気質: MDNは自動的に自動動作/発信していました。 失敗した/失敗: 送付者が受信機と等しいFailure: AS2、-、名前が同じである、AS2、-、名前。
The following set of examples represents allowable constructions of the Disposition field that employ pure RFC 3798 Disposition-modifiers with optional error, warning, and failure fields. These examples are provided as informational only. These constructions are not guaranteed to be backward compatible with AS2 implementations prior to version 1.1.
以下のセットの例は任意の誤り、警告、および失敗分野で純粋なRFC3798Disposition-修飾語を使うDisposition分野の許容できる構造を表します。 例が情報として提供されるこれら専用。 これらの構造は、バージョン1.1の前のAS2実装と互換性があった状態で後方であるために保証されません。
Disposition: automatic-action/MDN-sent-automatically; processed
気質: MDNは自動的に自動動作/発信していました。 処理されます。
Disposition: automatic-action/MDN-sent-automatically;
processed/error
Error: authentication-failed
Error: The signature did not decrypt into a valid PKCS#1 Type-2
block.
Error: The length of the decrypted key does not equal the
octet length of the modulus.
気質: MDNは自動的に自動動作/発信していました。 処理/誤りError: 認証で失敗したError: 署名は、#、が1つのType-2ブロックであると有効なPKCSに解読しませんでした。 誤り: 解読されたキーの長さは係数の八重奏の長さと等しくはありません。
Disposition: automatic-action/MDN-sent-automatically;
processed/warning
Warning: duplicate-document
気質: MDNは自動的に自動動作/発信していました。 処理されたか警告しているWarning: 写しドキュメント
Moberg & Drummond Standards Track [Page 34] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[34ページ]RFC4130AS2
Disposition: automatic-action/MDN-sent-automatically; failed
Failure: sender-equals-receiver
気質: MDNは自動的に自動動作/発信していました。 失敗したFailure: 送付者は受信機と等しいです。
7.6. Receipt Reply Considerations in an HTTP POST
7.6. HTTPポストによる領収書回答問題
The details of the response to the POST command vary depending upon whether a receipt has been requested.
領収書が要求されているかどうかによって、ポストコマンドへの応答の詳細は異なります。
With no extended header requesting a receipt, and with no errors accessing the request-URI specified processing, the status line in the Response to the POST request SHOULD be in the 200 range. Status codes in the 200 range SHOULD also be used when an entity is returned (a signed receipt in a multipart/signed content type or an unsigned receipt in a multipart/report). Even when the disposition of the data was an error condition at the authentication, decryption or other higher level, the HTTP status code SHOULD indicate success at the HTTP level.
領収書を要求しないどんな拡張ヘッダーとも、そして、要求URIの指定された処理、Responseの状況表示行にポスト要求SHOULDにアクセスする誤りなしで、200範囲にいてください。 状態は200範囲でSHOULDをコード化します、また、(複合/レポートの複合の、または、署名しているcontent typeか未署名の領収書の署名している領収書)を実体に返すときには、使用してください。 データの気質が認証、復号化または他の、より高いレベルにおいてエラー条件でさえあったときに、HTTPステータスコードSHOULDはHTTPレベルで成功を示します。
The HTTP server-side application may respond with an unsolicited multipart/report as a message body that the HTTP client might not have solicited, but the client may discard this. Applications SHOULD avoid emitting unsolicited receipt replies because bandwidth or processing limitations might have led administrators to suspend asking for acknowledgements.
HTTPサーバサイドアプリケーションは、メッセージ本体として求められていない複合/レポートでHTTPクライアントが請求していないかもしれませんが、クライアントがこれを捨てるかもしれないと応答するかもしれません。 アプリケーションSHOULDは、帯域幅か処理制限が、管理者が承認のための尋ねることを中断させるように導いたかもしれないので求められていない領収書回答を放つのを避けます。
Message Disposition Notifications, when used in the HTTP reply context, will closely parallel a SMTP MDN. For example, the disposition field is a required element in the machine-readable second part of a multipart/report for a MDN. The final-recipient- field ([5], Section 3.1) value SHOULD be derived from the entity headers of the request.
HTTP回答文脈で使用されると、メッセージDisposition Notificationsは密接にSMTP MDNに沿うでしょう。 例えば、気質分野はMDNのための複合/レポートの機械可読な第二部の必要な要素です。 最終受理者分野([5]、セクション3.1) 要求の実体ヘッダーから派生していた状態でSHOULDを評価してください。
In an MDN, the first part of the multipart/report (the human-readable part) SHOULD include items such as the subject, the date, and other information when those fields are present in entity header fields following the POST request. An application MUST report the Message- ID of the request in the second part of the multipart/report (the machine-readable part). Also, an MDN SHOULD have its own unique Message-ID HTTP header. The HTTP reply SHOULD normally omit the third optional part of the multipart/report (used to return the original message or its headers in the SMTP context).
MDN、SHOULDが含む複合/レポート(人間読み込み可能な部分)の最初の部分では、ポストの要求に続いて、対象や、日付や、それらの分野がいつかという他の情報などの項目が実体でヘッダーフィールドを提示します。 アプリケーションは複合/レポート(機械可読な部分)の第二部における要求のMessage IDを報告しなければなりません。 また、MDN SHOULDには、それ自身のユニークなMessage-ID HTTPヘッダがあります。 通常、HTTP回答SHOULDは複合/レポート(以前はSMTP文脈でよくオリジナルのメッセージかそのヘッダーを返していた)の3番目の任意の部分を省略します。
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,
近いうちに、商事組合を確立するプロセスの一部として公開鍵の交換とこれらのキーの証明を扱わなければなりません。 UA、そして/または、EDIアプリケーション・インターフェースは暗号化か署名に使用される公開鍵に関するデータベースを維持しなければなりません。
Moberg & Drummond Standards Track [Page 35] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[35ページ]RFC4130AS2
in addition to the mapping between the EDI trading partner ID and the RFC 2822 [9] email address and HTTP URL/URI. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages.
EDI貿易相手国IDと、RFC2822[9]EメールアドレスとHTTP 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. The use of a certification authority is therefore OPTIONAL. Certificates may be self-signed.
X.509証明書はREQUIREDです。 同意している証明権威が使用されていないなら貿易相手国が自己に互いを公認するのは、RECOMMENDEDです。 この適用性証明は証明権威の使用を必要としません。 したがって、証明権威の使用はOPTIONALです。 証明書は自己に署名されるかもしれません。
It is RECOMMENDED that when trading partners are using S/MIME they also exchange public key certificates, considering advice provided in [12].
また、貿易相手国がS/MIMEを使用しているとき公開鍵証明書を交換するのは、RECOMMENDEDです、[12]に提供されたアドバイスを考える場合。
The message formats useful for certificate exchange are found in [7] and [13].
証明書交換の役に立つメッセージ・フォーマットは[7]と[13]で見つけられます。
In the long term, additional standards may be developed to simplify the process of establishing a trading partnership, including the third-party authentication of trading partners, as well as the attributes of the trading relationship.
長期で、追加規格は商事組合を確立するプロセスを簡素化するために開発されるかもしれません、貿易相手国の第三者認証を含んでいて、取り引き関係の属性と同様に。
9. Security Considerations
9. セキュリティ問題
This entire document is concerned with secure transport of business to business data, and it considers both data confidentiality and authentication issues.
この全体のドキュメントは企業間電子商取引データの安全な輸送に関係があります、そして、それはデータの機密性と認証問題の両方を考えます。
Extracted from RFC 3851 [7]: 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 Triple DES 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 of the relative cryptographic strength of messages.
RFC3851[7]から抽出される: 40ビットの暗号化は弱いとほとんどの暗号使用者によって考えられます。 S/MIMEに弱い暗号を使用するのはほとんど送付平文の上に実際のセキュリティを提供しません。 しかしながら、Triple DESの仕様などのS/MIMEの他の特徴とあなたと交信するパーティーへの、より強い暗号の能力を発表する能力で、送付者は強い暗号化を使用するメッセージを作成できます。 弱い暗号を使用するのは唯一の選択肢が暗号であるなら決してお勧めではありません。 可能であるときに、送受信エージェントSHOULDはメッセージの相対的な暗号の強さについて送付者と受取人に知らせます。
Extracted from RFC 3850 [12]: 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 have not been listed, however, the reader should not assume
RFC3850[12]から抽出される: 証明書を処理するとき、多くの状況が処理が失敗するかもしれないところにあります。 ユーザエージェント、セキュリティゲートウェイ、または他のプログラムで処理をするかもしれないので、そのような失敗を扱うどんなただ一つの方法もありません。 しかしながら、失敗を扱うメソッドが記載されているだけではないので、読者が記載されているべきでない、仮定
Moberg & Drummond Standards Track [Page 36] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[36ページ]RFC4130AS2
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 situations in which signature and certificate checking might fail include the following:
署名と証明書の照合が失敗するかもしれない多くの状況のいくつかが以下を含んでいます:
o No certificate chain leads to a trusted CA.
o どんな証明書チェーンも信じられたカリフォルニアに通じません。
o No ability to check the Certificate Revocation List (CRL) for a
certificate.
o 証明書がないかどうかCertificate Revocation List(CRL)をチェックする能力がありません。
o An invalid CRL was received.
o 無効のCRLを受け取りました。
o The CRL being checked is expired.
o チェックされるCRLは満期です。
o The certificate is expired.
o 証明書は満期です。
o The certificate has been revoked.
o 証明書は取り消されました。
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. See RFC 3280 for additional information on certificate path validation.
確かに、チェックが失敗するなら、他のインスタンスが証明書が無効であるかもしれなく、それらを皆、徹底的にチェックして、何をしたらよいかを決めるのが、処理ソフトウェアの責任であるところにあります。 証明書経路合法化の追加情報に関してRFC3280を見てください。
The following are additional security considerations to those listed in [7] and [12].
↓これは[7]と[12]に記載されたものへの追加担保問題です。
9.1. NRR Cautions
9.1. NRR警告
This specification seeks to provide multiple mechanisms that can be combined in accordance with local policies to achieve a wide range of security needs as determined by threat and risk analyses of the business peers. It is required that all these mechanisms be implemented by AS2 software so that the software has capabilities that promote strong interoperability, no matter what policies are adopted.
この仕様はローカルの方針によると、ビジネス同輩の脅威とリスク分析で決定するようにさまざまな安全要求を達成するために結合できる複数のメカニズムを提供しようとします。 ソフトウェアには、これらのすべてのメカニズムがAS2ソフトウェアで実装されるのが必要であるので、強い相互運用性を促進する能力があります、どんな方針が採られても。
One strong cluster of mechanisms (the secure transmission loop) can provide good support for meeting the evidentiary needs of non- repudiation of receipt by the original sender and by a third party supplied with all stated evidence. However, this specification does not itself define non-repudiation of receipt nor enumerate its essential properties because NRR is a business analysis and/or legal requirement, and not relevantly defined by a technical applicability statement.
メカニズム(安全なトランスミッション輪)の1個の強いクラスタがすべての述べられた証拠が供給された元の送り主と第三者による領収書の非拒否の証拠となる需要を満たす良いサポートを提供できます。 しかしながら、領収書の非拒否を定義して、NRRが企業分析、そして/または、法的必要条件であるので不可欠の特性を数え上げて、技術的な適用性証明によって適切に定義されないで、この仕様はそれ自体をするというわけではありません。
Moberg & Drummond Standards Track [Page 37] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[37ページ]RFC4130AS2
Some analyses observe that non-repudiation of receipt presupposes that non-repudiation of the sender of the original message is obtained, and further that non-repudiation should be implemented by means of digital signature on the original message. To satisfy strict NRR evidence, authentication and integrity MUST be provided by some mechanism, and the RECOMMENDED mechanism is digital signatures on both the original message and the receipt message.
いくつかの分析が、領収書の非拒否がオリジナルのメッセージの送付者の非拒否を得て、さらに、オリジナルのメッセージにおけるデジタル署名によってその非拒否を実装するべきであるのを予想するのを観測します。 厳しい状態で満足させるために、何らかのメカニズムでNRR証拠、認証、および保全を提供しなければなりません、そして、RECOMMENDEDメカニズムはオリジナルのメッセージと領収書メッセージの両方におけるデジタル署名です。
Given that this specification has selected several mechanisms that can be combined in several ways, it is important to realize that if a digital signature is omitted from the original message, in order to satisfy the preceding analysis of NRR requirements, some authentication mechanism MUST accompany the request for a signed receipt and its included Received-content-MIC value. This authentication might come from using client-side SSL, authentication via IPsec, or HTTP authentication (while using SSL). In any case, records of the message content, its security basis, and the digest value need to be retained for the NRR process.
この仕様がいくつかの方法で結合できる数個のメカニズムを選択したなら、デジタル署名がNRR要件の前の分析を満たすためにオリジナルのメッセージから省略されるなら、何らかの認証機構が署名している領収書を求める要求とその含まれているReceivedの満足しているMIC値に伴わなければならないとわかるのは重要です。 この認証はクライアントサイドSSL、IPsecを通した認証、またはHTTP認証を使用するのから来るかもしれません(SSLを使用している間)。 どのような場合でも、メッセージ内容、セキュリティ基礎、およびダイジェスト価値に関する記録は、NRRプロセスのために保有される必要があります。
Therefore, if NRR is one of the goals of the policy that is adopted, by using the mechanisms of the secure transmission loop mentioned above and by retaining appropriate records of authentication at the original message sender site, strong evidentiary requirements proposed for NRR can be fulfilled.
したがって、NRRが前記のように安全なトランスミッション輪のメカニズムを使用して、元のメッセージ送付者サイトで認証の適切な記録を保有することによって採られる方針の目標の1つであるなら、NRRのために提案された強い証拠となる要件が実現できます。
Other ways of proceeding may fall short of fulfilling the most stringent sets of evidence required for NRR to obtain, but may nevertheless be part of a commercial trading agreement and, as such, are good enough for the parties involved. However, if MDNs are returned unsigned, evidentiary requirements for NRR are weak; some authentication of the identity of the receiver is needed.
進行の他の道は、NRRに必要である証拠の入手する中で最も厳しいセットを実現させるのに及ばないかもしれませんが、それにもかかわらず、商業取り引き協定の一部であるかもしれなく、かかわったパーティーには、十分そういうものとして良いです。 しかしながら、MDNsを返すなら、NRRのための未署名の、そして、証拠となる要件は弱いです。 受信機のアイデンティティの何らかの認証が必要です。
9.2. HTTPS Remark
9.2. HTTPS注意
The following certificate types MUST be supported for SSL server-side certificates:
SSLサーバサイド証明書のために以下の証明書タイプをサポートしなければなりません:
o with URL in the Distinguished Name Common Name attribute
o Distinguished Name俗称属性におけるURLで
o without URL in the Distinguished Name Common Name attribute
o Distinguished Name俗称属性におけるURLなしで
o self-signed (self-issued)
o 自己に署名されます。(自己に発行されます)
o certification authority certified
o 権威が公認した証明
The URL, which matches the source server identity, SHOULD be carried in the certificate. However, it is not required that DNS checks or reverse lookups to vouch for the accuracy of the URL or server value.
URL。(そのURLは運ばれたコネが証明書であったならソースサーバのアイデンティティ、SHOULDに合っています)。 しかしながら、DNSがURLかサーバ価値の精度を保証するためにチェックするか、またはルックアップを覆すのが必要ではありません。
Moberg & Drummond Standards Track [Page 38] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[38ページ]RFC4130AS2
Because server-side certificates are exchanged, and also trust is established during the configuration of the trading partner relationship, runtime checks are not required by implementations of this specification.
サーバサイド証明書を交換して、また、貿易相手国関係の構成の間、信頼を確立するので、ランタイムチェックはこの仕様の実装によって必要とされません。
The complete certification chain MUST be included in all certificates. All certificate verifications MUST "chain to root" or to an accepted trust anchor. Additionally, the certificate hash SHOULD match the hash recomputed by the receiver.
すべての証明書に完全な証明チェーンを含まなければなりません。 すべての証明書検証が、「根づくために、鎖を作る」か、または受け入れられた信頼に投錨されなければなりません。 さらに、証明書ハッシュSHOULDは受信機によって再計算されたハッシュに合っています。
9.3. Replay Remark
9.3. 再生注意
Because business data documents normally contain transaction ids, replays (such as resends of not-yet-acknowledged messages) are discarded as part of the normal process of duplicate detection. Detection of duplicates by Message-Id or by business transaction identifiers is recommended.
通常、データドキュメントはビジネスであるので、トランザクションイドを含んでいます、再生、(再送、まだ承認されなかったメッセージ) 写し検出の正常なプロセスの一部として、捨てられます。 Message-イドか企業取引識別子による写しの検出はお勧めです。
10. IANA Considerations
10. IANA問題
RFC 3335 registered two Disposition-Notification-Options parameters
RFC3335は2つのDisposition通知オプションパラメタを示しました。
Parameter-name: signed-receipt-protocol
Parameter-name: signed-receipt-micalg
パラメタ名: 署名している領収書プロトコルParameter-名: 署名している領収書micalg
that are also used by this specification (see Section 7.3).
また、それはこの仕様で使用されます(セクション7.3を見てください)。
RFC 3335 also registered on MDN Extension field name
また、MDN Extensionフィールド名に登録されたRFC3335
Extension field name: Received-content-MIC
拡大フィールド名: 容認された満足しているMIC
that is also used by this specification (see Section 7.4.3). Registration of the above is therefore NOT needed.
また、それはこの仕様で使用されます(セクション7.4.3を見てください)。 したがって、上記での登録は必要ではありません。
10.1. Registration
10.1. 登録
This specification defines an extension to the Message Disposition Notification (MDN) protocol for a disposition-modifier in the Disposition field of a body of content-type "message/disposition- notification".
この仕様はcontent typeのボディーのDisposition分野の気質修飾語のためにMessage Disposition Notification(MDN)プロトコルと拡大を定義します。「メッセージ/気質通知。」
10.1.1. Disposition Modifier 'warning'
10.1.1. 気質修飾語'警告'
Parameter-name: warning Semantics: See Sections 7.4.3 and 7.5.5 of this document.
パラメタ名: 警告Semantics: セクション7.4.3とこの.5が記録する7.5を見てください。
Moberg & Drummond Standards Track [Page 39] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[39ページ]RFC4130AS2
11. Acknowledgements
11. 承認
Carl Hage, Karen Rosenfeld, Chuck Fenton, and many others have provided valuable suggestions that improved this applicability statement. The authors would also like to thank the vendors who participated in the Drummond Group Inc. AS2 interoperability testing. Their contributions led to great improvement in the clarity of this document.
カール・ヘイグ、カレン・ローゼンフェルド、チャック・フェントン、および多くの他のものがこの適用性証明を改良した貴重な提案を提供しました。 また、作者はドラモンドのGroup株式会社AS2相互運用性テストに参加したベンダーに感謝したがっています。 彼らの貢献はこのドキュメントの明快におけるかなりの改良につながりました。
12. References
12. 参照
12.1. Normative References
12.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] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[3] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[4] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure
Peer-to-Peer Business Data Interchange over the Internet", RFC
3335, September 2002.
[4] ハーディング、T.、ドラモンド、R.、およびC.Shih、「MIMEベースの安全なピアツーピア業務データはインターネットの上で交換します」、RFC3335、2002年9月。
[5] Hansen, T. and G. Vaudreuil, "Message Disposition Notification",
RFC 3798, May 2004.
[5] ハンセン、T.、およびG.ボードルイ(「メッセージ気質通知」、RFC3798)は2004がそうするかもしれません。
[6] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[6] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「署名していて複合の/が暗号化した複合/」、RFC1847、1995年10月。
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, July
2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1メッセージ仕様であると機密保護する」[7]、RFC3851、2004年7月。
Moberg & Drummond Standards Track [Page 40] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[40ページ]RFC4130AS2
[8] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 3462,
January 2003.
[8] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポートcontent type」、RFC3462、2003年1月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[10] Murata, M., Laurent, S. St., and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[10] ムラタとM.とローラン、S.通りとD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[11] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[11] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
Ramsdell(B.)が「/マルチパーパスインターネットメールエクステンション(S/MIME)バージョン3.1証明書取り扱いであると機密保護する」[12]、RFC3850、2004年7月。
[13] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[13]Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[14] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
12.2. Informative References
12.2. 有益な参照
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[15] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
Moberg & Drummond Standards Track [Page 41] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[41ページ]RFC4130AS2
Appendix A: Message Examples
付録A: メッセージの例
NOTE: All examples are provided for illustration only, and are not considered part of the protocol specification. If an example conflicts with the protocol definitions specified above or in the other referenced RFCs, the example is wrong.
以下に注意してください。 すべての例が、イラストだけに提供されて、プロトコル仕様の一部であると考えられるというわけではありません。 例がRFCsの上、または、他の参照をつけられたRFCsで指定されるプロトコル定義と闘争するなら、例は間違っています。
A.1. Signed Message Requesting a Signed, Synchronous Receipt
A.1。 署名していて、同期の領収書を要求するメッセージであると署名されます。
POST /receive HTTP/1.0
Host: 10.234.160.12:80
User-Agent: AS2 Company Server
Date: Wed, 31 Jul 2002 13:34:50 GMT
From: mrAS2@example.com
AS2-Version: 1.1
AS2-From: "\" as2Name \""
AS2-To: 0123456780000
Subject: Test Case
Message-Id: <200207310834482A70BF63@\"~~foo~~\">
Disposition-Notification-To: mrAS2@example.com
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Content-Type: multipart/signed; boundary="as2BouNdary1as2";
protocol="application/pkcs7-signature"; micalg=sha1
Content-Length: 2464
HTTP/1.0ホストを掲示するか、または受けてください: 10.234.160.12:80ユーザエージェント: AS2会社サーバ日付: グリニッジ標準時2002年7月31日水曜日13時34分50秒From: mrAS2@example.com AS2-バージョン: 1.1 AS2-From: 「「\」as2Name\、」 」 AS2-To: 0123456780000 Subject: テストケースメッセージイド: 「<200207310834482A70BF63@\」~~foo~~\「>気質通知To:」 mrAS2@example.com 気質通知オプション: 署名している領収書プロトコル=任意である、pkcs7-署名。 署名している領収書-micalgは任意のsha1コンテントタイプと等しいです: 複合か署名される。 境界は"as2BouNdary1as2""と等しいです。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 micalg=sha1 Content-長さ: 2464
--as2BouNdary1as2
Content-Type: application/edi-x12
Content-Disposition: Attachment; filename=rfc1767.dat
[ISA ...EDI transaction data...IEA...]
--as2BouNdary1as2コンテントタイプ: edi-x12 Contentアプリケーション/気質: 付属。 ファイル名=rfc1767.dat[ISA…EDI変更用データ… IEA]
--as2BouNdary1as2 Content-Type: application/pkcs7-signature
--as2BouNdary1as2コンテントタイプ: pkcs7アプリケーション/署名
[omitted binary pkcs7 signature data]
--as2BouNdary1as2--
[省略された2進のpkcs7署名データ]--as2BouNdary1as2--
A.2. MDN for Message A.1, Above
A.2。 上のメッセージA.1のためのMDN
HTTP/1.0 200 OK
AS2-From: 0123456780000
AS2-To: "\" as2Name \""
AS2-Version: 1.1
Message-ID: <709700825.1028122454671.JavaMail@ediXchange>
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_57_648441049.1028122454671"
Connection: Close
HTTP/1.0 200OK AS2-From: 0123456780000 AS2-To: 「「\」as2Name\、」 」 AS2-バージョン: 1.1Message ID: <709700825.1028122454671.JavaMail@ediXchange>コンテントタイプ: 複合か署名される。 micalg=sha1。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 「境界=」----=_「パート_57_648441049.1028122454671」接続: 閉鎖
Moberg & Drummond Standards Track [Page 42] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[42ページ]RFC4130AS2
Content-Length: 1980
コンテンツの長さ: 1980
------=_Part_57_648441049.1028122454671
------=_パート_57_648441049.1028122454671
& 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@\"~~foo~~\"> & From: "\" as2Name \"" & To: "0123456780000" & 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: AS2 Server &Original-Recipient: rfc822; 0123456780000 &Final-Recipient: rfc822; 0123456780000 &Original-Message-ID: <200207310834482A70BF63@\"~~foo~~\"> &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@\」~~foo~~\、「>とFrom:」 「「\」as2Name\」、」 To: 「0123456780000」 受け取られています: (東部夏時間)09:34:14の2002年7月31日と状態: 処理、Comment: または、メッセージが持っている保証でなく、完全に処理されたこの受信と翻訳者に解釈されます。------=__56_1672293592.1028122454656とコンテントタイプを分けてください: 気質メッセージ/通知とContent-転送をコード化しています: 7に噛み付いた、報告-UA、: AS2サーバ、オリジナルの受取人、: rfc822。 0123456780000と最終受理者: rfc822。 0123456780000、元のMessage ID、: 「<200207310834482A70BF63@\」~~foo~~\、「>、受信された内容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を分けてください--
Moberg & Drummond Standards Track [Page 43] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[43ページ]RFC4130AS2
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 the "S/MIME Message
Specification, PKCS Security Services for MIME".)
2. どう複合の、または、プロトコル=を契約された「pkcs7アプリケーション/署名」を準備するかに関する詳細に関して、「S/MIMEメッセージ仕様、MIMEのためのPKCSセキュリティー・サービス」を見てください。)
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 [8], 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[8]で指定するか、または必要でないように複合/の3番目の身体の部分のオリジナルのメッセージの部分が、報告する。 これは任意の身体の部分です。 しかしながら、この身体の部分が省略されるか、または空白のままにされるのが、RECOMMENDEDです。
A.3. Signed, Encrypted Message Requesting a Signed, Asynchronous
Receipt
A.3。 暗号化メッセージが署名していて、非同期な領収書を要求して、署名されます。
Message-ID: <#as2_company#01#a4260as2_companyout#>
Date: Thu, 19 Dec 2002 15:04:18 GMT
From: me@example.com
Subject: Async MDN request
Mime-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=smime.p7m
Recipient-Address: 10.240.1.2//
Disposition-Notification-To:
http://10.240.1.2:8201/exchange/as2_company
Disposition-Notification-Options: signed-receipt-protocol=optional,
pkcs7-signature; signed-receipt-micalg=optional,sha1
Receipt-Delivery-Option:
http://10.240.1.2:8201/exchange/as2_company
AS2-From: as2_company
AS2-To: "AS2 Test"
AS2-Version: 1.1
Host: 10.240.1.2:8101
Connection: close
Content-Length: 3428
Message ID: <#as2_会社の#01#a4260as2_companyout#>日付: グリニッジ標準時2002年12月19日木曜日15時4分18秒From: me@example.com Subject: Async MDNはMime-バージョンを要求します: 1.0コンテントタイプ: pkcs7アプリケーション/パントマイム。 smime-タイプはおおわれたデータと等しいです。 =smime.p7m Content-転送コード化を命名してください: 2進のContent-気質: 付属。 ファイル名はsmime.p7m Recipient-アドレスと等しいです: 10.240.1.2 気質//通知To: http://10.240.1.2:8201/exchange/as2_company 気質通知オプション: 署名している領収書プロトコル=任意である、pkcs7-署名。 署名している領収書-micalgは任意のsha1 Receipt配送オプションと等しいです: http://10.240.1.2:8201/exchange/as2_company AS2-From: as2_会社、AS2-To: 「AS2テスト」AS2-バージョン: 1.1ホスト: 10.240.1.2 : 8101年の接続: Content-長さを閉じてください: 3428
[omitted binary encrypted data]
[省略された2進の暗号化されたデータ]
Moberg & Drummond Standards Track [Page 44] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[44ページ]RFC4130AS2
A.4. Asynchronous MDN for Message A.3, Above
A.4。 上のメッセージA.3のための非同期なMDN
POST / HTTP/1.1
Host: 10.240.1.2:8201
Connection: close, TE
TE: trailers, deflate, gzip, compress
User-Agent: RPT-HTTPClient/0.3-3I (Windows 2000)
Date: Thu, 19 Dec 2002 15:03:38 GMT
Message-ID: <AS2-20021219_030338@as2_company.dgi_th>
AS2-Version: 1.1
Mime-Version: 1.0
Recipient-Address:
http://10.240.1.2:8201/exchange/as2_company
AS2-To: as2_company
AS2-From: "AS2 Test"
Subject: Your Requested MDN Response
From: as2debug@example.com
Accept-Encoding: deflate, gzip, x-gzip, compress, x-compress
Content-Type: multipart/signed; micalg=sha1;
protocol="application/pkcs7-signature";
boundary="----=_Part_337_6452266.1040310218750"
Content-Length: 3103
/ HTTP/1.1ホストを掲示してください: 10.240.1.2 : 8201年の接続: TE TE、閉じてください: トレーラ、gzip、空気を抜いてください、そして、User-エージェントを圧縮してください: RPT-HTTPClient/0.3-3I(Windows2000)日付: グリニッジ標準時2002年12月19日木曜日15時3分38秒のメッセージID: <AS2-20021219_030338@as2_company.dgi_、第>AS2-バージョン: 1.1パントマイムバージョン: 1.0 受取人アドレス: http://10.240.1.2:8201/exchange/as2_company AS2-To: as2_会社、AS2-From: 「AS2テスト」Subject: あなたの要求されたMDN応答From: as2debug@example.com 、コード化を受け入れます: gzip、空気を抜いてください、そして、x-gzip、湿布はコンテントタイプをxで圧縮します: 複合か署名される。 micalg=sha1。 =「pkcs7アプリケーション/署名」について議定書の中で述べてください。 「境界=」----=_「パート_337_6452266.1040310218750」コンテンツの長さ: 3103
------=_Part_337_6452266.1040310218750
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="----=_Part_336_6069110.1040310218718"
------=__337_6452266.1040310218750コンテントタイプを分けてください: 複合/レポート。 レポートタイプは気質通知と等しいです。 「境界=」----=_「パート_336_6069110.1040310218718」
------=_Part_336_6069110.1040310218718 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit
------=__336_6069110.1040310218718コンテントタイプを分けてください: テキスト/平野。 charsetが私たちと等しい、-、ASCII Content転送コード化: 7ビット
The message <x12.edi> sent to Recipient <AS2 Test> on Thu, 19 Dec 2002 15:04:18 GMT with Subject <async MDN request> has been received. The EDI Interchange was successfully decrypted, and its integrity was verified. In addition, the sender of the message, Sender <as2_company> at Location http://10.240.1.2:8201/exchange/as2_company was authenticated as the originator of the message. There is no guarantee, however, that the EDI interchange was syntactically correct, or that it was received by the EDI application/translator.
Subject<async MDN要求>があるグリニッジ標準時2002年12月19日木曜日15時4分18秒にRecipient<AS2 Test>に送られたメッセージ<x12.edi>を受け取りました。 EDI Interchangeは首尾よく解読されました、そして、保全は確かめられました。 追加、メッセージ送信者では、Location http://10.240.1.2:8201/exchange/as2_company のSender<as2_会社の>はメッセージの創始者として認証されました。 しかしながら、保証が全くありません。EDI置き換えがシンタクス上正しかったか、またはそれはEDIアプリケーション/翻訳者によって受け取られました。
Moberg & Drummond Standards Track [Page 45] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[45ページ]RFC4130AS2
------=_Part_336_6069110.1040310218718 Content-Type: message/disposition-notification Content-Transfer-Encoding: 7bit
------=__336_6069110.1040310218718コンテントタイプを分けてください: 気質メッセージ/通知Content転送コード化: 7ビット
Reporting-UA: AS2@test:8101
Original-Recipient: rfc822; "AS2 Test"
Final-Recipient: rfc822; "AS2 Test"
Original-Message-ID: <#as2_company#01#a4260as2_companyout#>
Disposition: automatic-action/MDN-sent-automatically;
processed
Received-Content-MIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=, sha1
報告しているUA: AS2@test : 8101年のオリジナルの受取人: rfc822。 「AS2テスト」最終受理者: rfc822。 「AS2はテストする」という元のMessage ID: <#as2_会社の#01#a4260as2_companyout#>Disposition: MDNは自動的に自動動作/発信していました。 処理Received満足しているMIC: Hes6my+vIxIYxmvsA+MNpEOTPAc=、sha1
------=_Part_336_6069110.1040310218718--
------=__336_6069110.1040310218718を分けてください--
------=_Part_337_6452266.1040310218750 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s
------=__337_6452266.1040310218750コンテントタイプを分けてください: pkcs7アプリケーション/署名。 =smime.p7s Content-転送コード化を命名してください: base64 Content-気質: 付属。 ファイル名=smime.p7s
BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM 4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=
BhbWjEfbyXoTAS/H0zpnEqLqbaBh29y2v82b8bdeGw8pipBQWmf53hIcqHGM 4ZBF3CHw5Wrf1JIE+8TwOzdbal30zeChw88WfRfD7c/j1fIA8sxsujvf2d9j UxCUga8BVdVB9kH0Geexytyt0KvWQXfaEEcgZGUAAAAAAAA=
------=_Part_337_6452266.1040310218750-
------=__337_6452266.1040310218750を分けてください、-
Authors' Addresses
作者のアドレス
Dale Moberg Cyclone Commerce 8388 E. Hartford Drive, Suite 100 Scottsdale, AZ 85255 USA
デールのモーベリの低気圧商業8388E.ハートフォードドライブ、Suite100スコッツデール、アリゾナ85255米国
EMail: dmoberg@cyclonecommerce.com
メール: dmoberg@cyclonecommerce.com
Rik Drummond Drummond Group Inc. 4700 Bryant Irvin Court, Suite 303 Fort Worth, TX 76107 USA
リクドラモンドドラモンドグループ株式会社4700ブライアントアービン法廷、Suite303フォートワース、テキサス76107米国
EMail: rvd2@drummondgroup.com
メール: rvd2@drummondgroup.com
Moberg & Drummond Standards Track [Page 46] RFC 4130 AS2 for Business Data Interchange Using HTTP July 2005
2005年7月にHTTPを使用する業務データ置き換えのためのモーベリとドラモンド標準化過程[46ページ]RFC4130AS2
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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機能のための基金は現在、インターネット協会によって提供されます。
Moberg & Drummond Standards Track [Page 47]
モーベリとドラモンド標準化過程[47ページ]
一覧
スポンサーリンク
