RFC3335 日本語訳
3335 MIME-based Secure Peer-to-Peer Business Data Interchange over theInternet. T. Harding, R. Drummond, C. Shih. September 2002. (Format: TXT=59687 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Harding
Request for Comments: 3335 Cyclone Commerce
Category: Standards Track R. Drummond
Drummond Group
C. Shih
Gartner Group
September 2002
コメントを求めるワーキンググループT.ハーディング要求をネットワークでつないでください: 3335年の低気圧商業カテゴリ: 標準化過程R.ドラモンドドラモンドグループC.Shihガートナーグループ2002年9月
MIME-based Secure Peer-to-Peer
Business Data Interchange over the Internet
インターネットの上のMIMEベースの安全なピアツーピア業務データ置き換え
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document describes how to exchange structured business data securely using SMTP transport for Electronic Data Interchange, (EDI - either the American Standards Committee X12 or UN/EDIFACT, Electronic Data Interchange for Administration, Commerce and Transport), XML or other data used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using Cryptographic Message Syntax (S/MIME) or OpenPGP security body parts. Authenticated acknowledgements make use of multipart/signed replies to the original SMTP message.
このドキュメントがElectronic Data InterchangeにしっかりとSMTP輸送を使用することで構造化された業務データを交換する方法を説明する、(EDI--標準委員会X12か国連/EDIFACTのどちらか、政権、Commerce、およびTransportのためのElectronic Data Interchange)、企業間電子商取引データに使用されるXMLか他のデータが交換されます。 データは、標準のMIME content typeを使用することでパッケージされます。 Cryptographic Message Syntax(S/MIME)かOpenPGPセキュリティ身体の部分を使用することによって、認証とプライバシーを得ます。 認証された承認はオリジナルのSMTPメッセージに複合の、または、署名している回答を利用します。
Harding, et. al. Standards Track [Page 1] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[1ページ]RFC3335
Table of Contents
目次
1.0 Introduction .................................................3 2.0 Overview .....................................................4 2.1 Purpose of a Security Guideline for MIME EDI .................4 2.2 Definitions ..................................................4 2.2.1 Terms ........................................................4 2.2.2 The Secure Transmission Loop .................................5 2.2.3 Definition of Receipts .......................................5 2.3 Assumptions ..................................................6 2.3.1 EDI Process Assumptions ......................................6 2.3.2 Flexibility Assumptions ......................................7 3.0 Referenced RFCs and Their Contribution .......................8 3.1 RFC 821 SMTP [7] .............................................8 3.2 RFC 822 Text Message Format [3] ..............................8 3.3 RFC 1847 MIME Security Multiparts [6] ........................8 3.4 RFC 1892 Multipart/Report [9] ................................8 3.5 RFC 1767 EDI Content [2] .....................................9 3.6 RFC 2015, 3156, 2440 PGP/MIME [4] ............................9 3.7 RFC 2045, 2046, and 2049 MIME [1] ............................9 3.8 RFC 2298 Message Disposition Notification [5] ................9 3.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8] 9 4.0 Structure of an EDI MIME Message - Applicability .............9 4.1 Introduction .................................................9 4.2 Structure of an EDI MIME Message - PGP/MIME .................10 4.2.1 No Encryption, No Signature .................................10 4.2.2 No Encryption, Signature ....................................10 4.2.3 Encryption, No Signature ....................................10 4.2.4 Encryption, Signature .......................................10 4.3 Structure of an EDI MIME Message - S/MIME ...................10 4.3.1 No encryption, No Signature..................................10 4.3.2 No encryption, Signature ....................................10 4.3.3 Encryption, No Signature ....................................11 4.3.4 Encryption, Signature .......................................11 5.0 Receipts ....................................................11 5.1 Introduction ................................................11 5.2 Requesting a Signed Receipt .................................13 5.2.1 Additional Signed Receipt Considerations ....................16 5.3 Message Disposition Notification Format .....................17 5.3.1 Message Disposition Notification Extensions .................18 5.3.2 Disposition Mode, Type, and Modifier Use ....................19 5.4 Message Disposition Notification Processing .................21 5.4.1 Large File Processing .......................................21 5.4.2 Example .....................................................22 6.0 Public Key Certificate Handling .............................24 6.1 Near Term Approach ..........................................24 6.2 Long Term Approach ..........................................24 7.0 Security Considerations .....................................25
1.0序論…3 2.0概要…4 2.1 MIME EDIのための安全ガイドラインの目的…4 2.2の定義…4 2.2 .1の用語…4 2.2 .2 安全なトランスミッション輪…5 2.2 .3 領収書の定義…5 2.3の仮定…6 2.3 .1 EDIは仮定を処理します…6 2.3 .2 柔軟性仮定…7 3.0はRFCsと彼らの貢献に参照をつけました…8 3.1 RFC821SMTP[7]…8 3.2 RFC822テキストメッセージ・フォーマット[3]…8 3.3 RFC1847はセキュリティMultiparts[6]をまねます…8 3.4 RFC1892複合/レポート[9]…8 3.5 RFC1767EDI内容[2]…9 3.6 RFC2015、3156、2440PGP/MIME[4]…9 3.7 RFC2045、2046、および2049は[1]をまねます…9 3.8 RFC2298メッセージ気質通知[5]…9 3.9 エディMIMEメッセージのRFC2633と2630秒間/のMIMEバージョン3メッセージ仕様[8]9 4.0構造(適用性)…9 4.1序論…9 4.2 エディMIMEメッセージの構造--PGP/MIME…10 4.2 .1 暗号化がない、署名がありません…10、4.2.2いいえ暗号化、署名…10 4.2 .3暗号化、署名がありません…10、4.2.4暗号化、署名…10 4.3 エディMIMEメッセージの構造--S/MIME…10 4.3 .1 暗号化がない、Signatureがありません…10 4.3 .2 いいえ、暗号化、Signature…10 4.3 .3暗号化、署名がありません…11、4.3.4暗号化、署名…11 5.0 領収書を出します。11 5.1序論…11 5.2 署名している領収書を要求します…13 5.2 .1 追加署名している領収書問題…16 5.3 メッセージ気質通知形式…17 5.3 .1 メッセージ気質通知拡張子…18 5.3 .2 気質モード、タイプ、および修飾語使用…19 5.4 メッセージ気質通知処理…21 5.4 .1 大きいファイル処理…21 5.4 .2の例…22 6.0 公開鍵証明書取り扱い…24 6.1 用語頃に、アプローチしてください…24 6.2 長い期間、アプローチしてください…24 7.0 セキュリティ問題…25
Harding, et. al. Standards Track [Page 2] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[2ページ]RFC3335
8.0 Acknowledgments .............................................26 9.0 References ..................................................26 Appendix IANA Registration Form ...................................28 Authors' Addresses ................................................28 Full Copyright Statement ..........................................29
8.0の承認…26 9.0の参照箇所…26 付録IANA登録用紙…28人の作者のアドレス…28 完全な著作権宣言文…29
1.0 Introduction
1.0 序論
Previous work on Internet EDI focused on specifying MIME content types for EDI data ([2] RFC 1767). This document expands on RFC 1767 to specify use of a comprehensive set of data security features, specifically data privacy, data integrity/authenticity, non- repudiation of origin and non-repudiation of receipt. This document also recognizes contemporary RFCs and is attempting to "re-invent" as little as possible. While this document focuses specifically on EDI data, any other data type is also supported.
インターネットEDIへの前の作業は、EDIデータ([2]RFC1767)にMIME content typeを指定するのは焦点を合わせました。 このドキュメントは、包括的なセットのデータ機密保護機能、明確にデータプライバシー、データ保全/信憑性、発生源の非拒否の使用と領収書の非拒否を指定するためにRFC1767について詳述します。 このドキュメントも、現代のRFCsを認めて、できるだけ少ししか「再発明しないこと」を試みています。 また、このドキュメントが特にEDIデータに焦点を合わせている間、いかなる他のデータ型もサポートされます。
With an enhancement in the area of "receipts", as described below (5.2), secure Internet MIME based EDI can be accomplished by using and complying with the following RFCs:
増進が「領収書」の領域にある状態で、(5.2)の下で説明されるように、以下のRFCsを使用して、従うことによって、安全なインターネットMIMEベースのEDIを達成できます:
-RFC 821 SMTP
-RFC 822 Text Message Formats
-RFC 1767 EDI Content Type
-RFC 1847 Security Multiparts for MIME
-RFC 1892 Multipart/Report
-RFC 2015, 3156, 2440 MIME/PGP
-MIME-RFC1892の複合/のためのRFC821SMTP -RFC822テキストメッセージ・フォーマット-RFC1767EDI content type-RFC1847セキュリティMultipartsは-RFC2015、3156を報告します、2440MIME/PGP
-RFC 2045 to 2049 MIME RFCs
-RFC 2298 Message Disposition Notification
-RFC 2630, 2633 S/MIME v3 Specification
-2049MIME RFCs -RFC2298Message Disposition Notification -RFC2630、2633秒間/MIMEのv3 SpecificationへのRFC2045
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.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
Harding, et. al. Standards Track [Page 3] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[3ページ]RFC3335
2.0 Overview
2.0 概要
2.1 Purpose of a Security Guideline for MIME EDI
2.1 MIME EDIのための安全ガイドラインの目的
The purpose of these specifications is to ensure interoperability between EDI user agents, invoking some or all of the commonly expected security features. This document is also NOT limited to strict EDI use, but applies to any electronic commerce application where business data needs to be exchanged over the Internet in a secure manner.
これらの仕様の目的はEDIユーザエージェントの間の相互運用性を確実にすることです、一般的に予想されたセキュリティ機能のいくつかかすべてを呼び出して。 このドキュメントは、また、厳しいEDI使用に制限されませんが、業務データが安全な方法でインターネットの上と交換される必要があるどんな電子商取引アプリケーションにも適用されます。
2.2 Definitions
2.2 定義
2.2.1 Terms
2.2.1 用語
EDI Electronic Data Interchange
EDI電子データ交換
EC Electronic Commerce
ECの電子通商
Receipt The functional message that is sent from a
receiver to a sender to acknowledge
receipt of an EDI/EC interchange.
EDI/ECの置き換えの領収書を受け取ったことを知らせるために受信機から送付者に送られる機能的なメッセージを領収書を出させてください。
Signed Receipt Same as above, but with a digital
signature.
同じくらい上でReceipt Sameであると署名されますがデジタル署名で。
Message Disposition The Internet messaging format used to
Notification convey a receipt. This term is used
interchangeably with receipt. A signed
MDN is a signed receipt.
メッセージング形式がNotificationに使用したメッセージDispositionインターネットは領収書を伝えます。 今期は領収書で互換性を持って使用されます。 署名しているMDNは署名している領収書です。
Non-repudiation of NRR is a "legal event" that occurs when
Receipt (NRR) the original sender of an EDI/EC
interchange has verified the signed
receipt coming back from the receiver.
NRR IS NOT a functional or a technical
message.
NRRの非拒否はEDI/ECの置き換えの元の送り主のReceipt(NRR)が. 受信機NRR IS NOTから機能的なメッセージか技術的なメッセージを支持しに来る署名している領収書を確かめたとき起こる「法的なイベント」です。
PGP/MIME Digital envelope security based on the
Pretty Good Privacy (PGP) standard
(Zimmerman), integrated with MIME Security
Multiparts [6].
PGP/MIME Digital封筒セキュリティはSecurity Multiparts[6]を標準(ジンマーマン)の、そして、MIMEについて統合しているプリティ・グッド・プライバシ(PGP)に基礎づけました。
S/MIME A format and protocol for adding
Cryptographic signature and/or encryption
services to Internet MIME messages.
Cryptographic署名を加えるためのS/MIME A形式とプロトコル、そして/または、暗号化はインターネットMIMEにメッセージを修理します。
Harding, et. al. Standards Track [Page 4] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[4ページ]RFC3335
2.2.2 The secure transmission loop
2.2.2 安全なトランスミッション輪
This document's focus is on the formats and protocols for exchanging EDI content that has had security applied to it using the Internet's messaging environment.
このドキュメントの焦点がインターネットのメッセージング環境を使用することでセキュリティをそれに適用したEDI内容を交換するための形式とプロトコルにあります。
The "secure transmission loop" for EDI involves one organization sending a signed and encrypted EDI interchange to another organization, requesting a signed receipt, followed later by the receiving organization sending this signed receipt back to the sending organization. In other words, the following transpires:
署名している領収書を要求して、EDIが署名していて暗号化されたEDI置き換えを別の組織に送る1つの組織にかかわるので、受信組織で「安全なトランスミッション輪」は後で領収書であると署名されるこれを送出し機関に送り返しながら、続きました。 言い換えれば、以下は蒸散します:
-The organization sending EDI/EC data signs and encrypts the data
using either PGP/MIME or S/MIME. In addition, the message will
request a signed receipt to be returned to the sender of the
message.
-組織送付EDI/ECデータは、PGP/MIMEかS/MIMEのどちらかを使用することでデータに署名して、暗号化します。 さらに、メッセージは、メッセージ送信者に返されるよう署名している領収書に要求するでしょう。
-The receiving organization decrypts the message and verifies the
signature, resulting in verified integrity of the data and
authenticity of the sender.
-受信組織は、メッセージを解読して、署名について確かめます、データの確かめられた保全と送付者の信憑性をもたらして。
-The receiving organization then returns a signed receipt to the
sending organization in the form of a message disposition
notification message. This signed receipt will contain the hash
of the signature from the received message, indicating to the
sender that the received message was verified and/or decrypted
properly.
-そして、受信組織はメッセージ気質通知メッセージの形の送出し機関に署名している領収書を返します。 領収書であると署名されるこれは受信されたメッセージからの署名のハッシュを含むでしょう、受信されたメッセージが適切に確かめられる、そして/または、解読されたのを送付者に示して。
The above describes functionality which, if implemented, would satisfy all security requirements. 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.2.3 Definition of receipts
2.2.3 領収書の定義
The term used for both the functional activity and message for acknowledging receipt 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 which is NOT signed. The second term is used if the acknowledgment is for an interchange resulting in a receipt which IS signed. The method used to request a receipt or a signed receipt is defined in RFC 2298, "An Extensible Message Format for Message Disposition Notifications".
用語は、両方にEDI/ECの置き換えの領収書が領収書であると認めることへの機能的活動とメッセージを使用したか、または領収書に署名しました。 前期は承認が署名されない領収書をもたらす置き換えのためのものであるなら使用されています。 2番目の期間は承認が署名される領収書をもたらす置き換えのためのものであるなら使用されています。 メソッドは、以前はよくRFC2298、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」で領収書か署名している領収書が定義されるよう要求していました。
The "rule" is:
「規則」は以下の通りです。
- If a receipt is requested, explicitly specifying that the receipt
be signed, then the receipt MUST be returned with a signature.
- 領収書が署名されると明らかに指定して、領収書を要求するなら、署名と共に領収書を返さなければなりません。
Harding, et. al. Standards Track [Page 5] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[5ページ]RFC3335
- If a receipt is requested, explicitly specifying that the receipt
be signed, but the recipient cannot support the requested
protocol format or requested MIC algorithms, then a receipt,
either signed or unsigned SHOULD be returned.
- 領収書が署名されると明らかに指定して、領収書が要求されているか、しかし、受取人は、MICアルゴリズム、次に署名される領収書または未署名のSHOULDが返されるよう要求されたプロトコルが形式であるとサポートすることができませんでしたし、要求もしました。
- If a signature is not explicitly requested, or if the signed
receipt request parameter is not recognized by the UA, a receipt
may or may not be returned. This behavior is consistent with the
MDN RFC 2298.
- 明らかに署名を要求しないか、またはUAが署名している領収書要求パラメタを認識しないなら、領収書を返すかもしれません。 この振舞いはMDN RFC2298と一致しています。
A term often used in combination with receipts is "Non-Repudiation of Receipt (NRR). NRR refers to a legal event which occurs only when the original sender of an interchange has verified the signed receipt coming back from recipient of the message. Note that NRR is not possible without signatures.
領収書と組み合わせてしばしば使用される用語は「領収書(NRR)の非拒否」です。 NRRは置き換えの元の送り主がメッセージの受取人から戻る署名している領収書を確かめたときだけ起こる法的なイベントについて言及します。 NRRが署名なしで可能でないことに注意してください。
2.3 Assumptions
2.3 仮定
2.3.1 EDI Process Assumptions
2.3.1 EDIプロセス仮定
-Encrypted object is an EDI Interchange
This specification assumes that a typical EDI interchange is the
lowest level object that will be subject to security services.
-暗号化されたオブジェクトによるEDI Interchange This仕様が、典型的なEDI置き換えがセキュリティー・サービスを受けることがある平らな最も低いオブジェクトであると仮定するということです。
In ANSI X12, this means anything between, and including segments ISA
and IEA. In EDIFACT, this means anything between, and including,
segments UNA/UNB and UNZ. In other words, the EDI interchanges
including envelope segments remain intact and unreadable during
secure transport.
ANSI X12では、これは、間の何とでも、セグメントISAとIEAを含んでいることを意味します。 EDIFACTでは、これはセグメントの間の何、包含、UNA/UNB、およびUNZでも意味します。 言い換えれば、封筒セグメントを含むEDI置き換えは安全な輸送の間、完全であって、読みにくいままで残っています。
-EDI envelope headers are encrypted
Congruent with the above statement, EDI envelope headers are NOT
visible in the MIME package. In order to optimize routing from
existing commercial EDI networks (called Value Added Networks or
VANs) to the Internet, work may need to be done in the future to
define ways to pull out some of the envelope information to make
them visible; however, this specification does not go into any
detail on this.
-EDI封筒ヘッダーが上の声明がある暗号化されたCongruentである、EDI封筒ヘッダーはMIMEパッケージの中に目に見えません。 既存の商業EDIネットワーク(付加価値通信網かVANと呼ばれる)からインターネットまでルーティングを最適化するために、仕事は、将来それらを目に見えるようにするように何らかの封筒情報を引き抜く方法を定義するためにする必要があるかもしれません。 しかしながら、この仕様はこれに関する少しの詳細も調べません。
-X12.58 and UN/EDIFACT security considerations
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.
-X12.58と国連/EDIFACTセキュリティ問題の最も一般的なEDI標準化団体、ANSI X12、およびEDIFACTには、セキュリティのための定義された内部の条項があります。 X12.58はANSI X12のためのセキュリティー対策です、そして、AUTACKはセキュリティをEDIFACTに供給します。 この仕様DOES NOTはこれらの機密保護基準の使用か非使用を書き取ります。 それらは、この仕様でともに完全に互換性があって、もっとも、ことによると余分です。
Harding, et. al. Standards Track [Page 6] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[6ページ]RFC3335
2.3.2 Flexibility Assumptions
2.3.2 柔軟性仮定
-Encrypted or unencrypted data
-データを暗号化したか、または非暗号化しました。
This specification allows for EDI message exchange where the EDI
data can either be un-protected or protected by means of encryption.
この仕様は、暗号化EDIデータが保護がない場合があるEDI交換処理のために許容したか、または保護されました。
-Signed or unsigned data
-署名しているか未署名のデータ
This specification allows for EDI message exchange with or without
digital signature of the original EDI transmission.
この仕様はオリジナルのEDIトランスミッションのデジタル署名のあるなしにかかわらずEDI交換処理を考慮します。
-Use of receipt or not
-領収書の使用です。
This specification allows for EDI message transmission with or
without a request for receipt notification. If a signed receipt
notification is requested however, a mic value is REQUIRED as part
of the returned receipt, unless an error condition occurs in which a
mic value cannot be returned. In error cases, an un-signed receipt
or MDN SHOULD be returned with the correct "disposition modifier"
error value.
この仕様は領収書通知に関する要求のあるなしにかかわらずEDIメッセージ送信を考慮します。 しかしながら、署名している領収書通知が要求されるなら、mic値は返された領収書の一部としてREQUIREDです、mic値を返すことができないエラー条件が起こらない場合。 誤り事件、未署名の領収書またはMDN SHOULDでは、正しい「気質修飾語」誤り価値と共に返してください。
-Formatting choices
-形式選択
This specification defines the use of two methods for formatting EDI
contents that have security applied to it:
この仕様は形式EDIコンテンツのためのセキュリティをそれに適用する2つのメソッドの使用を定義します:
-PGP/MIME
-S/MIME
-PGP/MIME-S/MIME
This specification relies on the guidelines set forth in RFC
2015/3156/2440, as reflected in [4] "MIME Security with Pretty Good
Privacy" (PGP); OpenPGP Message Format, and RFC 2633/2630 [8]
"S/MIME Version 3 Message Specification; Cryptographic Message
Syntax". PGP/MIME or S/MIME as defined in this Applicability
statement.
この仕様はRFC2015/3156/2440に詳しく説明されたガイドラインを当てにします、[4] 「プリティ・グッド・プライバシがあるMIMEセキュリティ」(PGP)に反映されるように。 OpenPGPメッセージ・フォーマット、およびRFC2633/2630[8]「S/MIMEバージョン3メッセージ仕様」。 「暗号のメッセージ構文。」 このApplicability声明で定義されるPGP/MIMEかS/MIME。
-Hash function, message digest choices
-ハッシュ関数、メッセージダイジェスト選択
When a signature is used, it is RECOMMENDED that the SHA1 hash
algorithm be used for all outgoing messages, and that both MD5 and
SHA1 be supported for incoming messages.
署名が使用されているとき、SHA1ハッシュアルゴリズムがすべての送信されるメッセージに使用されて、MD5とSHA1の両方が入力メッセージのためにサポートされるのは、RECOMMENDEDです。
In summary, the following eight permutations are possible in any
given trading relationship:
概要では、取り引き関係を考えて、以下の8つの順列がいずれでも可能です:
(1) Sender sends unencrypted data, does NOT request a receipt.
(1) 領収書は、送付者が非暗号化されたデータを送るよう要求しません。
Harding, et. al. Standards Track [Page 7] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[7ページ]RFC3335
(2) Sender sends unencrypted data, requests a signed or unsigned
receipt. The receiver sends back the signed or unsigned
receipt.
(2) 署名しているか未署名の領収書は、送付者が非暗号化されたデータを送るよう要求します。 受信機は署名しているか未署名の領収書を返送します。
(3) Sender sends encrypted data, does NOT request a receipt.
(3) 領収書は、送付者が暗号化されたデータを送るよう要求しません。
(4) Sender sends encrypted data, requests a signed or unsigned
receipt. The receiver sends back the signed or unsigned
receipt.
(4) 署名しているか未署名の領収書は、送付者が暗号化されたデータを送るよう要求します。 受信機は署名しているか未署名の領収書を返送します。
(5) Sender sends signed data, does NOT request a signed or unsigned
receipt.
(5) 署名しているか未署名の領収書は、送付者が署名しているデータを送るよう要求しません。
(6) Sender sends signed data, requests a signed or unsigned receipt.
Receiver sends back the signed or unsigned receipt.
(6) 署名しているか未署名の領収書は、送付者が署名しているデータを送るよう要求します。 受信機は署名しているか未署名の領収書を返送します。
(7) Sender sends encrypted and signed data, does NOT request a
signed or unsigned receipt.
(7) 署名しているか未署名の領収書は、送付者が暗号化されて署名しているデータを送るよう要求しません。
(8) Sender sends encrypted and signed data, requests a signed or
unsigned receipt. Receiver sends back the signed or unsigned
receipt.
(8) 署名しているか未署名の領収書は、送付者が暗号化されて署名しているデータを送るよう要求します。 受信機は署名しているか未署名の領収書を返送します。
NOTE: Users can choose any of the eight possibilities, but only example (8), when a signed receipt is requested, offers the whole suite of security features described in the "Secure transmission loop" above.
以下に注意してください。 ユーザは8つの可能性のどれかを選ぶことができますが、署名している領収書が要求されているとき、例(8)だけが上の「トランスミッションが輪であると機密保護してください」で説明されたセキュリティ機能の全体のスイートを提供します。
3.0 Referenced RFCs and Their Contribution
3.0 参照をつけられたRFCsと彼らの貢献
3.1 RFC 821 SMTP [7]
3.1 RFC821SMTP[7]
This is the core mail transfer standard that all MTAs need to adhere to.
これはすべてのMTAsが固く守る必要があるコアメール管理換え基準です。
3.2 RFC 822 Text Message Format [3]
3.2 RFC822テキストメッセージ・フォーマット[3]
Defines message header fields and the parts making up a message.
メッセージヘッダーフィールドとメッセージを作る部品を定義します。
3.3 RFC 1847 MIME Security Multiparts [6]
3.3 RFC1847MIMEセキュリティMultiparts[6]
This document defines security multiparts for MIME: multipart/encrypted and multipart/signed.
このドキュメントはMIMEのためにセキュリティの「マルチ-部品」を定義します: 暗号化された複合/と複合/は署名しました。
3.4 RFC 1892 Multipart/report [9]
3.4 RFC1892複合/レポート[9]
This RFC defines the use of the multipart/report content type, something that the MDN RFC 2298 builds upon.
このRFCは複合/レポートcontent typeの使用、MDN RFC2298が当てにする何かを定義します。
Harding, et. al. Standards Track [Page 8] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[8ページ]RFC3335
3.5 RFC 1767 EDI Content [2]
3.5 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.6 RFC 2015, 3156, 2440 PGP/MIME [4]
3.6 RFC2015、3156、2440PGP/MIME[4]
These RFCs define the use of content types "multipart/encrypted", "multipart/signed", "application/pgp encrypted" and "application/pgp-signature" for defining MIME PGP content.
これらのRFCsは定義のための「暗号化されたアプリケーション/pgp」と「pgpアプリケーション/署名」「複合か暗号化され」て、「複合か署名している」MIME PGP満足していた状態でcontent typeの使用を定義します。
3.7 RFC 2045, 2046, and 2049 MIME [1]
3.7 RFC2045、2046、および2049はまねられます。[1]
These are the basic MIME standards, upon which all MIME related RFCs build, including this one. Key contributions include definition of "content type", "sub-type" and "multipart", as well as encoding guidelines, which establishes 7-bit US-ASCII as the canonical character set to be used in Internet messaging.
これらは基本的なMIME規格です。(そこでは、これを含んでいて、すべてのMIMEの関連するRFCsが建てます)。 主要な貢献はインターネットメッセージングで使用されるために正準な文字集合と7ビットの米国-ASCIIを書き立てるガイドラインをコード化することと同様に「サブタイプ」の、そして、「複合」の「content type」の定義を含んでいます。
3.8 RFC 2298 Message Disposition Notification [5]
3.8 RFC2298メッセージ気質通知[5]
This Internet RFC defines how a message disposition notification (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.9 RFC 2633 and 2630 S/MIME Version 3 Message Specifications [8]
3.9 RFC2633と2630秒間/MIMEのバージョン3メッセージ仕様[8]
This specification describes how MIME shall carry CMS Objects.
この仕様はMIMEがどうCMS Objectsを運ぶだろうかを説明します。
4.0 Structure of an EDI MIME Message - Applicability
エディMIMEメッセージの4.0構造--適用性
4.1 Introduction
4.1 序論
The structures below are described hierarchically in terms of which RFC's are applied to form the specific structure. For details of how to code in compliance with all RFC's involved, turn directly to the RFC's referenced.
RFCのどのものが特定の構造を形成するために適用されるかに関して以下の構造は階層的で説明されます。 RFCがかかわったすべてに従ってコードへのどのようにに関する詳細に関しては、直接参照をつけられるRFCのものに変わってくださいか。
Also, these structures describe the initial transmission only. Receipts, and requests for receipts are handled in section 5.
また、これらの構造は初期のトランスミッションだけについて説明します。 領収書、および領収書を求める要求はそうです。セクション5では、扱われます。
Harding, et. al. Standards Track [Page 9] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[9ページ]RFC3335
4.2 Structure of an EDI MIME Message - PGP/MIME
エディMIMEメッセージの4.2構造--PGP/MIME
4.2.1 No Encryption, No Signature
4.2.1 暗号化がない、署名がありません。
-RFC822/2045
-RFC1767 (application/EDIxxxx or /xml)
-RFC822/2045 -RFC1767(アプリケーション/EDIxxxxか/xml)
4.2.2 No Encryption, Signature
4.2.2 暗号化がない、署名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767 (application/EDIxxxx or /xml)
-RFC2015/2440/3156 (application/pgp-signature)
-RFC822/2045 -RFC1847(複合か署名される)の-RFC1767(アプリケーション/EDIxxxxか/xml)-RFC2015/2440/3156(pgpアプリケーション/署名)
4.2.3 Encryption, No Signature
4.2.3 暗号化、署名がありません。
-RFC822/2045
-RFC1847 (multipart/encrypted)
-RFC2015/2440/3156 (application/pgp-encrypted)
-"Version: 1"
-RFC2015/2440/3156 (application/octet-stream)
-RFC1767 (application/EDIxxxx or /xml) (encrypted)
-RFC822/2045 -RFC1847(複合の、または、暗号化された)-RFC2015/2440/3156(pgpによってアプリケーション/暗号化された)--、「バージョン:」 1インチの-RFC2015/2440/3156(八重奏アプリケーション/ストリーム)-RFC1767(アプリケーション/EDIxxxxか/xml)(暗号化されます)
4.2.4 Encryption, Signature
4.2.4 暗号化、署名
-RFC822/2045
-RFC1847 (multipart/encrypted)
-RFC2015/2440/3156 (application/pgp-encrypted)
-"Version: 1"
-RFC2015/2440/3156 (application/octet-stream)
-RFC1847 (multipart/signed)(encrypted)
-RFC1767 (application/EDIxxxx or /xml)(encrypted)
-RFC2015/2440/3156 (application/pgp-signature)(encrypted)
-RFC822/2045 -RFC1847(複合の、または、暗号化された)-RFC2015/2440/3156(pgpによってアプリケーション/暗号化された)--、「バージョン:」 1インチの-RFC2015/2440/3156(八重奏アプリケーション/ストリーム)-RFC1847(複合か署名される)(暗号化された)の-RFC1767(アプリケーション/EDIxxxxか/xml)(暗号化される)-RFC2015/2440/3156(pgpアプリケーション/署名)(暗号化されます)
4.3 Structure of an EDI MIME Message - S/MIME
エディMIMEメッセージの4.3構造--S/MIME
4.3.1 No Encryption, No Signature
4.3.1 暗号化がない、署名がありません。
-RFC822/2045
-RFC1767 (application/EDIxxxx or /xml)
-RFC822/2045 -RFC1767(アプリケーション/EDIxxxxか/xml)
4.3.2 No Encryption, Signature
4.3.2 暗号化がない、署名
-RFC822/2045
-RFC1847 (multipart/signed)
-RFC1767 (application/EDIxxxx or /xml)
-RFC2633 (application/pkcs7-signature)
-RFC822/2045 -RFC1847(複合か署名される)の-RFC1767(アプリケーション/EDIxxxxか/xml)-RFC2633(pkcs7アプリケーション/署名)
Harding, et. al. Standards Track [Page 10] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[10ページ]RFC3335
4.3.3 Encryption, No Signature
4.3.3 暗号化、署名がありません。
-RFC822/2045
-RFC2633 (application/pkcs7-mime)
-RFC1767 (application/EDIxxxx or /xml) (encrypted)
-RFC822/2045 -RFC2633(pkcs7アプリケーション/パントマイム)-RFC1767(アプリケーション/EDIxxxxか/xml)(暗号化されます)
4.3.4 Encryption, Signature
4.3.4 暗号化、署名
-RFC822/2045
-RFC2633 (application/pkcs7-mime)
-RFC1847 (multipart/signed) (encrypted)
-RFC1767 (application/EDIxxxx or /xml) (encrypted)
-RFC2633 (application/pkcs7-signature) (encrypted)
-RFC822/2045 -RFC2633(pkcs7アプリケーション/パントマイム)-RFC1847(複合か署名される)(暗号化された)の-RFC1767(アプリケーション/EDIxxxxか/xml)(暗号化される)-RFC2633(pkcs7アプリケーション/署名)(暗号化されます)
5.0 Receipts
5.0の領収書
5.1 Introduction
5.1 序論
In order to support non-repudiation of receipt (NRR), a signed receipt, based on digitally signing a message disposition notification, is to be implemented by a receiving trading partner's UA (User Agent). The message disposition notification, specified by RFC 2298 is digitally signed by a receiving trading partner as part of a multipart/signed MIME message.
領収書(NRR)の非拒否をサポートするために、メッセージ気質通知にデジタルに署名するのに基づく署名している領収書は受信貿易相手国のUA(ユーザエージェント)によって実装されることです。 メッセージ気質通知、RFCによって指定されて、2298は複合の、または、署名している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値を署名している領収書におけるメッセージ送信者に返すでしょう。
4) 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.
4) 最初の身体の部分としてのメッセージ気質通知、および2番目の身体の部分としての署名で複合の、または、署名している内容を作成する能力。
5) The ability to return the signed receipt to the sending trading
partner.
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 EDI
Interchange.
1) 受信貿易相手国は送られたEDI Interchangeの領収書を受け取ったことを知らせます。
Harding, et. al. Standards Track [Page 11] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[11ページ]RFC3335
2) If the sent message was signed, then the receiving trading partner
has authenticated the sender of the EDI Interchange.
2) 送信されたメッセージが署名されたなら、受信貿易相手国はEDI Interchangeの送付者を認証しました。
3) If the sent message was signed, then the receiving trading partner
has verified the integrity of the sent EDI Interchange.
3) 送信されたメッセージが署名されたなら、受信貿易相手国は送られたEDI Interchangeの保全について確かめました。
Regardless of whether the EDI Interchange was sent in S/MIME or PGP/MIME format, the receiving trading partner's UA MUST provide the following basic processing:
S/MIMEかPGP/MIME形式でEDI Interchangeを送ったかどうかにかかわらず、受信貿易相手国のUaは以下の基本的な処理を提供しなければなりません:
1) If the sent EDI Interchange is encrypted, then the encrypted
symmetric key and initialization vector (if applicable) is
decrypted using the receiver's private key.
1) 送られたEDI Interchangeが暗号化されているなら、暗号化された対称鍵と初期化ベクトル(適切であるなら)は、受信機の秘密鍵を使用することで解読されます。
2) The decrypted symmetric encryption key is then used to decrypt the
EDI Interchange.
2) そして、解読された左右対称の暗号化キーは、EDI 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 is 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ヘッダーを含んでいて。
Harding, et. al. Standards Track [Page 12] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[12ページ]RFC3335
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アプリケーション/署名」について議定書の中で述べてください。
PGP/MIME: protocol = "application/pgp-signature"
PGP/MIME: プロトコル=「pgpアプリケーション/署名」
8) The signature information is formatted according to S/MIME or
PGP/MIME specifications.
8) 署名情報はS/MIMEかPGP/MIME仕様通りにフォーマットされます。
The EDI 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.
EDI InterchangeとRFC1767のMIME EDIの満足しているヘッダーは実際に複合MIME満足しているタイプの一部であるかもしれません。 EDI Interchangeが複合MIME満足しているタイプの一部であるときに、全体の複合内容の向こう側にミックについて計算しなければなりません、MIMEヘッダーを含んでいて。
The signed MDN, when received by the sender of the EDI Interchange can be used by the sender:
サインされたMDNであり、送付者はEDI Interchangeの送付者によって受け取られたいつを使用できるか:
1) As an acknowledgment that the EDI Interchange 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.
1) EDI Interchangeが受信貿易相手国によって発信して、届けられて、承認されたという承認として。 受信機は、サインされた領収書のMDN部分で送信されたメッセージのオリジナルのメッセージイドを返すことによって、これをします。
2) As an acknowledgment that the integrity of the EDI Interchange was
verified by the receiving trading partner. The receiver does this
by returning the calculated MIC of the received EDI Interchange
(and 1767 MIME headers) in the "Received-content-MIC" field of the
signed MDN.
2) EDI Interchangeの保全が受信貿易相手国によって確かめられたという承認として。 受信機は、サインされたMDNの「容認された満足しているMIC」分野で容認されたEDI Interchange(そして、1767個のMIMEヘッダー)の計算されたMICを返すことによって、これをします。
3) As an acknowledgment that the receiving trading partner has
authenticated the sender of the EDI Interchange.
3) 受信貿易相手国がEDI Interchangeの送付者を認証したという承認として。
4) As a non-repudiation of receipt when the signed MDN is
successfully verified by the sender with the receiving trading
partner's public key and the returned mic value inside the MDN is
the same as the digest of the original message.
4) サインされたMDNが受信貿易相手国の公開鍵で送付者によって首尾よく確かめられるときの領収書の非拒否と返されたmicが内部を評価するとき、MDNはオリジナルのメッセージのダイジェストと同じです。
5.2 Requesting a Signed Receipt
5.2 サインされた領収書を要求すること。
Message Disposition Notifications are requested as per RFC 2298,
メッセージDisposition NotificationsはRFC2298に従って要求されています。
"An Extensible Message Format for Message Disposition Notification". 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:
「メッセージ気質通知のための広げることができるメッセージ・フォーマット。」 送られるべきメッセージに以下のヘッダーを置くことによって、受信ユーザエージェントがメッセージ気質通知を発行するという要求をします:
Harding, et. al. Standards Track [Page 13] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[13ページ]RFC3335
MDN-request-header = "Disposition-notification-to" ":"
mail-address
「MDN要求ヘッダー=、「気質通知、」、」、:、」 郵便の宛先
The mail-address field is specified as an RFC 822 user@domain address, and is the return address for the message disposition notification.
郵便の宛先分野は、RFC822 user@domain アドレスとして指定されて、メッセージ気質通知のための返送先です。
In addition to requesting a message disposition notification, a message disposition notification that is digitally signed, or what has been referred to as a signed receipt, can be requested by placing the following in the message header following the "Disposition- Notification-To" line.
メッセージ気質通知を要求することに加えて続いて、メッセージヘッダーに以下を置くことによってデジタルにサインされるメッセージ気質通知、またはサインされた領収書と呼ばれたことは要求できる、「気質、通知、-、」 立ち並んでください。
Disposition-notification-options =
"Disposition-Notification-Options" ":"
disposition-notification-parameters
「気質通知オプションは「気質通知オプション」と等しい」:、」 気質通知パラメタ
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 supported values for <protocol symbol> are "pkcs7-signature", for the S/MIME detached signature format, or "pgp-signature", for the pgp signature format.
<プロトコルシンボル>のための現在支持された値は「pkcs7-署名」です、S/MIMEの離れている署名形式、または「pgp-署名」のために、pgp署名形式のために。
The currently supported values for MIC algorithm values are:
MICアルゴリズム値のための現在支持された値は以下の通りです。
Algorithm Value used
Valueが使用したアルゴリズム
MD5 md5 SHA-1 sha1
MD5 md5 SHA-1 sha1
Harding, et. al. Standards Track [Page 14] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[14ページ]RFC3335
(Historical Note: Some early implementations of EDIINT emitted and expected "rsa-md5" and "rsa-sha1" for the micalg parameter.) Receiving agents SHOULD be able to recover gracefully from a micalg parameter value that they do not recognize.
そして、(歴史的なNote: EDIINTのいくつかの早めの実現が放って、予想した、「rsa-md5"、「micalgパラメタのためのrsa-sha1")。」 エージェントSHOULDを受けて、彼らが認識しないmicalgパラメタ価値から優雅に回復できてください。
An example of a formatted options line would be as follows:
フォーマットされたオプション線の例は以下の通りでしょう:
Disposition-notification-options:
signed-receipt-protocol=optional, pkcs7-signature;
signed-receipt-micalg=optional, sha1, md5
気質通知オプション: サインされた領収書プロトコル=任意である、pkcs7-署名。 サインされた領収書micalg=任意である、sha1、md5
The semantics of the "signed-receipt-protocol" parameter is as follows:
「サインされた領収書プロトコル」パラメタの意味論は以下の通りです:
1) The "signed-receipt-protocol" parameter is used to request a
signed receipt from the recipient trading partner. The
"signed-receipt-protocol" parameter also specifies the format in
which the signed receipt should be returned to the requester.
1) 「サインされた領収書プロトコル」パラメタは、受取人貿易相手国からサインされた領収書を要求するのに使用されます。 また、「サインされた領収書プロトコル」パラメタはサインされた領収書がリクエスタに返されるべきである形式を指定します。
The "signed-receipt-micalg" parameter is a list of MIC algorithms
preferred by the requester for use in signing the returned
receipt. The list of MIC algorithms should be honored by the
recipient from left to right.
「サインされた領収書micalg」パラメタは返された領収書にサインすることにおける使用のためにリクエスタによって好まれたMICアルゴリズムのリストです。 MICアルゴリズムのリストは左から右まで受取人によって光栄に思われるべきです。
Both the "signed-receipt-protocol" and the "signed-receipt-micalg"
option parameters are REQUIRED when requesting a signed receipt.
サインされた領収書を要求するとき、「サインされた領収書プロトコル」と「サインされた領収書micalg」オプションパラメタの両方がREQUIREDです。
2) The "importance" attribute of "Optional" is defined in the MDN RFC
2298 and has the following meaning:
2) 「任意」の「重要性」属性は、MDN RFC2298で定義されて、以下の意味を持っています:
Parameters with an importance of "Optional" permit a UA that does
not understand the particular options parameter to still generate
a MDN in response to a request for a MDN. A UA that does not
understand the "signed-receipt-protocol" parameter, or the
"signed-receipt-micalg" will obviously not return a signed
receipt.
「任意」の重要性があるパラメタは特定のオプションパラメタがMDNを求める要求に対応してMDNをまだ発生させているのを理解していないUAを可能にします。 「サインされた領収書プロトコル」パラメタを理解していない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 as well as why the MDN could not be signed. See the
Disposition field in section 5.3 for more information.
返されたMDNはMDNにサインできなかった理由と同様にメッセージの気質の情報を含むでしょう。 詳しい情報に関してセクション5.3のDisposition分野を見てください。
Harding, et. al. Standards Track [Page 15] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[15ページ]RFC3335
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. In general, if a signed
receipt is required in the trading relationship and is not
received, the transaction will likely not be considered valid.
EDIの取り引き関係の中では、サインされた領収書が予想されて、返されないなら、取引の正当性は決議する貿易相手国次第です。 一般に、サインされた領収書が取り引き関係で必要であり、受け取られていないと、取引は有効であるとおそらく考えられないでしょう。
5.2.1 Additional Signed Receipt Considerations
5.2.1 追加サインされた領収書問題
The "rules" stated in Section 2.2.3 for signed receipts are as follows:
サインされた領収書のためにセクション2.2.3で述べられた「規則」は以下の通りです:
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 requested MIC algorithms, then
either a signed or unsigned receipt SHOULD be returned.
2) 領収書を要求するときには、領収書がサインされて、受取人だけが要求されたプロトコル形式、または要求されたMICアルゴリズム、次にサインされたか無記名の領収書SHOULDを支持できないと明らかに指定して、返してください。
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, that the UA send back at a minimum, an unsigned receipt. If a signed receipt however 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 for why the contents could not be processed MUST be set in the "disposition-field".
サインされた領収書を求める要求をしますが、メッセージのコンテンツを処理するのにおいて誤りがあるとき、まだサインされた領収書を返さなければなりません。 取引自体は有効でないかもしれませんが、サインされた領収書SHALLを求める要求がまだ光栄に思われていて、有効であってください。 「気質分野」にコンテンツを処理できなかった理由の理由を設定しなければなりません。
When a request for a signed receipt is made, the "Received-content-MIC" MUST always be returned to the requester. The"Received-content-MIC" MUST be calculated as follows:
サインされた領収書を求める要求をするとき、いつも「容認された満足しているミック」をリクエスタに返さなければなりません。 以下の通り「容認された満足しているミック」について計算しなければなりません:
- For any signed messages, the MIC to be returned is calculated on
the RFC1767 MIME header and content. Canonicalization as specified
in RFC 1848 MUST be performed before the MIC is calculated, since
the sender requesting the signed receipt was also REQUIRED to
canonicalize.
- どんなサインされたメッセージに関してはも、返されるべきMICはRFC1767 MIMEヘッダーと内容で計算されます。 MICが計算される前にRFC1848の指定されるとしてのCanonicalizationを実行しなければなりません、また、サインされた領収書を要求した送付者がcanonicalizeするREQUIREDであったので。
Harding, et. al. Standards Track [Page 16] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[16ページ]RFC3335
- For encrypted, unsigned messages, the MIC to be returned is
calculated on the decrypted RFC 1767 MIME header and content. The
content after decryption MUST be canonicalized before the MIC is
calculated.
- コード化されて、無記名のメッセージに関しては、返されるべきMICは解読されたRFC1767MIMEヘッダーと内容で計算されます。 MICが計算される前に復号化の後の内容をcanonicalizedしなければなりません。
- For unsigned, unencrypted messages, the MIC MUST be calculated over
the message contents prior to Content-Transfer-Encoding and without
the MIME or any other RFC 822 headers, since these are sometimes
altered or reordered by MTAs.
- 無記名の、そして、非コード化されたメッセージに関しては、これらが時々変更されて、Content転送コード化の前とMIMEかいかなる他のRFCなしでも822個のヘッダーを満足させるか、またはMTAsによって再命令されて、メッセージに関してミックについて計算しなければなりません。
5.3 Message Disposition Notification Format
5.3 メッセージ気質通知形式
The format of a message disposition notification is specified in RFC 2298. For use in Internet EDI, the following format will be used:
メッセージ気質通知の形式はRFC2298で指定されます。 インターネットEDIにおける使用のために、以下の形式は使用されるでしょう:
- content-type - per RFC 1892 and the RFC 2298 specification
- RFC1892あたりの満足しているタイプとRFC2298仕様
- reporting-ua-field - per RFC 2298 specification
- RFC2298仕様あたりの報告しているua分野
- MDN-gateway-field - per RFC 2298 specification
- RFC2298仕様あたりのMDNゲートウェイ分野
- original-recipient-field - per RFC 2298 specification
- RFC2298仕様あたりの元の受取人分野
- final-recipient-field - per RFC 2298 specification
- RFC2298仕様あたりの最終受理者分野
- original-message-id-field - per RFC 2298 specification
- RFC2298仕様あたりの元のメッセージイド分野
- disposition-field - the following "disposition-mode" values SHOULD
be used for Internet EDI:
- 以下の「気質モード」はSHOULDを評価します。気質分野--、インターネットEDIには、使用されてください:
"automatic-action" - The disposition described by the disposition
type was a result of an automatic action,
rather than an explicit instruction by the
user for this message.
「自動動作」--気質タイプによって説明された気質はこのメッセージのためのユーザによる明白な指示よりむしろ自動動作の結果でした。
"manual-action" - 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.
「手動の動き」--気質タイプによって説明された気質はある種の自動的に実行された動作よりむしろユーザによる明白な指示の結果でした。
"MDN-sent-automatically" - The MDN was sent because the UA had
previously been configured to do so.
「MDNは自動的に発信しました」--UAが以前にそうするために構成されたので、MDNを送りました。
"MDN-sent-manually" - The user explicitly gave permission for this
particular MDN to be sent.
"MDN-sent-manually" is meaningful with
"manual-action", but not with
"automatic-action".
「MDNは手動で発信しました」--ユーザは明らかにこの特定のMDNが送られる許可を与えました。 「手動で送られたMDN」は、「手動の動き」ゆえ重要ですが、「自動動作」で重要であるというわけではありません。
Harding, et. al. Standards Track [Page 17] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[17ページ]RFC3335
- disposition-field - the following "disposition-type" values SHOULD
be used for Internet EDI:
- 以下は値のSHOULDを「気質でタイプします」。気質分野--、インターネットEDIには、使用されてください:
"processed" - The message has been processed in some manner (e.g.,
printed, faxed, forwarded, gatewayed) without being
displayed to the user. The user may or may not see
the message later.
--「処理され」て、ユーザに表示しないで、何らかの方法(例えば、進められてファックスされて、gatewayedされていた状態で、印刷される)でメッセージを処理してあります。 ユーザは後でメッセージを見るかもしれません。
"failed" - A failure occurred that prevented the proper generation
of an MDN. More information about the cause of the
failure may be contained in a Failure field. The
"failed" disposition type is not to 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.
--「失敗され」て、MDNの適切な世代を防いだ失敗は起こりました。 失敗の原因に関する詳しい情報はFailure分野に保管されるかもしれません。 MDNを求める要求を解釈する以外のメッセージを処理するのにおいて何らかの問題がある状況に「失敗した」気質タイプを使用してはいけません。 適切な気質修飾語がある「処理された」か他の気質タイプはそのような状況で使用されることになっています。
- disposition-field - the following "disposition-modifier" values
SHOULD be used for Internet EDI:
- 以下の「気質修飾語」はSHOULDを評価します。気質分野--、インターネットEDIには、使用されてください:
"error" - An error of some sort occurred that prevented successful
processing of the message. Further information is
contained in an Error field.
「誤り」--メッセージのうまくいっている処理を防いだある種の誤りは発生しました。 詳細はError分野に保管されています。
"warning" - The message was successfully processed but some sort of
exceptional condition occurred. Further Information is
contained in a Warning field.
「警告」--メッセージは首尾よく処理されましたが、ある種の例外的な状態が現れました。 さらなる情報はWarning分野に保管されています。
5.3.1 Message Disposition Notification Extensions
5.3.1 メッセージ気質通知拡張子
The following "extension field" will be added in order to support signed receipts for RFC 1767 MIME content type and multipart MIME content types that include the RFC 1767 MIME content type. The extension field" defined below follows the "disposition-field" in the MDN.
以下の「拡大分野」は、RFC1767MIME内容タイプを含んでいるRFC1767MIME内容タイプとMIMEの複合内容タイプのためにサインされた領収書を支えるために加えられるでしょう。 以下で定義された「拡大分野」はMDNの「気質分野」に続きます。
The "Received-content-MIC" extension field is set when the integrity of the received message is verified. The MIC is the base64 encoded quantity computed over the received message with a hash function. For details of "what" the "Received-content-MIC" should be calculated over, see Section 5.2.1. The algorithm used to calculate the "Received-content-MIC" value MUST be the same as the "micalg" value used by the sender in the multipart/signed message. When no signature is received, or the mic-alg parameter is not supported then it is RECOMMENDED that the SHA1 algorithm be used to calculate the MIC on the received message or message contents.
受信されたメッセージの保全が確かめられるとき、「容認された満足しているMIC」拡大分野は設定されます。 MICはコード化された量がハッシュ関数で受信されたメッセージに関して計算したbase64です。 「容認された満足しているMIC」が「何」に関して計算されるべきであるかに関する詳細に関しては、セクション5.2.1を見てください。 アルゴリズムは、以前はよく「容認された満足しているMIC」値が複合の、または、サインされたメッセージの送付者によって使用された"micalg"値と同じであるに違いないと見込んでいました。 どんな署名も受け取られていないか、mic-algパラメタが支持されないで、次に、SHA1アルゴリズムが受信されたメッセージかメッセージ内容でMICについて計算するのに使用されるのが、RECOMMENDEDであるときに。
Harding, et. al. Standards Track [Page 18] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[18ページ]RFC3335
This field is set only when the contents of the message are processed successfully. This field is used in conjunction with the recipient's signature on the MDN in order for the sender to verify "non- repudiation of receipt".
メッセージの内容が首尾よく処理されるときだけ、この分野は設定されます。 送付者が「領収書の非拒否」について確かめるのにこの分野はMDNにおける受取人の署名に関連して使用されます。
- extension field = "Received-content-MIC" ":" MIC
- 「拡大分野=「容認された満足しているMIC」」:、」 ミック
where:
どこ:
<MIC> = <base64MicValue> "," <micalg>
」 「<MIC>は<base64MicValue>と等しい」<micalg>。
<base64MicValue> = the result of one way hash function, base64
encoded.
<base64MicValue>は一方通行のハッシュ関数、コード化されたbase64の結果と等しいです。
< micalg> = the micalg value defined in RFC1847, an IANA
registered MIC algorithm ID token.
micalg値がRFC1847、IANAで定義した<micalg>=はMICアルゴリズムID象徴を登録しました。
5.3.2 Disposition Mode, Type, and Modifier Use
5.3.2 気質モード、タイプ、および修飾語使用
Guidelines for use of the "disposition-mode", "disposition-type", and "disposition-modifier" fields within Internet EDI are discussed in this section. The "disposition-mode", "disposition-type', and "disposition-modifier' fields are described in detail in RFC 2298. The "disposition-mode', "disposition-type" and "disposition-modifier" values SHOULD be used as follows:
このセクションで「気質モード」、「気質タイプ」、およびインターネットEDIの中の「気質修飾語」分野の使用のためのガイドラインについて議論します。 '「気質モード」、「気質タイプ'、および「気質修飾語'分野はRFC2298で詳細に説明されます。」 '「気質モード'、「気質タイプ」、および「気質修飾語」はSHOULDを評価します。以下の通り使用されてください:、」
5.3.2.1 Successful Processing
5.3.2.1 うまくいっている処理
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 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 to not send a signed receipt when the sender requests one.
領収書かサインされた領収書を求める要求、および受信されたメッセージ内容がそうであるときには「気質タイプ」セットでそこに返しているのが、ユーザがMDNの発信を制御する明白な方法でないという受信EDI UA、領収書またはMDN SHOULDによる、ことになってください、そして、首尾よく処理されて、次に、「気質モード」の最初の部分は「自動動作」に設定されるべきです。 ユーザの構成可能なコントロールの下でMDNを送ると、「気質モード」の最初の部分を「手動の動き」に設定するべきです。 サインされた領収書を求める要求がいつも光栄に思うべきであるので、ユーザに送付者が1つを要求するとき、サインされた領収書を送らないようにUAを構成させてはいけません。
The second part of the "disposition-mode" is set to "MDN-sent- manually" if the user gave explicit permission for the MDN to be sent. Again, the user MUST not be allowed to explicitly refuse to send a signed receipt when the sender requests one. The second part of the "disposition-mode" is set to "MDN-sent-automatically" whenever the EDI UA sends the MDN automatically, regardless of whether the sending was under a user's, administrator's, or under software control.
「気質モード」の第二部は設定されます。ユーザがMDNが送られる明白な許可を与えたなら、「-手動でMDN発信しました」。 一方、ユーザに送付者が1つを要求するとき、サインされた領収書を送るのを明らかに拒否させてはいけません。 EDI UAが自動的にMDNを送るときはいつも、「気質モード」の第二部は「自動的に送られたMDN」に設定されます、発信がユーザ、アドミニストレータかソフトウェア制御装置の下にあったことにかかわらず。
Harding, et. al. Standards Track [Page 19] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[19ページ]RFC3335
Since EDI content is generally handled automatically by the EDI UA, a request for a receipt or signed receipt will generally return the following in the "disposition-field":
EDI内容がEDI UAによって一般に自動的に扱われるので、一般に、領収書かサインされた領収書を求める要求は「気質分野」で以下を返すでしょう:
Disposition: automatic-action/MDN-sent-automatically; processed
気質: MDNは自動的に自動動作/発信していました。 処理されます。
Note this specification does not restrict the use of the "disposition-mode" to just automatic actions. Manual actions are valid as long as it is kept in mind that a request for a signed receipt MUST be honored.
この仕様が「気質モード」の使用をまさしく自動動作に制限しないことに注意してください。 サインされた領収書を求める要求が光栄に思うに違いないのが覚えておかれる限り、手動の動きは有効です。
5.3.2.2 Unprocessed Content
5.3.2.2 未加工の内容
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 in the case where 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, so the EDI UA chooses not to process the message contents itself, should be specified in the MDN "disposition-field" as follows:
サインされた領収書を求める要求は返されたサインされた領収書のプロトコル形式を指定する2「気質通知オプション」とメッセージ内容に関してmicについて計算するのに使用されるMICアルゴリズムの使用を必要とします。 EDI UAが、メッセージコンテンツ自体を処理しないのを選んで、要求されたプロトコル形式を支持しないので、EDI UAが、サインされた領収書を返すことができないことを決定するなら、メッセージ内容が拒絶されるか、または例えば無視されている場合に使用されるべきである「気質分野」値は以下のMDN「気質分野」で指定されるべきです:
Disposition: "disposition-mode";
failed/Failure: unsupported format
気質: 「気質モード」。 失敗した/失敗: サポートされない形式
The syntax of the "failed" "disposition-type" is general, allowing the sending of any textual information along with the "failed" "disposition-type". For use in Internet EDI, the following "failed" values are defined:
「失敗した」「気質タイプ」に伴うどんな文字情報の発信も許して、「失敗した」「気質タイプ」の構文は一般的です。 インターネットEDIにおける使用において、以下の「失敗した」値は定義されます:
"Failure: unsupported format" "Failure: unsupported MIC-algorithms"
「失敗:」 「サポートされない形式」、「失敗:」 「サポートされないMIC-アルゴリズム」
5.3.2.3 Content Processing Errors
5.3.2.3 誤りを処理する内容
When errors occur processing the received message content, the "disposition-field" should be set to the "processed" "disposition- type" value and the "error" "disposition-modifier" value. For use in Internet EDI, the following "error" "disposition-modifier" values are defined:
誤りが受信されたメッセージ内容を処理しながら発生するとき、「気質分野」は「処理された」「気質タイプ」値と「誤り」「気質修飾語」価値へのセットであるべきです。 インターネットEDIにおける使用において、以下の「誤り」「気質修飾語」値は定義されます:
"Error: decryption-failed" - the receiver could not decrypt the
message contents.
「誤り:」 「復号化で失敗される」--受信機は、メッセージがコンテンツであると解読することができませんでした。
"Error: authentication-failed" - the receiver could not authenticate
the sender.
「誤り:」 「認証で失敗される」--受信機は送付者を認証できませんでした。
Harding, et. al. Standards Track [Page 20] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[20ページ]RFC3335
"Error: integrity-check-failed" - the receiver could not verify
content integrity.
「誤り:」 「保全チェックは失敗しました」--受信機は満足している保全について確かめることができませんでした。
"Error: unexpected-processing-error" - a catch-all for any additional
processing errors.
「誤り:」 「予期していなかった整理過程の誤差」--どんな追加整理過程の誤差のためのキャッチすべて。
An example of how the "disposition-field" would look when content processing errors are detected is as follows:
満足している整理過程の誤差が検出されるとき、「気質分野」がどう見えるだろうかに関する例は以下の通りです:
Disposition: "disposition-mode";
processed/Error: decryption-failed
気質: 「気質モード」。 処理/誤り: 復号化で、失敗されています。
5.3.2.4 Content Processing Warnings
5.3.2.4 警告を処理する内容
Situations arise in EDI where even if a trading partner cannot be authenticated correctly, the trading partners still agree to continue processing the EDI transactions. Transaction reconciliation is done between the trading partners at a later time. In the content processing warning situations as described above, the "disposition- field" SHOULD be set to the "processed" "disposition-type" value, and the "warning" "disposition-modifier" value. For use in Internet EDI, the following "warning" "disposition-modifier" values are defined:
状況は正しく貿易相手国を認証できないでも、貿易相手国がEDI取引を処理し続けているのにまだ同意しているEDIに起こります。 後で貿易相手国の間で取引和解をします。 上で説明される警告状況、「気質分野」SHOULDを処理する内容では、「処理された」「気質タイプ」値、および「警告」「気質修飾語」価値に設定されてください。 インターネットEDIにおける使用において、以下の「警告」「気質修飾語」値は定義されます:
"Warning: authentication-failed, processing continued"
「警告:」 「認証によって失敗されていて、処理は続きました」
An example of how the "disposition-field" would look when content processing warnings are detected is as follows:
満足している処理警告が検出されるとき、「気質分野」がどう見えるだろうかに関する例は以下の通りです:
Disposition: "disposition-mode"; processed/Warning:
authentication-failed, processing continued
気質: 「気質モード」。 処理されるか、または警告します: 認証によって失敗されていて、処理は続きました。
5.4 Message Disposition Notification Processing
5.4 メッセージ気質通知処理
5.4.1 Large File Processing
5.4.1 大きいファイル処理
Large EDI Interchanges sent via SMTP can be automatically fragmented by some message transfer agents. A subtype of message/partial, is defined in RFC 2045 [1] to allow large objects to be delivered as separate pieces of mail and to be automatically reassembled by the receiving user agent. Using message/partial, can help alleviate fragmentation of large messages by different message transfer agents, but does not completely eliminate the problem. It is still possible that a piece of a partial message, upon re-assembly, may prove to contain a partial message as well. This is allowed by the Internet standards, and it is the responsibility of the user agent to reassemble the fragmented pieces.
いくつかのメッセージ転送エージェントは自動的にSMTPを通して送られた大きいEDI Interchangesを断片化できます。 Aは、メッセージ/パーシャルを副タイプして、大きい物が別々のメールとして届けられて、受信ユーザエージェントによって自動的に組み立て直されるのを許容するためにRFC2045[1]で定義されます。 使用メッセージ/部分的です、完全に問題を解決するというわけではなくて、助けは異なったメッセージ転送エージェントで大きいメッセージの断片化を軽減できますか? 部分的なメッセージの1つの断片が再アセンブリのときにまた、部分的なメッセージを含むと判明するのは、まだ可能です。 これはインターネット標準によって許容されています、そして、断片化している断片を組み立て直すのは、ユーザエージェントの責任です。
Harding, et. al. Standards Track [Page 21] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[21ページ]RFC3335
It is RECOMMENDED that the size of the EDI Interchange sent via SMTP be configurable so that if fragmentation is needed, then message/partial can be used to send the large EDI Interchange in smaller pieces. RFC 2045 [1] defines the use of Content-Type: message/partial.
SMTPを通して送られたEDI Interchangeのサイズが断片化が必要であって、次に、メッセージ/部分的であるなら大きいEDI Interchangeをより小さい断片に送るのにそれを使用できるように構成可能であることは、RECOMMENDEDです。 RFC2045[1]はコンテントタイプの使用を定義します: メッセージ/部分的です。
Note: Support of the message/partial content type for use in Internet EDI is OPTIONAL and in the absence of knowledge that the recipient supports partial it SHOULD NOT be used.
以下に注意してください。 インターネットEDIにおける使用のためのメッセージ/部分的な満足しているタイプのサポートがOPTIONALと受取人がサポートする知識がないときある、部分的である、それ、SHOULD NOT、使用されてください。
The receiving UA is required to re-assemble the original message before sending the message disposition notification to the original sender of the message. A message disposition notification is used to specify the disposition of the entire message that was sent, and should not be returned by a processing UA until the entire message is received, even if the received message requires re-assembling.
メッセージ気質通知をメッセージの元の送り主に送る前に、受信UAはオリジナルのメッセージを組み立て直さなければなりません。 メッセージ気質通知を送られた全体のメッセージの気質を指定するのに使用して、全体のメッセージが受信されるまで、処理UAは返すはずがありません、受信されたメッセージが、組み立て直すのを必要としても。
5.4.2 Example
5.4.2 例
The following is an example of a signed receipt returned by a UA after successfully processing a MIME EDI content type. The sending trading partner has requested a return signed receipt.
↓これは首尾よくMIME EDIの満足しているタイプを処理した後にUAによって返されたサインされた領収書に関する例です。 送付貿易相手国は、リターンが領収書にサインしたよう要求しました。
This example follows the S/MIME application/pkcs-7-signature format.
この例はS/MIME pkcs7アプリケーション/署名形式に続きます。
NOTE: This example is provided as an illustration only, and is 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で指定されるプロトコル定義と闘争するなら、例は間違っています。
To: <recipient email>
Subject:
From: <sender email>
Date: <date>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="separator";
micalg=sha1; protocol="application/pkcs7-signature"
To: <受取人メール>Subject: From: <送付者メール>日付: <日付の>パントマイムバージョン: 1.0コンテントタイプ: 複合かサインされる。 境界は「分離符」と等しいです。 micalg=sha1。 プロトコル=「pkcs7アプリケーション/署名」
--separator
& Content-Type: multipart/report; report-type=disposition
& notification; boundary="xxxxx"
&
& --xxxxx
& Content-Type: text/plain
&
& The message sent to Recipient <Recipient@cyclonesoftware.com>
& has been received, the EDI Interchange was successfully
& decrypted and its integrity was verified. In addition, the
--分離符とコンテントタイプ: 複合/レポート。 レポートタイプは気質と通知と等しいです。 境界=、「xxxxx、」 --xxxxxとコンテントタイプ: テキスト/平野、メッセージが Recipient <Recipient@cyclonesoftware.com に発信した、gt;、受け取られていて、首尾よくである解読されたEDI Interchangeとその保全が確かめられたということでした。 添加で
Harding, et. al. Standards Track [Page 22] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[22ページ]RFC3335
& sender of the message, Sender <Edi_Sender@cyclonesoftware.com>
& was authenticated as the originator of the message. There is
& no guarantee however that the EDI Interchange was
& syntactically correct, or was received by the EDI
& application.
&
& --xxxxx
& Content-Type: message/disposition-notification
&
& Reporting-UA: Interchange.cyclonesoftware.com (CI 2.2)
& Original-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com
& Final-Recipient: rfc822; Edi_Recipient@cyclonesoftware.com
& Original-Message-ID: <17759920005.12345@cyclonesoftware.com >
& Disposition: automatic-action/MDN-sent-automatically; processed
& Received-content-MIC: Q2hlY2sgSW50XwdyaXRIQ, sha1
&
& --xxxxx
& Content-Type: message/rfc822
&
& To: <recipient email>
& Subject:
&
& [additional header fields go here]
&
& --xxxxx--
メッセージ送信者、 Sender <Edi_Sender@cyclonesoftware.com 、gt;、メッセージの創始者として、認証されました。 あって、いいえをしかしながら、EDI Interchangeがあって、シンタクス上正しいのを保証したか、またはEDIとアプリケーションで受け取りました。 --xxxxxとコンテントタイプ: 気質メッセージ/通知、Reporting-UA: Interchange.cyclonesoftware.com(CI2.2)とオリジナルの受取人: rfc822。 Edi_Recipient@cyclonesoftware.com と最終受理者: rfc822。 Edi_Recipient@cyclonesoftware.com と元のMessage ID: <17759920005.12345@cyclonesoftware.com>と気質: MDNは自動的に自動動作/発信していました。 処理されてReceivedがMICを満足させている、: Q2hlY2sgSW50XwdyaXRIQ、sha1、--xxxxxとコンテントタイプ: メッセージ/rfc822、To: <受取人メール>とSubject: [ここで順調な追加ヘッダーフィールド]、--xxxxx--
--separator
Content-Type: application/pkcs7-signature; name=smime.p7s;
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s
--分離符コンテントタイプ: pkcs7アプリケーション/署名。 =をsmime.p7sと命名してください。 満足している転送コード化: base64 Content-気質: 付属。 ファイル名=smime.p7s
MIIHygYJKoZIhvcNAQcDoIIHuzCCB7cCAQAxgfIwge8CAQAwg
ZgwgYMxFjAUBgNVBAMTDVRlcnJ5IEhhcmRpbmcxEDAOBgNVBA
oTB0NZQ0xPTkUxDDAKBgNVBAsTA04vQTEQMA4GA1UEBxMHU=
MIIHygYJKoZIhvcNAQcDoIIHuzCCB7cCAQAxgfIwge8CAQAwg ZgwgYMxFjAUBgNVBAMTDVRlcnJ5IEhhcmRpbmcxEDAOBgNVBA oTB0NZQ0xPTkUxDDAKBgNVBAsTA04vQTEQMA4GA1UEBxMHU=
--separator--
--分離符--
Notes:
注意:
-The lines preceded with "&" is what the signature is calculated
over.
-“&"で先行された系列は署名が何に関して計算されるかということです。
(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".)
(どう複合の、または、プロトコル=を契約された「pkcs7アプリケーション/署名」を準備するかに関する詳細に関して、「S/MIMEメッセージ仕様、MIMEのためのPKCSセキュリティー・サービス」を見てください。)
Harding, et. al. Standards Track [Page 23] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[23ページ]RFC3335
Note: As specified by RFC 1892 [9], 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. It is RECOMMENDED that the received headers from the original message be placed in the third body part, as they can be helpful in tracking problems.
以下に注意してください。 オリジナルを返して、RFC1892[9]で指定するか、または必要でないように複合/の3番目の身体の部分のオリジナルのメッセージの部分が、報告する。 これは任意の身体の部分です。 オリジナルのメッセージからの容認されたヘッダーが3番目の身体の部分に置かれるのは、RECOMMENDEDです、彼らが問題点の追跡に役立つことができるとき。
Also 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.
また、気質ヘッダーによって報告されたエラー条件の、より詳細な説明を含むのに複合/レポートの原文の最初の身体の部分を使用できることに注意してください。 このように使用されると、複合/の最初の身体の部分は報告します、と詳細に問題をより診断する人が許します。
6.0 Public Key Certificate Handling
6.0 公開鍵証明書取り扱い
6.1 Near Term Approach
6.1 短期間アプローチ
In the near term, the exchange of public keys and certification of these keys must be handled as part of the process of establishing a trading partnership. The UA and/or EDI application interface must maintain a database of public keys used for encryption or signatures, in addition to the mapping between EDI trading partner ID and RFC 822 [3] email address. The procedures for establishing a trading partnership and configuring the secure EDI messaging system might vary among trading partners and software packages.
近いうちに、商事組合を確立するプロセスの一部として公開鍵の交換とこれらのキーの証明を扱わなければなりません。 UA、そして/または、EDIアプリケーション・インターフェースは暗号化に使用される公開鍵に関するデータベースかEDI貿易相手国IDとRFC822[3]Eメールアドレスの間のマッピングに加えた署名を維持しなければなりません。 商事組合、安全なEDIメッセージシステムが貿易相手国の中で異なるかもしれないのを構成して、およびソフトウェアパッケージを確立するための手順。
For systems which make use of X.509 certificates, it is RECOMMENDED that trading partners self-certify each other if an agreed upon certification authority is not used. It is highly RECOMMENDED that when trading partners are using S/MIME, that they also exchange public key certificates using the recommendations specified in the S/MIME Version 3 Message Specification. The message formats and S/MIME conformance requirements for certificate exchange are specified in this document.
貿易相手国が自己に互いを公認するのが、X.509証明書を利用するシステムのためのRECOMMENDEDである、同意されて、証明権威は使用されていません。 それは非常にそうです。貿易相手国であるときにS/MIMEを使用しているRECOMMENDED、また、推薦を使用することで公開鍵証明書を交換するのはS/MIMEバージョン3Message Specificationで指定しました。 証明書交換のためのメッセージ・フォーマットとS/MIME順応要件は本書では指定されます。
This applicability statement does NOT require the use of a certification authority. The use of a certification authority is therefore OPTIONAL.
この適用性証明は証明権威の使用を必要としません。 したがって、証明権威の使用はOPTIONALです。
6.2 Long Term Approach
6.2 長期アプローチ
In the long term, additional Internet-EDI standards may be developed to simplify the process of establishing a trading partnership, including the third party authentication of trading partners, as well as attributes of the trading relationship.
長期で、追加インターネット-EDI規格は商事組合を確立するプロセスを簡素化するために開発されるかもしれません、貿易相手国の第三者認証を含んでいて、取り引き関係の属性と同様に。
Harding, et. al. Standards Track [Page 24] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[24ページ]RFC3335
7.0 Security Considerations
7.0 セキュリティ問題
This entire document is concerned with secure transport of business to business data, and considers both privacy and authentication issues.
この全体のドキュメントは、企業間電子商取引データの安全な輸送に関係があって、プライバシーと認証問題の両方を考えます。
Extracted from S/MIME Version 2 Message Specification:
S/MIMEバージョン2メッセージ仕様から抽出される:
40-bit encryption is considered weak by most cryptographers. Using weak cryptography offers little actual security over sending plain text. However, other features of S/MIME, such as the specification of tripleDES or AES and the ability to announce stronger cryptographic capabilities to parties with whom you communicate, allow senders to create messages that use strong encryption. Using weak cryptography is never recommended unless the only alternative is no cryptography. When feasible, sending and receiving agents should inform senders and recipients the relative cryptographic strength of messages.
40ビットの暗号化は弱いとほとんどの暗号使用者によって考えられます。 弱い暗号を使用するのはほとんど送付プレーンテキストの上に実際のセキュリティを提供しません。 しかしながら、tripleDESかAESの仕様などのS/MIMEの他の特徴とあなたと交信するパーティーへの、より強い暗号の能力を発表する能力で、送付者は強い暗号化を使用するメッセージを作成できます。 弱い暗号を使用するのは唯一の選択肢が暗号であるなら決してお勧めではありません。 可能であるときに、送受信エージェントはメッセージの相対的な暗号の強さの送付者と受取人に知らせるべきです。
Extracted from S/MIME Version 2 Certificate Handling:
S/MIMEバージョン2証明書取り扱いから抽出される:
When processing certificates, there are many situations where the processing might fail. Because the processing may be done by a user agent, a security gateway, or other program, there is no single way to handle such failures. Just because the methods to handle the failures has not been listed, however, the reader should not assume that they are not important. The opposite is true: if a certificate is not provably valid and associated with the message, the processing software should take immediate and noticeable steps to inform the end user about it.
証明書を処理するとき、多くの状況が処理が失敗するかもしれないところにあります。 ユーザエージェント、セキュリティゲートウェイ、または他のプログラムで処理をするかもしれないので、そのような失敗を扱うどんなただ一つの方法もありません。 失敗を扱うメソッドが記載されているだけではないので、しかしながら、読者は、それらが重要でないと仮定するべきではありません。 正反対は本当です: 証明書がメッセージに有効であって、関連していて、証明可能に、処理ソフトウェアがそれに関してエンドユーザに知らせるために即座の、そして、めぼしい方法を採るはずであるということでないなら。
Some of the many places where signature and certificate checking might fail include:
署名と証明書の照合が失敗するかもしれない多くの場所のいくつかは:
- no certificate chain leads to a trusted CA - no ability to check the CRL for a certificate - an invalid CRL was received - the CRL being checked is expired - the certificate is expired - the certificate has been revoked
- 信じられたカリフォルニアへの証明書チェーン先導がありません--証明書がないかどうかCRLをチェックする能力がありません--無効のCRLを受け取りました--チェックされるCRLは満期です--証明書は満期です--証明書は取り消されました。
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.
確かに、チェックが失敗するなら、他のインスタンスが証明書が無効であるかもしれなく、それらを皆、徹底的にチェックして、何をしたらよいかを決めるのが、処理ソフトウェアの責任であるところにあります。
Harding, et. al. Standards Track [Page 25] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[25ページ]RFC3335
8.0 Acknowledgments
8.0 承認
Many thanks go out to the previous authors of the MIME-based Secure EDI IETF Draft: Mats Jansson.
許可していた状態で、MIMEベースのSecureエディIETF Draftの前の作者への外でありがとうございます: マッツ・ヤンソン。
The authors would like to extend special thanks to Carl Hage, Jun Ding, Dale Moberg, and Karen Rosenthal for providing the team with valuable, and very thorough feedback. Without participants like those cited above, these efforts become hard to complete in a way useful to the users and implementers of the technology.
作者は、貴重で、非常に徹底的なフィードバックをチームに提供するためにカール・ヘイグ、Jun Ding、デール・モーベリ、およびカレンRosenthalに特別な感謝を表したがっています。 上で引用されたもののような関係者がいなければ、これらの取り組みは技術のユーザとimplementersの役に立つ方法で完成しにくいようになります。
In addition, the authors would like to thank Harald Alvestrand, Jim Galvin, and Roger Fajman for their guidance and input.
さらに、作者は彼らの指導と入力についてハラルドAlvestrand、ジム・ガルビン、およびロジャーFajmanに感謝したがっています。
9.0 References
9.0の参照箇所
[1] Borenstein, N. and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[1] Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
Borenstein, N. and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Borenstein, N. and N. Freed, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Examples",
RFC 2049, November 1996.
Borenstein、N.、およびN.フリード、「マルチパーパスインターネットメールエクステンション(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] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[3] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[4] Elkins, M., "MIME Security With Pretty Good Privacy (PGP)", RFC
2015, October 1996.
[4] エルキンズ、M.、「プリティ・グッド・プライバシ(PGP)があるMIMEセキュリティ」、RFC2015、1996年10月。
Callas, J., Donnerhacke, L., Finney, H. and R.Thayer "OpenPGP
Message Format", RFC 2440, November 1998.
カラスとJ.とDonnerhackeとL.とフィニーとH.とR.セイヤー「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
Elkins, M., Del Torto, D., Levien, R. and T. Roessler "MIME
Security with OpenPGP", RFC 3156, August 2001.
エルキンズ、M.、デルTorto、D.、レヴィエン、R.、およびT.Roesslerが「OpenPGPと共にセキュリティをまねる」、RFC3156、8月2001日
[5] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[5]Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、1998年3月。
[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月。
Harding, et. al. Standards Track [Page 26] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[26ページ]RFC3335
[7] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
1982.
[7]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、1982年4月。
[8] Ramsdell, B., "S/MIME Version 3 Message Specification;
Cryptographic Message Syntax", RFC 2633, June 1999.
[8]Ramsdell、B.、「S/MIMEバージョン3メッセージ仕様」。 「暗号のメッセージ構文」、RFC2633、1999年6月。
Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[9] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC 1892,
January 1996.
[9] ボードルイ、G.、「メールのシステムの管理メッセージの報告のための複合/レポートcontent type」、RFC1892、1996年1月。
Harding, et. al. Standards Track [Page 27] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[27ページ]RFC3335
Appendix IANA Registration Form
付録IANA登録用紙
A.1 IANA registration of the signed-receipt-protocol content
disposition parameter
署名している領収書プロトコルの満足している気質パラメタのA.1 IANA登録
Parameter-name: signed-receipt-protocol
Syntax: See section 5.2 of this document
Specification: See section 5.2 of this document
パラメタ名: 署名している領収書プロトコルSyntax: このドキュメントSpecificationのセクション5.2を見てください: このドキュメントのセクション5.2を見てください。
A.2 IANA registration of the signed-receipt-micalg content
disposition parameter
署名している領収書micalgの満足している気質パラメタのA.2 IANA登録
Parameter-name: signed-receipt-micalg
Syntax: See section 5.2 of this document
Specification: See section 5.2 of this document
パラメタ名: 署名している領収書micalg Syntax: このドキュメントSpecificationのセクション5.2を見てください: このドキュメントのセクション5.2を見てください。
A.3 IANA registration of the Received-content-MIC MDN extension
field name
Receivedの満足しているMIC MDN拡大フィールド名のA.3 IANA登録
Extension field name: Received-content-MIC
Syntax: See section 5.3.1 of this document
Specification: See section 5.3.1 of this document
拡大フィールド名: 容認された満足しているMIC構文: この.1セクション5.3ドキュメントSpecificationを見てください: この.1通のセクション5.3ドキュメントを見てください。
Authors' Addresses
作者のアドレス
Terry Harding Cyclone Commerce 8388 E. Hartford Drive Scottsdale, Arizona 85255, USA
Driveスコッツデール、アリゾナ 85255、タオルハーディング低気圧商業8388E.ハートフォード米国
EMail: tharding@cyclonecommerce.com
メール: tharding@cyclonecommerce.com
Chuck Shih Gartner Group 251 River Oaks Parkway San Jose, CA 95134-1913 USA
チャックShihガートナーグループ251川のオークParkwayサンノゼ、カリフォルニア95134-1913米国
EMail: chuck.shih@gartner.com
メール: chuck.shih@gartner.com
Rik Drummond Drummond Group P.O. Box 101567 Ft. Worth, TX 76105 USA
リクドラモンドドラモンドグループ私書箱101567フィート テキサス76105ワース(米国)
EMail: rik@drummondgroup.com
メール: rik@drummondgroup.com
Harding, et. al. Standards Track [Page 28] RFC 3335 MIME-based Secure EDI September 2002
etハーディング、アル。 安全なEDI2002年9月のMIMEベースの標準化過程[28ページ]RFC3335
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. v This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう; Thisドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証に対して。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Harding, et. al. Standards Track [Page 29]
etハーディング、アル。 標準化過程[29ページ]
一覧
スポンサーリンク
