RFC2801 日本語訳
2801 Internet Open Trading Protocol - IOTP Version 1.0. D. Burdett. April 2000. (Format: TXT=598794 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Burdett Request for Comments: 2801 Commerce One Category: Informational April 2000
コメントを求めるワーキンググループD.バーデット要求をネットワークでつないでください: 2801年の商業1つのカテゴリ: 情報の2000年4月
Internet Open Trading Protocol - IOTP
Version 1.0
インターネットの開いている取り引きプロトコル--IOTPバージョン1.0
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Secure Channel Credit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the Payment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party.
インターネットオープンTradingプロトコル(IOTP)は共同利用できるフレームワークをインターネット商業に提供します。 それは、決済システム独立者であり、SETなどの決済システム、Secure Channel Credit/借り方、モンデックス、サイバーコイン、GeldKarteなどをカプセル化します。 IOTPは買い物サイト、Payment Handler、商品の、または、サービスのDelivery Handler、および顧客サポートのプロバイダーが異なったパーティーによって実行されるか、1のそのような商人の役割がパーティーへ行くケースを扱うことができます。
Table of Contents
目次
1. Background .....................................................7
1.1 Commerce on the Internet, a Different Model .................7
1.2 Benefits of IOTP ............................................9
1.3 Baseline IOTP ..............................................10
1.4 Objectives of Document .....................................10
1.5 Scope of Document ..........................................11
1.6 Document Structure .........................................11
1.7 Intended Readership ........................................13
1.7.1 Reading Guidelines ...................................13
2. Introduction ..................................................14
2.1 Trading Roles ..............................................16
2.2 Trading Exchanges ..........................................18
2.2.1 Offer Exchange .......................................19
2.2.2 Payment Exchange .....................................21
2.2.3 Delivery Exchange ....................................24
2.2.4 Authentication Exchange ..............................26
2.3 Scope of Baseline IOTP .....................................28
1. バックグラウンド…7 1.1 インターネットにおける商業、異なったモデル…7 IOTPの1.2の利益…9 1.3 基線IOTP…10 ドキュメントの1.4の目的…10 1.5 ドキュメントの範囲…11 1.6 構造を記録してください…11 1.7 購読者層は意図しました…13 1.7 .1 ガイドラインを読みます…13 2. 序論…14 2.1 役割を取り引きします…16 2.2 取り引き交換…18 2.2 .1 交換を提供してください…19 2.2 .2 支払い交換…21 2.2 .3 配送交換…24 2.2 .4 認証交換…26 2.3 基線IOTPの範囲…28
Burdett Informational [Page 1] RFC 2801 IOTP/1.0 April 2000
バーデット[1ページ]情報のRFC2801IOTP/2000年4月1日
3. Protocol Structure ............................................31
3.1 Overview ...................................................32
3.1.1 IOTP Message Structure ...............................32
3.1.2 IOTP Transactions ....................................34
3.2 IOTP Message ...............................................35
3.2.1 XML Document Prolog ..................................37
3.3 Transaction Reference Block ................................37
3.3.1 Transaction Id Component .............................38
3.3.2 Message Id Component .................................39
3.3.3 Related To Component .................................41
3.4 ID Attributes ..............................................42
3.4.1 IOTP Message ID Attribute Definition .................43
3.4.2 Block and Component ID Attribute Definitions .........44
3.4.3 Example of use of ID Attributes ......................46
3.5 Element References .........................................46
3.6 Extending IOTP .............................................48
3.6.1 Extra XML Elements ...................................49
3.6.2 Opaque Embedded Data .................................50
3.7 Packaged Content Element ...................................50
3.7.1 Packaging HTML .......................................52
3.7.2 Packaging XML ........................................53
3.8 Identifying Languages ......................................54
3.9 Secure and Insecure Net Locations ..........................54
3.10 Cancelled Transactions .....................................55
3.10.1 Cancelling Transactions ..............................55
3.10.2 Handling Cancelled Transactions ......................56
4. IOTP Error Handling ...........................................56
4.1 Technical Errors ...........................................57
4.2 Business Errors ............................................57
4.3 Error Depth ................................................58
4.3.1 Transport Level ......................................58
4.3.2 Message Level ........................................58
4.3.3 Block Level ..........................................59
4.4 Idempotency, Processing Sequence, and Message Flow .........61
4.5 Server Role Processing Sequence ............................62
4.5.1 Initiating Transactions ..............................62
4.5.2 Processing Input Messages ............................63
4.5.3 Cancelling a Transaction .............................70
4.5.4 Retransmitting Messages ..............................70
4.6 Client Role Processing Sequence ............................71
4.6.1 Initiating Transactions ..............................71
4.6.2 Processing Input Messages ............................72
4.6.3 Cancelling a Transaction .............................74
4.6.4 Retransmitting Messages ..............................74
5. Security Considerations .......................................74
5.1 Determining whether to use digital signatures ..............74
5.2 Symmetric and Asymmetric Cryptography ......................76
5.3 Data Privacy ...............................................77
3. 構造について議定書の中で述べてください…31 3.1概要…32 3.1 .1 IOTPメッセージ構造…32 3.1 .2 IOTPトランザクション…34 3.2IOTPメッセージ…35 3.2 .1 XMLはプロローグを記録します…37 3.3 トランザクション対比試験片…37 3.3 .1トランザクションイドコンポーネント…38 3.3 .2メッセージイドコンポーネント…39 3.3 .3はコンポーネントに関係しました…41 3.4 ID属性…42 3.4 .1 IOTPメッセージID属性定義…43 3.4 .2ブロックとComponent IDは定義を結果と考えます…44 3.4 ID Attributesで役に立つ.3の例…46 3.5 要素参照…46 3.6 IOTPを広げています…48 3.6 .1 付加的なXML Elements…49 3.6 .2 埋め込まれたデータについて不透明にしてください…50 3.7は満足している要素をパッケージしました…50 3.7 .1 HTMLをパッケージします…52 3.7 .2 XMLをパッケージします…53 3.8 言語を特定します…54 3.9 安全で不安定なネットの位置…54 3.10はトランザクションを取り消しました…55 3.10.1 トランザクションを取り消します…55 3.10.2 取り扱いはトランザクションを取り消しました…56 4. IOTPエラー処理…56 4.1 技術的な誤り…57 4.2 ビジネス誤り…57 4.3 誤りの深さ…58 4.3 .1 レベルを輸送してください…58 4.3 .2 メッセージレベル…58 4.3 .3 レベルを妨げてください…59 4.4のIdempotency、処理系列、およびメッセージは流れます…61 4.5 サーバーの役割処理系列…62 4.5 .1 トランザクションを開始します…62 4.5 .2 処理はメッセージを入力しました…63 4.5 .3 トランザクションを取り消します…70 4.5 .4 メッセージを再送します…70 4.6 クライアント役割の処理系列…71 4.6 .1 トランザクションを開始します…71 4.6 .2 処理はメッセージを入力しました…72 4.6 .3 トランザクションを取り消します…74 4.6 .4 メッセージを再送します…74 5. セキュリティ問題…74 5.1 デジタル署名を使用するかどうか決定します…74 5.2の左右対称の、そして、非対称の暗号…76 5.3 データプライバシー…77
Burdett Informational [Page 2] RFC 2801 IOTP/1.0 April 2000
バーデット[2ページ]情報のRFC2801IOTP/2000年4月1日
5.4 Payment Protocol Security ..................................77
6. Digital Signatures and IOTP ...................................77
6.1 How IOTP uses Digital Signatures ...........................77
6.1.1 IOTP Signature Example ...............................80
6.1.2 OriginatorInfo and RecipientInfo Elements ............82
6.1.3 Using signatures to Prove Actions Complete
Successfully .........................................83
6.2 Checking a Signature is Correctly Calculated ...............84
6.3 Checking a Payment or Delivery can occur ...................85
6.3.1 Check Request Block sent Correct Organisation ........86
6.3.2 Check Correct Components present in Request Block ....91
6.3.3 Check an Action is Authorised ........................91
7. Trading Components ............................................93
7.1 Protocol Options Component .................................96
7.2 Authentication Request Component ...........................97
7.3 Authentication Response Component ..........................98
7.4 Trading Role Information Request Component .................99
7.5 Order Component ...........................................100
7.5.1 Order Description Content ...........................101
7.5.2 OkFrom and OkTo Timestamps ..........................101
7.6 Organisation Component ....................................102
7.6.1 Organisation IDs ....................................104
7.6.2 Trading Role Element ................................105
7.6.3 Contact Information Element .........................108
7.6.4 Person Name Element .................................109
7.6.5 Postal Address Element ..............................110
7.7 Brand List Component ......................................111
7.7.1 Brand Element .......................................113
7.7.2 Protocol Brand Element ..............................115
7.7.3 Protocol Amount Element .............................116
7.7.4 Currency Amount Element .............................117
7.7.5 Pay Protocol Element ................................118
7.8 Brand Selection Component .................................120
7.8.1 Brand Selection Brand Info Element ..................122
7.8.2 Brand Selection Protocol Amount Info Element ........122
7.8.3 Brand Selection Currency Amount Info Element ........123
7.9 Payment Component .........................................123
7.10 Payment Scheme Component ..................................125
7.11 Payment Receipt Component .................................126
7.12 Payment Note Component ....................................128
7.13 Delivery Component ........................................129
7.13.1 Delivery Data Element ...............................130
7.14 Consumer Delivery Data Component ..........................132
7.15 Delivery Note Component ...................................133
7.16 Status Component ..........................................134
7.16.1 Offer Completion Codes ..............................137
7.16.2 Payment Completion Codes ............................138
7.16.3 Delivery Completion Codes ...........................140
5.4 支払いプロトコルセキュリティ…77 6. デジタル署名とIOTP…77 6.1 どのようにIOTPはDigital Signaturesを使用するか…77 6.1 .1IOTP署名の例…80 6.1 .2 OriginatorInfoとRecipientInfo Elements…82 6.1 .3 Prove Actions Complete Successfullyに署名を使用します…83 6.2 Signatureをチェックするのは、Correctly Calculatedです…84 6.3 PaymentかDeliveryをチェックするのは起こることができます…85 6.3 .1 チェックRequest BlockはCorrect Organisationを送りました…86 6.3 .2 Request Blockの現在のCorrect Componentsをチェックしてください…6.3に、.3はチェックします。91、ActionはAuthorisedです…91 7. コンポーネントを取り引きします…93 7.1 オプションコンポーネントについて議定書の中で述べてください…96 7.2認証要求コンポーネント…97 7.3認証応答コンポーネント…98 7.4 役割の情報を取り引きして、コンポーネントを要求してください…99 7.5 コンポーネントを命令してください…100 7.5.1 記述内容を注文してください…101 7.5.2 OkFromとOkToタイムスタンプ…101 7.6機構コンポーネント…102 7.6.1 機構ID…104 7.6.2 取り引き役割の要素…105 7.6.3 問い合わせ先要素…108 7.6.4 人の名前要素…109 7.6.5 郵便のアドレス要素…110 7.7 リストコンポーネントに商標を付けてください…111 7.7.1 要素に商標を付けてください…113 7.7.2 ブランド要素について議定書の中で述べてください…115 7.7.3 量の要素について議定書の中で述べてください…116 7.7.4 貨幣額要素…117 7.7.5 プロトコル要素支払ってください…118 7.8 選択にコンポーネントと商標を付けてください…120 7.8.1 選択にブランドインフォメーション要素と商標を付けてください…122 7.8.2 選択プロトコルに量のインフォメーション要素と商標を付けてください…122 7.8.3 選択貨幣額にインフォメーション要素と商標を付けてください…123 7.9支払いコンポーネント…123 7.10支払い体系コンポーネント…125 7.11支払い領収書の部品…126 7.12支払い注意コンポーネント…128 7.13配送コンポーネント…129 7.13 .1配送データ要素…130 7.14 消費者配送データ構成要素…132 7.15納品受領書の部品…133 7.16状態コンポーネント…134 7.16 .1 完了コードを提供してください…137 7.16 .2 支払い完了コード…138 7.16 .3 配送完了コード…140
Burdett Informational [Page 3] RFC 2801 IOTP/1.0 April 2000
バーデット[3ページ]情報のRFC2801IOTP/2000年4月1日
7.16.4 Authentication Completion Codes .....................142
7.16.5 Undefined Completion Codes ..........................144
7.16.6 Transaction Inquiry Completion Codes ................144
7.17 Trading Role Data Component ...............................144
7.17.1 Who Receives a Trading Role Data Component ..........145
7.18 Inquiry Type Component ....................................146
7.19 Signature Component .......................................147
7.19.1 IOTP usage of signature elements and attributes .....148
7.19.2 Offer Response Signature Component ..................150
7.19.3 Payment Receipt Signature Component .................151
7.19.4 Delivery Response Signature Component ...............152
7.19.5 Authentication Request Signature Component ..........152
7.19.6 Authentication Response Signature Component .........153
7.19.7 Inquiry Request Signature Component .................153
7.19.8 Inquiry Response Signature Component ................153
7.19.9 Ping Request Signature Component ....................153
7.19.10 Ping Response Signature Component...................154
7.20 Certificate Component .....................................154
7.20.1 IOTP usage of signature elements and attributes .....154
7.21 Error Component ...........................................154
7.21.1 Error Processing Guidelines .........................157
7.21.2 Error Codes .........................................158
7.21.3 Error Location Element ..............................162
8. Trading Blocks ...............................................163
8.1 Trading Protocol Options Block ............................166
8.2 TPO Selection Block .......................................167
8.3 Offer Response Block ......................................168
8.4 Authentication Request Block ..............................169
8.5 Authentication Response Block .............................170
8.6 Authentication Status Block ...............................171
8.7 Payment Request Block .....................................171
8.8 Payment Exchange Block ....................................173
8.9 Payment Response Block ....................................173
8.10 Delivery Request Block ....................................175
8.11 Delivery Response Block ...................................176
8.12 Inquiry Request Trading Block .............................177
8.13 Inquiry Response Trading Block ............................177
8.14 Ping Request Block ........................................179
8.15 Ping Response Block .......................................179
8.16 Signature Block ...........................................181
8.16.1 Signature Block with Offer Response .................182
8.16.2 Signature Block with Payment Request ................182
8.16.3 Signature Block with Payment Response ...............182
8.16.4 Signature Block with Delivery Request ...............182
8.16.5 Signature Block with Delivery Response ..............182
8.17 Error Block ...............................................183
8.18 Cancel Block ..............................................184
9. Internet Open Trading Protocol Transactions ..................184
7.16.4 認証完了コード…142 7.16 .5の未定義の完了コード…144 7.16 .6 取引照会完了コード…144 7.17 取り引き役割のデータ構成要素…144 7.17 .1 だれが取り引き役割のデータ構成要素を受け取るか…145 7.18問い合せタイプ成分…146 7.19署名コンポーネント…147 7.19 .1 署名要素と属性のIOTP用法…148 7.19 .2 応答署名コンポーネントを提供してください…150 7.19 .3支払い領収書署名の部品…151 7.19 .4配送応答署名コンポーネント…152 7.19 .5認証要求署名コンポーネント…152 7.19 .6認証応答署名コンポーネント…153 7.19 .7問い合せ要求署名コンポーネント…153 7.19 .8問い合せ応答署名コンポーネント…153 7.19 .9 要求署名コンポーネントを確認してください…153 7.19 .10 応答署名コンポーネントを確認してください…154 7.20 コンポーネントを証明してください…154 7.20 .1 署名要素と属性のIOTP用法…154 7.21誤りコンポーネント…154 7.21 .1 エラー処理ガイドライン…157 7.21 .2 誤りコード…158 7.21 .3誤り位置の要素…162 8. 取り引きブロック…163 8.1 オプションが妨げる取り引きプロトコル…166 8.2TPO選択ブロック…167 8.3 応答ブロックを提供してください…168 8.4認証要求ブロック…169 8.5認証応答ブロック…170 8.6認証状態ブロック…171 8.7支払請求書ブロック…171 8.8支払い交換ブロック…173 8.9支払い応答ブロック…173 8.10配送要求ブロック…175 8.11配送応答ブロック…176 8.12 問い合せ要求通商圏…177 8.13 問い合せ応答通商圏…177 8.14 要求ブロックを確認してください…179 8.15 応答ブロックを確認してください…179 8.16署名欄…181 8.16 申し出応答がある.1署名欄…182 8.16 支払請求書がある.2署名欄…182 8.16 支払い応答がある.3署名欄…182 8.16 配送要求がある.4署名欄…182 8.16 配送応答がある.5署名欄…182 8.17誤りブロック…183 8.18 ブロックを取り消してください…184 9. インターネットの開いている取り引きプロトコルトランザクション…184
Burdett Informational [Page 4] RFC 2801 IOTP/1.0 April 2000
バーデット[4ページ]情報のRFC2801IOTP/2000年4月1日
9.1 Authentication and Payment Related IOTP Transactions ......185
9.1.1 Authentication Document Exchange ....................188
9.1.2 Offer Document Exchange .............................194
9.1.3 Payment Document Exchange ...........................203
9.1.4 Delivery Document Exchange ..........................209
9.1.5 Payment and Delivery Document Exchange ..............212
9.1.6 Baseline Authentication IOTP Transaction ............216
9.1.7 Baseline Deposit IOTP Transaction ...................218
9.1.8 Baseline Purchase IOTP Transaction ..................220
9.1.9 Baseline Refund IOTP Transaction ....................222
9.1.10 Baseline Withdrawal IOTP Transaction ................224
9.1.11 Baseline Value Exchange IOTP Transaction ............226
9.1.12 Valid Combinations of Document Exchanges ............230
9.1.13 Combining Authentication Transactions with other
Transactions ........................................234
9.2 Infrastructure Transactions ...............................235
9.2.1 Baseline Transaction Status Inquiry IOTP Transaction 235
9.2.2 Baseline Ping IOTP Transaction ......................241
10. Retrieving Logos .............................................244
10.1 Logo Size .................................................245
10.2 Logo Color Depth ..........................................245
10.3 Logo Net Location Examples ................................246
11. Brands .......................................................246
11.1 Brand Definitions and Brand Selection .....................246
11.1.1 Definition of Payment Instrument ....................247
11.1.2 Definition of Brand .................................247
11.1.3 Definition of Dual Brand ............................248
11.1.4 Definition of Promotional Brand .....................248
11.1.5 Identifying Promotional Brands ......................249
11.2 Brand List Examples .......................................251
11.2.1 Simple Credit Card Based Example ....................252
11.2.2 Credit Card Brand List Including Promotional Brands..253
11.2.3 Brand Selection Example .............................254
11.2.4 Complex Electronic Cash Based Brand List ............255
12. IANA Considerations ..........................................257
12.1 Codes Controlled by IANA ..................................257
12.2 Codes not controlled by IANA ..............................263
13. Internet Open Trading Protocol Data Type Definition ..........263
14. Glossary .....................................................277
15. References ...................................................284
16. Author's Address .............................................287
17. Full Copyright Statement .....................................290
9.1の認証と支払いはIOTPトランザクションを関係づけました…185 9.1.1 認証ドキュメント交換…188 9.1.2 ドキュメント交換を提供してください…194 9.1.3 支払いドキュメント交換…203 9.1.4 配送ドキュメント交換…209 9.1.5 支払いと配送は交換を記録します…212 9.1.6 基線認証IOTPトランザクション…216 9.1.7 基線預金IOTPトランザクション…218 9.1.8 基線購買IOTPトランザクション…220 9.1.9 基線還付IOTPトランザクション…222 9.1.10 基線退出IOTPトランザクション…224 9.1.11 基礎値交換IOTPトランザクション…226 9.1.12 ドキュメント交換の有効な組み合わせ…230 9.1.13 他のTransactionsにAuthentication Transactionsを結合します…234 9.2 インフラストラクチャトランザクション…235 9.2.1 基線トランザクション資産調査IOTPトランザクション235 9.2.2基線ピングIOTPトランザクション…241 10. ロゴを検索します…244 10.1 ロゴサイズ…245 10.2 ロゴ色の濃さ…245 10.3 ロゴネット位置の例…246 11. ブランド…246 11.1 定義とブランド選択に商標を付けてください…246 11.1 .1 支払い器具の定義…247 11.1 .2 ブランドの定義…247 11.1 .3 二元的なブランドの定義…248 11.1 .4 宣伝のブランドの定義…248 11.1 .5 宣伝のブランドを特定します…249 11.2 リストの例に商標を付けてください…251 11.2 .1シンプル・クレジットカードは例を基礎づけました…252 11.2 宣伝のブランドを含む.2クレジットカードブランドリスト。253 11.2 .3 選択に例と商標を付けてください…254 11.2 .4 複雑な電子現金はブランドリストを基礎づけました…255 12. IANA問題…257 12.1のコードがIANAによって制御されました…257 12.2のコードはIANAによって制御されませんでした…263 13. インターネットの開いている取り引きプロトコルデータ型定義…263 14. 用語集…277 15. 参照…284 16. 作者のアドレス…287 17. 完全な著作権宣言文…290
Burdett Informational [Page 5] RFC 2801 IOTP/1.0 April 2000
バーデット[5ページ]情報のRFC2801IOTP/2000年4月1日
Table of Figures
数値表
Figure 1 IOTP Trading Roles 16 Figure 2 Offer Exchange 19 Figure 3 Payment Exchange 22 Figure 4 Delivery Exchange 25 Figure 5 Authentication Exchange 27 Figure 6 IOTP Message Structure 33 Figure 7 An IOTP Transaction 34 Figure 8 Example use of ID attributes 46 Figure 9 Element References 48 Figure 10 Signature Digests 79 Figure 11 Example use of Signatures for Baseline Purchase 81 Figure 12 Checking a Payment Handler can carry out a Payment 87 Figure 13 Checking a Delivery Handler can carry out a Delivery 90 Figure 14 Trading Components 94 Figure 15 Brand List Element Relationships 113 Figure 16 Trading Blocks 164 Figure 17 Payment and Authentication Message Flow Combinations 187 Figure 18 Authentication Document Exchange 190 Figure 19 Brand Dependent Offer Document Exchange 196 Figure 20 Brand Independent Offer Exchange 198 Figure 21 Payment Document Exchange 204 Figure 22 Delivery Document Exchange 210 Figure 23 Payment and Delivery Document Exchange 214 Figure 24 Baseline Authentication IOTP Transaction 217 Figure 25 Baseline Deposit IOTP Transaction 219 Figure 26 Baseline Purchase IOTP Transaction 221 Figure 27 Baseline Refund IOTP Transaction 223 Figure 28 Baseline Withdrawal IOTP Transaction 225 Figure 29 Baseline Value Exchange IOTP Transaction 228 Figure 30 Baseline Value Exchange Signatures 230 Figure 31 Valid Combinations of Document Exchanges 231 Figure 32 Baseline Transaction Status Inquiry 238 Figure 33 Baseline Ping Messages 242
図1 IOTP Trading Roles16図2 Offer Exchange19図3 Payment Exchange22図4 Delivery Exchange25図5 IOTP Message Structure33図7 An IOTP Transaction34図8 Exampleが使用するID属性46図9 Element References48図10 Exampleが使用するBaseline Purchase81図12 Checking a Payment HandlerのためのSignaturesのSignature Digests79図11のAuthentication Exchange27図6はPayment87図13からChecking a Delivery Handler缶のキャリーの出ているa Deliveryを載せることができます; 217図25 基線預金IOTPトランザクション219図26 基線購買IOTPトランザクション221図27 基線還付IOTPトランザクション223図28 基線退出IOTPトランザクション225図29 基礎値交換IOTPトランザクション228図30 基礎値交換署名230図31 ドキュメント交換231の有効な組み合わせは32基線トランザクション資産調査238図33 基線ピングメッセージ242について計算します。
Burdett Informational [Page 6] RFC 2801 IOTP/1.0 April 2000
バーデット[6ページ]情報のRFC2801IOTP/2000年4月1日
1. Background
1. バックグラウンド
The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the Payment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party.
インターネットオープンTradingプロトコル(IOTP)は共同利用できるフレームワークをインターネット商業に提供します。 それは、決済システム独立者であり、SET、モンデックス、CyberCash、DigiCash、GeldKarteなどの決済システムをカプセル化します。 IOTPは買い物サイト、Payment Handler、商品の、または、サービスのDelivery Handler、および顧客サポートのプロバイダーが異なったパーティーによって実行されるか、1のそのような商人の役割がパーティーへ行くケースを扱うことができます。
The developers of IOTP seek to provide a virtual capability that safely replicates the real world, the paper based, traditional, understood, accepted methods of trading, buying, selling, value exchanging that has existed for many hundreds of years. The negotiation of who will be the parties to the trade, how it will be conducted, the presentment of an offer, the method of payment, the provision of a payment receipt, the delivery of goods and the receipt of goods. These are events that are taken for granted in the course of real world trade. IOTP has been produced to provide the same for the virtual world, and to prepare and provide for the introduction of new models of trading made possible by the expanding presence of the virtual world.
IOTPの開発者は何百年間も存在している値が交換されて、売れていて、買って、取り引きするベースの、そして、伝統的で、理解されていて、受け入れられたメソッドを安全に本当の世界を模写する仮想の能力、紙に供給しようとします。 商品のだれがそれが取り引き、どう行われるかと関係するだろうか、そして、申し出の予感、支払方法、支払い領収書の設備、品物の配達、および受領の交渉。 これらは本当の世界貿易の間に当然のことと思われるイベントです。 IOTPは、仮想世界の拡張存在によって可能にされた取り引きの新しいモデルの導入に同じように仮想世界に備えて、準備して、備えるために生産されました。
The other fundamental ideal of the IOTP effort is to produce a definition of these trading events in such a way that no matter where produced, two unfamiliar parties using electronic commerce capabilities to buy and sell that conform to the IOTP specifications will be able to complete the business safely and successfully.
IOTP取り組みのもう片方の基本的な理想は生産されているところでは、売買するIOTP仕様に従う電子商取引能力を使用している2回のなじみのないパーティーがそうするどんな問題も安全に首尾よくビジネスを終了できないような方法とのこれらの取り引きイベントの定義を起こすことです。
In summary, IOTP supports:
概要では、IOTPは以下をサポートします。
o Familiar trading models
o 身近な取り引きモデル
o New trading models
o 新しい取り引きモデル
o Global interoperability
o グローバルな相互運用性
The remainder of this section provides background to why IOTP was developed. The specification itself starts in the next chapter.
このセクションの残りはIOTPが開発された理由にバックグラウンドを提供します。 仕様自体は次の章で始まります。
1.1 Commerce on the Internet, a Different Model
1.1 インターネット、異なったモデルにおける商業
The growth of the Internet and the advent of electronic commerce are bringing about enormous changes around the world in society, politics and government, and in business. The ways in which trading partners communicate, conduct commerce, are governed have been enriched and changed forever.
インターネットの成長と電子商取引の到来は社会と、政治と政府、およびビジネスにおける世界中の巨大な変化を引き起こしています。 豊かにして、いつまでも変えて、貿易相手国が交信する方法(行為商業)は支配されます。
Burdett Informational [Page 7] RFC 2801 IOTP/1.0 April 2000
バーデット[7ページ]情報のRFC2801IOTP/2000年4月1日
One of the very fundamental changes about which IOTP is concerned is taking place in the way consumers and merchants trade. Characteristics of trading that have changed markedly include:
どのIOTPが関係があるかに関して非常に基本的な変化の1つは消費者と商人が取り引きする方法で行われています。 著しく変化した取り引きの特性は:
o Presence: Face-to-face transactions become the exception, not the
rule. Already with the rise of mail order and telephone order
placement this change has been felt in western commerce.
Electronic commerce over the Internet will further expand the
scope and volume of transactions conducted without ever seeing the
people who are a part of the enterprise with whom one does
business.
o 存在: 面と向かっているトランザクションは規則ではなく、例外になります。 既に通信販売と電話による注文プレースメントの上昇で、この変化は西商業で感じられました。 インターネットの上の電子通商はさらに1つとビジネスをする企業の一部である人々を見ないで行われたトランザクションの範囲とボリュームを広くするでしょう。
o Authentication: An important part of personal presence is the
ability of the parties to use familiar objects and dialogue to
confirm they are who they claim to be. The seller displays one or
several well known financial logos that declaim his ability to
accept widely used credit and debit instruments in the payment
part of a purchase. The buyer brings government or financial
institution identification that assures the seller she will be
paid. People use intangibles such as personal appearance and
conduct, location of the store, apparent quality and familiarity
with brands of merchandise, and a good clear look in the eye to
reinforce formal means of authentication.
o 認証: 個人的な存在の重要な部分はパーティーが彼らがそれらが主張する人であると確認するのになじみ深いオブジェクトと対話を使用する能力です。 広く受け入れる彼の能力に熱弁をふるわせる売り手ディスプレイ1か数個のよく知られている財政的なロゴが、購入の支払い部分にクレジットを使用して、器具を借り方に記入します。 買い手は彼女が支払われることを売り手に知らせる政府か金融機関識別をもたらします。 人々は、認証の正式な手段を補強するのに風采や行為などの無形財産、店の位置、商品のブランドへの見かけの品質と親しみ、および目での良い明確な一見を使用します。
o Payment Instruments: Despite the enormous size of bank card
financial payments associations and their members, most of the
world's trade still takes place using the coin of the realm or
barter. The present infrastructure of the payments business cannot
economically support low value transactions and could not survive
under the consequent volumes of transactions if it did accept low
value transactions.
o 支払い器具: 銀行カードの莫大なサイズにもかかわらず、財政的な支払い協会と彼らのメンバー、世界の貿易の大部分は、分野か物物交換のコインを使用することでまだ行われています。 それが低い値のトランザクションを受け入れるなら、支払いビジネスの現在のインフラストラクチャは、低値がトランザクションであると経済的にサポートすることができないで、トランザクションの結果のボリュームの下で存続できないでしょうに。
o Transaction Values: New meaning for low value transactions arises
in the Internet where sellers may wish to offer for example, pages
of information for fractions of currency that do not exist in the
real world.
o 取引額: 低い値のトランザクションのための新しい意味は売り手が断片のために本当の世界に存在しない通貨について例えばページの情報を提供したがっているかもしれないインターネットに起こります。
o Delivery: New modes of delivery must be accommodated such as
direct electronic delivery. The means by which receipt is
confirmed and the execution of payment change dramatically where
the goods or services have extremely low delivery cost but may in
fact have very high value. Or, maybe the value is not high, but
once delivery occurs the value is irretrievably delivered so
payment must be final and non-refundable but delivery nonetheless
must still be confirmed before payment. Incremental delivery such
as listening or viewing time or playing time are other models that
operate somewhat differently in the virtual world.
o 配送: ダイレクト電子配送などのように配送の新型に対応しなければなりません。 領収書が確認される手段と支払いの実行は、商品かサービスがどこに非常に低い運送費を持っていますが、事実上、非常に高い値を持っているかもしれないかを劇的に変えます。 または、多分、値は高くはありませんが、配送がいったん起こると、支払いが最終的であって、払戻し不能であるに違いありませんが、支払いの前にそれにもかかわらず、まだ配送を確認しなければならなくて、提供されて、値は取り返しがつかないほど高いです。 時間かプレー時間を聴くか、または見などなどの増加の配送は仮想世界でいくらか異なって働いている他のモデルです。
Burdett Informational [Page 8] RFC 2801 IOTP/1.0 April 2000
バーデット[8ページ]情報のRFC2801IOTP/2000年4月1日
1.2 Benefits of IOTP
1.2 IOTPの利益
ELECTRONIC COMMERCE SOFTWARE VENDORS
電子商取引ソフトウェアベンダー
Electronic Commerce Software Vendors will be able to develop e- commerce products which are more attractive as they will inter- operate with any other vendors' software. However, since IOTP focuses on how these solutions communicate, there is still plenty of opportunity for product differentiation.
電子通商Software Vendorsはいかなる他のベンダーのソフトウェアでも相互作動するので、より魅力的な電子商業製品を開発できるでしょう。 しかしながら、IOTPがこれらのソリューションがどう交信するかに焦点を合わせるので、製品差別化の多くの機会がまだあります。
PAYMENT BRANDS
支払いブランド
IOTP provides a standard framework for encapsulating payment protocols. This means that it is easier for payment products to be incorporated into IOTP solutions. As a result the payment brands will be more widely distributed and available on a wider variety of platforms.
IOTPは支払いプロトコルをカプセル化するのに標準のフレームワークを提供します。 これは、支払い製品がIOTPソリューションに組み入れられるのが、より簡単であることを意味します。 その結果、支払いブランドは、より広いバラエティーのプラットホームで広く分配されていて、より利用可能になるでしょう。
MERCHANTS
商人
There are several benefits for Merchants:
Merchantsのためのいくつかの利益があります:
o they will be able to offer a wider variety of payment brands,
o 彼らは、より広いバラエティーの支払いブランドを提供できるでしょう。
o they can be more certain that the customer will have the software
needed to complete the purchase
o それらは顧客には購買を終了するのに必要であるソフトウェアがあるのをより確信している場合があります。
o through receiving payment and delivery receipts from their
customers, they will be able to provide customer care knowing that
they are dealing with the individual or organisation with which
they originally traded
o 彼らの顧客から支払いと納品受領証を受け取ることで、彼らが元々取り引きした個人か機構と取り引きしているのを知りながら、彼らは顧客ケアを提供できるでしょう。
o new merchants will be able to enter this new (Internet) market-
place with new products and services, using the new trading
opportunities which IOTP presents
o 新しい商人は新製品とサービスでこの新しい(インターネット)市場の地域に入ることができるでしょう、IOTPが提示する新しい取り引き機会を利用して
BANKS AND FINANCIAL INSTITUTIONS
銀行と金融機関
There are also several benefits for Banks and Financial Institutions:
また、バンクスとFinancial Institutionsのためのいくつかの利益があります:
o they will be able to provide IOTP support for merchants
o 彼らは商人のサポートをIOTPに供給できるでしょう。
o they will find new opportunities for IOTP related services:
o 彼らは、IOTPの新しい機会がサービスを関係づけたのがわかるでしょう:
- providing customer care for merchants
- fees from processing new payments and deposits
- 商人のための顧客ケアを提供します--新しい支払いと預金を処理するのからの料金
Burdett Informational [Page 9] RFC 2801 IOTP/1.0 April 2000
バーデット[9ページ]情報のRFC2801IOTP/2000年4月1日
o they have an opportunity to build relationships with new types of
merchants
o 彼らには、新しいタイプの商人との関係を築き上げる機会があります。
CUSTOMERS
顧客
For Customers there are several benefits:
Customersのために、いくつかの利益があります:
o they will have a larger selection of merchants with whom they can
trade
o 彼らには、彼らが取り引きできる商人の、より広い品揃えがあるでしょう。
o there is a more consistent interface when making the purchase
o 購買をするとき、より一貫したインタフェースがあります。
o there are ways in which they can get their problems fixed through
the merchant (rather than the bank!)
o それらが商人を通して自己の問題を修正させることができる方法があります。(銀行よりむしろ!)
o there is a record of their transaction which can be used, for
example, to feed into accounting systems or, potentially, to
present to the tax authorities
o 税当局には例えば会計システムの中、または、潜在的にプレゼントへ供給するのに使用できるそれらのトランザクションに関する記録があります。
1.3 Baseline IOTP
1.3 基線IOTP
This specification is Baseline IOTP. It is a Baseline in that it contains ways of doing trades on the Internet which are the most common, for example purchases and refunds.
この仕様はBaseline IOTPです。 インターネットにおける最も一般的である取り引きをする方法、例えば、購買、および還付を含んでいるので、それはBaselineです。
The group that has worked on the IOTP see an extended version being developed over time but feel a need to focus on a limited function but completely usable specification in order that implementers can develop solutions that work now.
implementersが現在働いている解決策を見いだすことができるように、IOTPに働いていたグループは、拡張版が時間がたつにつれて開発されているのを見ますが、限られた機能にもかかわらず、完全に使用可能な仕様に焦点を合わせる必要性を感じます。
During this period it is anticipated that there will be no changes to the scope of this specification with the only changes made being limited to corrections where problems are found. Software solutions have been developed based on earlier versions of this specification (for example version 0.9 published in early 1998 and earlier revisions of version 1.0 published during 1999) which prove that the IOTP works.
この期間、この仕様の範囲への変化が全く問題が見つけられるところに修正に制限されながら行われた唯一の変更をもってないと予期されます。 IOTPが働いていると立証するこの仕様(例えば、バージョン0.9は1998年前半に発行しました、そして、バージョン1.0の以前の改正は1999の間、発行された)の以前のバージョンに基づいてソフトウェアソリューションを開発してあります。
1.4 Objectives of Document
1.4 ドキュメントの目的
The objectives of this document are to provide a specification of version 1.0 of the Internet Open Trading Protocols which can be used to design and implement systems which support electronic trading on the Internet using the Internet Open Trading Protocols.
このドキュメントの目的はインターネットでインターネットオープンTradingプロトコルを使用することで電子商取引をサポートするシステムを設計して、導入するのに使用できるインターネットオープンTradingプロトコルのバージョン1.0の仕様を提供することです。
Burdett Informational [Page 10] RFC 2801 IOTP/1.0 April 2000
バーデット[10ページ]情報のRFC2801IOTP/2000年4月1日
The purpose of the document is:
ドキュメントの目的は以下の通りです。
o to allow potential developers of products based on the protocol to
develop software/hardware solutions which use the protocol
o プロトコルに基づく製品の潜在的開発者がプロトコルを使用するソフトウェア/ハードウェア解決策を見いだすのを許容するために
o to allow the financial services industry to understand a
developing electronic commerce trading protocol that encapsulates
(without modification) any of the current or developing payment
schemes now being used or considered by their merchant customer
base
o 金融サービス業界が、現在現在の、または、展開している支払い体系のいずれもカプセル化する(変更なしで)展開している電子商取引取り引きプロトコルがそれらの商人顧客ベースによって使用されるか、または考えられるのを理解しているのを許容するために
1.5 Scope of Document
1.5 ドキュメントの範囲
The protocol describes the content, format and sequences of messages that pass among the participants in an electronic trade - consumers, merchants and banks or other financial institutions, and customer care providers. These are required to support the electronic commerce transactions outlined in the objectives above.
プロトコルは電子取り引きの関係者の中で終わるメッセージの内容、形式、および系列について説明します--消費者か商人と銀行か他の金融機関と、顧客介添え人。 これらが、電子商取引が上の目的に概説されたトランザクションであるとサポートするのに必要です。
The protocol is designed to be applicable to any electronic payment scheme since it targets the complete purchase process where the movement of electronic value from the payer to the payee is only one, but important, step of many that may be involved to complete the trade.
プロトコルは、電子価値の支払い者から受取人までの動きが1であるだけであるところで完全な購買プロセスを狙うのでどんな電子決済体系にも適切になるように設計されていて、重要です、取り引きを終了するために伴われるかもしれない多くのステップ。
Payment Scheme which IOTP could support include MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton, etc.
IOTPがサポートすることができた支払いSchemeはマスターカードCredit、Visa Credit、モンデックスCash、Visa Cash、GeldKarte、eCash、サイバーコイン、ミリセント、Protonなどを含んでいます。
Each payment scheme contains some message flows which are specific to that scheme. These scheme-specific parts of the protocol are contained in a set of payment scheme supplements to this specification.
それぞれの支払い体系はいくつかのその体系に特定のメッセージ流れを含んでいます。 プロトコルのこれらの体系特有の部分は支払い体系補足のセットにこの仕様に含まれています。
The document does not prescribe the software and processes that will need to be implemented by each participant. It does describe the framework necessary for trading to take place.
ドキュメントは各関係者によって実装される必要があるソフトウェアとプロセスを定めません。 それは行われるために取り引きするのに必要なフレームワークについて説明します。
This document also does not address any legal or regulatory issues surrounding the implementation of the protocol or the information systems which use them.
このドキュメントも、プロトコルの実装を囲むどんな法的であるか規定の問題か情報もそれらを使用するシステムであると、扱いません。
1.6 Document Structure
1.6 ドキュメント構造
The document consists of the following sections:
ドキュメントは以下のセクションから成ります:
o Section 1 - Background: This section gives a brief background on
electronic commerce and the benefits IOTP offers.
o 1--バックグラウンドを区分してください: このセクションは電子商取引と利益IOTP申し出のときに簡潔なバックグラウンドを与えます。
Burdett Informational [Page 11] RFC 2801 IOTP/1.0 April 2000
バーデット[11ページ]情報のRFC2801IOTP/2000年4月1日
o Section 2 - Introduction: This section describes the various
Trading Exchanges and shows how these trading exchanges are used
to construct the IOTP Transactions. This section also explains
various Trading Roles that would participate in electronic trade.
o 2--序論を区分してください: このセクションは、様々なTrading Exchangesについて説明して、これらの取り引き交換がIOTP Transactionsを組み立てるのにどう使用されるかを示しています。 また、このセクションは電子貿易に参加する様々なTrading Rolesについて説明します。
o Section 3 - Protocol Structure: This section summarises how
various IOTP transactions are constructed using the Trading Blocks
and Trading Components that are the fundamental building blocks
for IOTP transactions. All IOTP transaction messages are well
formed XML documents.
o セクション3--構造について議定書の中で述べてください: このセクションは様々なIOTPトランザクションがIOTPトランザクションに基本的なブロックであるTrading BlocksとTrading Componentsを使用することでどう構成されるかについて略言します。 すべてのIOTPトランザクションメッセージが整形式のXMLドキュメントです。
o Section 4 - IOTP Error Handling: This section describes how to
process exceptions and errors during the protocol message exchange
and trading exchange processing. This section provides a generic
overview of the exception handling. This section should be read
carefully.
o セクション4--IOTPエラー処理: このセクションはプロトコル交換処理と取り引き交換処理の間、例外と誤りを処理する方法を説明します。 このセクションは例外処理のジェネリック概要を提供します。 このセクションは注意して読まれるべきです。
o Section 5 - Security Considerations: This section considers from
an IETF perspective, how IOTP addresses security. It includes: how
to determine whether to use digital signatures with IOTP, how IOTP
address data privacy, and how security built into payment
protocols relate to IOTP security.
o セクション5--セキュリティ問題: IOTPがIETF見解、どうセキュリティを扱うかからこのセクションは考えます。 それは: IOTPとのデジタル署名を使用するかどうかと、IOTPが、データがプライバシーであるとどのように扱うか、そして、支払いプロトコルが組み込まれたセキュリティがどのようにIOTPセキュリティに関係するかを決定する方法。
o Section 6 - Digital Signatures and IOTP: This section provides an
overview of how IOTP uses digital signatures; how to check a
signature is correctly calculated and how the various Trading
Roles that participate in trade should check signatures when
required.
o セクション6--デジタル署名とIOTP: このセクションはIOTPがどうデジタル署名を使用するかに関する概要を提供します。 署名をチェックするのはどう正しく計算されるか、そして、必要であると、貿易に参加する様々なTrading Rolesはどう署名をチェックするはずであるか。
o Section 7 - Trading Components: This section defines the XML
elements required by Trading Components.
o セクション7--コンポーネントを取り引きします: このセクションはTrading Componentsによって必要とされたXML要素を定義します。
o Section 8 - Trading Blocks: This section describes how Trading
Blocks are constructed from Trading Components.
o セクション8--通商圏: このセクションはTrading BlocksがTrading Componentsからどう組み立てられるかを説明します。
o Section 9 - Internet Open Trading Protocol Transactions: This
section describes all the IOTP Baseline transactions. It refers to
Trading Blocks and Trading Components and Signatures. This section
doesn't directly link error handling during the protocol
exchanges, the reader is advised to understand Error Handling as
defined in section before reading this section.
o セクション9--インターネットの開く取り引きはトランザクションについて議定書の中で述べます: このセクションはすべてのIOTP Baselineトランザクションについて説明します。 それはTrading Blocks、Trading Components、およびSignaturesについて言及します。 このセクションはプロトコル交換の間、直接エラー処理をリンクしないで、読者がこのセクションを読む前にセクションで定義されるようにError Handlingを理解しているようにアドバイスされます。
o Section 10 - Retrieving Logos: This section describes how IOTP
specific logos can be retrieved.
o セクション10--ロゴを検索します: このセクションはどうIOTPの特定のロゴを検索できるかを説明します。
Burdett Informational [Page 12] RFC 2801 IOTP/1.0 April 2000
バーデット[12ページ]情報のRFC2801IOTP/2000年4月1日
o Section 11 - Brands: This section provides: an overview of Brand
Definitions and Brand Selection which describe how a Consumer can
select a Brand from a list provided by the Merchant; as well as
some examples of Brand Lists.
o セクション11--ブランド: このセクションは提供されます: Consumerがマーチャントによって提供されたリストからBrandをどう選択できるかを説明するBrand DefinitionsとBrand Selectionの概要。 Brand Listsに関するいくつかの例と同様に。
o Section 12 - IANA Considerations: This section describes how new
values for codes used by IOTP are co-ordinated.
o セクション12--IANA問題: このセクションはIOTPによって使用されたコードのための新しい値がどう連携しているかを説明します。
o Section 13 - Internet Open Trading Protocol Data Type Definition:
This section contains the XML Data Type Definitions for IOTP.
o セクション13--インターネットの開いている取り引きプロトコルデータ型定義: このセクションはIOTPのためのXML Data Type Definitionsを含みます。
o Section 14 - Glossary. This describes all the major terminology
used by IOTP.
o セクション14--用語集。 これはIOTPによって使用されたすべての主要な用語について説明します。
o Section 15 - A list of the other documents referenced by the IOTP
specification.
o セクション15--IOTP仕様で参照をつけられる他のドキュメントのリスト。
o Section 16 - The Author's Address
o セクション16--作者のアドレス
o Section 17 - Full Copyright Statement
o セクション17--完全な著作権宣言文
1.7 Intended Readership
1.7 意図している購読者層
Software and hardware developers; development analysts; business and technical planners; industry analysts; merchants; bank and other payment handlers; owners, custodians, and users of payment protocols.
ソフトウェアとハードウェア開発者。 開発アナリスト。 ビジネスと技術立案者。 業界アナリスト。 商人。 銀行と他の支払い操作者。 支払いプロトコルの所有者、管理人、およびユーザ。
1.7.1 Reading Guidelines
1.7.1 読書ガイドライン
This IOTP specification is structured primarily in a sequence targeted at people who want to understand the principles of IOTP. However from practical implementation experience by implementers of earlier of versions of the protocol new readers who plan to implement IOTP may prefer to read the document in a different sequence as described below.
このIOTP仕様は主としてIOTPの本質を理解したがっている人々をターゲットにした系列で構造化されます。 しかしながら、プロトコルのバージョンについて、より早いことのimplementersによる実用的な実装経験から、IOTPを実装するのを計画している新しい読者は、以下で説明されるように異なった系列でドキュメントを読むのを好むかもしれません。
Review the transport independent parts of the specification. This covers:
仕様の輸送の独立している部分を見直してください。 これは以下をカバーしています。
o Section 14 - Glossary
o セクション14--用語集
o Section 1 - Background
o セクション1--バックグラウンド
o Section 2 - Introduction
o セクション2--序論
o Section 3 - Protocol Structure
o セクション3--プロトコル構造
o Section 4 - IOTP Error Handling
o セクション4--IOTPエラー処理
Burdett Informational [Page 13] RFC 2801 IOTP/1.0 April 2000
バーデット[13ページ]情報のRFC2801IOTP/2000年4月1日
o Section 5 - Security Considerations
o セクション5--セキュリティ問題
o Section 9 - Internet Open Trading Protocol Transactions
o セクション9--インターネットの開いている取り引きプロトコルトランザクション
o Section 11 - Brands
o セクション11--ブランド
o Section 12 - IANA Considerations
o セクション12--IANA問題
o Section 10 - Retrieving Logos
o セクション10--ロゴを検索すること。
Review the detailed XML definitions:
詳細なXML定義を見直してください:
o Section 8 - Trading Blocks
o セクション8--通商圏
o Section 7 - Trading Components
o セクション7--取り引きコンポーネント
o Section 6 - Digital Signatures and IOTP
o セクション6--デジタル署名とIOTP
2. Introduction
2. 序論
The Internet Open Trading Protocols (IOTP) define a number of different types of IOTP Transactions:
インターネットオープンTradingプロトコル(IOTP)はIOTP Transactionsの多くの異なったタイプを定義します:
o Purchase. This supports a purchase involving an offer, a payment
and optionally a delivery
o 購買。 これが、購入が申し出にかかわる支払いであると任意にサポートする、配送
o Refund. This supports the refund of a payment as a result of,
typically, an earlier purchase
o 還付します。 これがaとしての支払いが結果になるaの還付を通常サポートする、以前の購入
o Value Exchange. This involves two payments which result in the
exchange of value from one combination of currency and payment
method to another
o 交換を評価してください。 これは価値の通貨と支払い方法の1つの組み合わせから別の組み合わせまでの交換をもたらす2つの支払いにかかわります。
o Authentication. This supports one organisation or individual to
check that another organisation or individual are who they appear
to be.
o 認証。 これは、別の機構か個人が彼らが見える人であることをチェックする1人の機構か個人であるとサポートします。
o Withdrawal. This supports the withdrawal of electronic cash from a
financial institution
o 退出。 これは金融機関から電子現金の退出をサポートします。
o Deposit. This supports the deposit of electronic cash at a
financial institution
o 預けます。 これは金融機関における電子現金の預金をサポートします。
o Inquiry. This supports inquiries on the status of an IOTP
transaction which is either in progress or is complete
o 問い合せ。 これは進行中であることの、または、完全なIOTPトランザクションの状態で問い合せをサポートします。
Burdett Informational [Page 14] RFC 2801 IOTP/1.0 April 2000
バーデット[14ページ]情報のRFC2801IOTP/2000年4月1日
o Ping. This supports a simple query which enables one IOTP aware
application to determine whether another IOTP application running
elsewhere is working or not.
o 確認してください。 これは1つのIOTPの意識しているアプリケーションが、ほかの場所に稼働する別のIOTPアプリケーションが働いているかどうか決定するのを可能にする簡単な質問をサポートします。
These IOTP Transactions are "Baseline" transactions since they have been identified as a minimum useful set of transactions. Later versions of IOTP may include additional types of transactions.
それらが最小の役に立つセットのトランザクションとして特定されたので、これらのIOTP Transactionsは「基線」トランザクションです。 IOTPの後のバージョンは追加タイプのトランザクションを含むかもしれません。
Each of the IOTP Transactions above involve:
それぞれの上のIOTP Transactionsは以下にかかわります。
o a number of organisations playing a Trading Role, and
o そしてTrading Roleをプレーする多くの機構。
o a set of Trading Exchanges. Each Trading Exchange involves the
exchange of data, between Trading Roles, in the form of a set of
Trading Components.
o Trading Exchangesの1セット。 各Trading ExchangeはTrading Rolesの間のデータの交換にTrading Componentsの1セットの形にかかわります。
Trading Roles, Trading Exchanges and Trading Components are described below.
取り引きRoles、Trading Exchanges、およびTrading Componentsは以下で説明されます。
Burdett Informational [Page 15] RFC 2801 IOTP/1.0 April 2000
バーデット[15ページ]情報のRFC2801IOTP/2000年4月1日
2.1 Trading Roles
2.1 取り引き役割
The Trading Roles identify the different parts which organisations can take in a trade. The five Trading Roles used within IOTP are illustrated in the diagram below.
Trading Rolesは機構が取り引きで取ることができる異なった部品を特定します。 IOTPの中で使用された5Trading Rolesが以下のダイヤグラムで例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Merchant Customer Care Provider resolves ----------
---------------------------------------------->| Merchant |
| Consumer disputes and problems |Cust.Care.|
| | Provider |
| ----------
|
Payment Handler accepts or makes ----------
| ------------------------------------------>| Payment |
| | Payment for Merchant | Handler |
| | ----------
v v
---------- Consumer makes purchases or obtains ----------
| Consumer |<--------------------------------------->| Merchant |
---------- refund from Merchant ----------
^
| Delivery Handler supplies goods or ----------
|---------------------------------------------->|Deliverer |
services for Merchant | Handler |
----------
商人Customer Care Provider決心---------- ---------------------------------------------->| 商人| | 消費者論争と問題|Cust.Care、|| | プロバイダー| | ---------- | Handlerが受け入れるか、または済ませる支払い---------- | ------------------------------------------>| 支払い| | | 商人のための支払い| 操作者| | | ---------- vに対して---------- 造が購入するか、または得る消費者---------- | 消費者|<--------------------------------------->| 商人| ---------- マーチャントからの還付---------- ^ | または配送Handlerが商品を供給する。---------- |---------------------------------------------->|配達人| マーチャントのためのサービス| 操作者| ----------
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 1 IOTP Trading Roles
図1 IOTPの取り引き役割
Burdett Informational [Page 16] RFC 2801 IOTP/1.0 April 2000
バーデット[16ページ]情報のRFC2801IOTP/2000年4月1日
The roles are:
役割は以下の通りです。
o Consumer. The person or organisation which is to receive and pay
for the goods or services
o 消費者。 商品かサービスを受け取って、代金を支払うことになっている人か機構
o Merchant. The person or organisation from whom the purchase is
being made and who is legally responsible for providing the goods
or services and receives the benefit of the payment made
o 商人。 だれがだれが購買をしているか、そして、商品かサービスを提供するのに法的に責任感が強く、支払いの恩恵を受けるかから作られた人か機構
o Payment Handler. The entity that physically receives the payment
from the Consumer on behalf of the Merchant
o 支払い操作者。 マーチャントを代表してConsumerから支払いを物理的に受け取る実体
o Delivery Handler. The entity that physically delivers the goods or
services to the Consumer on behalf of the Merchant.
o 配送操作者。 物理的にマーチャントを代表してConsumerに対する商品かサービスを提供する実体。
o Merchant Customer Care Provider. The entity that is involved with
customer dispute negotiation and resolution on behalf of the
Merchant
o 商人顧客介添え人。 マーチャントを代表して顧客論争交渉と解決にかかわる実体
Roles may be carried out by the same organisation or different organisations. For example:
役割が同じ機構か異なった機構によって行われるかもしれません。 例えば:
o in the simplest case one physical organisation (e.g., a merchant)
could handle the purchase, accept the payment, deliver the goods
and provide merchant customer care
o 最も簡単な場合では、1つの物理的な機構(例えば、商人)が、購買を扱って、支払いを受け入れて、商品を提供して、顧客ケアを商人に提供できました。
o at the other extreme, a merchant could handle the purchase but
instruct the consumer to pay a bank or financial institution,
request that delivery be made by an overnight courier firm and to
contact an organisation which provides 24x7 service if problems
arise.
o それとは正反対に、商人は購買を扱うことができましたが、銀行か金融機関に支払うよう消費者に命令してください、そして、配送が翌日配達会社によってされるよう要求してください、そして、問題であるなら年中無休、24時間間のサービスを提供する機構に連絡するために、起こってください。
Note that in this specification, unless stated to the contrary, when the words Consumer, Merchant, Payment Handler, Delivery Handler or Customer Care Provider are used, they refer to the Trading Role rather than an actual organisation.
単語のConsumer、マーチャント、Payment Handler、Delivery HandlerまたはCustomer Care Providerが使用されているとき、それと反対に述べられない場合、この仕様では、彼らが実際の機構よりむしろTrading Roleについて言及することに注意してください。
An individual organisation may take multiple roles. For example a company which is selling goods and services on the Internet could take the role of Merchant when selling goods or services and the role of Consumer when the company is buying goods or services itself.
個々の機構は複数の役割を果たすかもしれません。 会社が商品を買っているか、またはそれ自体を修理するとき、Consumerの商品かサービスと役割を販売するとき、例えば、インターネットで商品とサービスを販売している会社はマーチャントの役割を果たすことができました。
As roles occur in different places there is a need for the organisations involved in the trade to exchange data, i.e. to carry out Trading Exchanges, so that the trade can be completed.
役割が異なった場所に起こるとき、データを交換して、すなわち、Trading Exchangesを行うために取り引きにかかわる機構の必要があります、取り引きが終了できるように。
Burdett Informational [Page 17] RFC 2801 IOTP/1.0 April 2000
バーデット[17ページ]情報のRFC2801IOTP/2000年4月1日
2.2 Trading Exchanges
2.2 取り引き交換
The Internet Open Trading Protocols identify four Trading Exchanges which involve the exchange of data between the Trading Roles. The Trading Exchanges are:
インターネットオープンTradingプロトコルはTrading Rolesの間のデータの交換にかかわる4Trading Exchangesを特定します。 Trading Exchangesは以下の通りです。
o Offer. The Offer Exchange results in the Merchant providing the
Consumer with the reason why the trade is taking place. It is
called an Offer since the Consumer must accept the Offer if a
trade is to continue
o 提供します。 Offer Exchangeは取り引きが行われている理由をConsumerに提供するマーチャントをもたらします。 取り引きが続くつもりであるならConsumerがOfferを受け入れなければならないので、それはOfferと呼ばれます。
o Payment. The Payment Exchange results in a payment of some kind
between the Consumer and the Payment Handler. This may occur in
either direction
o 支払い。 Payment ExchangeはConsumerとPayment Handlerの間のある種の支払いをもたらします。 これはどちらの方向にも起こるかもしれません。
o Delivery. The Delivery Exchange transmits either the on-line
goods, or delivery information about physical goods from the
Delivery Handler to the Consumer, and
o 配送。 そしてDelivery ExchangeがDelivery HandlerからConsumerまでオンライン商品か物理的な商品の配送情報のどちらかを伝える。
o Authentication. The Authentication Exchange can be used by any
Trading Role to authenticate another Trading Role to check that
they are who they appear to be.
o 認証。 彼らが見える人であることをチェックするために別のTrading Roleを認証するどんなTrading Roleも使用にAuthentication Exchangeを使用できます。
IOTP Transactions are composed of various combinations of these Trading Exchanges. For example, an IOTP Purchase transaction includes Offer, Payment, and Delivery Trading Exchanges. As another example, an IOTP Value Exchange transaction is composed of an Offer Trading Exchange and two Payment Trading Exchanges.
IOTP TransactionsはこれらのTrading Exchangesの様々な組み合わせで構成されます。 例えば、IOTP PurchaseトランザクションはOffer、Payment、およびDelivery Trading Exchangesを含んでいます。 別の例として、IOTP Value ExchangeトランザクションはOffer Trading Exchangeと2Payment Trading Exchangesで構成されます。
Trading Exchanges consist of Trading Components that are transmitted between the various Trading Roles. Where possible, the number of round-trip delays in an IOTP Transaction is minimised by packing the Components from several Trading Exchanges into combination IOTP Messages. For example, the IOTP Purchase transaction combines a Delivery Organisation Component with an Offer Response Component in order to avoid an extra Consumer request and response.
取り引きExchangesは様々なTrading Rolesの間に伝えられるTrading Componentsから成ります。 可能であるところでは、IOTP Transactionの往復の遅れの数が、数個のTrading ExchangesからのComponentsに組み合わせIOTP Messagesに詰め込むことによって、最小となります。 例えば、IOTP Purchaseトランザクションは、付加的なConsumer要求と応答を避けるためにDelivery Organisation ComponentをOffer Response Componentに結合します。
Each of the IOTP Trading Exchanges is described in more detail below. For clarity of description, these describe the Trading Exchanges as though they were standalone operations. For performance reasons, the Trading Exchanges are intermingled in the actual IOTP Transaction definitions.
それぞれのIOTP Trading Exchangesはさらに詳細に以下で説明されます。 記述の明快ために、これらはまるで自分達がスタンドアロン操作であるかのようにTrading Exchangesについて説明します。 性能理由で、Trading Exchangesは実際のIOTP Transaction定義で混ぜ合わされます。
Burdett Informational [Page 18] RFC 2801 IOTP/1.0 April 2000
バーデット[18ページ]情報のRFC2801IOTP/2000年4月1日
2.2.1 Offer Exchange
2.2.1 交換を提供してください。
The goal of the Offer Exchange is for the Merchant to provide the Consumer with information about the trade so that the Consumer can decide whether to continue with the trade. This is illustrated in the figure below.
Offer Exchangeの目標はConsumerが、取り引きを続行するかどうか決めることができるようにマーチャントが取り引きの情報をConsumerに提供することです。 これは以下の図で例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Merchant
STEP | |
1. Consumer decides to trade and sends information about the
transaction (requests an offer) to the Merchant e.g.,
using HTML.
*消費者| 商人ステップ| | 1. 消費者は、取り引きすると決めて、マーチャントへのトランザクション(申し出を要求する)の情報に例えば使用HTMLを送ります。
C --> M Data: Information on what is being purchased (Offer Request)
- outside scope of IOTP
C-->Mデータ: IOTPの範囲の外の購入されている(Requestを提供します)ものに関する情報
2. Merchant checks the information provided by the Consumer,
creates an Offer optionally signs it and sends it to the
Consumer.
2. 商人は、Consumerによって提供された情報をチェックして、任意にOfferを作成します。Consumerにそれに署名して、それを送ります。
C <-- M OFFER RESPONSE. Components: Status; Organisation(s)
(Consumer, DelivTo, Merchant, Payment Handler, Customer
Care); Order; Payment; Delivery; TradingRoleData (optional)
Offer Response Signature (optional) that signs other
components
C<--Mは応答を提供します。 コンポーネント: 状態。 機構(消費者、DelivTo、商人、支払い操作者、顧客ケア)。 注文してください。 支払い。 配送。 TradingRoleData(任意の)は他のコンポーネントに署名するResponse Signature(任意の)を提供します。
3. Consumer checks the information from the Merchant and
decides whether to continue.
3. 消費者は、マーチャントからの情報をチェックして、続くかどうか決めます。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 2 Offer Exchange
図2 交換を提供してください。
An Offer Exchange uses the following Trading Components that are passed between the Consumer and the Merchant:
Offer ExchangeはConsumerとマーチャントの間で渡される以下のTrading Componentsを使用します:
o the Status component is used to indicate to other parties that a
valid Offer Response has been generated
o Statusの部品は、有効なOffer Responseが生成されたのを相手に示すのに使用されます。
o the Organisation Component contains information which describes
the Organisations which are taking a role in the trade:
o Organisation Componentは取り引きにおける役割を果たしているOrganisationsについて説明する情報を含んでいます:
- the consumer provides information, about who the consumer is
and, if goods or services are being delivered, where the goods
or services are to be delivered to
- 消費者が消費者がだれであるかの情報と商品かサービスが提供されるときのどこに商品を提供することになっているか、そして、またはサービスに届けられることになっています。
Burdett Informational [Page 19] RFC 2801 IOTP/1.0 April 2000
バーデット[19ページ]情報のRFC2801IOTP/2000年4月1日
- the merchant augments this information by providing information
about the merchant, the Payment Handler, the customer care
provider and, if goods or services are being delivered, the
Delivery Handler
- 商人は、顧客介添え人と商品かサービスが提供されるときのDelivery Handlerを商人(Payment Handler)の情報に提供することによって、この情報を増大させます。
o the Order Component contains descriptions of the goods or services
which will result from the trade if the consumer agrees to the
offer. This information is sent by the Merchant to the consumer
who should verify it
o Order Componentは消費者が申し出に同意するなら取り引きから生じる商品の、または、サービスの記述を含んでいます。 だれがそれについて確かめるべきであるかというこの情報はマーチャントによって消費者に送られます。
o the Payment Component generated by the Merchant, contains details
of how much to pay, the currency and the payment direction, for
example the consumer could be asking for a refund. Note that there
may be more than one payment in a trade
o Payment Componentはマーチャントを生成して、どのくらい支払うかに関する詳細を含んでいます、と通貨と支払い方向、例えば、消費者は還付のために尋ねることができました。 取り引きには1つ以上の支払いがあるかもしれないことに注意してください。
o the Delivery Component, also generated by the Merchant, is used if
goods or services are being delivered. This contains information
about how delivery will occur, for example by post or using e-mail
o 商品かサービスが提供されるなら、また、マーチャントが生成されたDelivery Componentは使用されています。 配送がどう起こるか、例えば、ポストかメールを使用することによって、これは情報を含んでいます。
o the Trading Role Data component contains data the Merchant wants
to forward to another Trading Role such as a Payment Handler or
Delivery Handler
o Trading Role Dataの部品はマーチャントがPayment HandlerかDelivery Handlerなどの別のTrading Roleに転送したがっているデータを含んでいます。
o the "Offer Response" Signature Component, if present, digitally
signs all of the above components to ensure their integrity.
o 存在しているなら、「申し出応答」Signature Componentは、彼らの保全を確実にするために上のコンポーネントのすべてにデジタルに署名します。
The exact content of the information provided by the Merchant to the Consumer will vary depending on the type of IOTP Transaction. For example:
IOTP Transactionのタイプに頼っていて、マーチャントによってConsumerに提供された情報の正確な内容は異なるでしょう。 例えば:
o low value purchases may not need a signature
o 低い値の購買は署名を必要としないかもしれません。
o the amount to be paid may vary depending on the payment brand and
payment protocol used
o 使用される支払いブランドと支払いプロトコルによって、支払われる額は異なるかもしれません。
o some offers may not involve the delivery of any goods
o いくつかの申し出はどんな商品の配送にもかかわらないかもしれません。
o a value exchange will involve two payments
o 値の交換は2つの支払いにかかわるでしょう。
o a merchant may not offer customer care.
o 商人は顧客ケアを提供しないかもしれません。
Information provided by the consumer to the merchant is provided using a variety of methods, for example, it could be provided:
さまざまなメソッドを使用することで消費者によって商人に提供された情報を提供しました、例えば、それを提供できました:
o using [HTML] pages as part of the "shopping experience" of the
consumer.
o 消費者の「買い物」の一部として[HTML]ページを使用します。
Burdett Informational [Page 20] RFC 2801 IOTP/1.0 April 2000
バーデット[20ページ]情報のRFC2801IOTP/2000年4月1日
o Using the Open Profiling Standard [OPS] which has recently been
proposed,
o 最近提案されたオープンProfiling Standard[OPS]を使用します。
o in the form of Organisation Components associated with an
authentication of a Consumer by a Merchant
o マーチャントによるConsumerの認証に関連しているOrganisation Componentsの形で
o as Order Components in a later version of IOTP.
o IOTPの後のバージョンのOrder Componentsとして。
2.2.2 Payment Exchange
2.2.2 支払い交換
The goal of the Payment Exchange is for a payment to be made from the Consumer to a Payment Handler or vice versa using a payment brand and payment protocol selected by the Consumer. A secondary goal is to optionally provide the Consumer with a digitally signed Payment Receipt which can be used to link the payment to the reason for the payment as described in the Offer Exchange.
ConsumerからPayment Handlerまで作られているか、または逆もまた同様にConsumerによって選択された支払いブランドと支払いプロトコルを使用しているために、Payment Exchangeの目標は支払いであります。 セカンダリ目標は任意にOffer Exchangeで説明されるように支払いの理由に支払いをリンクするのに使用できるデジタルに署名しているPayment ReceiptをConsumerに提供することです。
Payment Exchanges can work in a variety of ways. The most general case where the trade is dependent on the payment brand and protocol used is illustrated in the diagram below. Simpler payment exchanges are possible.
支払いExchangesはさまざまな方法で働くことができます。 取り引きが使用される支払いブランドとプロトコルに依存している最も一般的なケースは以下のダイヤグラムで例証されます。 より簡単な支払い交換は可能です。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer Pay Handler
| Merchant |
STEP | | |
1. Consumer decides to trade and sends information
about the transaction (requests an offer) to the
Merchant e.g., using HTML.
*消費者..賃金..操作者| 商人| ステップ| | | 1. 消費者は、取り引きすると決めて、マーチャントへのトランザクション(申し出を要求する)の情報に例えば使用HTMLを送ります。
C --> M Information on what is being paid for (outside
scope of IOTP
C、--、>M情報が何に関して代価を払われている(IOTPの外の範囲
2. Merchant decides which payment brand, payment
protocols and currencies/amounts to offer,
places then in a Brand List Component and sends
them to the Consumer
2. 商人は、どの支払いブランド(提供する支払いプロトコルと通貨/量)がその時、Brand List Componentで入賞して、それらをConsumerに送るかと決めます。
C <-- M Components: Brand List
C<--Mコンポーネント: ブランドリスト
3. Consumer selects the payment brand, protocol and
currency/amount to use, creates a Brand Selection
component and sends it to the Merchant
3. 消費者は、マーチャントに支払いブランド、プロトコル、および使用する通貨/量を選択して、Brand Selectionの部品を作成して、それを送ります。
C --> M Component: Brand List Selection
C-->Mの部品: ブランドリスト選択
Burdett Informational [Page 21] RFC 2801 IOTP/1.0 April 2000
バーデット[21ページ]情報のRFC2801IOTP/2000年4月1日
4. Merchant checks Brand Selection, creates a Payment
Amount information, optionally signs it to
authorise payment and sends it to the Consumer
4. 商人は、Brand Selectionをチェックして、Payment Amount情報を作成して、支払いを認可するために任意にそれに署名して、それをConsumerに送ります。
C <-- M Component: Payment; Organisation(s) (Merchant and
Payment Handler); Optional Offer Response Signature
that signs other components
C<--Mコンポーネント: 支払い。 機構(商人と支払い操作者)。 他のコンポーネントに署名する任意のOffer Response Signature
5. Consumer checks the Payment Amount information and
if OK requests that the payment starts by sending
information to the Payment Handler
5. 消費者は、Payment Amount情報とOKが、支払いが情報をPayment Handlerに送ることによって始まるよう要求するかどうかチェックします。
C --------> P PAYMENT REQUEST. Components: Status, Payment;
Organisations (Merchant and Payment Handler);
Trading Role Data (optional); Optional Offer
Response Signature that signs other components;
Pay Scheme Data
C-------->P支払請求書コンポーネント: 状態、支払い。 機構(商人と支払い操作者)。 取り引き役割のデータ(任意の)。 他のコンポーネントに署名する任意のOffer Response Signature。 体系データを支払ってください。
6. Payment Handler checks information including
optional signature and if OK starts exchanging Pay
Scheme Data components for selected payment brand
and payment protocol
6. 支払いHandlerは任意の署名とOKが選択された支払いブランドと支払いプロトコルとPay Scheme Dataの部品を交換し始めるかどうかを含む情報をチェックします。
C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme Data
C<。------->P支払い交換。 コンポーネント: 体系データを支払ってください。
7. Eventually payment protocol messages finish so
Payment Handler sends Pay Receipt and optional
signature to the Consumer as proof of payment
7. 結局支払いプロトコルメッセージが終わるので、Payment Handlerは支払証明としてPay Receiptと任意の署名をConsumerに送ります。
C <-------> P PAYMENT RESPONSE. Components: Status, Pay Receipt;
Payment Note; Trading Role Data (optional);
Optional Offer Response Signature; Optional
Payment Receipt Signature that binds the payment
to the Offer
C<。------->P支払い応答。 コンポーネント: 状態、賃金領収書。 支払い紙幣。 取り引き役割のデータ(任意の)。 任意の申し出応答署名。 Offerに支払いを縛る任意のPayment Receipt Signature
8. Consumer checks Payment Receipt is OK
8. 消費者チェックPayment ReceiptはOKです。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 3 Payment Exchange
図3 支払い交換
A Payment Exchange uses the following Trading Components that are passed between the Consumer, the Merchant and the Payment Handler:
Payment ExchangeはConsumerと、マーチャントとPayment Handlerの間で渡される以下のTrading Componentsを使用します:
o The Brand List Component contains a list of payment brands (for
example, MasterCard, Visa, Mondex, GeldKarte), payment protocols
(for example SET Version 1.0, Secure Channel Credit Debit (SCCD -
the name used for a credit or debit card payment where
o Brand List Componentは支払いブランド(例えば、マスターカード、Visa、モンデックス、GeldKarte)のリストを含んでいます、支払いプロトコル、(例えば、SETバージョン1.0、Secure Channel Credit Debit、(SCCD、--名前がクレジットかデビットカード支払いにどこを使用した
Burdett Informational [Page 22] RFC 2801 IOTP/1.0 April 2000
バーデット[22ページ]情報のRFC2801IOTP/2000年4月1日
unauthorised access to account information is prevented through
use of secure channel transport mechanisms such as SSL/TLS) as
well as currencies/amounts that apply. The Merchant sends the
Brand List to the Consumer. The consumer compares the payment
brands, protocols and currencies/amounts on offer with those that
the Consumer supports and makes a selection.
会計情報への権限のないアクセスは適用される通貨/量と同じくらい良いSSL/TLSなどの安全なチャンネル移送機構の使用で防がれます。 マーチャントはBrand ListをConsumerに送ります。 消費者は、申し出の支払いブランド、プロトコル、および通貨/量をConsumerがサポートするものと比較して、選定します。
o The Brand Selection Component contains the Consumer's selection.
Payment brand, protocol, currency/amount and possibly protocol-
specific information is sent back to the Merchant. This
information may be used to change information in the Offer
Exchange. For example, a merchant could choose to offer a discount
to encourage the use of a store card.
o Brand Selection ComponentはConsumerの選択を含んでいます。 支払いブランド、プロトコル、通貨/量、およびことによるとプロトコル特殊情報はマーチャントに送り返されます。 この情報は、Offer Exchangeの情報を変えるのに使用されるかもしれません。 例えば、商人は、ストアカードの使用を奨励するために割引を申し出るのを選ぶことができました。
o the Status component is used to indicate to the Payment Handler
that an earlier exchange (e.g., an Offer Exchange) has
successfully completed and by the Payment Handler to indicate the
completion status of the Payment Exchange.
o Statusの部品はPayment Exchangeの完成状態を示すために以前の交換(例えば、Offer Exchange)が首尾よく完成したPayment HandlerとPayment Handlerで示すのにおいて使用されています。
o The Organisation Components are generated by the Merchant. They
contain details of the Merchant and Payment Handler Roles:
o Organisation Componentsはマーチャントによって生成されます。 それらはマーチャントとPayment Handler Rolesの細部を含んでいます:
- the Merchant role is required so that the Payment Handler can
identify which Merchant initiated the payment. Typically, the
result of the Payment Handler accepting (or making) a payment
on behalf of the Merchant will be a credit or debit transaction
to the Merchant's account held by the Payment Handler. These
transactions are outside the scope of this version of IOTP
- マーチャントの役割が、Payment Handlerが、どのマーチャントが支払いを開始したかを特定できるくらい必要です。 Payment Handlerがマーチャントを代表して支払いを受け入れるという(または、作成)結果は、通常、クレジットか借り方トランザクションにPayment Handlerによって保持されたマーチャントのアカウントに、なるでしょう。 IOTPのこのバージョンの範囲の外にこれらのトランザクションがあります。
- the Payment Handler role is required so that the Payment
Handler can check that it is the correct Payment Handler to be
used for the payment
- Payment Handlerの役割が、Payment Handlerが、支払いに使用されるためにそれが正しいPayment Handlerであることをチェックできるくらい必要です。
o The Payment Component contains details of how much to pay, the
currency and the payment direction
o Payment Componentはどのくらい支払うかに関する詳細、通貨、および支払い方向を含んでいます。
o The "Offer Response" Signature Component, if present, digitally
signs all of the above components to ensure their integrity. Note
that the Brand List and Brand Selection Components are not signed
until the payment information is created (step 4 in the diagram)
o 存在しているなら、「申し出応答」Signature Componentは、彼らの保全を確実にするために上のコンポーネントのすべてにデジタルに署名します。 決済情報が作成されるまでBrand ListとBrand Selection Componentsが署名されないことに注意してください。(ダイヤグラムにおけるステップ4)
o the Trading Role Data component contains from other roles (e.g., a
Merchant) that needs to be forwarded to the Payment Handler
o Trading Role Dataの部品は他からPayment Handlerに送るために必要とする役割(例えば、マーチャント)を含んでいます。
o The Payment Scheme Component contains messages from the payment
protocol used in the Trade. For example they could be SET
messages, Mondex messages, GeldKarte Messages or one of the other
payment methods supported by IOTP. The content of the Payment
o Payment Scheme ComponentはTradeで使用される支払いプロトコルからのメッセージを含んでいます。 例えば、彼らは、SETメッセージ、モンデックスメッセージ、GeldKarte MessagesまたはIOTPによってサポートされた他の支払い方法の1つであるかもしれません。 Paymentの内容
Burdett Informational [Page 23] RFC 2801 IOTP/1.0 April 2000
バーデット[23ページ]情報のRFC2801IOTP/2000年4月1日
Scheme Component is defined in the supplements that describe how
IOTP works with various payment protocols.
体系ComponentはIOTPが様々な支払いプロトコルでどう働いているかを説明する補足で定義されます。
o The Payment Receipt Component contains a record of the payment.
The content depends upon the payment protocol used.
o Payment Receipt Componentは支払いに関する記録を含んでいます。 内容は使用される支払いプロトコルによります。
o The "Payment Receipt" Signature Component provides proof of
payment by digitally signing both the Payment Receipt Component
and the Offer Response Signature. The signature on the offer
digitally signs the Order, Organisation and Delivery Components
contained in the Offer. This signature effectively binds the
payment to the offer.
o 両方がPayment Receipt ComponentとOffer Response Signatureであるとデジタルに署名することによって、「支払い領収書」Signature Componentは支払証明を提供します。 申し出の署名はOfferに含まれたOrder、Organisation、およびDelivery Componentsにデジタルに署名します。 事実上、この署名は申し出に支払いを縛ります。
The example of a Payment Exchange above is the most general case. Simpler cases are also possible. For example, if the amount paid is not dependent on the payment brand and protocol selected then the payment information generated by step 3 can be sent to the Consumer at the same time as the Brand List Component generated by step 1. These and other variations are described in the Baseline Purchase IOTP Transaction (see section 9.1.8).
上のPayment Exchangeに関する例は最も一般的なケースです。 また、より簡単なケースも可能です。 例えば、払込金額が選択された支払いブランドとプロトコルに依存していないなら、ステップ1で生成されたBrand List Componentと同時にステップ3で生成された決済情報はConsumerに送ることができます。 これらと他の変化はBaseline Purchase IOTP Transactionで説明されます(セクション9.1.8を見てください)。
2.2.3 Delivery Exchange
2.2.3 配送交換
The goal of the Delivery Exchange is to cause purchased goods to be delivered to the consumer either online or via physical delivery. A second goal is to provide a "delivery note" to the consumer, providing details about the delivery, such as shipping tracking number. The result of the delivery may also be signed so that it can be used for customer care in the case of problems with physical delivery. The message flow is illustrated in the diagram below.
Delivery Exchangeの目標は購入された商品がオンラインか物理的な配送で消費者に提供されることを引き起こすことです。 2番目の目標は「納品受領書」を消費者に提供することです、配送に関する詳細を明らかにして、問い合わせ番号を出荷するのなどように。 また、配送の結果は、物理的な配送に関する問題の場合における顧客ケアにそれを使用できるように署名されるかもしれません。 メッセージ流動は以下のダイヤグラムで例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
CONSUMER DELIVERY
| HANDLER
| Merchant |
STEP | | |
1. Consumer decides to trade and sends information
about what to deliver and who is to take delivery,
to the Merchant e.g., using HTML.
*消費者..配送| 操作者| 商人| ステップ| | | 1. 消費者は、取り引きすると決めて、だれが何を提供するか、そして、マーチャントに配送を取ることになっているかの情報に例えば使用HTMLを送ります。
C --> M Information on what is being delivered (outside
scope of IOTP)
C--提供されているものに関する>M情報(IOTPの外の範囲)
2. Merchant checks the information provided by the
Consumer, adds information about how the delivery
will occur, information about the Organisations
involved in the delivery and optionally sings it
and sends it to the Consumer
2. 情報がConsumerで提供して、情報を加える配送が起こる商人チェック、配送に任意にかかわるOrganisationsの情報はConsumerにそれを歌って、それを送ります。
Burdett Informational [Page 24] RFC 2801 IOTP/1.0 April 2000
バーデット[24ページ]情報のRFC2801IOTP/2000年4月1日
C <-- M Components: Delivery; Organisations (Delivery
Handler, Deliver To); Order, Optional Offer
Response Signature
C<--Mコンポーネント: 配送。 機構、(配送操作者が配送してください、)、。 注文、任意の申し出応答署名
3. Consumer checks delivery information is OK,
obtains authorisation for the delivery, for
example by making a payment, and sends the
delivery information to the Delivery Handler
3. 消費者チェック配送情報は、OKであり、配送、例えば、支払いを済ませることによって認可を得て、配送情報をDelivery Handlerに送ります。
C --------> D DELIVERY REQUEST. Components: Status; Delivery,
Organisations: (Merchant, Delivery Handler,
DelivTo); Order, Trading Role Data (optional);
Optional Offer Response Signature, Optional
Payment Receipt Signature (from Payment Exchange)
C-------->D配送要求コンポーネント: 状態。 配送、機構: (商人、配送操作者、DelivTo)。 役割のデータ(任意の)を取り引きして、注文してください。 任意の申し出応答署名、任意の支払い領収書署名(支払い交換からの)
4. Delivery Handler checks information and
authorisation. Starts or schedules delivery and
creates and then sends a delivery not tot the
Consumer which can optionally be signed.
4. 配送Handlerは情報と認可をチェックします。 そして、始めかスケジュール配送、任意に署名することができるConsumerは作成して、次に、幼児ではなく、配送を送ります。
C <-------- D DELIVERY RESPONSE. Components: Status; Delivery
Note, Trading Role Data (optional); Optional
Delivery Response Signature
C<。-------- D配送応答。 コンポーネント: 状態。 納品受領書、取り引き役割のデータ(任意の)。 任意の配送応答署名
5. Consumer checks delivery note is OK and accepts or
waits for delivery as described in the the Delivery
Note.
5. 消費者チェック納品受領書は、Delivery Noteで説明されるように配送をOKであり、受け入れるか、または待っています。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 4 Delivery Exchange
図4 配送交換
A Delivery Exchange uses the following Trading Components that are passed between the Consumer, the Merchant and the Delivery Handler:
Delivery ExchangeはConsumerと、マーチャントとDelivery Handlerの間で渡される以下のTrading Componentsを使用します:
o the Status component is used to indicate to the Delivery Handler
that an earlier exchange (e.g., an Offer Exchange or Payment
Exchange) has successfully completed and by the Delivery Handler
to indicate the completion status of the Delivery Exchange.
o Statusの部品はDelivery Exchangeの完成状態を示すために以前の交換(例えば、Offer ExchangeかPayment Exchange)が首尾よく完成したDelivery HandlerとDelivery Handlerで示すのにおいて使用されています。
o The Organisation Component(s) contain details of the Deliver To,
Delivery Handler and Merchant Roles:
o Organisation Component(s)はDeliver To、Delivery Handler、およびマーチャントRolesの細部を含んでいます:
- the Deliver To role indicates where the goods or services are
to be delivered to
- Deliver Toの役割は、どこで商品かサービスに配送されることになっているかを示します。
Burdett Informational [Page 25] RFC 2801 IOTP/1.0 April 2000
バーデット[25ページ]情報のRFC2801IOTP/2000年4月1日
- the Delivery Handler role is required so that the Delivery
Handler can check that she is the correct Delivery Handler to
do the delivery
- Delivery Handlerの役割が、Delivery Handlerが、配送するために彼女が正しいDelivery Handlerであることをチェックできるくらい必要です。
- the Merchant role is required so that the Delivery Handler can
identify which Merchant initiated the delivery
- マーチャントの役割が、Delivery Handlerが、どのマーチャントが配送を開始したかを特定できるくらい必要です。
o The Order Component, contains information about the goods or
services to be delivered
o Order Component、提供される商品かサービスの情報を含んでいます。
o The Delivery Component contains information about how delivery
will occur, for example by post or using e-mail.
o 配送がどう起こるか、例えば、ポストかメールを使用することによって、Delivery Componentは情報を含んでいます。
o The "Offer Response" Signature Component, if present, digitally
signs all of the above components to ensure their integrity.
o 存在しているなら、「申し出応答」Signature Componentは、彼らの保全を確実にするために上のコンポーネントのすべてにデジタルに署名します。
o The "Payment Receipt" Signature Component provides proof of
payment by digitally signing the Payment Receipt Component and the
Offer Signature. This is used by the Delivery Handler to check
that delivery is authorised
o 「支払い領収書」Signature Componentは、Payment Receipt ComponentとOffer Signatureにデジタルに署名することによって、支払証明を提供します。 これは、配送が認可されているのをチェックするのにDelivery Handlerによって使用されます。
o The Delivery Note Component contains customer care information
related to a physical delivery, or alternatively the actual
"electronic goods". The Consumer's software does not interpret
information about a physical delivery but should have the ability
to display the information, both at the time of the delivery and
later if the Consumer selects the Trade to which this delivery
relates from a transaction list
o Delivery Note Componentは物理的な配送、またはあるいはまた、実際の「電子商品」に関連する顧客ケア情報を含んでいます。 Consumerのソフトウェアには、物理的な配送の情報を解釈しませんが、Consumerがこの配送がトランザクションリストから関係するTradeを選択するなら、配送で、より遅い時点で情報を表示する能力があるはずです。
o The "Delivery Response" Signature Component, if present, provides
proof of the results of the Delivery by digitally signing the
Delivery Note and any Offer Response or Payment Response
signatures that the Delivery Handler received.
o 存在しているなら、どんなDelivery NoteとOffer ResponseやPayment ResponseもDelivery Handlerが受けた署名であるとデジタルに署名することによって、「配送応答」Signature ComponentはDeliveryの結果の証拠を提供します。
2.2.4 Authentication Exchange
2.2.4 認証交換
The goal of the Authentication Exchange is to allow one Organisation, for example a financial institution, to be able to check that another Organisation, for example a consumer, is who they appear to be.
Authentication Exchangeの目標が1Organisation、例えば金融機関を許容することであり、別のOrganisation(例えば、消費者)が彼らがだれに見えるかということであることをチェックできるように、いてください。
An Authentication Exchange involves:
Authentication Exchangeは以下にかかわります。
o an Authenticator - the Organisation which is requesting the
authentication, and
o そしてAuthenticator--認証を要求しているOrganisation。
o an Authenticatee - the Organisation being authenticated.
o Authenticatee--認証されるOrganisation。
Burdett Informational [Page 26] RFC 2801 IOTP/1.0 April 2000
バーデット[26ページ]情報のRFC2801IOTP/2000年4月1日
This is illustrated in the diagram below.
これは以下のダイヤグラムで例証されます。
+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Organisation 1
(Authenticatee)
| Organisation 2
| (Authenticator)
STEP | |
1. First Organisation, e.g., a Consumer, takes an action (for
example by pressing a button on an HTML page) which
requires that the Organisation is authenticated
機構| 機構2| (固有識別文字) ステップ| | 1. まず最初に、Organisation(例えば、Consumer)はOrganisationが認証されるのを必要とする行動(例えば、1HTML形式のページでボタンを押すのによる)を取ります。
1 --> 2 Need for Authentication (outside scope of IOTP)
1--2が認証に必要とする>。(IOTPの外の範囲)
2. The second Organisation generates an Authentication
Request - including challenge data, and a list of the
algorithms that may be used for the authentication -
and/or a request for the Organisation information then
sends it to the first Organisation
2. 第2OrganisationはAuthentication Request(挑戦データ、および認証に使用されるかもしれないアルゴリズムのリストを含んでいる)を生成します、そして、次に、Organisation情報に関する要求は最初のOrganisationにそれを送ります。
1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication
Request, Trading Role Information Request
1 <--2 認証要求コンポーネント: 認証要求、取り引き役割の情報要求
3. The first Organisation optionally checks any signature
associated with the Authentication Request then uses the
specified authentication algorithm to generate an
Authentication Response which is sent back to the second
Organisation together with details of any Organisation
information requested
3. 最初のOrganisationは任意にどんなOrganisation情報の詳細に伴うOrganisationも要求した2番目へのその時が送られるAuthentication Responseを生成するのに指定された認証アルゴリズムを使用するAuthentication Requestに関連しているどんな署名もチェックします。
1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication
Response, Organisation(s)
1-->2認証応答。 コンポーネント: 認証応答、機構(s)
4. The Authentication Response is checked against the
challenge data to check that the first Organisation is
who they appear to be and the result recorded in a Status
Component which is then sent back to the first
Organisation.
4. あって、Authentication Responseは、最初のOrganisationがだれに見えるかということであることをチェックするために挑戦データに対してチェックされます。結果は、次に、最初のOrganisationがどれに送り返されるかをStatus Componentに記録しました。
1 <-- 2 AUTHENTICATION STATUS. Component: Status
1 <--2 認証状態。 コンポーネント: 状態
5. The first Organisation then optionally checks the results
indicated by the Status and any associated signature and
takes the appropriate action or stops.
5. 最初のOrganisationは次に、任意にStatusによって示された結果とどんな関連署名もチェックして、適切な行動を取るか、または止まります。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 5 Authentication Exchange
図5 認証交換
Burdett Informational [Page 27] RFC 2801 IOTP/1.0 April 2000
バーデット[27ページ]情報のRFC2801IOTP/2000年4月1日
An Authentication Exchange uses the following Trading Components that are passed between the two Organisations:
Authentication Exchangeは2Organisationsの間で渡される以下のTrading Componentsを使用します:
o the Authentication Request Component that requests an
Authentication and indicates the authentication algorithm and
optional challenge data to be used.
o Authenticationを要求して、使用されるために認証アルゴリズムと任意の挑戦データを示すAuthentication Request Component。
o A Trading Role Information Request Component that requests
information about an Organisation, for example a ship to address.
o Organisation、例えば扱う船の情報を要求するTrading Role情報Request Component。
o The Authentication Response Component which contains the challenge
response generated by the recipient of the Authentication Request
Component.
o Authentication Request Componentの受取人によって生成されたチャレンジレスポンスを含むAuthentication Response Component。
o Organisation Components that contain the result of the Trading
Role Information Request
o Trading Role情報Requestの結果を含む機構Components
o the Status Component which contains the results of the second
party's verification of the Authentication Response.
o 2番目のパーティーのAuthentication Responseの検証の結果を含むStatus Component。
2.3 Scope of Baseline IOTP
2.3 基線IOTPの範囲
This specification describes the IOTP Transactions which make up Baseline IOTP. As described in the preface, IOTP will evolve over time. This section defines the initial conformance criteria for implementations that claim to "support IOTP."
この仕様はBaseline IOTPを作るIOTP Transactionsについて説明します。 序文で説明されるように、IOTPは時間がたつにつれて、発展するでしょう。 このセクションは「IOTPをサポートします」と主張する実装の初期の順応評価基準を定義します。
The main determinant on the scope of an IOTP implementation is the roles which the solution is designed to support. The roles within IOTP are described in more detail in section 2.1 Trading Roles. To summarise the roles are: Merchant, Consumer, Payment Handler, Delivery Handler and Customer Care Provider.
IOTP実装の範囲の上の主な決定因はソリューションがサポートするように設計されている役割です。 IOTPの中の役割はさらに詳細にセクション2.1Trading Rolesで説明されます。 役割について略言するのは、以下の通りです。 商人、消費者、支払い操作者、配送操作者、および顧客はプロバイダーについて気にかけます。
Payment Handlers who can be of three types:
3のものであることができる支払いHandlersは以下をタイプします。
o those who accept a payment as part of a purchase or make a payment
as part of a refund,
o 購入の一部として支払いを認めるか、または還付の一部として支払いを済ませる人
o those who accept value as part of a deposit transaction, or
o または預金トランザクションの一部として値を認める人。
o those that issue value a withdrawal transaction
o 退出トランザクションを値に発行するもの
The following table defines, for each role, the IOTP Transactions and Trading Blocks which must be supported for that role.
以下のテーブルは、各役割、IOTP Transactions、およびTrading Blocksのためにその役割のためにどれをサポートしなければならないかを定義します。
Burdett Informational [Page 28] RFC 2801 IOTP/1.0 April 2000
バーデット[28ページ]情報のRFC2801IOTP/2000年4月1日
Merchants
商人
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
eキャッシュeキャッシュは値の値の消費者支払い配送発行人のアクワイアラ操作者操作者を保存します。
TRANSACTIONS
トランザクション
Purchase Must Must
購買必須必須
Merchants
商人
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
eキャッシュeキャッシュは値の値の消費者支払い配送発行人のアクワイアラ操作者操作者を保存します。
Refund Must b)
Depends
還付Must b) よります。
Authentication May Must May b)
Depends
認証5月のMust5月のb) よります。
Value Exchange May Must
交換5月がそうしなければならない値
Withdrawal Must b)
Depends
退出Must b) よります。
Deposit Must b)
Depends
預金Must b) よります。
Inquiry Must Must Must May Must Must
問い合せ必須必須必須5月の必須必須
Ping Must Must Must May Must Must
ピング必須必須必須5月の必須必須
TRADING BLOCKS
通商圏
TPO Must Must Must Must
TPO必須必須必須必須
TPO Selection Must Must Must Must
TPO選択必須必須必須必須
Auth-Request a) a) a)
Depends Depends Depends
Auth-要求a)a)a) 依存、依存、依存
Auth-Reply a) a) a)
Depends Depends Depends
Auth-回答a)a)a) 依存、依存、依存
Offer Response Must Must Must Must
応答必須必須必須必須を提供してください。
Burdett Informational [Page 29] RFC 2801 IOTP/1.0 April 2000
バーデット[29ページ]情報のRFC2801IOTP/2000年4月1日
Payment Must Must Request
支払い必須必須要求
Payment Must Must Exchange
支払い必須必須交換
Payment Must Must Response
支払い必須必須応答
Delivery Must Must Request
必須が要求しなければならない配送
Delivery Must Must Response
配送必須必須応答
Merchants
商人
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
eキャッシュeキャッシュは値の値の消費者支払い配送発行人のアクワイアラ操作者操作者を保存します。
Inquiry Must Must Must Must Must Must Request
必須が要求しなければならない問い合せ必須必須必須必須
Inquiry Must Must Must Must Must Must Response
問い合せ必須必須必須必須必須必須応答
Ping Request Must Must Must Must Must Must
ピング要求必須必須必須必須必須必須
Ping Response Must Must Must Must Must Must
ピング応答必須必須必須必須必須必須
Signature Must Must Must Limited Must Must
署名必須必須必須株式会社必須必須
Error Must Must Must Must Must Must
誤り必須必須必須必須必須必須
In the above table:
上のテーブルで:
o "Must" means that a Trading Role must support the Transaction or
Trading Block.
o "Must"は、Trading RoleがTransactionかTrading Blockをサポートしなければならないことを意味します。
o "May" means that an implementation may support the Transaction or
Trading Block at the option of the developer.
o 「5月」は、実装が開発者の選択のときにTransactionかTrading Blockをサポートするかもしれないことを意味します。
o "Depends" means implementation of the Transaction or Trading Block
depends on one of the following conditions:
o 「依存」は、TransactionかTrading Blockの実装が以下の条件の1つによることを意味します:
- if Baseline Authentication IOTP Transaction is supported;
- Baseline Authentication IOTP Transactionがサポートされるなら。
Burdett Informational [Page 30] RFC 2801 IOTP/1.0 April 2000
バーデット[30ページ]情報のRFC2801IOTP/2000年4月1日
- if required by a Payment Method as defined in its IOTP
Supplement document.
- 必要ならIOTP Supplementドキュメントで定義されるPayment Method。
o "Limited" means the Trading Block must be understood and its
content manipulated but not in every respect. Specifically, on the
Signature Block, Consumers do not have to be able to validate
digital signatures.
o 「株式会社」は、Trading Blockが理解されていて操られたその内容であるに違いないことを意味しますが、すべての点で意味するというわけではありません。 明確に、Signature Blockでは、Consumersはデジタル署名を有効にすることができる必要はありません。
An IOTP solution must support all the IOTP Transactions and Trading Blocks required by at least one role (column) as described in the above table for that solution to be described as "supporting IOTP".
ソリューション..サポートする..必要..少なくとも..役割..コラム..説明..上..テーブル..ソリューション..記述..サポートする
3. Protocol Structure
3. プロトコル構造
The previous section provided an introduction which explained:
前項は説明した序論を提供しました:
o Trading Roles which are the different roles which Organisations
can take in a trade: Consumer, Merchant, Payment Handler, Delivery
Handler and Customer Care Provider, and
o Organisationsが取り引きで取ることができる異なる役割である取り引きRoles: そして消費者、商人、支払い操作者、配送操作者、および顧客がプロバイダーについて気にかける。
o Trading Exchanges where each Trading Exchange involves the
exchange of data, between Trading Roles, in the form of a set of
Trading Components.
o Trading Componentsの1セットの形でTrading Rolesの間で各Trading Exchangeがデータの交換にかかわるExchangesを取り引きします。
This section describes:
このセクションは以下について説明します。
o how Trading Components are constructed into Trading Blocks and the
IOTP Messages which are physically sent in the form of [XML]
documents between the different Trading Roles,
o Trading Componentsはどう[XML]ドキュメントの形で物理的に異なったTrading Rolesの間に送られるTrading BlocksとIOTP Messagesに組み立てられるか。
o how IOTP Messages are exchanged between Trading Roles to create an
IOTP Transaction
o IOTP Transactionを作成するためにTrading Rolesの間でどうIOTP Messagesを交換するか。
o the XML definitions of an IOTP Message including a Transaction
Reference Block - an XML element which identifies an IOTP
Transaction and the IOTP Message within it
o Transaction Reference Blockを含むIOTP MessageのXML定義--それの中でIOTP TransactionとIOTP Messageを特定するXML要素
o the definitions of the XML ID Attributes which are used to
identify IOTP Messages, Trading Blocks and Trading Components and
how these are referred to using Element References from other XML
elements
o IOTP Messages、Trading Blocks、およびTrading Componentsを特定するのに使用されるXML ID Attributesと他のXML要素からElement Referencesを使用することでこれらがどう言及されるかに関する定義
o how extra XML Elements and new user defined values for existing
IOTP codes can be used when Extending IOTP,
o Extending IOTPであるときに、使用されて、既存のIOTPコードのためのXML Elementsと新しいユーザ定義された値は何と付加的である場合がありますのだろう!
o how IOTP uses the Packaged Content Element to embed data such as
payment protocol messages or detailed order definitions within an
IOTP Message
o IOTPは、IOTP Messageの中で支払いプロトコルメッセージか詳細なオーダー定義などのデータを埋め込むのにどうPackaged Content Elementを使用するか。
Burdett Informational [Page 31] RFC 2801 IOTP/1.0 April 2000
バーデット[31ページ]情報のRFC2801IOTP/2000年4月1日
o how IOTP Identifies Languages so that different languages can be
used within IOTP Messages
o どのようにIOTP Identifies Languages、IOTP Messagesの中で異なった言語を使用できるか。
o how IOTP handles both Secure and Insecure Net Locations when
sending messages
o メッセージを送るとき、IOTPはどうSecureとInsecureネットLocationsの両方を扱うか。
o how an IOTP Transaction can be cancelled.
o どうIOTP Transactionを取り消すことができるか。
3.1 Overview
3.1 概要
3.1.1 IOTP Message Structure
3.1.1 IOTPメッセージ構造
The structure of an IOTP Message and its relationship with Trading Blocks and Trading Components is illustrated in the diagram below.
IOTP Messageの構造とTrading BlocksとTrading Componentsとのその関係は以下のダイヤグラムで例証されます。
Burdett Informational [Page 32] RFC 2801 IOTP/1.0 April 2000
バーデット[32ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE <---------- IOTP Message - an XML Document which is | transported between the Trading Roles |-Trans Ref Block <----- Trans Ref Block - contains information which | | describes the IOTP Transaction and the IOTP | | Message. | |-Trans Id Comp. <--- Transaction Id Component - uniquely | | identifies the IOTP Transaction. The Trans Id | | Components are the same across all IOTP | | messages that comprise a single IOTP | | transaction. | |-Msg Id Comp. <----- Message Id Component - identifies and | describes an IOTP Message within an IOTP | Transaction |-Signature Block <----- Signature Block (optional) - contains one or | | more Signature Components and their | | associated Certificates | |-Signature Comp. <-- Signature Component - contains digital | | signatures. Signatures may sign digests of | | the Trans Ref Block and any Trading Component | | in any IOTP Message in the same IOTP | | transaction. | |-Certificate Comp. < Certificate Component (Optional) Used to check | the signature. |-Trading Block <------- Trading Block - an XML Element within an IOTP | |-Trading Comp. Message that contains a predefined set of | |-Trading Comp. Trading Components | |-Trading Comp. | |-Trading Comp. <--- Trading Components - XML Elements within a | Trading Block that contain a predefined set |-Trading Block of XML elements and attributes containing | |-Trading Comp. information required to support a Trading | |-Trading Comp. Exchange | |-Trading Comp. | |-Trading Comp. | |-Trading Comp.
IOTPメッセージ<。---------- IOTP Message--そうするXML Document| Trading Rolesの間で輸送されます。|-移-審判ブロック<。----- 移-Ref Block--、情報を含んでいる、どれ| | IOTP TransactionとIOTPについて説明します。| | メッセージ。 | |-移-イドコンピュータ。 <-- トランザクションId Component--唯一| | IOTP Transactionを特定します。 移-イド| | コンポーネントはすべてのIOTPの向こう側に同じです。| | 独身のIOTPを包括するメッセージ| | トランザクション。 | |-エムエスジーイドコンピュータ。 <、-、-、-、-- そしてメッセージId Component--、特定。| IOTPの中でIOTP Messageについて説明します。| トランザクション|-署名欄<。----- または署名Block(任意の)--、1つを含んでいる。| | そして、 より多くのSignature Components、彼ら| | 関連Certificates| |-署名コンピュータ。 <-- 署名Component--、含有、デジタル| | 署名。 署名はダイジェストに署名するかもしれません。| | Trans Ref BlockとどんなTrading Component| | 同じIOTPのどんなIOTP Messageでも| | トランザクション。 | |-コンピュータを証明してください。 <証明書Component(任意の)は以前はよくチェックしていました。| 署名。 |-通商圏<。------- 通商圏--IOTPの中のXML要素| |-コンピュータを取り引きします。 それが事前に定義されたセットを含むメッセージ| |-コンピュータを取り引きします。 取り引きコンポーネント| |-コンピュータを取り引きします。 | |-コンピュータを取り引きします。 <-- 取り引きコンポーネント--aの中のXML Elements| 事前に定義されたセットを含む取り引きBlock|-XML要素と属性含有の取り引きBlock| |-取り引きComp情報がTradingをサポートするのが必要です。| |-コンピュータを取り引きします。 交換| |-コンピュータを取り引きします。 | |-コンピュータを取り引きします。 | |-コンピュータを取り引きします。
*-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 6 IOTP Message Structure
図6 IOTPメッセージ構造
The diagram also introduces the concept of a Transaction Reference Block. This block contains, amongst other things, a globally unique identifier for the IOTP Transaction. Also each block and component is given an ID Attribute (see section 3.4) which is unique within an IOTP Transaction. Therefore the combination of the ID attribute and
また、ダイヤグラムはTransaction Reference Blockの概念を紹介します。 このブロックは他のものの中にIOTP Transactionに、グローバルにユニークな識別子を含んでいます。 IOTP Transactionの中でユニークなID Attribute(セクション3.4を見る)を各ブロックとコンポーネントにも与えます。 そしてしたがって、ID属性の組み合わせ。
Burdett Informational [Page 33] RFC 2801 IOTP/1.0 April 2000
バーデット[33ページ]情報のRFC2801IOTP/2000年4月1日
the globally unique identifier in the Transaction Reference Block is sufficient to uniquely identify any Trading Block or Trading Component.
Transaction Reference Blockのグローバルにユニークな識別子は、唯一どんなTrading BlockやTrading Componentも特定するために十分です。
3.1.2 IOTP Transactions
3.1.2 IOTPトランザクション
A predefined set of IOTP Messages exchanged between the Trading Roles constitute an IOTP Transaction. This is illustrated in the diagram below.
Trading Rolesの間で交換された事前に定義されたセットのIOTP MessagesはIOTP Transactionを構成します。 これは以下のダイヤグラムで例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
CONSUMER MERCHANT
Generate first
IOTP Message
--- |
| | v
Process incoming | I | -------------
IOTP Message & <------------- | | ------------ | IOTP Message |
generate next IOTP | | -------------
Message | N |
| | |
v | |
------------- | T | Process incoming
| IOTP Message | -------------- | | -----------> IOTP Message &
------------- | | generate next
| E | IOTP Message
| | |
| | v
Process incoming | R | -------------
IOTP Message <------------- | | ------------ | IOTP Message |
generate last IOTP | | -------------
Message & stop | N |
| | |
v | |
------------- | E | Process last
| IOTP Message | -------------- | | -------------> incoming IOTP
------------- | | Message & stop
| | T | |
v | | v
STOP --- STOP
CONSUMER MERCHANT Generate最初のIOTP Message--- | | | Process入来に対して| I| ------------- IOTPメッセージと<。------------- | | ------------ | IOTPメッセージ| 次のIOTPを生成してください。| | ------------- メッセージ| N| | | | v| | ------------- | T| プロセス入来| IOTPメッセージ| -------------- | | ----------->IOTPメッセージ------------- | | 次を生成してください。| E| IOTPメッセージ| | | | | Process入来に対して| R| ------------- IOTPメッセージ<。------------- | | ------------ | IOTPメッセージ| 最後のIOTPを生成してください。| | ------------- メッセージと停止| N| | | | v| | ------------- | E| 最後に処理してください。| IOTPメッセージ| -------------- | | ------------->の入って来るIOTP------------- | | メッセージと停止| | T| | v| | STOPに対して--- 停止
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 7 An IOTP Transaction
図7 IOTPトランザクション
Burdett Informational [Page 34] RFC 2801 IOTP/1.0 April 2000
バーデット[34ページ]情報のRFC2801IOTP/2000年4月1日
In the above diagram the Internet is shown as the transport mechanism. This is not necessarily the case. IOTP Messages can be transported using a variety of transport mechanisms.
上のダイヤグラムで、インターネットは移送機構として示されます。 これは必ずそうであるというわけではありません。 さまざまな移送機構を使用することでIOTP Messagesを輸送できます。
The IOTP Transactions (see section 9) in this version of IOTP are specifically:
IOTPのこのバージョンのIOTP Transactions(セクション9を見る)は明確に以下の通りです。
o Purchase. This supports a purchase involving an offer, a payment
and optionally a delivery
o 購買。 これが、購入が申し出にかかわる支払いであると任意にサポートする、配送
o Refund. This supports the refund of a payment as a result of,
typically, an earlier purchase
o 還付します。 これがaとしての支払いが結果になるaの還付を通常サポートする、以前の購入
o Value Exchange. This involves two payments which result in the
exchange of value from one combination of currency and payment
method to another
o 交換を評価してください。 これは価値の通貨と支払い方法の1つの組み合わせから別の組み合わせまでの交換をもたらす2つの支払いにかかわります。
o Authentication. This supports the remote authentication of one
Trading Role by another Trading Role using a variety of
authentication algorithms, and the provision of an Organisation
Information about the Trading Role that is being authenticated for
use in, for example, the creation of an offer
o 認証。 これは例えば、申し出の作成における使用のために認証されているTrading Roleに関して別のTrading Roleによる1Trading Roleのリモート認証がさまざまな認証アルゴリズムを使用して、Organisation情報の支給であるとサポートします。
o Withdrawal. This supports the withdrawal of electronic cash from a
financial institution
o 退出。 これは金融機関から電子現金の退出をサポートします。
o Deposit. This supports the deposit of electronic cash at a
financial institution
o 預けます。 これは金融機関における電子現金の預金をサポートします。
o Inquiry This supports inquiries on the status of an IOTP
transaction which is either in progress or is complete
o 問い合せThisは進行中であることの、または、完全なIOTPトランザクションの状態で問い合せをサポートします。
o Ping This supports a simple query which enables one IOTP aware
application to determine whether another IOTP application running
elsewhere is working or not.
o ピングThisは1つのIOTPの意識しているアプリケーションが、ほかの場所に稼働する別のIOTPアプリケーションが働いているかどうか決定するのを可能にする簡単な質問をサポートします。
3.2 IOTP Message
3.2 IOTPメッセージ
As described earlier, IOTP Messages are [XML] documents which are physically sent between the different Trading Roles that are taking part in a trade.
より早く説明されるように、IOTP Messagesは物理的に取り引きに参加している異なったTrading Rolesの間に送られる[XML]ドキュメントです。
The XML definition of an IOTP Message is as follows.
IOTP MessageのXML定義は以下の通りです。
<!ELEMENT IotpMessage
( TransRefBlk,
SigBlk?,
ErrorBlk?,
<!要素IotpMessage、(TransRefBlk、SigBlk?、ErrorBlk?
Burdett Informational [Page 35] RFC 2801 IOTP/1.0 April 2000
バーデット[35ページ]情報のRFC2801IOTP/2000年4月1日
( AuthReqBlk |
AuthRespBlk |
AuthStatusBlk |
CancelBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk
)*
) >
<!ATTLIST IotpMessage
xmlns CDATA
'iotp:ietf.org/iotp-v1.0'
(AuthReqBlk|AuthRespBlk|AuthStatusBlk|CancelBlk|DeliveryReqBlk|DeliveryRespBlk|InquiryReqBlk|InquiryRespBlk|OfferRespBlk|PayExchBlk|PayReqBlk|PayRespBlk|PingReqBlk|PingRespBlk|TpoBlk| TpoSelectionBlk) *) ><!ATTLIST IotpMessage xmlns CDATAは': ietf.org/iotp-v1.0をiotpします'。
Content:
内容:
TransRefBlk This contains information which describes an IOTP
Message within an IOTP Transaction (see section
3.3 immediately below)
TransRefBlk ThisはIOTP Transactionの中でIOTP Messageについて説明する情報を含んでいます。(すぐに下のセクション3.3を見ます)
AuthReqBlk, These are the Trading Blocks. AuthRespBlk, DeliveryReqBlk, The Trading Blocks present within an IOTP Message, DeliveryRespBlk and the content of a Trading Block itself is ErrorBlk dependent on the type of IOTP Transaction being InquiryReqBlk, carried out - see the definition of each InquiryRespBlk, transaction in section 9 Internet Open Trading OfferRespBlk, Protocol Transactions. PayExchBlk, PayReqBlk, Full definitions of each Trading Block are PayRespBlk, described in section 8. PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk
AuthReqBlk、TheseはTrading Blocksです。 Trading Block自身のAuthRespBlk、DeliveryReqBlk、IOTP Messageの中の現在のTrading Blocks、DeliveryRespBlk、および内容は行われたInquiryReqBlkであるIOTP Transactionのタイプの上のErrorBlk扶養家族です--それぞれのInquiryRespBlkの定義を見てください、セクション9インターネットオープンTrading OfferRespBlkのトランザクション、プロトコルTransactions。 PayExchBlk、PayReqBlk、それぞれのTrading BlockのFull定義はセクション8で説明されたPayRespBlkです。 PingReqBlk、PingRespBlk、SigBlk、TpoBlk、TpoSelectionBlk
Attributes:
属性:
xmlns The [XML Namespace] definition for IOTP messages.
IOTPメッセージのための[XML Namespace]定義をxmlnsします。
Burdett Informational [Page 36] RFC 2801 IOTP/1.0 April 2000
バーデット[36ページ]情報のRFC2801IOTP/2000年4月1日
3.2.1 XML Document Prolog
3.2.1 XMLドキュメントプロローグ
The IOTP Message is the root element of the XML document. It therefore needs to be preceded by an appropriate XML Document Prolog. For example:
IOTP MessageはXMLドキュメントの根の要素です。 したがって、それは、適切なXML Document Prologによって先行される必要があります。 例えば:
<?XML Version='1.0'?>
<!DOCTYPE IotpMessage >
<IotpMessage>
...
</IotpMessage>
<?XMLバージョン='1.0'?><!DOCTYPE IotpMessage><IotpMessage>… </IotpMessage>。
3.3 Transaction Reference Block
3.3 トランザクション対比試験片
A Transaction Reference Block contains information which identifies the IOTP Transaction and IOTP Message. The Transaction Reference Block contains:
Transaction Reference BlockはIOTP TransactionとIOTP Messageを特定する情報を含んでいます。 Transaction Reference Blockは以下を含んでいます。
o a Transaction Id Component which globally uniquely identifies the
IOTP Transaction. The Transaction Id Components are the same
across all IOTP messages that comprise a single IOTP transaction,
o 唯一IOTP Transactionをグローバルに特定するTransaction Id Component。 Transaction Id Componentsはただ一つのIOTPトランザクションを包括するすべてのIOTPメッセージの向こう側に同じです。
o a Message Id Component which provides control information about
the IOTP Message as well as uniquely identifying the IOTP Message
within an IOTP Transaction, and
o そしてIOTP Transactionの中で唯一IOTP Messageを特定することと同様にIOTP Messageに関する制御情報を提供するMessage Id Component。
o zero or more Related To Components which link this IOTP
Transaction to either other IOTP Transactions or other events
using the identifiers of those events.
o ゼロかそれらのイベントに関する識別子を使用することで他のIOTP Transactionsかイベントのどちらかに他のこのIOTP Transactionをリンクするより関連のTo Components。
The definition of a Transaction Reference Block is as follows:
Transaction Reference Blockの定義は以下の通りです:
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
<!要素TransRefBlk(トランザクション識別子、MsgId、RelatedTo*)><!ATTLIST TransRefBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Transaction Reference Block within the IOTP
Transaction (see section 3.4 ID Attributes).
IOTP Transaction(セクション3.4ID Attributesを見る)の中で唯一Transaction Reference Blockを特定するID An識別子。
Content:
内容:
TransId See 3.3.1 Transaction Id Component immediately
below.
すぐに以下のトランザクション識別子See3.3.1Transaction Id Component。
MsgId See 3.3.2 Message Id Component immediately below.
すぐに以下のMsgId See3.3.2Message Id Component。
Burdett Informational [Page 37] RFC 2801 IOTP/1.0 April 2000
バーデット[37ページ]情報のRFC2801IOTP/2000年4月1日
RelatedTo See 3.3.3 Related To Component immediately below.
すぐに以下のRelatedTo See3.3.3の関連To Component。
3.3.1 Transaction Id Component
3.3.1 トランザクションイドコンポーネント
This contains information which globally uniquely identifies the IOTP Transaction. Its definition is as follows:
これは唯一IOTP Transactionをグローバルに特定する情報を含んでいます。 定義は以下の通りです:
<!ELEMENT TransId EMPTY >
<!ATTLIST TransId
ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'
IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIRED
TransTimeStamp CDATA #REQUIRED >
ATTLISTのIDの#必要なバージョンNMTOKENトランザクション識別子ID#、がIotpTransId CDATAの必要なIotpTransType CDATA#必要なTransTimeStamp CDATA##、が必要とした'1.0'>を固定した<!要素トランザクション識別子の空の><!
Attributes:
属性:
ID An identifier which uniquely identifies the
Transaction Id Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Transaction Id Componentを特定するID An識別子。
Version This identifies the version of IOTP, and therefore
the structure of the IOTP Messages, which the IOTP
Transaction is using.
バージョンThisはIOTPのバージョンを特定して、したがって、IOTP Messagesの構造を特定します。(IOTP TransactionはIOTP Messagesを使用しています)。
IotpTransId Contains data which uniquely identifies the IOTP
Transaction. It must conform to the rules for
Message Ids in [RFC 822].
唯一IOTP Transactionを特定するIotpTransId Containsデータ。 それは[RFC822]のMessage Idsのために規則に従わなければなりません。
IotpTransTyp This is the type of IOTP Transaction being carried
out. For Baseline IOTP it identifies a "standard"
IOTP Transaction and implies the sequence and
content of the IOTP Messages exchanged between the
Trading Roles. The valid values for Baseline IOTP
are:
o BaselineAuthentication
o BaselineDeposit
o BaselinePurchase
o BaselineRefund
o BaselineWithdrawal
o BaselineValueExchange
o BaselineInquiry
o BaselinePing
IotpTransTyp Thisは行われるIOTP Transactionのタイプです。 Baseline IOTPに関しては、それは、「標準」のIOTP Transactionを特定して、Trading Rolesの間で交換されたIOTP Messagesの系列と内容を含意します。 Baseline IOTPのための有効値は以下の通りです。 o BaselineAuthentication o BaselineDeposit o BaselinePurchase o BaselineRefund o BaselineWithdrawal o BaselineValueExchange o BaselineInquiry o BaselinePing
Values of IotpTransType are managed under the
procedure described in section 12 IANA
Considerations which also allows user defined
values of IotpTransType to be defined.
IotpTransTypeの値はまた、IotpTransTypeのユーザの定義された値が定義されるのを許容するセクション12IANA Considerationsで説明された手順の下で管理されます。
Burdett Informational [Page 38] RFC 2801 IOTP/1.0 April 2000
バーデット[38ページ]情報のRFC2801IOTP/2000年4月1日
In later versions of IOTP, this list will be
extended to support different types of standard
IOTP Transaction. It is also likely to support the
type Dynamic which indicates that the sequence of
steps within the transaction are non-standard.
IOTPの後のバージョンでは、このリストは、標準のIOTP Transactionの異なったタイプをサポートするために広げられるでしょう。 また、それもタイプがトランザクションの中のステップの系列が標準的でないのを示すDynamicであるとサポートしそうです。
TransTimeStamp Where the system initiating the IOTP Transaction
has an internal clock, it is set to the time at
which the IOTP Transaction started in [UTC]
format.
TransTimeStamp Where、IOTP Transactionを開始するシステムは内部クロックを持って、IOTP Transactionが[UTC]形式で始まった時に設定されます。
The main purpose of this attribute is to provide
an alternative way of identifying a transaction by
specifying the time at which it started.
この属性の主な目的はそれが始まった時を指定することによってトランザクションを特定する代替の方法を提供することです。
Some systems, for example, hand held devices may
not be able to generate a time stamp. In this
case this attribute should contain the value "NA"
for Not Available.
例えば、いくつかのシステムであり携帯用のデバイスはタイムスタンプを生成することができないかもしれません。 この場合、この属性が値の「Na」を含むべきである、利用可能ではありません。
3.3.2 Message Id Component
3.3.2 メッセージイドコンポーネント
The Message Id Component provides control information about the IOTP Message as well as uniquely identifying the IOTP Message within an IOTP Transaction. Its definition is as follows.
Message Id ComponentはIOTP Transactionの中で唯一IOTP Messageを特定することと同様にIOTP Messageに関する制御情報を提供します。 定義は以下の通りです。
<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
ID ID #REQUIRED
RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED
SenderTradingRoleRef NMTOKEN #IMPLIED
SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED >
<!ELEMENT MsgId EMPTY><!ATTLIST MsgId ID ID#REQUIRED RespIotpMsg NMTOKEN#IMPLIED xml: lang NMTOKEN#REQUIRED LangPrefList NMTOKENS#IMPLIED CharSetPrefList NMTOKENS#IMPLIED SenderTradingRoleRef NMTOKEN#IMPLIED SoftwareId CDATA#REQUIRED TimeStamp CDATA#IMPLIED>。
Attributes:
属性:
ID An identifier which uniquely identifies the
IOTP Message within the IOTP Transaction (see
section 3.4 ID Attributes). Note that if an
IOTP Message is resent then the value of this
attribute remains the same.
IOTP Transaction(セクション3.4ID Attributesを見る)の中で唯一IOTP Messageを特定するID An識別子。 IOTP Messageを再送するならこの属性の値が同じままで残っていることに注意してください。
RespIotpMsg This contains the ID attribute of the Message
Id Component of the IOTP Message to which this
IOTP Message is a response. In this way all
RespIotpMsg ThisはこのIOTP Messageが応答であるIOTP MessageのMessage Id ComponentのID属性を含んでいます。 このよう、すべて
Burdett Informational [Page 39] RFC 2801 IOTP/1.0 April 2000
バーデット[39ページ]情報のRFC2801IOTP/2000年4月1日
the IOTP Messages in an IOTP Transaction are
unambiguously linked together. This field is
required on every IOTP Message except the
first IOTP Message in an IOTP Transaction.
IOTP TransactionのIOTP Messagesは明白に結びつけられます。 この分野がIOTP Transactionにおける最初のIOTP Message以外のあらゆるIOTP Messageで必要です。
SenderTradingRoleRef The Element Reference (see section 3.5) of the
Trading Role which has generated the IOTP
message. It is used to identify the Net
Locations (see section 3.9) of the Trading
Role to which problems Technical Errors (see
section 4.1) with any of Trading Blocks should
be reported.
IOTPメッセージを生成したTrading RoleのSenderTradingRoleRef Element Reference(セクション3.5を見ます)。 それは、Trading Blocksのどれかがある問題Technical Errors(セクション4.1を見る)が報告されるべきであるTrading RoleのネットLocations(セクション3.9を見る)を特定するのに使用されます。
Xml:lang Defines the language used by attributes or
child elements within this component, unless
overridden by an xml:lang attribute on a child
element. See section 3.8 Identifying
Languages.
Xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
LangPrefList Optional list of Language codes that conform
to [XML] Language Identification. It is used
by the sender to indicate, in preference
sequence, the languages that the receiver of
the message ideally should use when generating
a response. There is no obligation on the
receiver to respond using one of the indicated
languages, but using one of the languages is
likely to provide an improved user experience.
[XML]言語Identificationに従うLanguageコードのLangPrefList Optionalリスト。 それは示す送付者によって使用されます、好みの系列で、応答を生成するときメッセージの受信機が理想的に使用するはずである言語。 示された言語の1つを使用することで応じるために、受信機の上に義務は全くありませんが、言語の1つを使用するのは改良されたユーザー・エクスペリエンスを提供しそうです。
CharSetPrefList Optional list of Character Set identifiers
that conform to [XML] Characters. It is used
by the sender to indicate, in preference
sequence, the character sets that the receiver
of the message ideally should use when
generating a response. There is no obligation
on the receiver to respond using one of the
character sets indicated, but using one of the
character sets is likely to provide an
improved user experience.
[XML]キャラクターに従う文字コード識別子のCharSetPrefList Optionalリスト。 それは示す送付者によって使用されます、好みの系列で、応答を生成するときメッセージの受信機が理想的に使用するはずである文字集合。 文字集合のひとりが示した使用を反応させるために、受信機の上に義務は全くありませんが、文字集合の1つを使用するのは改良されたユーザー・エクスペリエンスを提供しそうです。
SoftwareId This contains information which identifies the
software which generated the IOTP Message. Its
purpose is to help resolve interoperability
problems that might occur as a result of
incompatibilities between messages produced by
different software. It is a single text string
in the language defined by xml:lang. It must
contain, as a minimum:
SoftwareId ThisはIOTP Messageを生成したソフトウェアを特定する情報を含んでいます。 目的は異なったソフトウェアによって出されたメッセージの間の非互換性の結果、起こるかもしれない相互運用性問題を解決するのを助けることです。 xmlによって定義された言語でそれはただ一つのテキスト文字列です: lang。 それは最小限として以下を含まなければなりません。
Burdett Informational [Page 40] RFC 2801 IOTP/1.0 April 2000
バーデット[40ページ]情報のRFC2801IOTP/2000年4月1日
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
o ソフトウェア製造業者oの名前、ソフトウェアの名前、○ ○ ソフトウェアのバージョン、およびソフトウェアの体格
TimeStamp Where the device sending the message has an
internal clock, it is set to the time at which
the IOTP Message was created in [UTC] format.
TimeStamp Where、メッセージを送るデバイスは内部クロックを持って、IOTP Messageが[UTC]形式で作成された時に設定されます。
3.3.3 Related To Component
3.3.3 コンポーネントに関連されました。
The Related To Component links IOTP Transactions to either other IOTP Transactions or other events using the identifiers of those events. Its definition is as follows.
関連To Componentは、それらのイベントに関する識別子を使用することで他のIOTP Transactionsかイベントのどちらかに他のIOTP Transactionsをリンクします。 定義は以下の通りです。
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED >
<!ELEMENT RelatedTo(PackagedContent)><!ATTLIST RelatedTo ID ID#REQUIRED xml: lang NMTOKEN#REQUIRED RelationshipType NMTOKEN#REQUIRED Relation CDATA#REQUIRED RelnKeyWords NMTOKENS#IMPLIED>。
Attributes:
属性:
ID An identifier which uniquely identifies the
Related To Component within the IOTP Transaction.
IOTP Transactionの中で唯一関連To Componentを特定するID An識別子。
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages.
xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
RelationshipType Defines the type of the relationship. Valid values
are:
関係のタイプのRelationshipType Defines。 有効値は以下の通りです。
o IotpTransaction. in which case the Packaged
Content Element contains an IotpTransId of
another IOTP Transaction
o Reference in which case the Packaged Content
Element contains the reference of some other,
non-IOTP document.
o Packaged Content Elementがどのケースについて参照を含むかにIotpTransaction Packaged Content Elementをケースに入れるコネが別のIOTP Transaction o ReferenceのIotpTransIdを含んでいる、ある他の非IOTPドキュメント。
Values of RelationshipType are controlled under
the procedures defined in section 12 IANA
Considerations which also allows user defined
values to be defined.
RelationshipTypeの値はまた、ユーザの定義された値が定義されるのを許容するセクション12IANA Considerationsで定義された手順の下で制御されます。
Burdett Informational [Page 41] RFC 2801 IOTP/1.0 April 2000
バーデット[41ページ]情報のRFC2801IOTP/2000年4月1日
Relation The Relation attribute contains a phrase in the
language defined by xml:lang which describes the
nature of the relationship between the IOTP
transaction that contains this component and
another IOTP Transaction or other event. The exact
words to be used are left to the implementers of
the IOTP software.
Relationが結果と考える関係はxmlによって定義された言語の句を含んでいます: 別のこのコンポーネントを含むIOTPトランザクションとIOTP Transactionか他のイベントとの関係の本質について説明するlang。 使用されるべき正確な知らせはIOTPソフトウェアのimplementersに残されます。
The purpose of the attribute is to provide the
Trading Roles involved in an IOTP Transaction with
an explanation of the nature of the relationship
between the transactions.
属性の目的はトランザクションの間の関係の本質に関する説明をIOTP TransactionにかかわるTrading Rolesに提供することです。
Care should be taken that the words used to in the
Relation attribute indicate the "direction" of the
relationship correctly. For example: one
transaction might be a refund for another earlier
transaction. In this case the transaction which is
a refund should contain in the Relation attribute
words such as "refund for" rather than "refund to"
or just "refund".
注意するべきです。単語は以前は正しくRelation属性で関係の「方向」をよく示していました。 例えば: 1つのトランザクションは別の以前のトランザクションのための還付であるかもしれません。 この場合還付であるトランザクションがRelationが単語を結果と考えるコネを含むべきである、「還付、」、むしろ、「」 まさしく「還付」に還付します。
RelnKeyWords This attribute contains keywords which could be
used to help identify similar relationships, for
example all refunds. It is anticipated that
recommended keywords will be developed through
examination of actual usage. In this version of
the specification there are no specific
recommendations and the keywords used are at the
discretion of implementers.
RelnKeyWords This属性は同様の関係、例えばすべての還付を特定するのを助けるのに使用できたキーワードを含んでいます。 お勧めのキーワードが実際の用法の試験で開発されると予期されます。 仕様のこのバージョンには、どんな特定の推薦もありません、そして、implementersの裁量には使用されるキーワードがあります。
Content:
内容:
PackagedContent The Packaged Content (see section 3.7) contains
data which identifies the related transaction. Its
format varies depending on the value of the
RelationshipType.
PackagedContent Packaged Content(セクション3.7を見る)は関連するトランザクションを特定するデータを含んでいます。 RelationshipTypeの値によって、形式は異なります。
3.4 ID Attributes
3.4 ID属性
IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading Blocks), Trading Components (including the Transaction Id Component and the Signature Component) and some of their child elements are each given an XML "ID" attribute which is used to identify an instance of these XML elements. These identifiers are used so that one element can be referenced by another. All these attributes are given the attribute name ID.
これらのXML要素のインスタンスを特定するのに使用されるXML「ID」属性を考えて、IOTP Messages、Blocks(すなわち、Transaction Reference BlocksとTrading Blocks)、Trading Components(Transaction Id ComponentとSignature Componentを含んでいる)、および彼らのいくつかの子供要素がそれぞれです。 これらの識別子は、別のものが1つの要素に参照をつけることができるように、使用されています。 IDという属性名をこれらのすべての属性に与えます。
Burdett Informational [Page 42] RFC 2801 IOTP/1.0 April 2000
バーデット[42ページ]情報のRFC2801IOTP/2000年4月1日
The values of each ID attribute are unique within an IOTP transaction i.e. the set of IOTP Messages which have the same globally unique Transaction ID Component. Also, once the ID attribute of an element has been assigned a value it is never changed. This means that whenever an element is copied, the value of the ID attribute remains the same.
それぞれのID属性の値はIOTPトランザクションの中でユニークです。すなわち、同じグローバルにユニークなTransaction ID Componentを持っているIOTP Messagesのセット。 また、いったん要素のID属性に値を割り当てると、それを決して変えません。 これは、要素がコピーされるときはいつも、ID属性の値が同じままで残っていることを意味します。
As a result it is possible to use these IDs to refer to and locate the content of any IOTP Message, Block or Component from any other IOTP Message, Block or Component in the same IOTP Transaction using Element References (see section 3.5).
その結果、同じIOTP TransactionのElement Referencesを使用するどんなIOTP Messageの内容、いかなる他のIOTP MessageからのBlockかComponent、BlockまたはComponentも示して、場所を見つけるのにこれらのIDを使用するのは可能です(セクション3.5を見てください)。
This section defines the rules for setting the values for the ID attributes of IOTP Messages, Blocks and Components.
このセクションは、IOTP Messages、Blocks、およびComponentsのID属性に値を設定するために規則を決めます。
3.4.1 IOTP Message ID Attribute Definition
3.4.1 IOTPメッセージID属性定義
The ID attribute of the Message Id Component of an IOTP Message must be unique within an IOTP Transaction. It's definition is as follows:
IOTP MessageのMessage Id ComponentのID属性はIOTP Transactionの中でユニークであるに違いありません。 定義は以下の通りということです:
IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix IotpMsgIdPrefix ::= NameChar (NameChar)* IotpMsgIdSuffix ::= Digit (Digit)*
IotpMsgId_は以下を評価します:= IotpMsgIdPrefix IotpMsgIdSuffix IotpMsgIdPrefix:、:= NameChar(NameChar)*IotpMsgIdSuffix:、:= ケタ(ケタ)*
IotpMsgIdPrefix Apart from messages which contain: an Inquiry
Request Trading Block, an Inquiry Response Trading
Block, a Ping Request Trading Block or a Ping
Response Trading Block; then the same prefix is
used for all messages sent by the Merchant or
Consumer role as follows:
以下を含むメッセージからのIotpMsgIdPrefix Apart 問い合せ要求通商圏、問い合せ応答通商圏、ピング要求通商圏またはピング応答通商圏。 次に、同じ接頭語は以下のマーチャントかConsumerの役割によって送られたすべてのメッセージに使用されます:
o "M" - Merchant
o "C" - Consumer
o 「M」--商人o「C」--消費者
For messages which contain an Inquiry Request
Trading Block or a Ping Request Trading Block, the
prefix is set to "I" for Inquiry.
Inquiry Request Trading BlockかPing Request Trading Blockを含むメッセージにおいて、接頭語は問い合せのために「私」に設定されます。
For messages which contain an Inquiry Response
Trading Block or a Ping Response Trading Block,
the prefix is set to "Q".
Inquiry Response Trading BlockかPing Response Trading Blockを含むメッセージにおいて、接頭語は「Q」に設定されます。
The prefix for the other roles in a trade is
contained within the Organisation Component for
the role and are typically set by the Merchant.
The following is recommended as a guideline and
must not be relied upon:
取り引きにおける他の役割のための接頭語は、役割のためのOrganisation Componentの中に含まれていて、マーチャントによって通常設定されています。 以下をガイドラインとしてお勧めであり、当てにされてはいけません:
Burdett Informational [Page 43] RFC 2801 IOTP/1.0 April 2000
バーデット[43ページ]情報のRFC2801IOTP/2000年4月1日
o "P" - First (only) Payment Handler
o "R" - Second Payment Handler
o "D" - Delivery Handler
o "C" - Deliver To
o 「P」--Handler o「R」--2番目の支払い操作者o「D」(配送操作者o「C」)が配送する最初(単に)の支払い
As a guideline, prefixes should be limited to one
character.
ガイドラインとして、接頭語は1つのキャラクタに制限されるべきです。
NameChar has the same definition as the [XML]
definition of NameChar.
NameCharには、NameCharの[XML]定義と同じ定義があります。
IotpMsgIdSuffix The suffix consists of one or more digits. The
suffix must be unique within a Trading Role within
an IOTP Transaction. The following is recommended
as a guideline and must not be relied upon:
IotpMsgIdSuffix、接尾語は複数のケタから成ります。 接尾語はIOTP Transactionの中のTrading Roleの中でユニークであるに違いありません。 以下をガイドラインとしてお勧めであり、当てにされてはいけません:
o the first IOTP Message sent by a trading role
is given the suffix "1"
o the second and subsequent IOTP Messages sent
by the same trading role are incremented by one
for each message
o no leading zeroes are included in the suffix
o 取り引き役割によって送られた最初のIOTP Messageによる接尾語を考えて、「2番目の、そして、その後のIOTPメッセージが同じ取り引き役割で送った1インチoはどんな主なゼロも接尾語に含まれていないという各メッセージoあたり1つ増加される」ということです。
Put more simply the Message Id Component of the
first IOTP Message sent by a Consumer would have
an ID attribute of, "C1", the second "C2", the
third "C3" etc.
より単に置かれて、Consumerによって送られた最初のIOTP MessageのMessage Id ComponentにはID属性があるだろう、「C1"、2番目、「C2"、3番目の「C3"など」
Digit has the same definition as the [XML]
definition of Digit.
ケタには、Digitの[XML]定義と同じ定義があります。
3.4.2 Block and Component ID Attribute Definitions
3.4.2 ブロックとコンポーネントID属性定義
The ID Attribute of Blocks and Components must also be unique within an IOTP Transaction. Their definition is as follows:
また、BlocksとComponentsのID AttributeもIOTP Transactionの中でユニークであるに違いありません。 彼らの定義は以下の通りです:
BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix IdSuffix ::= Digit (Digit)*
BlkOrCompId_は以下を評価します:= 「IotpMsgId_値」、」 IdSuffix IdSuffix:、:= ケタ(ケタ)*
IotpMsgId_value The ID attribute of the Message ID Component of
the IOTP Message where the Block or Component is
first used.
IotpMsgId_はBlockかComponentが最初に使用されるIOTP MessageのMessage ID ComponentのID属性を評価します。
In IOTP, Trading Components and Trading Blocks are
copied from one IOTP Message to another. The ID
attribute does not change when an existing Trading
Block or Component is copied to another IOTP
Message.
IOTPでは、Trading ComponentsとTrading Blocksは1IOTP Messageから別のIOTP Messageまでコピーされます。 ID属性は、既存のTrading BlockかComponentがいつ別のIOTP Messageにコピーされるかを変えません。
Burdett Informational [Page 44] RFC 2801 IOTP/1.0 April 2000
バーデット[44ページ]情報のRFC2801IOTP/2000年4月1日
IdSuffix The suffix consists of one or more digits. The
suffix must be unique within the ID attribute of
the Message ID Component used to generate the ID
attribute. The following is recommended as a
guideline and must not be relied upon:
IdSuffix、接尾語は複数のケタから成ります。 接尾語はID属性を生成するのに使用されるMessage ID ComponentのID属性の中でユニークであるに違いありません。 以下をガイドラインとしてお勧めであり、当てにされてはいけません:
o the first Block or Component sent by a trading
role is given the suffix "1"
o the ID attributes of the second and subsequent
Blocks or Components are incremented by one for
each new Block or Component added to an IOTP
Message
o no leading zeroes are included in the suffix
o 取り引き役割によって送られた最初のBlockかComponentがそう、「1インチoに、秒とその後のブロックかコンポーネントのID属性がそれぞれの新しいブロック単位の1つ増加されたか、またはコンポーネントは、どんな主なゼロも接尾語に含まれていないとIOTPメッセージoに追加したこと」を接尾語に与えます。
Put more simply, the first new Block or Component
added to the second IOTP Message sent, for
example, by a consumer would have a an ID
attribute of "C2.1", the second "C2.2", the third
"C2.3" etc.
より単に置かれて、例えば消費者が送られた第2IOTP Messageに加えられた最初の新しいBlockかComponentがaを持っているだろう、ID属性、「C2.1"、2番目、「C2.2"、3番目の「C2.3"など」
Digit has the same definition as the [XML]
definition of Digit.
ケタには、Digitの[XML]定義と同じ定義があります。
Burdett Informational [Page 45] RFC 2801 IOTP/1.0 April 2000
バーデット[45ページ]情報のRFC2801IOTP/2000年4月1日
3.4.3 Example of use of ID Attributes
3.4.3 ID Attributesで役に立つ例
The diagram below illustrates how ID attribute values are used.
以下のダイヤグラムはID属性値がどう使用されているかを例証します。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st IOTP MESSAGE 2nd IOTP MESSAGE
(e.g., from Merchant to (e.g., from Consumer to
Consumer Payment Handler)
最初のIOTPメッセージ第2IOTPメッセージ、(例えば、商人(例えば、消費者から消費者支払い操作者までの)
IOTP MESSAGE IOTP MESSAGE *
|-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1*
| |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp.
| | Copy Element | | ID=M1.2
| |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 *
| |
|-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5*
| |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15
| Copy Element |
|-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 *
| |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4
| | Copy Element |
| |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5
| | Copy Element |
| |-Comp. ID=M1.6 |-Comp. ID=C1.3 *
| |-Comp. ID=M1.7 |-Comp. ID=C1.4 *
|
|-Trading Block. ID=M1.9
|-Comp. ID=M1.10 * = new elements
|-Comp. ID=M1.11
|-Comp. ID=M1.12
|-Comp. ID=M1.13
IOTPメッセージIOTPメッセージ*|-移-審判ブロック。 IDはM1.1と等しいです。|-移-審判Block.ID=C1.1*| |-移-イドコンピュータ。 IDはM1.2と等しいです。------------>| |-移-イドコンピュータ。 | | コピー要素| | IDはM1.2と等しいです。| |-エムエスジーイドコンピュータ。 IDはM1と等しいです。| |-エムエスジーイドコンピュータ。 IDはC1*と等しいです。| | |-署名欄。 IDはM1.8と等しいです。|-Signature Block.ID=C1.5*| |-Sigコンピュータ。 IDはM1.15と等しいです。------------------>| |-コンピュータ。 IDはM1.15と等しいです。| コピー要素| |-ブロックを取り引きします。 IDはM1.3と等しいです。|-Trading Block.ID=C1.2*| |-コンピュータ。 IDはM1.4と等しいです。-------------------------->|、-コンピュータ。 IDはM1.4と等しいです。| | コピー要素| | |-コンピュータ。 IDはM1.5と等しいです。-------------------------->|、-コンピュータ。 IDはM1.5と等しいです。| | コピー要素| | |-コンピュータ。 IDはM1.6と等しいです。|-コンピュータ。 IDはC1.3*と等しいです。| |-コンピュータ。 IDはM1.7と等しいです。|-コンピュータ。 IDはC1.4*と等しいです。| |-ブロックを取り引きします。 IDはM1.9と等しいです。|-コンピュータ。 ID=M1.10*は新しい要素と等しいです。|-コンピュータ。 IDはM1.11と等しいです。|-コンピュータ。 IDはM1.12と等しいです。|-コンピュータ。 IDはM1.13と等しいです。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 8 Example use of ID attributes
ID属性のエイト環Example使用
3.5 Element References
3.5 要素参照
A Trading Component or one of its child XML elements, may contain an XML attribute that refers to another Block (i.e. a Transaction Reference Block or a Trading Block) or Trading Component (including a Transaction Id and Signature Component). These Element References are used for many purposes, a few examples include:
Trading Componentか子供XML要素の1つ、別のBlock(すなわち、Transaction Reference BlockかTrading Block)かTrading Componentについて言及するXML属性を含むかもしれません(Transaction IdとSignature Componentを含んでいて)。 これらのElement Referencesは多くの目的に使用されて、いくつかの例は:
o identifying an XML element whose Digest is included in a Signature
Component,
o DigestがSignature Componentに含まれているXML要素を特定します。
Burdett Informational [Page 46] RFC 2801 IOTP/1.0 April 2000
バーデット[46ページ]情報のRFC2801IOTP/2000年4月1日
o referring to the Payment Handler Organisation Component which is
used when making a Payment
o Paymentを作るとき使用されたPayment Handler Organisation Componentについて言及します。
An Element Reference always contains the value of an ID attribute of a Block or Component.
Element ReferenceはいつもBlockかComponentのID属性の値を含んでいます。
Identifying the IOTP Message, Trading Block or Trading Component which is referred to by an Element Reference, involves finding the XML element which:
Element Referenceによって言及されるIOTP Message、Trading BlockまたはTrading Componentを特定するのが、XML要素を見つけることを伴う、どれ、:
o belongs to the same IOTP Transaction (i.e. the Transaction Id
Components of the IOTP Messages match), and
o そして同じIOTP Transaction(すなわち、IOTP MessagesのTransaction Id Componentsは合っている)に属す。
o where the value of the ID attribute of the element matches the
value of the Element Reference.
o 要素のID属性の値がElement Referenceの値に合っているところ。
Note: The term "match" in this specification has the same definition as the [XML] definition of match.
以下に注意してください。 「マッチ」というこの仕様による用語には、マッチの[XML]定義と同じ定義があります。
An example of "matching" an Element Reference is illustrated in the example below.
Element Referenceの「マッチ」である例は以下の例で例証されます。
Burdett Informational [Page 47] RFC 2801 IOTP/1.0 April 2000
バーデット[47ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st IOTP MESSAGE 2nd IOTP MESSAGE
(e.g., from Merchant to (e.g., from Consumer to
Consumer Payment Handler)
最初のIOTPメッセージ第2IOTPメッセージ、(例えば、商人(例えば、消費者から消費者支払い操作者までの)
IOTP MESSAGE IOTP MESSAGE
|-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1
| |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2
| | must be | |
| |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1
| ^ |
|-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5
| |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15
| AND |
|-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2
| |-Comp. ID=M1.4 | |-Comp. ID=M1.4
| | v |
| |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5
| | and El Ref |
| |-Comp. ID=M1.6 values must |-Comp. ID=C1.3
| | match--------|--> El Ref=M1.5
| |-Comp. ID=M1.7 |-Comp. ID=C1.4
|
|-Trading Block. ID=M1.9
|-Comp. ID=M1.10
|-Comp. ID=M1.11
|-Comp. ID=M1.12
|-Comp. ID=M1.13
IOTPメッセージIOTPメッセージ|-移-審判ブロック。 IDはM1.1移-IDと等しいです。|-移-RefBlock。 IDはC1.1と等しいです。| |-移-イドコンピュータ。 IDがM1.2の<-部品と等しい、-|、-、>|、-トランザクション識別子Comp.ID=M1.2| | あるに違いありません。| | | |-エムエスジーイドコンピュータ。 IDはM1と同じ状態で等しいです。| |-エムエスジーイドコンピュータ。 IDはC1と等しいです。| ^ | |-署名欄。 IDはM1.8と等しいです。| |-Signature Block.ID=C1.5| |-Sigコンピュータ。 IDはM1.15と等しいです。| | |-コンピュータ。 IDはM1.15と等しいです。| AND| |-ブロックを取り引きします。 IDはM1.3と等しいです。| |-ブロックを取り引きします。 IDはC1.2と等しいです。| |-コンピュータ。 IDはM1.4と等しいです。| |-コンピュータ。 IDはM1.4と等しいです。| | v| | |-コンピュータ。 IDはM1.5<と等しいです。-------- -ID属性|-コンピュータ。 IDはM1.5と等しいです。| | そして、高架鉄道審判| | |-コンピュータ。 M1.6ID=値はそうしなければなりません。|-コンピュータ。 IDはC1.3と等しいです。| | マッチ--------|-->高架鉄道審判=M1.5| |-コンピュータ。 IDはM1.7と等しいです。|-コンピュータ。 IDはC1.4と等しいです。| |-ブロックを取り引きします。 IDはM1.9と等しいです。|-コンピュータ。 IDはM1.10と等しいです。|-コンピュータ。 IDはM1.11と等しいです。|-コンピュータ。 IDはM1.12と等しいです。|-コンピュータ。 IDはM1.13と等しいです。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 9 Element References
図9 要素参照
Note: Element Reference attributes are defined as "NMTOKEN" rather than "IDREF" (see [XML]). This is because an IDREF requires that the XML element referred to is in the same XML Document. With IOTP this is not necessarily the case.
以下に注意してください。 要素Reference属性は"IDREF"よりむしろ"NMTOKEN"と定義されます([XML]を見てください)。 これはIDREFが、示されたXML要素が同じXML Documentにあるのを必要とするからです。 IOTPと共に、これは必ずそうであるというわけではありません。
3.6 Extending IOTP
3.6 IOTPを広げること。
Baseline IOTP defines a minimum protocol which systems supporting IOTP must be able to accept. As new versions of IOTP are developed, additional types of IOTP Transactions will be defined. In addition to this, Baseline and future versions of IOTP will support user extensions to IOTP through two mechanisms:
基線IOTPはIOTPをサポートするシステムが受け入れることができなければならない最小のプロトコルを定義します。 IOTPの新しいバージョンがIOTP Transactionsの開発されて、追加しているタイプが定義されるということであるので。 これに加えて、IOTPのBaselineと将来のバージョンは2つのメカニズムを通してIOTPへの拡大をユーザにサポートするでしょう:
Burdett Informational [Page 48] RFC 2801 IOTP/1.0 April 2000
バーデット[48ページ]情報のRFC2801IOTP/2000年4月1日
o extra XML elements, and
o そして付加的なXML要素。
o new values for existing IOTP codes.
o 既存のIOTPコードのための新しい値。
3.6.1 Extra XML Elements
3.6.1 付加的なXML Elements
The XML element and attribute names used within IOTP constitute an [XML Namespace] as identified by the xmlns attribute on the IotpMessage element. This allows IOTP to support the inclusion of additional XML elements within IOTP messages through the use of [XML Namespaces].
IOTPの中で使用されたXML要素と属性名はIotpMessage要素のxmlns属性によって特定されるように[XML Namespace]を構成します。 これで、IOTPはIOTPメッセージの中で[XML Namespaces]の使用で追加XML要素の包含をサポートすることができます。
Using XML Namespaces, extra XML elements may be included at any level within an IOTP message including:
XML Namespacesを使用して、含まれていて、:付加的なXML要素はIOTPメッセージの中のどんなレベルでも含まれるかもしれません。
o new Trading Blocks
o 新しいTrading Blocks
o new Trading Components
o 新しいTrading Components
o new XML elements within a Trading Component.
o Trading Componentの中の新しいXML要素。
The following rules apply:
以下の規則は適用されます:
o any new XML element must be declared according to the rules for
[XML Namespaces]
o 規則に従って、どんな新しいXML要素も申告しなければなりません。[XML名前空間]
o new XML elements which are either Trading Blocks or Trading
Components must contain an ID attributes with an attribute name of
ID.
o Trading BlocksかTrading Componentsのどちらかである新しいXML要素はIDの属性名があるID属性を含まなければなりません。
In order to make sure that extra XML elements can be processed properly, IOTP reserves the use of a special attribute, IOTP:Critical, which takes the values True or False and may appear in extra elements added to an IOTP message.
付加的なXML要素缶が適切に処理されるのを確実にするために、IOTPは特別な属性の使用を控えます、IOTP:、重要である、どれが値のTrueかFalseを取って、付加的な要素に現れるかもしれないかはIOTPメッセージに加えました。
The purpose of this attribute is to allow an IOTP aware application to determine if the IOTP transaction can safely continue. Specifically:
この属性の目的はIOTPの意識しているアプリケーションが、IOTPトランザクションが安全に続くことができるかどうか決定するのを許容することです。 明確に:
o if an extra XML element has an "IOTP:Critical" attribute with a
value of "True" and an IOTP aware application does not know how to
process the element and its child elements, then the IOTP
transaction has a Technical Error (see section 4.1) and must fail.
o 付加的なXML要素がそうした、「IOTP:、重要である、」 「本当」の値とIOTPの意識しているアプリケーションがある属性が要素とその子供要素を処理する方法を知らないで、次に、IOTPトランザクションは、Technical Error(セクション4.1を見る)を持って、失敗しなければなりません。
o if an extra XML element has an "IOTP:Critical" attribute with a
value of "False" then the IOTP transaction may continue if the
IOTP aware application does not know how to process it. In this
case:
o 付加的なXML要素がそうした、「IOTP:、重要である、」 「偽」の値で、IOTPの意識しているアプリケーションがそれを処理する方法を知らないなら、IOTPトランザクションが続けるかもしれないその時を結果と考えてください。 この場合:
Burdett Informational [Page 49] RFC 2801 IOTP/1.0 April 2000
バーデット[49ページ]情報のRFC2801IOTP/2000年4月1日
- any extra XML elements contained within an XML element defined
within the IOTP namespace, must be included with that element
whenever the IOTP XML element is used or copied by IOTP
- どんな付加的なXML要素もIOTP名前空間の中で定義されたXML要素の中に含まれなければならないか、IOTP XML要素が使用されているときはいつも、その要素で含まれなければならないか、またはIOTPはコピーしなければなりません。
- the content of the extra element must be ignored except that it
must be included when it is used in the creation of a digest as
part of the generation of a signature
- それが署名の世代の一部としてダイジェストの作成に使用されるとき、それを含まなければならないのを除いて、付加的な要素の内容を無視しなければなりません。
o if an extra XML element has no "IOTP:Critical" attribute then it
must be treated as if it had an "IOTP:Critical" attribute with a
value of "True"
o 付加的なXML要素でいいえがある、「IOTP:、重要である、」、まるで結果と考えたかのように扱われた状態でその時でなければならないことを結果と考えてください、「IOTP:、重要である、」 「本当」の値がある属性
o if an XML element contains an "IOTP:Critical" attribute, then the
value of that attribute is assumed to apply to all the child
elements within that element
o XML要素が含んでいる、「IOTP:、重要である、」 属性、そして、その属性の値がその要素の中のすべての子供要素に適用すると思われます。
In order to ensure that documents containing "IOTP:Critical" are valid, it is declared as part of the DTD for the extra element as:
その書類含有を確実にする、「IOTP:、重要である、」、有効です、それが以下としての付加的な要素のためにDTDの一部として宣言されるということです。
IOTP:Critical (True | False ) 'True'
IOTP:、重要である、(本当である、| 偽) '本当に'
3.6.2 Opaque Embedded Data
3.6.2 不明瞭な埋め込まれたデータ
If IOTP is to be extended using Opaque Embedded Data then a Packaged Content Element (see section 3.7) should be used to encapsulate the data.
IOTPがOpaque Embedded Dataを使用することで広げられるつもりであるなら、Packaged Content Element(セクション3.7を見る)は、データをカプセル化するのに使用されるべきです。
3.7 Packaged Content Element
3.7 パッケージされた満足している要素
The Packaged Content element supports the concept of an embedded data stream, transformed to both protect it against misinterpretation by transporting systems and to ensure XML compatibility. Examples of its use in IOTP include:
Packaged Content要素はシステムを輸送することによって誤解に対してそれを保護して、XMLに互換性を確実にするために変えられた埋め込まれたデータ・ストリームの概念をサポートします。 IOTPにおける使用に関する例は:
o to encapsulate payment scheme messages, such as SET messages,
o 支払いをカプセル化するには、SETメッセージなどのメッセージを計画してください。
o to encapsulate a description of an order, a payment note, or a
delivery note.
o オーダー、支払い紙幣、または納品受領書の記述をカプセル化するために。
In general it is used to encapsulate one or more data streams.
一般に、それは、1つ以上のデータがストリームであるとカプセル化するのに使用されます。
This data stream has three standardised attributes that allow for identification, decoding and interpretation of the contents. Its definition is as follows.
このデータ・ストリームには、コンテンツの識別、解読、および解釈を考慮する3つの標準化された属性があります。 定義は以下の通りです。
Burdett Informational [Page 50] RFC 2801 IOTP/1.0 April 2000
バーデット[50ページ]情報のRFC2801IOTP/2000年4月1日
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent
Name CDATA #IMPLIED
Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" >
ATTLIST PackagedContentがCDATA#暗示している内容NMTOKEN"PCDATA"変換(なにも| BASE64)「なにも」>と命名する<!要素PackagedContent(#PCDATA)><!
Attributes:
属性:
Name Optional. Distinguishes between multiple
occurrences of Packaged Content Elements at the
same point in IOTP. For example:
<ABCD>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
</PackagedContent>
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
名前任意です。 IOTPの同じポイントでPackaged Content Elementsの複数の発生を見分けます。 例えば: <ABCD><PackagedContent Nameは'FirstPiece'>snroasdfnas934k</PackagedContent><PackagedContent Nameは'SecondPiece'>dvdsjnl5poidsdsflkjnw45</PackagedContent></ABCD>と等しいこと'と等しいです。
The name attribute may be omitted, for example if
there is only one Packaged Content element.
例えば、1つのPackaged Content要素しかなければ、名前属性は省略されるかもしれません。
Content This identifies what type of data is contained
within the Content of the Packaged Content
Element. The valid values for the Content
attribute are as follows:
o PCDATA. The content of the Packaged Content
Element can be treated as PCDATA with no
further processing.
o MIME. The content of the Packaged Content
Element is a complete MIME item. Processing
should include looking for MIME headers inside
the Packaged Content Element.
o MIME:mimetype. The content of the Packaged
Content Element is MIME content, with the
following header "Content-Type: mimetype".
Although it is possible to have MIME:mimetype
with the Transform attribute set to NONE, it is
far more likely to have Transform attribute set
to BASE64. Note that if Transform is NONE is
used, then the entire content must still
conform to PCDATA. Some characters will need to
be encoded either as the XML default entities,
or as numeric character entities.
内容Thisは、どんなタイプに関するデータがPackaged Content ElementのContentの中に含まれているかを特定します。 Content属性のための有効値は以下の通りです: o PCDATA。 さらなる処理o MIMEなしでPackaged Content Elementの内容をPCDATAとして扱うことができます。 Packaged Content Elementの内容は完全なMIME項目です。 処理は、Packaged Content Elementの中でMIMEヘッダーを探すのを含むべきです。. o MIME: mimetype。 Packaged Content Elementの内容が以下のヘッダーがあるMIME内容である、「コンテントタイプ:」 "mimetype"。 MIME: Transform属性があるmimetypeをNONEにセットさせるのが、可能ですが、おそらく、Transform属性をBASE64に設定させるのは遠いです。 TransformであるならNONEである注意が使用されている、そして、全体の内容はまだPCDATAに従わなければなりません。 何人かのキャラクタが、XMLデフォルト実体として、または、数字実体としてコード化される必要があるでしょう。
Burdett Informational [Page 51] RFC 2801 IOTP/1.0 April 2000
バーデット[51ページ]情報のRFC2801IOTP/2000年4月1日
o XML. The content of the Packaged Content
Element can be treated as an XML document.
Entities and CDATA sections, or Transform set
to BASE64, must be used to ensure that the
Packaged Content Element contents are
legitimate PCDATA.
o XML。 XMLドキュメントとしてPackaged Content Elementの内容を扱うことができます。 Packaged Content Element内容が正統のPCDATAであることを保証するのに実体とCDATA部か、BASE64に用意ができているTransformを使用しなければなりません。
Values of the Content attribute are controlled
under the procedures defined in section 12 IANA
Considerations which also allows user defined
values to be defined.
Content属性の値はまた、ユーザの定義された値が定義されるのを許容するセクション12IANA Considerationsで定義された手順の下で制御されます。
Transform This identifies the transformation that has been
done to the data before it was placed in the
content. Valid values are:
変換Thisはそれが内容に置かれる前にデータに行われた変換を特定します。 有効値は以下の通りです。
o NONE. The PCDATA content of the Packaged
Content Element is the correct representation
of the data. Note that entity expansion must
occur first (i.e. replacement of & and
	) before the data is examined. CDATA
sections may legitimately occur in a Packaged
Content Element where the Transform attribute
is set to NONE.
o BASE64. The PCDATA content of the Packaged
Content Element represents a BASE64 encoding of
the actual content.
o なし。 Packaged Content ElementのPCDATA内容はデータの正しい表現です。 データが調べられる前に実体拡張が最初に(すなわち、&と の交換)起こらなければならないことに注意してください。 CDATA部はTransform属性がNONE o BASE64に設定されるPackaged Content Elementに合法的に現れるかもしれません。 Packaged Content ElementのPCDATA内容は実際の内容をコード化するBASE64を表します。
Content:
内容:
PCDATA This is the actual data which has been embedded.
The format of the data and rules on how to decode
it are contained in the Content and the Transform
attributes
PCDATA Thisは埋め込まれている実際のデータです。 データの形式とどうそれを解読するかに関する規則はContentとTransform属性に含まれています。
Note that any special details, especially custom attributes, must be represented at a higher level.
より高いレベルでどんな特別な詳細(特にカスタムの属性)も表さなければならないことに注意してください。
3.7.1 Packaging HTML
3.7.1 パッケージHTML
The packaged content may contain HTML. In this case the following conventions are followed:
パッケージされた内容はHTMLを含むかもしれません。 この場合、以下のコンベンションは続かれています:
o references to any documents, images or other things, such as
sounds or web pages, which can affect the recipient's
understanding of the data which is being packaged must refer to
other Packaged Elements contained within the same parent element,
e.g., an Order Description
o どんなドキュメントの参照、受取人のパッケージされているデータの理解に影響できる音やウェブページなどのイメージか他のものが同じ親元素の中に含まれた状態で他のPackaged Elementsについて言及しなければなりません、例えば、Order記述
Burdett Informational [Page 52] RFC 2801 IOTP/1.0 April 2000
バーデット[52ページ]情報のRFC2801IOTP/2000年4月1日
o if more than one Packaged Content element is included within a
parent element in order to meet the previous requirement, then the
Name attribute of the top level Packaged Content from which
references to all other Packaged Elements can be determined,
should have a value of Main
o 1つ以上のPackaged Content要素が会うために親元素の中に含まれているなら、前の要件(当時の他のPackaged Elementsについての言及が決定できる最高平らなPackaged ContentのName属性)には、Mainの値があるべきです。
o relative references to other documents, images, etc. from one
Packaged Content element to another are realised by setting the
value of the relative reference to the Name attribute of another
Packaged Content element at the same level and within the same
parent element
o 他のドキュメント、1つのPackaged Content要素から別の要素までのイメージなどの相対参照は、同じレベルにおいて同じ親元素の中に別のPackaged Content要素のName属性の相対参照の値を設定することによって、わかります。
o no external references that require the reference to be resolved
immediately should be used. As this could make the HTML difficult
or impossible to display completely
o 参照がすぐに決議されるのを必要とする外部参照を全く使用するべきではありません。 これが、HTMLを完全に表示するのを難しいか不可能にするかもしれないので
o [MIME] is used to encapsulate the data inside each Packaged
Element. This means that the information in the MIME header used
to identify the type of data which has been encapsulated and
therefore how it should be displayed.
o [MIME]は、各Packaged Elementの中でデータをカプセル化するのに使用されます。 これは、MIMEヘッダーの情報が以前はよくカプセル化されたデータとしたがって、どうそれを表示するべきであるかに関するタイプを特定していたことを意味します。
If the above conventions are not followed by, for example, including external references which must be resolved, then the recipient of the HTML should be informed.
例えば、決議しなければならない外部参照を含んでいるのが上のコンベンションのあとに続かないなら、HTMLの受取人は知識があるべきです。
Note: As an implementation guideline the values of the Name Attributes allocated to Packaged Content elements should make it possible to extract each Packaged Content into a directory and then display the HTML directly
以下に注意してください。 Name Attributesの値がPackaged Content要素に割り当てた実施要綱で各Packaged Contentをディレクトリに抽出して、次に、直接HTMLを表示するのが可能になるべきであるとき
3.7.2 Packaging XML
3.7.2 パッケージXML
Support for XML is recommended. When XML needs to be displayed, for example to display the content of an Order Description to a Consumer, then implementers should follow the latest recommendations of the World Wide Web Consortium.
XMLのサポートはお勧めです。 XMLが表示されて、例えばOrder記述の内容をConsumerに表示する必要があると、implementersはワールドワイドウェブコンソーシアムの最新の推薦に続くはずです。
Note: At the time of writing this specification, standards are under development that specify XML style sheets that show how XML documents should be displayed. See:
以下に注意してください。 これを書いている時点でこの仕様、規格はどうXMLドキュメントを表示するべきであるかを示しているXMLスタイルシートを指定する開発中であります。 見ます:
o "Extensible Stylesheet Language (XSL) Specification" at
http://www.w3.org/TR/WD-xsl, and
o そして http://www.w3.org/TR/WD-xsl の「広げることができるスタイルシート言語(XSL)仕様」。
o "Associating stylesheets with XML documents" at
http://www.w3.org/TR/xml-stylesheet.
o http://www.w3.org/TR/xml-stylesheet で「XMLドキュメントにスタイルシートを関連づけます」。
Burdett Informational [Page 53] RFC 2801 IOTP/1.0 April 2000
バーデット[53ページ]情報のRFC2801IOTP/2000年4月1日
Once these standards become W3C "Recommendations", then it is anticipated that this specification will be amended if practical.
一度、これらの規格はW3C「推薦」になって、次に、実用的であるならこの仕様が改正されると予期されます。
3.8 Identifying Languages
3.8 言語を特定すること。
IOTP uses [XML] Language Identification to specify which languages are used within the content and attributes of IOTP Messages.
IOTPは、どの言語がIOTP Messagesの内容と属性の中で使用されるかを指定するのに[XML]言語Identificationを使用します。
The following principles have been used in order to determine which XML elements contain an xml:lang Attributes:
以下の原則はどのXML要素がxml: lang Attributesを含むかを決定するのに使用されました:
o a mandatory xml:lang attribute is contained on every Trading
Component which contains attributes or content which may need to
be displayed or printed in a particular language
o 義務的なxml: lang属性は特定の言語で表示するか、または印刷する必要があるかもしれない属性か内容を含むあらゆるTrading Componentに含まれています。
o an optional xml:lang attribute is included on child elements of
these Trading Components. In this case the value of xml:lang, if
present, overrides the value for the Trading Component.
o 任意のxml: lang属性はこれらのTrading Componentsの子供要素の上に含まれています。 この場合xmlの値: 存在しているなら、langはTrading Componentのために値をくつがえします。
xml:lang attributes which follow these principles are included in the Trading Components and their child XML elements defined in section 7.
xml: これらの原則に従うlang属性が要素がセクション7で定義したTrading Componentsと彼らの子供XMLに含まれています。
A sender of a message, typically a Consumer can indicate a preference for a language, and a character set by specifying a list of preferred languages/character sets in a Message Id Component (see section 3.3.2). Note that there is no obligation on the receiver of such a message to respond using one of the listed languages/character sets as they may not have the technology to be able to do it. It also means that the ability to handle these lists is not a requirement for conformance to this specification. However the ability to respond, for example using one of the stated languages/character sets is likely to provide a better user experience.
メッセージの送付者、通常、ConsumerはMessage Id Componentで都合のよい言語/文字集合のリストを指定することによって、言語、および文字集合のための優先を示すことができます(セクション3.3.2を見てください)。 それらにはそれをできる技術がないかもしれないので記載された言語/文字集合の1つを使用することで応じるそのようなメッセージの受信機の上に義務が全くないことに注意してください。 また、それは、これらのリストを扱う能力がこの仕様への順応のための要件でないことを意味します。 応じる能力、例えば、述べられた言語/文字集合の1つを使用するのが、どのようにそうであっても、提供するために、おそらく、aはユーザー・エクスペリエンスを改善します。
3.9 Secure and Insecure Net Locations
3.9 安全で不安定なネットの位置
IOTP contains several "Net Locations" which identify places where, typically, IOTP Messages may be sent. Net Locations come in two types:
IOTPは通常、IOTP Messagesが送られるかもしれない場所を特定する数個の「ネットの位置」を含んでいます。 ネットLocationsは2つのタイプで登場します:
o "Secure" Net Locations which are net locations where privacy of
data is secured using, for example, encryption methods such as
[SSL/TLS], and
o そしてデータのプライバシーが例えば[SSL/TLS]などの暗号化メソッドを使用することで保証されるネットの位置である「安全な」ネットLocations。
o "Insecure" Net Locations where privacy of data is not assured.
o データのプライバシーが保証されない「不安定な」ネットLocations。
Note that either a Secure Net Location or an Insecure Net Location or both must be present.
SecureネットLocationかInsecureネットLocationか両方のどちらかが存在していなければならないことに注意してください。
Burdett Informational [Page 54] RFC 2801 IOTP/1.0 April 2000
バーデット[54ページ]情報のRFC2801IOTP/2000年4月1日
If only one of the two Net Locations is present, then the one present must be used.
2ネットLocationsの1つだけが存在しているなら、1個のプレゼントを使用しなければなりません。
Where both types of net location are present then either may be used depending on the preference of the sender of the message.
メッセージ送信者の好みによって、ネットの位置の両方のタイプがその時どこに出席しているかは使用されるかもしれません。
3.10 Cancelled Transactions
3.10 取り消されたトランザクション
Any Trading Role involved in an IOTP transaction may cancel that transaction at any time.
IOTPトランザクションにかかわるどんなTrading Roleもいつでも、そのトランザクションを取り消すかもしれません。
3.10.1 Cancelling Transactions
3.10.1 トランザクションを取り消すこと。
IOTP Transactions are cancelled by sending an IOTP message containing just a Cancel Block with an appropriate Status Component to the other Trading Role involved in the Trading Exchange.
IOTP Transactionsは、適切なStatus Componentと共にTrading Exchangeにかかわるもう片方のTrading RoleにまさしくキャンセルBlockを含むIOTPメッセージを送ることによって、取り消されます。
Note: The Cancel Block can be sent asynchronously of any other IOTP Message. Specifically it can be sent either before sending or after receiving an IOTP Message from the other Trading Role
以下に注意してください。 いかなる他のIOTP MessageについてもキャンセルBlockを非同期に送ることができます。 発信する前かもう片方のTrading RoleからIOTP Messageを受けた後に、明確にそれを送ることができます。
If an IOTP Transaction is cancelled during a Trading Exchange (i.e. the interval between sending a "request" block and receiving the matching "response" block) then the Cancel Block is sent to the same location as the next IOTP Message in the Trading Exchange would have been sent.
Trading Exchange(すなわち、「要求」ブロックを送って、合っている「応答」ブロックを受け取るところの間隔)の間、IOTP Transactionを取り消すなら、Trading Exchangeの次のIOTP Messageを送るような同じ位置にキャンセルBlockを送ります。
If a Consumer cancels a transaction after a Trading Exchange has completed (i.e. the "response" block for the Trading Exchange has been received), but before the IOTP Transaction has finished then the Consumer sends a Cancel Block with an appropriate Status Component to the net location identified by the SenderNetLocn or SecureSenderNetLocn contained in the Protocol Options Component (see section 7.1) contained in the TPO Block (see section 8.1) for the transaction. This is normally the Merchant Trading Role.
Trading Exchangeが取り消した後に完成されますが(Trading Exchangeのためのすなわち、「応答」ブロックを受け取りました)、IOTP Transactionが終わる前を除いて、Consumerがトランザクションを取り消すなら、ConsumerはトランザクションのためにTPO Blockに含まれた(セクション8.1を見ます)プロトコルOptions Component(セクション7.1を見る)に含まれたSenderNetLocnかSecureSenderNetLocnによって特定されたネットの位置に適切なStatus ComponentとキャンセルBlockを送ります。 通常、これはマーチャントTrading Roleです。
A Consumer should not send a Cancel Block after the IOTP Transaction has completed. Cancelling a complete transaction should be treated as a technical error.
ConsumerはIOTP Transactionの後のBlockが終了したキャンセルを送るはずがありません。 完全なトランザクションを取り消すのは技術的な誤りとして扱われるべきです。
After cancelling the IOTP Transaction, the Consumer should go to the net location specified by the CancelNetLocn attribute contained in the Trading Role Element for the Organisation that was sent the Cancel Block.
IOTP Transactionを取り消した後に、ConsumerはTrading Role Elementに含まれたCancelNetLocn属性によってキャンセルBlockが送られたOrganisationに指定されたネットの位置まで行くはずです。
A non-Consumer Trading Role should only cancel a transaction:
非消費者Trading Roleはトランザクションを取り消すだけであるはずです:
o after a request block has been received and
o そして要求ブロックを受け取った後。
Burdett Informational [Page 55] RFC 2801 IOTP/1.0 April 2000
バーデット[55ページ]情報のRFC2801IOTP/2000年4月1日
o before the response block has been sent
o 応答ブロックを送る前に
If a non-Consumer Trading Role cancels a transaction at any other time it should be treated by the recipient as an error.
非消費者Trading Roleが他の時ならいつでもトランザクションを取り消すなら、それは誤りとして受取人によって扱われるべきです。
3.10.2 Handling Cancelled Transactions
3.10.2 取り扱いはトランザクションを取り消しました。
If a Cancel Block is received by a Consumer at a point in the IOTP Transaction when cancellation is allowed, then the Consumer should stop the transaction.
キャンセルが許容されているとき、キャンセルBlockがIOTP TransactionのポイントにConsumerによって受け取られるなら、Consumerはトランザクションを止めるはずです。
If a Cancel Block is received by a non-Consumer role, then the Trading Role should anticipate that the Consumer may go to the location specified by the CancelNetLocn attribute contained in the Trading Role Element for the Trading Role.
非消費者の役割でキャンセルBlockを受け取るなら、Trading Roleは、ConsumerがTrading Role Elementに含まれたCancelNetLocn属性によってTrading Roleに指定された位置まで行くかもしれないと予期するはずです。
4. IOTP Error Handling
4. IOTPエラー処理
IOTP is designed as a request/response protocol where each message is composed of a number of Trading Blocks which contain a number of Trading Components. There are several interrelated considerations in handling errors, re-transmissions, duplicates, and the like. These factors mean IOTP aware applications must manage message flows more complex than the simple request/response model. Also a wide variety of errors can occur in messages as well as at the transport level or in Trading Blocks or Components.
IOTPは各メッセージが多くのTrading Componentsを含む多くのTrading Blocksで構成される要求/応答プロトコルとして設計されています。 取り扱い誤り、再トランスミッション、写し、および同様のものにはいくつかの相関的な問題があります。 これらの要素はアプリケーションが簡単な要求/応答モデルより複雑なメッセージ流れを管理しなければならないのを意識しているIOTPを意味します。 さまざまな誤りも輸送レベルにおいて、または、メッセージとTrading BlocksかComponentsに発生できます。
This section describes at a high level how IOTP handles errors, retries and idempotency. It covers:
このセクションは、高いレベルでIOTPがどのように誤り、再試行、およびidempotencyを扱うかを説明します。 それは以下をカバーしています。
o the different types of errors which can occur. This is divided
into:
o 発生できる異なったタイプの誤り。 これは以下に分割されます。
- "technical errors" which are independent of the purpose of the
IOTP Message,
- IOTP Messageの目的から独立している「技術的な誤り」
- "business errors" which indicate that there is a problem
specific to the process (e.g., payment or delivery) which is
being carried out, and
- そしてそこでそれを示す「ビジネス誤り」が行われているプロセス(例えば、支払いか配送)に特定の問題である。
o the depth of the error which indicates whether the error is at the
transport, message or block/component level
o 輸送には誤りがあるかを示す誤りの深さ、メッセージかブロック/コンポーネントレベル
o how the different trading roles should handle the different types
of messages which they may receive.
o 異なった取り引き役割はどう、彼らが受け取るかもしれない異なったタイプに関するメッセージを扱うべきであるか。
Burdett Informational [Page 56] RFC 2801 IOTP/1.0 April 2000
バーデット[56ページ]情報のRFC2801IOTP/2000年4月1日
4.1 Technical Errors
4.1 技術的な誤り
Technical Errors are those which are independent of the meaning of the message. This means, they can affect any attempt at IOTP communication. Typically they are handled in a standard fashion with a limited number of standard options for the user. Specifically these are:
技術的なErrorsはメッセージの意味から独立しているものです。 この手段であり、それらはIOTPコミュニケーションへのどんな試みにも影響できます。 通常、それらはユーザのために限られた数の標準のオプションがある一般的なファッションで扱われます。 明確にこれらは以下の通りです。
o retrying the transmission, or
o またはトランスミッションを再試行する。
o cancelling the transaction.
o トランザクションを取り消します。
When communications are operating sufficiently well, a technical error is indicated by an Error Component (see section 7.21) in an Error Block (see section 8.17) sent by the party which detected the error in an IOTP message to the party which sent the erroneous message.
コミュニケーションが十分よく作動しているとき、技術的な誤りは誤ったメッセージを送ったパーティーにIOTPメッセージにおける誤りを検出したパーティーによって送られたError Block(セクション8.17を見る)でError Component(セクション7.21を見る)によって示されます。
If communications are too poor, a message which was sent may not reach its destination. In this case a time-out might occur.
コミュニケーションが不十分過ぎるなら、送られたメッセージは目的地に到着しないかもしれません。 この場合、タイムアウトは起こるかもしれません。
The Error Codes associated with Technical Errors are recorded in the Error Component which lists all the different technical errors which can be set.
Technical Errorsに関連しているError Codesは設定できるすべての異なった技術的な誤りを記載するError Componentに記録されます。
4.2 Business Errors
4.2 ビジネス誤り
Business Errors may occur when the IOTP messages are "technically" correct. They are connected with a particular process, for example, an offer, payment, delivery or authentication, where each process has a different set of possible business errors.
IOTPメッセージが「技術的に」正しいときに、ビジネスErrorsは起こるかもしれません。 それらは例えば、特定のプロセス、申し出、支払い、配送または認証に接続されます、各プロセスには可能な異なったビジネス誤りがあるところで。
For example, "Insufficient funds" is a reasonable payment error but makes no sense for a delivery while "Back ordered" is a reasonable delivery error but not meaningful for a payment. Business errors are indicated in the Status Component (see section 7.16) of a "response block" of the appropriate type, for example a Payment Response Block or a Delivery Response Block. This allows whatever additional response related information is needed to accompany the error indication.
例えば、「資金不足」は、合理的な支払い誤りですが、「後部は注文したこと」が支払いで合理的な配送誤りにもかかわらず、重要でない間の配送のために意味をなさないです。 ビジネス誤りは適切なタイプ、例えば、Payment Response Blockの「応答ブロック」のStatus Component(セクション7.16を見る)かDelivery Response Blockで示されます。 これは誤り表示に伴うのに必要であるどんな追加応答関連情報も許容します。
Business errors must usually be presented to the user so that they can decide what to do next. For example, if the error is insufficient funds in a Brand Independent Offer (see section 9.1.2.2), the user might wish to choose a different payment instrument/account of the same brand or a different brand or payment system. Alternatively, if
通常、次に何をしたらよいかを決めることができるようにビジネス誤りをユーザに提示しなければなりません。 例えば、誤りであるなら、Brandの資金不足は無党派Offerです。(同じブランド、異なったブランドまたは決済システムについて.2、)ユーザが異なった支払い器具/アカウントを選びたがっているかもしれないセクション9.1.2を見てください。 代わりに
Burdett Informational [Page 57] RFC 2801 IOTP/1.0 April 2000
バーデット[57ページ]情報のRFC2801IOTP/2000年4月1日
the IOTP based implementation allows it and it makes sense for that instrument, the user might want to put more funds into the instrument/account and try again.
その器具のために理解できて、ユーザは、IOTPのベースの実装がそれを許容して、器具/アカウントにより多くの基金を入れて、再試行したがっているかもしれません。
4.3 Error Depth
4.3 誤りの深さ
The three levels at which IOTP errors can occur are the transport level, the message level, and the block level. Each is described below.
IOTP誤りが発生できる3つのレベルが、輸送レベルと、メッセージレベルと、ブロックレベルです。 それぞれが以下で説明されます。
4.3.1 Transport Level
4.3.1 輸送レベル
This level of error indicates a fundamental problem in the transport mechanism over which the IOTP communication is taking place.
このレベルの誤りはIOTPコミュニケーションが行われている移送機構の基本的な問題を示します。
All transport level errors are technical errors and are indicated by either an explicit transport level error indication, such as a "No route to destination" error from TCP/IP, or by a time out where no response has been received to a request.
すべてが技術的な誤りであり、TCP/IPからの「目的地へのルートがありません」誤りなどの明白な輸送レベル誤り表示で示されるか、または応答がないのがそうしたタイムアウトによって要求に受けられた平らな誤りを輸送します。
The only reasonable automatic action when faced with transport level errors is to retry and, after some number of automatic retries, to inform the user.
唯一の合理的な自動動作が輸送レベル誤りが直面されていると再試行することであり、自動の何らかの数の後に、ユーザは、知らせるために再試行しています。
The explicit error indications that can be received are transport dependent and the documentation for the appropriate IOTP Transport supplement should be consulted for errors and appropriate actions.
受けることができる明白な誤り指摘は輸送扶養家族です、そして、適切なIOTP Transport補足のためのドキュメンテーションは誤りと適切な行動のために参照されるべきです。
Appropriate time outs to use are a function of both the transport being used and of the payment system if the request encapsulates payment information. The transport and payment system specific documentation should be consulted for time out and automatic retry parameters. Frequently there is no way to directly inform the other party of transport level errors but they should generally be logged and if automatic recovery is unsuccessful and there is a human user, the user should be informed.
輸送を使用されて、決済システムについて機能させて、要求が決済情報をカプセル化するなら、使用する適切な時期アウトは両方の機能です。 輸送と決済システムの特定のドキュメンテーションはタイムアウトと自動再試行パラメタのために参照されるべきです。 一般に、それらは登録されるべきです、そして、輸送レベル誤りについて直接相手に知らせる方法が全く頻繁にありませんが、自動復旧が失敗していて、人間のユーザがいれば、ユーザは知識があるべきです。
4.3.2 Message Level
4.3.2 メッセージレベル
This level of error indicates a fundamental technical problem with an entire IOTP message. For example, the XML is not "Well Formed", or the message is too large for the receiver to handle or there are errors in the Transaction Reference Block (see section 3.3) so it is not possible to figure out what transaction the message relates to.
このレベルの誤りは全体のIOTPメッセージの基本的な技術的問題を示します。 例えば、XMLが「整形式ではありません」、誤りがTransaction Reference Blockにあって(セクション3.3を見てください)、またはメッセージが受信機が扱うことができないくらい大きいので、メッセージがどんなトランザクションに関連するかを理解するのは可能ではありません。
All message level errors are technical errors and are indicated by Error Components (see section 7.21) sent to the other party. The Error Component includes a Severity attribute which indicates whether
すべてのメッセージレベル誤りが、技術的な誤りであり、相手に送られたError Components(セクション7.21を見る)によって示されます。 Error Componentインクルードa Severityがどれを結果と考えるか、表示
Burdett Informational [Page 58] RFC 2801 IOTP/1.0 April 2000
バーデット[58ページ]情報のRFC2801IOTP/2000年4月1日
the error is a Warning and may be ignored, a TransientError which indicates that a retry may resolve the problem or a HardError in which case the transaction must fail.
誤りは、Warningであり、無視されるかもしれません、再試行が問題かHardErrorを解決するかもしれなくて、その場合、トランザクションが失敗しなければならないのを、示すTransientError。
The Technical Errors (see section 7.21.2 Error Codes) that are Message Level errors are:
Message Level誤りであるTechnical Errors(セクション7.21.2Error Codesを見る)は以下の通りです。
o XML not well formed. The document is not well formed XML (see
[XML])
o XML、整形式ではありません。 ドキュメントは整形式のXMLではありません。([XML]を見ます)
o XML not valid. The document is not valid XML (see [XML])
o XML、有効ではありません。 ドキュメントは有効なXMLではありません。([XML]を見ます)
o block level technical errors (see section 4.3.3) on the
Transaction Reference Block (see section 3.3) and the Signature
Block only. Checks on these blocks should only be carried out if
the XML is valid
o Transaction Reference Block(セクション3.3を見る)とSignature Blockだけで平らな技術的な誤り(セクション4.3.3を見る)を妨げてください。 XMLが有効である場合にだけ、これらのブロックのチェックが行われるべきです。
Note that checks on the Signature Block include checking, where possible, that each Signature Component is correctly calculated. If the Signature is incorrectly calculated then the data that should have been covered by the signature can not be trusted and must be treated as erroneous. A description of how to check a signature is correctly calculated is contained in section 6.2.
Signature Blockのチェックが、可能であるところにチェックするのを含んで、各Signature Componentが正しく見込まれることに注意してください。 Signatureが不当に計算されるなら、署名でカバーされているべきであったデータを、信じることができないで、誤るとして扱わなければなりません。 署名をチェックするのがどう正しく計算されるかに関する記述はセクション6.2に含まれています。
4.3.3 Block Level
4.3.3 ブロックレベル
A Block level error indicates a problem with a block or one of its components in an IOTP message (apart from Transaction Reference or Signature Blocks). The message has been transported properly, the overall message structure and the block/component(s) including the Transaction Reference and Signature Blocks are meaningful but there is some error related to one of the other blocks.
Blockの平らな誤りはブロックに関する問題かIOTPメッセージのコンポーネントの1つ(Transaction ReferenceかSignature Blocksは別として)を示します。 メッセージは適切に輸送されました、総合的なメッセージ構造、Transaction ReferenceとSignature Blocksを含むブロック/コンポーネントは重要ですが、他のブロックの1つに関連する何らかの誤りがあります。
Block level errors can be either:
ブロックレベル誤りはどちらかであるかもしれません:
o technical errors, or
o または技術的な誤り。
o business errors
o ビジネス誤り
Technical Errors are further divided into:
技術的なErrorsはさらに以下に分割されます。
o Block Level Attribute and Element Checks, and
o そして平らな属性と要素チェックを妨げてください。
o Block and Component Consistency Checks
o ブロックとコンポーネントの一貫性はチェックします。
o Transient Technical Errors
o 一時的な技術的な誤り
Burdett Informational [Page 59] RFC 2801 IOTP/1.0 April 2000
バーデット[59ページ]情報のRFC2801IOTP/2000年4月1日
If a technical error occurs related to a block or component, then an Error Component is generated for return.
技術的な誤りが発生するなら、ブロックかコンポーネントに関係づけられて、Error Componentはリターンのために生成されます。
4.3.3.1 Block Level Attribute and Element Checks
4.3.3.1 ブロックの平らな属性と要素チェック
Block Level Attribute and Element Checks occur only within the same block. Checks which involve cross-checking against other blocks are covered by Block and Component Consistency Checks.
ブロックLevel AttributeとElement Checksは同じブロックだけの中に起こります。 他のブロックに対してクロスチェックすることを伴うチェックがBlockとComponent Consistency Checksでカバーされています。
The Block Level Attribute & Element checks are:
Block Level Attribute&Elementチェックは以下の通りです。
o checking that each attribute value within each element in a block
conforms to any rules contained within this IOTP specification
o ブロックの各要素の中の各属性値がこのIOTP仕様の中に含まれたどんな規則にも従うのをチェックします。
o checking that the content of each element conforms to any rules
contained within this IOTP specification
o それぞれの要素の内容がこのIOTP仕様の中に含まれたどんな規則にも従うのをチェックします。
o if the previous checks are OK, then checking the consistency of
attribute values and element content against other attribute
values or element content within any other components in the same
block.
o 一貫性がその時チェックして、前のチェックは属性値でOKであるかどうか、そして、他の属性値に対する要素含有量か同じブロックのいかなる他のコンポーネントの中の要素含有量。
4.3.3.2 Block and Component Consistency Checks
4.3.3.2 ブロックとコンポーネントの一貫性はチェックします。
Block and Component Consistency Checks consist of:
ブロックとComponent Consistency Checksは以下から成ります。
o checking that the combination of blocks and/or components present
in the IOTP Message are consistent with the rules contained within
this IOTP specification
o IOTP Messageの現在のブロック、そして/または、コンポーネントの組み合わせがこのIOTP仕様の中に含まれている規則と一致しているのをチェックします。
o checking for consistency between attributes and element content
within the blocks within the same IOTP message.
o 属性と要素含有量の間の一貫性がないかどうか同じIOTPメッセージの中でブロックの中でチェックします。
o checking for consistency between attributes and elements in blocks
in this IOTP message and blocks received in earlier IOTP messages
for the same IOTP transaction
o 同じIOTPトランザクションのためにこのIOTPメッセージと以前のIOTPメッセージに受け取られたブロックでのブロックの属性と要素の間の一貫性がないかどうかチェックします。
If the block passes the "Block Level Attribute and Element Checks" and the "Block and Component Consistency Checks" then it is processed either by the IOTP Aware application or perhaps by some "back-end" system such as a payment server.
ブロックがそして「ブロックの平らな属性と要素チェック」、および「ブロックとコンポーネント一貫性チェック」を通過するなら、それはIOTP Awareアプリケーションか恐らく支払いサーバなどの何らかの「バックエンド」システムによって処理されます。
4.3.3.3 Transient Technical Errors
4.3.3.3 一時的な技術的な誤り
During the processing of the Block some temporary failure may occur that can potentially be recovered by the other trading role re- transmitting, at some slightly later time, the original message that they sent. In this case the other role is informed of the Transient
Blockの処理の間、他の取り引き役割の再送信で潜在的に回復できる何らかの一時障害が起こるかもしれません、何らかの時間わずかに後半に、彼らが発信したというオリジナルのメッセージ。 この場合、もう片方の役割はTransientにおいて知識があります。
Burdett Informational [Page 60] RFC 2801 IOTP/1.0 April 2000
バーデット[60ページ]情報のRFC2801IOTP/2000年4月1日
Error by sending them an Error Component (see section 7.21) with the Severity Attribute set to TransientError and the MinRetrySecs attribute set to some value suitable for the Transport Mechanism and/or payment protocol being used (see appropriate Transport and payment protocol Supplements).
Severity Attributeと共にError Componentをそれらに送るのによる(セクション7.21を見ます)誤りはTransientErrorにセットしました、そして、MinRetrySecs属性は使用されるTransport Mechanism、そして/または、支払いプロトコルに適した何らかの値にセットしました(適切なTransportと支払いプロトコルSupplementsを見てください)。
Note that transient technical errors can be generated by any of the Trading Roles involved in transaction.
トランザクションにかかわるTrading Rolesのどれかが一時的な技術的な誤りを生成することができることに注意してください。
4.3.3.4 Block Level Business Errors
4.3.3.4 ブロックの平らなビジネス誤り
If a business error occurs in a process such as a Payment or a Delivery, then the appropriate type of response block is returned containing a Status Component (see section 7.16) with the ProcessState attribute set to Failed and the CompletionCode indicating the nature of the problem.
ビジネス誤りがPaymentかDeliveryなどのプロセスに発生するなら、Status Componentを含んでいて(セクション7.16を見ます)、Failedに用意ができているProcessState属性とCompletionCodeが問題の性格を示していて、適切なタイプの応答ブロックを返します。
Some business errors may be "transient" in that the Consumer role may be able to recover and complete the transaction in some other way. For example if the Credit Card that a consumer provided had insufficient funds for a purchase, then the Consumer may recover by using a different credit card.
ある他の方法で取引を回復して、Consumerの役割が完了できるかもしれないので、いくつかのビジネス誤りが「一時的であるかもしれません」。 例えば、消費者が提供したCredit Cardが購入のための資金不足を持っていたなら、Consumerは、異なったクレジットカードを使用することによって、回復するかもしれません。
Recovery from "transient" business errors is dependent on the CompletionCode. See the definition of the Status Component for what is possible.
「一時的な」ビジネス誤りからの回復はCompletionCodeに依存しています。 可能なことに関してStatus Componentの定義を見てください。
Note that no Error Component or Error Block is generated for business errors.
どんなError ComponentもError Blockもビジネス誤りによって生成されないことに注意してください。
4.4 Idempotency, Processing Sequence, and Message Flow
4.4 Idempotency、処理系列、およびメッセージ流動
IOTP messages are actually a combination of blocks and components as described in 3.1.1 IOTP Message Structure. Especially in future extensions of IOTP, a rich variety of combinations of such blocks and components can occur. It is important that the multiple transmission/receipt of the "same" request for an action that will change state does not result in that action occurring more than once. This is called idempotency. For example, a customer paying for an order would want to pay the full amount only once. Most network transport mechanisms have some probability of delivering a message more than once or not at all, perhaps requiring retransmission. On the other hand, a request for status can reasonably be repeated and should be processed fresh each time it is received.
IOTPメッセージは実際にブロックの組み合わせであり、3.1における説明されるとしてのコンポーネントは.1IOTP Message Structureです。 特にIOTPの今後の拡大では、豊かなバラエティーのそのようなブロックとコンポーネントの組み合わせは起こることができます。 状態を変える動作を求める「同じ」要求の複駆動動力伝達装置/領収書が一度より多くのその動作発生に結果として生じないのは、重要です。 これはidempotencyと呼ばれます。 例えば、注文の代価を払う顧客は一度だけ全額を支払いたがっているでしょう。 ほとんどのネットワーク移送機構で伝言をもたらすという何らかの確率が一度より多くなるか、とんでもない、恐らく「再-トランスミッション」を必要として。 他方では、状態を求める要求は、それが受け取られている各回に合理的に繰り返すことができて、新たに処理されるべきです。
Burdett Informational [Page 61] RFC 2801 IOTP/1.0 April 2000
バーデット[61ページ]情報のRFC2801IOTP/2000年4月1日
Correct implementation of IOTP can be modelled by a particular processing order as detailed below. Any other method that is indistinguishable in the messages sent between the parties is equally acceptable.
以下で詳しく述べられるように特定の処理命令でIOTPの正しい実装をモデル化できます。 いかなる他のパーティーの間に送られたメッセージにおいて区別がつかないメソッドも等しく許容できます。
4.5 Server Role Processing Sequence
4.5 サーバーの役割処理系列
"Server roles" are any Trading Role which is not the Consumer role. They are "Server roles" since they typically receive a request which they must service and then produce a response. However server roles can also initiate transactions. More specifically Server Roles must be able to:
「サーバーの役割」はConsumerの役割でないあらゆるTrading Roleです。 それらが修理しなければならない要求を通常受け取って、次に、応答を起こすので、それらは「サーバーの役割」です。 しかしながら、また、サーバーの役割はトランザクションを開始できます。 より明確にServer Rolesは以下にできるに違いありません。
o Initiate a transaction (see section 4.5.1). These are divided
into:
o トランザクションを開始してください(セクション4.5.1を見てください)。 これらは以下に分割されます。
- payment related transactions and
- そして支払いがトランザクションを関係づけた。
- infrastructure transactions
- インフラストラクチャトランザクション
o Accept and process a message received from another role (see
section 4.5.2). This includes:
o 別の役割から受け取られたメッセージを、受け入れて、処理してください(セクション4.5.2を見てください)。 これは:
- identifying if the message belongs to a transaction that has
been received before
- メッセージが以前受け取られたことがあるトランザクションに属すかどうか特定します。
- handling duplicate messages
- 取り扱い写しメッセージ
- generating Transient errors if the servers that process the
input message are too busy to handle it
- 入力メッセージを処理するサーバがそれを扱うことができないくらい忙しいなら、Transientに誤りを生成します。
- processing the message if it is error free, authorised and, if
appropriate, producing a response to send back to the other
role
- それであるならメッセージを処理するのはエラーのないです、認可されて、適切であるならもう片方の役割を送り返すために応答を起こして
o Cancel a current transaction if requested (see section 4.5.3)
o 要求されるなら、経常取引を中止してください。(セクション4.5.3を見ます)
o Re-transmit messages if a response was expected but has not been
received in a reasonable time (see section 4.5.4).
o 応答が予想されましたが、妥当な時間受けられていないなら(セクション4.5.4を見てください)、メッセージを再送してください。
4.5.1 Initiating Transactions
4.5.1 トランザクションを開始すること。
Server Roles may initiate a variety of different types of transaction. Specifically:
サーバRolesはさまざまな異なったタイプのトランザクションを開始するかもしれません。 明確に:
o an Inquiry Transaction (see section 9.2.1)
o 問い合せトランザクション(セクション9.2.1を見ます)
o a Ping Transaction (see section 9.2.2)
o ピングトランザクション(セクション9.2.2を見ます)
Burdett Informational [Page 62] RFC 2801 IOTP/1.0 April 2000
バーデット[62ページ]情報のRFC2801IOTP/2000年4月1日
o an Authentication Transaction (see section 9.1.6)
o 認証トランザクション(セクション9.1.6を見ます)
o a Payment Related Transaction such as:
o 以下などのPaymentの関連Transaction
- a Deposit (see section 9.1.7)
- 預金(セクション9.1.7を見ます)
- a Purchase (see section 9.1.8)
- 購入(セクション9.1.8を見ます)
- a Refund (see section 9.1.9)
- 還付(セクション9.1.9を見ます)
- a Withdrawal (see section 9.1.10)
- 退出(セクション9.1.10を見ます)
- a Value Exchange (see section 9.1.11)
- 値の交換(セクション9.1.11を見ます)
4.5.2 Processing Input Messages
4.5.2 処理入力メッセージ
Processing input messages involves the following:
入力メッセージを処理すると、以下はかかわります:
o checking the structure and identity of the message
o メッセージの構造とアイデンティティをチェックします。
o checking for and handling duplicate messages
o 写しメッセージをチェックして、扱います。
o processing non-duplicate original messages which includes:
o 非写しのオリジナルのメッセージを処理して、どれが以下を含んでいますか?
- checking for errors, then if no errors are found
- エラーを確認して、そして、誤りはいいえなら見つけられます。
- processing the message to produce an output message if
appropriate
- 適切であるなら、出力メッセージを出すメッセージを処理します。
Each of these is discussed in more detail below.
さらに詳細に以下でそれぞれのこれらについて議論します。
4.5.2.1 Checking Structure and Message Identity
4.5.2.1 構造とメッセージのアイデンティティをチェックすること。
It is critical to check that the message is "well formed" XML and that the transaction identifier (IotpTransId attribute on the TransId Component) within the IOTP message can be successfully identified since an IotpTransId will be needed to generate a response.
メッセージが「整形式」のXMLであり、IotpTransIdが応答を生成するのに必要であるので首尾よくIOTPメッセージの中のトランザクション識別子(IotpTransIdはトランザクション識別子でComponentを結果と考える)は特定できるのをチェックするのが重要です。
If the input message is not well formed then generate an Error Component with a Severity of HardError and ErrorCode of XmlNotWellFrmd.
入力メッセージが整形式でないなら、HardErrorのSeverityとXmlNotWellFrmdのErrorCodeと共にError Componentを生成してください。
If the message is well formed but the IotpTransId cannot be identified then generate an ErrorComponent with:
メッセージが整形式ですが、IotpTransIdを特定できないなら、以下でErrorComponentを生成してください。
o a Severity of HardError and an ErrorCode of AttMissing,
o HardErrorの厳しさとAttMissingのErrorCode
Burdett Informational [Page 63] RFC 2801 IOTP/1.0 April 2000
バーデット[63ページ]情報のRFC2801IOTP/2000年4月1日
o a PackagedContent containing "IotpTransId" - the missing
attribute.
o "IotpTransId"を含むPackagedContent--なくなった属性。
Insert the Error Component inside an Error Block with a new TransactionId component with a new IotpTransId and return it to the sender of the original message.
新しいIotpTransIdと共に新しいTransactionIdの部品でError ComponentをError Blockに挿入してください、そして、オリジナルのメッセージの送付者にそれを返してください。
4.5.2.2 Checking/Handling Duplicate Messages
4.5.2.2 写しメッセージをチェックするか、または扱うこと。
If the input message can be identified as potentially a valid input message then check to see if an "identical" input message has been received before. Identical means that all blocks, components, elements, attribute values and element content in the input message are the same.
同じくらい潜在的に入力メッセージを特定できるなら、有効な入力メッセージは、「同じ」入力メッセージが以前受け取られたことがあるかどうかを見るためにチェックします。 入力メッセージのすべてが妨げる同じ手段、コンポーネント、要素、属性値、および要素含有量は同じです。
Note: The recommended way of checking for identical messages is to check for equal values of their [DOM-HASH]
以下に注意してください。 同じメッセージがないかどうかチェックするお勧めの方法が等しい値がないかどうかチェックすることになっている、それら[ドム-ハッシュ]
If an identical message has been received before then check to see if the processing of the previous message has completed.
それ以前同じメッセージを受け取ったなら、チェックします。前のメッセージの処理がそうしたかどうか確認してください、そして、完成されます。
If processing has not completed then generate an Error Component with a Severity of Transient Error and an Error Code of MsgBeingProc to indicate the message is being processed and send it back to the sender of the Input Message requesting that the original message be resent after an appropriate period of time.
処理がその時を完成していないならTransient ErrorのSeverityとMsgBeingProcのError Codeと共にError Componentを生成して、メッセージが処理されているのを示して、オリジナルのメッセージが適切な期間の後に再送されるよう要求するInput Messageの送付者にそれを送り返してください。
Otherwise, if processing has completed and resulted in an output message then retrieve the last message that was sent and send it again.
さもなければ、処理が出力メッセージを完成して、もたらしたなら、送られた最後のメッセージを検索してください、そして、もう一度それを送ってください。
If the message is not a duplicate then it should be processed.
メッセージが写しでないなら、それは処理されるべきです。
4.5.2.3 Processing Non-Duplicate Message
4.5.2.3 処理非写しメッセージ
Once it's been established that the message is not a duplicate, then it can be processed. This involves:
一度、メッセージが写しでないことを確証したことがあって、次に、それを処理できます。 これは以下にかかわります。
o checking that a server is available to handle the message,
generating a Transient Error if it is not
o それが生成しないならTransient Errorを生成して、サーバがメッセージを扱うために利用可能であることをチェックします。
o checking the Transaction is Not Already in error or cancelled
o Transactionをチェックするのは、誤りか取り消されるところのNot Alreadyです。
o validating the input message. This includes:
o 入力メッセージを有効にします。 これは:
- checking for message level errors
- メッセージレベル誤りがないかどうかチェックします。
- checking for block level errors
- ブロックがないかどうかチェックして、誤りを平らにしてください。
Burdett Informational [Page 64] RFC 2801 IOTP/1.0 April 2000
バーデット[64ページ]情報のRFC2801IOTP/2000年4月1日
- checking any encapsulated data
- どんなカプセル化されたデータもチェックします。
o checking for errors in the sequence that blocks have been received
o 誤りがないかどうか系列でブロックが受け取られたのをチェックします。
o generating error components for any errors that result
o どんな誤りのための誤りコンポーネントもその結果であると生成します。
o if neither hard errors nor transient errors result, then
processing the message and generating an output message, if
required, for return to the sender of the Input Message
o 困難な誤りも一時的エラーも結果として生じないか、そして、次に、メッセージを処理して、必要ならInput Messageの送付者へのリターンへの出力メッセージを生成すること。
Note: This approach to handling of duplicate input messages means, if absolutely "identical" messages are received then absolutely "identical" messages are returned. This also applies to Inquiry and Ping transactions when in reality the state of a transaction or the processing ability of the servers may have changed. If up-to-date status of transactions or servers is required, then an IOTP transaction with a new value for the ID attribute of the MsgId component must be used.
以下に注意してください。 多重入力メッセージ手段の取り扱いへのこのアプローチ、絶対に「同じ」メッセージが受信されているなら、絶対に「同じ」メッセージを返します。 また、トランザクションの状態かサーバの処理能力がほんとうは変化したとき、これはInquiryとPingトランザクションに適用されます。 トランザクションかサーバの最新の状態が必要であるなら、MsgIdの部品のID属性のための新しい値があるIOTPトランザクションを使用しなければなりません。
Each of the above steps is discussed below.
以下でそれぞれの上のステップについて議論します。
CHECKING A SERVER IS AVAILABLE
サーバをチェックするのは利用可能です。
The process that is handling the input message should check that the rest of the system is not so busy that a response in a reasonable time cannot be produced.
入力メッセージを扱っているプロセスは、システムの残りが非常に忙しくないので妥当な時間で応答を起こすことができないのをチェックするはずです。
If the server is too busy, then it should generate an Error Component with a Severity of Transient Error and an Error Code of SystemBusy and send it back to the sender of the Input Message requesting that the original message be resent after an appropriate period of time.
サーバが忙し過ぎるなら、それは、Transient ErrorのSeverityとSystemBusyのError Codeと共にError Componentを生成して、オリジナルのメッセージが適切な期間の後に再送されるよう要求するInput Messageの送付者にそれを送り返すべきです。
Note: Some servers may occasionally become very busy due to unexpected increases in workload. This approach allows short peaks in workloads to be handled by delaying the input of messages by asking the sender of the message to resubmit later.
以下に注意してください。 いくつかのサーバが時折予期されなかった増加のためにワークロードで非常に忙しくなるかもしれません。 このアプローチは、ワークロードの短いピークが後で再提出するようにメッセージ送信者に頼むことによってメッセージの入力を遅らせることによって扱われるのを許容します。
CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED
トランザクションをチェックするのは、誤りには既にないか、または取り消されます。
Check that:
以下のことをチェックしてください。
o previous messages received or sent did not contain or result in
Hard Errors, and
o そして受け取ったか、または送った前のメッセージがHard Errorsを含みもしませんでしたし、もたらしもしなかった。
o the Transaction has not been cancelled by either the Consumer or
the Server Trading Role
o TransactionはConsumerかServer Trading Roleのどちらかによって取り消されていません。
Burdett Informational [Page 65] RFC 2801 IOTP/1.0 April 2000
バーデット[65ページ]情報のRFC2801IOTP/2000年4月1日
If it has then, ignore the message. A transaction with hard errors or that has been cancelled, cannot be restarted.
それにその時があるなら、メッセージを無視してください。 困難な誤りかそれがあるトランザクションを取り消して、再開できません。
CHECK FOR MESSAGE AND BLOCK LEVEL ERRORS
そして、ブロックが誤りを平らにするというメッセージがないかどうかチェックしてください。
If the transaction is still OK then check for message level errors. This involves:
トランザクションがまだOKであるなら、メッセージレベル誤りがないかどうかチェックしてください。 これは以下にかかわります。
o checking the XML is valid
o XMLをチェックするのは有効です。
o checking that the elements, attributes and content of the
Transaction Reference Block are without error and conform to this
specification
o Transaction Reference Blockの要素、属性、および内容が誤りなしであって、この仕様に一致しているのをチェックします。
o checking the digital signature which involves:
o デジタル署名をチェックして、どれが以下にかかわりますか?
- checking that the Signature value is correctly calculated, and
- そしてそれをSignatureが評価するチェックするのが正しく計算される。
- the hash values in the digests are correctly calculated where
the source of the hash value is available.
- ハッシュ値の源が利用可能であるところでダイジェストのハッシュ値は正しく計算されます。
Checking for block level errors involves:
ブロックレベル誤りがないかどうかチェックするのは以下にかかわります。
o checking within each block (apart from the Transaction Reference
Block) that:
o それぞれ中でチェックして、それを妨げてください(Transaction Reference Blockは別として):
- the attributes, elements and element contents are valid
- 属性、要素、および要素コンテンツは有効です。
- the values of the attributes, elements and element contents are
consistent within the block
- 属性、要素、および要素コンテンツの値はブロックの中で一貫しています。
o checking that the combination of blocks are valid
o ブロックの組み合わせが有効であることをチェックします。
o checking that the values of the attribute, elements and element
contents are consistent between the blocks in the input message
and blocks in earlier messages either sent or received. This
includes checking that the presence of a block is valid for a
particular transaction type
o 属性、要素、および要素コンテンツの値が入力メッセージでのブロックと以前のメッセージでのブロックの間で一貫しているのをチェックするのを、発信したか、または受信されました。 これは、特定の取引タイプに、1ブロックの存在が有効であることをチェックするのを含んでいます。
If the message contains any encapsulated data, then if possible check the encapsulated data for errors using additional software to check the data where appropriate.
メッセージが何かカプセル化されたデータを含むなら、できれば、誤りがないかどうか適切であるところでデータをチェックするのに付加ソフトウェアを使用することでカプセル化されたデータをチェックしてください。
4.5.2.4 Check for Errors in Block Sequence
4.5.2.4 ブロック法では、エラーを確認してください。
Note: For reasons of brevity, the following explanations of how to check for errors in Block sequence, the phrase "refers to an IOTP transaction" is interpreted as "is contained in an IOTP Message where
以下に注意してください。 簡潔さの理由で、Block系列における誤りがないかどうか句が「IOTPトランザクションについて言及すること」をどうチェックするかに関する以下の説明が解釈される、「IOTP Messageに含まれている、どこ、」
Burdett Informational [Page 66] RFC 2801 IOTP/1.0 April 2000
バーデット[66ページ]情報のRFC2801IOTP/2000年4月1日
the Trans Ref Block contains an IotpTransId that refers to". So, for example, " If an Error or Cancel Block refers to an IOTP transaction that is not recognised then ..." should be interpreted as " If an Error or Cancel Block is contained in an IOTP Message where the Trans Ref Block contains an IotpTransId that refers to an IOTP transaction that is not recognised then ...
「Trans Ref Blockは参照するIotpTransIdを含んでいます」 そのように、例えば、「ErrorかキャンセルBlockがその時認識されないIOTPトランザクションについて言及する」なら、「ErrorかキャンセルBlockがTrans Ref Blockがその時認識されないIOTPトランザクションについて言及するIotpTransIdを含むIOTP Messageに含まれている」なら、…は解釈されるべきです…
Errors in the sequence that blocks arrive depends on the block. Blocks where checking for sequence is required are:
それが妨げる系列における誤りは到着します。ブロックによります。 系列がないかどうかチェックするのが必要であるブロックは以下の通りです。
o Error and Cancel Blocks. If an Error or Cancel Block refers to an
IOTP transaction that is not recognised then it is a Hard Error.
Do not return an error if Error or Cancel Blocks have been
received for the IOTP Transaction before to avoid looping.
o 誤りとキャンセルブロック。 ErrorかキャンセルBlockが認識されないIOTPトランザクションについて言及するなら、それはHard Errorです。 IOTP Transactionにおいて、ErrorかキャンセルBlocksが以前輪にするのを避けるために受け取られていたことがあるなら、誤りを返さないでください。
o Inquiry Request and Response Blocks. If an Inquiry Request or an
Inquiry Response Block refers to an IOTP transaction that is not
recognised then it is a Hard Error
o 問い合せ要求と応答ブロック。 Inquiry RequestかInquiry Response Blockが認識されないIOTPトランザクションについて言及するなら、それはHard Errorです。
o Authentication Request Block. If an Authentication Request Block
refers to an IOTP transaction that is recognised it is a Hard
Error
o 認証要求ブロック。 Authentication Request Blockが認識されるIOTPトランザクションについて言及するなら、それはHard Errorです。
o Authentication Response Block. Check as follows:
o 認証応答ブロック。 以下の通りチェックしてください:
- if an Authentication Response Block does not refer to an IOTP
transaction that is recognised it is a Hard Error, otherwise
- Authentication Response Blockが認識されるIOTPトランザクションについて言及しないなら、それはHard Errorです、そうではありません。
- if the Authentication Response Block doesn't refer to an
Authentication Request that had been previously sent then it is
a Hard Error, otherwise
- Authentication Response Blockが以前に送られたAuthentication Requestについて言及しないなら、それはHard Errorです、そうではありません。
- if an Authentication Response for the same IOTP transaction has
been received before and the Authentication was successful then
it is a Hard Error.
- 以前、同じIOTPトランザクションのためのAuthentication Responseを受け取ったことがあって、Authenticationがうまくいったなら、それはHard Errorです。
o Authentication Status Block. Check as follows:
o 認証状態ブロック。 以下の通りチェックしてください:
- if an Authentication Status Block does not refer to an IOTP
transaction that is recognised it is a Hard Error, otherwise
- Authentication Status Blockが認識されるIOTPトランザクションについて言及しないなら、それはHard Errorです、そうではありません。
- if the Authentication Status Block doesn't refer to an
Authentication Response that had been previously sent then it
is a Hard Error, otherwise
- Authentication Status Blockが以前に送られたAuthentication Responseについて言及しないなら、それはHard Errorです、そうではありません。
- if an Authentication Status for the same IOTP transaction has
been received before then it is a Warning Error
- それ以前同じIOTPトランザクションのためのAuthentication Statusを受け取ったなら、それはWarning Errorです。
Burdett Informational [Page 67] RFC 2801 IOTP/1.0 April 2000
バーデット[67ページ]情報のRFC2801IOTP/2000年4月1日
o TPO Selection Block (Merchant only). Check as follows:
o TPO Selection Block(商人専用)。 以下の通りチェックしてください:
- if the TPO Selection Block doesn't refer to an IOTP Transaction
that is recognised then it is a Hard Error, otherwise
- TPO Selection Blockが認識されるIOTP Transactionについて言及しないなら、それはHard Errorです、そうではありません。
- if the TPO Selection Block refers to an IOTP Transaction where
a TPO Block and Offer Response (in one message) had previously
been sent then it is a Hard Error, otherwise
- TPO Selection BlockがTPO BlockとOffer Response(1つのメッセージの)が以前に送られたIOTP Transactionについて言及するなら、それはHard Errorです、そうではありません。
- if the TPO Selection Block does not refer to an IOTP
Transaction where a TPO Block only (i.e. without an Offer
Response) had previously been sent then it is a Hard Error,
otherwise
- TPO Selection BlockがTPO Blockだけが以前に送られたIOTP Transactionについて言及しないなら、それはHard Errorです、そうではありません。
- if a TPO Selection Block for the same TPO Block has been
received before then it is a Hard Error
- それ以前同じTPO BlockのためのTPO Selection Blockを受け取ったなら、それはHard Errorです。
o Payment Request Block (Payment Handler only). Check as follows:
o 支払いRequest Block(支払いHandler専用)。 以下の通りチェックしてください:
- if the Payment Request Block refers to an IOTP Transaction that
is not recognised then its OK, otherwise
- Payment Request Blockが認識されないIOTP Transactionについて言及するなら、それは、OKであって、そうではありません。
- if the Payment Request Block refers to IOTP Transaction that
was not for a Payment then it is a Hard Error, otherwise
- Payment Request BlockがPaymentのためのものでなかったIOTP Transactionについて言及するなら、それはHard Errorです、そうではありません。
- if there was a previous payment that failed with a non-
recoverable Completion Code then it is a Hard Error, otherwise
- 非回復可能なCompletion Codeと共に失敗した前の支払いがあったなら、それはHard Errorです、そうではありません。
- if a previous payment is still in progress then it is a Hard
Error
- 前の支払いがまだ進行しているなら、それはHard Errorです。
o Payment Exchange Block (Payment Handler only). Check as follows:
o 支払いExchange Block(支払いHandler専用)。 以下の通りチェックしてください:
- if the Payment Exchange Block doesn't refer to an IOTP
Transaction that is recognised then it is a Hard Error,
otherwise
- Payment Exchange Blockが認識されるIOTP Transactionについて言及しないなら、それはHard Errorです、そうではありません。
- if the Payment Exchange doesn't refer to an IOTP Transaction
where a Payment Exchange had previously been sent then it a
Hard Error
- Payment ExchangeがPayment Exchangeがその時以前に送られたIOTP Transactionについて言及しない、それ、Hard Error
o Delivery Request (Delivery Handler Only). If the Delivery Request
Block refers to an IOTP Transaction that is recognised by the
Server then it is a Hard Error
o 配送要求(配送操作者専用)。 Delivery Request BlockがServerによって認識されるIOTP Transactionについて言及するなら、それはHard Errorです。
Burdett Informational [Page 68] RFC 2801 IOTP/1.0 April 2000
バーデット[68ページ]情報のRFC2801IOTP/2000年4月1日
If any Error Components have been generated then collect them into an Error Block for sending to the sender of the Input message. Note that Error Blocks should be sent back to the sender of the message and to the ErrorLogNetLocn for the Trading Role of the sender if one is specified.
何かError Componentsが生成されたなら、Inputメッセージの送付者に発信するために彼らをError Blockに集めてください。 1つが指定されるならError Blocksがメッセージ送信者と、そして、送付者のTrading RoleのためのErrorLogNetLocnに返送されるべきであることに注意してください。
Note: The above checking on the sequence of Authentication Responses and Payment Requests supports the Consumer re-submitting a repeat action request since the previous one failed, for example:
以下に注意してください。 例えば、前のものが失敗したので、Authentication ResponsesとPayment Requestsの系列における上の照合は、Consumer再提出が反復動作要求であるとサポートします:
o because they did not know the correct response (e.g., a password)
on an authentication or,
o または彼らが認証のときに正しい応答(例えば、パスワード)を知らなかった。
o they were unable to pay as there were insufficient funds on a
credit card
o クレジットカードの上に資金不足があったとき、彼らは支払うことができませんでした。
PROCESS THE ERROR FREE INPUT MESSAGE
エラーのない入力メッセージを処理してください。
If the input message passes the previous checks then it can be processed to produce an output message if required. Note that:
入力メッセージが前のチェックを通過するなら、必要なら、出力メッセージを出すためにそれを処理できます。 以下のことに注意してください。
o Inquiry Requests on Ping Transactions should be ignored
o Ping Transactionsの上の問い合せRequestsは無視されるべきです。
o if the Input message contains an Error Block with a Transient
Error then wait for the required time then resend the previous
message, if a response to the earlier message has not been
received
o 前のメッセージを再送してください、Inputメッセージが必要な時間のTransient Errorの当時の待ちがあるError Blockを含んでいて、以前のメッセージへの応答が受けられていないなら
o if the input message contains a Error Component with a HardError
or a Cancel Block then stop all further processing of the
transaction. This includes suppressing the sending of any messages
currently being generated or responding to any new non-duplicate
messages that are received
o 入力メッセージがHardErrorかキャンセルBlockとError Componentを含むなら、トランザクションのさらなるすべての処理を止めてください。 これは、現在生成されるどんなメッセージの発信も抑圧するか、またはどんな受信された新しい非写しメッセージにも応じるのを含んでいます。
o processing of encapsulated messages (e.g., Payment Protocol
Messages) may result in additional transient errors
o カプセル化されたメッセージ(例えば、PaymentプロトコルMessages)の処理は追加一時的エラーをもたらすかもしれません。
o a digital signature can only safely be generated once all the
blocks and components have been generated and it is known which
elements in the message need to be signed.
o かつてのすべてのブロックであると安全にデジタル署名を生成することができるだけです、そして、コンポーネントは生成されました、そして、メッセージのどの要素が、署名される必要であるかが知られています。
If an output message is generated then it should be saved so that it can be resent as required if an identical input message is received again. Note that output messages that contain transient errors are not saved so that they can be processed afresh when the input message is received again.
出力メッセージが発生しているなら、それは、再び同じ入力メッセージを受け取るなら必要に応じてそれを再送できるように貯蓄されるべきです。 一時的エラーを含む出力メッセージが新たに再び入力メッセージを受け取るとき、それらを処理できるように保存されないことに注意してください。
Burdett Informational [Page 69] RFC 2801 IOTP/1.0 April 2000
バーデット[69ページ]情報のRFC2801IOTP/2000年4月1日
4.5.3 Cancelling a Transaction
4.5.3 トランザクションを取り消すこと。
This process is used to cancel a transaction running on an IOTP server. It is initiated by some other process as a result of an external request from another system or server that is being run by the same Trading Role. The processing required is as follows:
このプロセスは、IOTPサーバで動くトランザクションを取り消すのに使用されます。それは同じTrading Roleによって動かされている別のシステムかサーバからの外部要求の結果、ある他のプロセスによって開始されます。 必要である処理は以下の通りです:
o if the IotpTransId of the transaction to be cancelled is not
recognised, or complete then fail the request, otherwise
o そうでなければ、取り消されるべきトランザクションのIotpTransIdが認識されていないか、または完全であるなら、要求に失敗してください。
o if the IotpTransId refers to a Ping Transaction then fail the
request, otherwise
o そうでなければ、IotpTransIdがPing Transactionについて言及するなら、要求に失敗してください。
o determine which Document Exchange to cancel and generate a Cancel
Block and send it to the other party
o どのDocument Exchangeを取り消したらよいか決定してください、そして、キャンセルBlockを生成してください、そして、それを相手に送ってください。
Note: Cancelling a transaction on an IOTP server typically arises for a business reason. For example a merchant may have attempted authentication several times without success and as a result decides to cancel the transaction. Therefore the process that decides to take this action needs to send a message from the process/server that made the business decision to the IOTP server with the instruction that the IOTP transaction should be cancelled.
以下に注意してください。 IOTPサーバでトランザクションを取り消すのはビジネス目的のために通常起こります。 例えば、商人は、成功なしで認証を何度か試みたかもしれなくて、トランザクションを取り消すとその結果決めます。 したがって、この行動を取ると決めるプロセスは、IOTPトランザクションが取り消されるべきであるという指示があるビジネス決定をしたプロセス/サーバからIOTPサーバまでのメッセージを送る必要があります。
4.5.4 Retransmitting Messages
4.5.4 メッセージを再送すること。
The server should periodically check for transactions where a message is expected in return but none has been received after a time that is dependent on factors such as:
サーバは、トランザクションがないかどうか定期的にどこにメッセージが代わりに予想されますが、なにも以下などの要素に依存する時の後に受け取られていないかをチェックするべきです。
o the Transport Mechanism being used;
o 使用されるTransport Mechanism。
o the time required to process encapsulated messages (e.g., Payment
messages) and
o そして処理するのに必要である時間が、メッセージが(例えば、Paymentメッセージ)であるとカプセル化した。
o whether or not human input is required.
o 人間の入力が必要であるかどうか
If no message has been received the original message should be resent. This should occur up to a maximum number of times dependent on the reliability of the Transport Mechanism being used.
メッセージを全く受け取っていないなら、オリジナルのメッセージを再送するべきです。 これは使用されるTransport Mechanismの信頼性に依存する回の最大数まで起こるべきです。
If no response is received after the required time then the Transaction should be "timed out". In this case, set the process state of the transaction to Failed, and a completion code of either:
必要な時の後に応答を全く受けないなら、Transactionは「外では、調節されているべきです」。 この場合、Failedへのトランザクションのプロセス状態、およびどちらかの完了コードを設定してください:
o TimedOutRcvr if the transaction can potentially recovered later,
or
o またはTimedOutRcvrがトランザクションであるなら潜在的に後で回復されていた状態でそうすることができる。
Burdett Informational [Page 70] RFC 2801 IOTP/1.0 April 2000
バーデット[70ページ]情報のRFC2801IOTP/2000年4月1日
o TimedOutNoRcvr if the transaction is non-recoverable
o TimedOutNoRcvrはトランザクションであるなら非回復可能です。
4.6 Client Role Processing Sequence
4.6 クライアント役割の処理系列
The "Client role" in IOTP is the Consumer Trading Role.
IOTPにおける「クライアントの役割」はConsumer Trading Roleです。
Note: A company or Organisation that is a Merchant, for example, may take on the Trading Role of a Consumer when making purchases or downloading or withdrawing electronic cash.
以下に注意してください。 電子現金を購買をするか、ダウンロードするか、または引き出すとき、例えば、マーチャントである会社かOrganisationがConsumerのTrading Roleを帯びるかもしれません。
More specifically the Consumer Role must be able to:
より明確にConsumer Roleは以下にできるに違いありません。
o Initiate a transaction (see section 4.6.1). These are divided
into:
o トランザクションを開始してください(セクション4.6.1を見てください)。 これらは以下に分割されます。
- payment related transactions and
- そして支払いがトランザクションを関係づけた。
- infrastructure transactions
- インフラストラクチャトランザクション
o Accept and process a message received from another role (see
section 4.6.2). This includes:
o 別の役割から受け取られたメッセージを、受け入れて、処理してください(セクション4.6.2を見てください)。 これは:
- identifying if the message belongs to a transaction that has
been received before
- メッセージが以前受け取られたことがあるトランザクションに属すかどうか特定します。
- handling duplicate messages
- 取り扱い写しメッセージ
- generating Transient errors if the servers that process the
input message are too busy to handle it
- 入力メッセージを処理するサーバがそれを扱うことができないくらい忙しいなら、Transientに誤りを生成します。
- processing the message if it is error free and, if appropriate,
producing a response to send back to the other role
- それが無料の誤りと適切であるときに応答を起こすことであるなら、もう片方の役割を送り返すためにメッセージを処理します。
o Cancel a current transaction if requested, for example by the User
(see section 4.6.3)
o 要求されるなら、例えば、Userで経常取引を中止してください。(セクション4.6.3を見ます)
o Re-transmit messages if a response was expected but has not been
received in a reasonable time (see section 4.6.4).
o 応答が予想されましたが、妥当な時間受けられていないなら(セクション4.6.4を見てください)、メッセージを再送してください。
4.6.1 Initiating Transactions
4.6.1 トランザクションを開始すること。
The Consumer Role may initiate a number of different types of transaction. Specifically:
Consumer Roleは多くの異なったタイプのトランザクションを開始するかもしれません。 明確に:
o an Inquiry Transaction (see section 9.2.1)
o 問い合せトランザクション(セクション9.2.1を見ます)
o a Ping Transaction (see section 9.2.2)
o ピングトランザクション(セクション9.2.2を見ます)
Burdett Informational [Page 71] RFC 2801 IOTP/1.0 April 2000
バーデット[71ページ]情報のRFC2801IOTP/2000年4月1日
o an Authentication Transaction (see section 9.1.6)
o 認証トランザクション(セクション9.1.6を見ます)
4.6.2 Processing Input Messages
4.6.2 処理入力メッセージ
Processing of Input Messages for a Consumer Role is the same as for an IOTP Server (see section 4.5.2) except in the area of checking for Errors in Block Sequence (for an IOTP Server see section 4.5.2.4). This is described below
IOTP Serverに関して、セクション4.5を見てください。Block Sequenceでエラーを確認する領域を除いて、Consumer RoleのためのInput Messagesの処理がIOTP Server(セクション4.5.2を見る)のように同じである、(.2 .4)。 これは以下で説明されます。
Note: The description of the processing for an IOTP Server includes consideration of multi-threading of input messages and multi-tasking of requests. For the Consumer Role - particularly if running on a stand-alone system such as a PC - use of multi-threading is a decision of the implementer of the consumer role IOTP solution.
以下に注意してください。 IOTP Serverのための処理の記述は要求が入力メッセージをマルチスレッド化して、マルチタスキングする考慮を含んでいます。 Consumer Roleに関しては、特にPCなどのスタンド・アローン・システムで動くならマルチスレッド化の使用は消費者役割のIOTPソリューションのimplementerの決定です。
4.6.2.1 Check for Errors in Block Sequence
4.6.2.1 ブロック法では、エラーを確認してください。
The handling of the following blocks is the same as for an IOTP Server (see section 4.5.2.4) except that the Consumer Role is substituted for IOTP Server Role:
以下のブロックの取り扱いはIOTP Serverのように同じです。(.4が)除くConsumer Roleがあるセクション4.5.2がIOTP Server Roleに代入されているのを見てください:
o Error and Cancel Blocks,
o 誤りとキャンセルブロック
o Inquiry Request and Response Blocks,
o 問い合せ要求と応答ブロック
o Authentication Request, Response and Status Blocks.
o 認証要求、応答、および状態ブロック。
For the other blocks a Consumer role might receive, the potential errors in the sequence that blocks arrive depends on the block. Blocks where checking for sequence is required are:
他のブロックに関して、Consumerの役割は受信されるかもしれません、系列における潜在的誤り。ブロックが届くのはブロックによります。 系列がないかどうかチェックするのが必要であるブロックは以下の通りです。
o TPO Block. Check as follows:
o TPOブロック。 以下の通りチェックしてください:
- if the input message also contains an Authentication Request
block and an Offer Response Block then there is a Hard Error,
otherwise
- また、入力メッセージがAuthentication RequestブロックとOffer Response Blockを含んでいるなら、Hard Errorがあります、そうではありません。
- if the input message also contains an Authentication Request
block and Authentication Status block then there is Hard Error
otherwise,
- そうでなければ、また、入力メッセージがAuthentication RequestブロックとAuthentication Statusブロックを含んでいるなら、Hard Errorがあります。
- if the input message also contains an Authentication Request
block and the IOTP Transaction is recognised by the Consumer
role's system, then there is a Hard Error, otherwise
- また、入力メッセージがAuthentication Requestブロックを含んでいて、IOTP TransactionがConsumerの役割のシステムによって認識されるなら、Hard Errorがあります、そうではありません。
Burdett Informational [Page 72] RFC 2801 IOTP/1.0 April 2000
バーデット[72ページ]情報のRFC2801IOTP/2000年4月1日
- if the input message also contains an Authentication Status
block and the IOTP Transaction is not recognised by the
Consumer role's system then there is a Hard Error, otherwise
- また、入力メッセージがAuthentication Statusブロックを含んでいて、IOTP TransactionがConsumerの役割のシステムによって認識されないなら、Hard Errorがあります、そうではありません。
- if input message also contains an Authentication Status Block
and the Authentication Status Block has not been sent after an
earlier Authentication Response message then there is a hard
error
- また、入力メッセージがAuthentication Status Blockを含んでいて、そしてそこの以前のAuthentication Responseメッセージが困難な誤りであった後にAuthentication Status Blockが送られないなら
- if input message also contains an Offer Response Block and the
IOTP Transaction is recognised by the Consumer role's system
then there is a Hard Error, otherwise
- また、入力メッセージがOffer Response Blockを含んでいて、IOTP TransactionがConsumerの役割のシステムによって認識されるなら、Hard Errorがあります、そうではありません。
- if the TPO Block occurs on its own and the IOTP Transaction is
recognised by the Consumer role's system then there is a Hard
Error
- TPO Blockがそれ自身のところに起こって、IOTP TransactionがConsumerの役割のシステムによって認識されるなら、Hard Errorがあります。
o Offer Response Block. Check as follows:
o 応答ブロックを提供してください。 以下の通りチェックしてください:
- if the Offer Response Block is part of a Brand Independent
Offer Exchange (see section 9.1.2.2) then there is no sequence
checking as it is part of the first message received, otherwise
- Offer Response BlockがBrand無党派Offer Exchangeの一部である、(見る、セクション9.1 .2 .2) 次に、それが受け取られた最初のメッセージの一部であるのでチェックする系列が全くない、そうではありませんさ
- if the Offer Response Block is not part of an IOTP Transaction
that is recognised by the Consumer role then there is a Hard
Error, otherwise
- Offer Response BlockがConsumerの役割によって認識されるIOTP Transactionの一部でないなら、Hard Errorがあります、そうではありません。
- if the Offer Response Block does not refer to an IOTP
transaction where a TPO Selection Block was the last message
sent then there is a Hard Error
- Offer Response BlockがTPO Selection Blockが最後のメッセージであったところとIOTPトランザクションを呼ばないなら、そしてそこに送るのは、Hard Errorです。
o Payment Exchange Block. Check as follows:
o 支払い交換ブロック。 以下の通りチェックしてください:
- if the Payment Exchange Block doesn't refer to an IOTP
Transaction that is recognised by the Consumer role's system
then there is a Hard Error, otherwise
- Payment Exchange BlockがConsumerの役割のシステムによって認識されるIOTP Transactionについて言及しないなら、Hard Errorがあります、そうではありません。
- if the Payment Exchange doesn't refer to an IOTP Transaction
where either a Payment Request or a Payment Exchange block was
most recently sent then there is a Hard Error
- Payment ExchangeがPayment RequestかPayment Exchangeブロックのどちらかがごく最近送られたIOTP Transactionについて言及しないなら、Hard Errorがあります。
o Payment Response Block. Check as follows:
o 支払い応答ブロック。 以下の通りチェックしてください:
- if the Payment Response Block doesn't refer to an IOTP
Transaction that is recognised by the Consumer role's system
then there is a Hard Error, otherwise
- Payment Response BlockがConsumerの役割のシステムによって認識されるIOTP Transactionについて言及しないなら、Hard Errorがあります、そうではありません。
Burdett Informational [Page 73] RFC 2801 IOTP/1.0 April 2000
バーデット[73ページ]情報のRFC2801IOTP/2000年4月1日
- if the Payment Response doesn't refer to an IOTOP Transaction
where either a Payment Request or a Payment Exchange block was
most recently sent then there is a Hard Error
- Payment ResponseがPayment RequestかPayment Exchangeブロックのどちらかがごく最近送られたIOTOP Transactionについて言及しないなら、Hard Errorがあります。
o Delivery Response Block. Check as follows:
o 配送応答ブロック。 以下の通りチェックしてください:
- if the Delivery Response Block doesn't refer to an IOTP
Transaction that is recognised by the Consumer role's system
then there is a Hard Error, otherwise
- Delivery Response BlockがConsumerの役割のシステムによって認識されるIOTP Transactionについて言及しないなら、Hard Errorがあります、そうではありません。
- If the Delivery Response doesn't refer to an IOTP Transaction
where either a Payment Request or a Payment Exchange block was
most recently sent then there is a Hard Error
- Delivery ResponseがPayment RequestかPayment Exchangeブロックのどちらかがごく最近送られたIOTP Transactionについて言及しないなら、Hard Errorがあります。
4.6.3 Cancelling a Transaction
4.6.3 トランザクションを取り消すこと。
This process cancels a current transaction on an Consumer role's system as a result of an external request from the user, or another system or server in the Consumer's role. The processing is the same as for an IOTP Server (see section 4.5.3).
このプロセスはConsumerの役割における別のユーザからの外部要求、システムまたはサーバの結果、Consumerの役割のシステムの上で経常取引を中止します。 処理はIOTP Serverのように同じです(セクション4.5.3を見てください)。
4.6.4 Retransmitting Messages
4.6.4 メッセージを再送すること。
The process of retransmitting messages is the same as for an IOTP Server (see section 4.5.4).
再送メッセージのプロセスはIOTP Serverのように同じです(セクション4.5.4を見てください)。
5. Security Considerations
5. セキュリティ問題
This section considers, from an IETF perspective how IOTP addresses security. The next section (see section 6. Digital Signatures and IOTP) describes how IOTP uses Digital Signatures when these are needed.
このセクションは、IETF見解からIOTPがどのようにセキュリティを扱うかを考えます。 次のセクション(セクション6のデジタルSignaturesとIOTPを見る)はこれらが必要であるときに、IOTPがどうDigital Signaturesを使用するかを説明します。
This section covers:
このセクションは以下をカバーします。
o determining whether to use digital signatures
o デジタル署名を使用するかどうか決定します。
o data privacy, and
o そしてデータプライバシー。
o payment protocol security.
o 支払いプロトコルセキュリティ。
5.1 Determining whether to use digital signatures
5.1 デジタル署名を使用するかどうか決定すること。
The use of digital signatures within IOTP are entirely optional. IOTP can work successfully entirely without the use of digital signatures.
IOTPの中のデジタル署名の使用は完全に任意です。 IOTPは完全なデジタル署名の使用なしで首尾よく働くことができます。
Ultimately it is up to the Merchant, or other trading role, to decide whether IOTP Messages will include signatures, and for the Consumer
結局、IOTP Messagesが署名を含むかどうか決めるために役割を取り引きして、Consumerのために他であり、それは、マーチャントまであるか、または他です。
Burdett Informational [Page 74] RFC 2801 IOTP/1.0 April 2000
バーデット[74ページ]情報のRFC2801IOTP/2000年4月1日
to decide whether carrying out a transaction without signatures is an acceptable risk. If Merchants discover that transactions without signatures are not being accepted, then they will either:
署名なしで取引を遂行するか否かに関係なく、決めるのは、許容リスクです。 Merchantsが、署名のないトランザクションが受け入れられていないと発見すると、そうするでしょう:
o start using signatures,
o 署名を使用し始めてください。
o find a method of working which does not need signatures, or
o または署名を必要としない働きのメソッドを見つけてください。
o accept a lower volume and value of business.
o ビジネスの下側の量と価値を受け入れてください。
A non-exhaustive list of the reasons why digital signatures might be used follows:
デジタル署名が使用されるかもしれない理由に関する非完全なりストは従います:
o the Merchant (or other trading role) wants to demonstrate that
they can be trusted. If, for example, a merchant generates an
Offer Response Signature (see section 7.19.2) using a certificate
from a trusted third party, known to the Consumer, then the
Consumer can check the signature and certificate and so more
reasonably rely on the offer being from the actual Organisation
the Merchant claims to be. In this case signatures using
asymmetric cryptography are likely to be required
o マーチャント(または、他の取り引きの役割)は、それらを信じることができるのを示したがっています。 例えば、商人がConsumerにおいて知られている信頼できる第三者機関からの証明書を使用することでOffer Response Signature(セクション7.19.2を見る)を生成するなら、Consumerは、署名と証明書をチェックするので、より合理的にマーチャントが主張する実際のOrganisationであるのから来ている申し出に依存できます。 この場合、非対称の暗号を使用する署名が必要でありそうです。
o the Merchant, or other Trading Role, want to generate a record of
the transaction that is fit for a particular purpose. For example,
with appropriate trust hierarchies, digital signatures could be
checked by the Consumer to determine:
o マーチャント、または他のTrading Roleが特定の目的に適しているトランザクションに関する記録を生成したがっています。 例えば、適切な信頼階層構造に、Consumerは、以下を決定するためにデジタル署名について問い合わせることができました。
- if it would be accepted by tax authorities as a valid record of
a transaction, or
- またはそれがトランザクションの有効な記録として税当局によって認められるなら。
- if some warranty, for example from a "Better Business Bureau"
orsimilar was being provided
- 何らかの保証であり、例えば、「商事改善協会」からorsimilarを提供していたなら
o the Payment Handler, or Delivery Handler, needs to know that the
request is unaltered and authorised. For example, in IOTP, details
of how much to pay is sent to the Consumer in the Offer Response
and then forwarded to the Payment Handler in a Payment Request. If
the request is not signed, the Consumer could change the amount
due by, for example, removing a digit. If the Payment Handler has
no access to the original payment information in the Offer
Response, then, without signatures, the Payment Handler cannot be
sure that the data has not been altered. Similarly, if the payment
information is not digitally signed, the Payment Handler cannot be
sure who is the Merchant that is requesting the payment
o Payment Handler、またはDelivery Handlerが、要求が非変更されて、認可されるのを知る必要があります。 例えば、IOTPでは、どのくらい支払うかに関する詳細をOffer ResponseでConsumerに送って、次に、Payment RequestでPayment Handlerに転送します。 要求が署名されないなら、Consumerは、例えば、ケタを取り除くことによって、支払われるべき金額を変えるかもしれません。 Payment HandlerがOffer Responseのオリジナルの決済情報に近づく手段を持っていないなら、署名がなければ、Payment Handlerはデータが変更されていないのを確信しているはずがありません。 同様に、決済情報がデジタルに署名されないなら、Payment Handlerはだれが支払いを要求しているマーチャントであるかを確信しているはずがありません。
o a Payment Handler or Delivery Handler wants to provide a non-
refutable record of the completion status of a Payment or
Delivery. If a Payment Response or Delivery Response is signed,
o Payment HandlerかDelivery HandlerがPaymentかDeliveryの完成状態の非反ぱく可能な記録を提供したがっています。 Payment ResponseかDelivery Responseが署名されるなら
Burdett Informational [Page 75] RFC 2801 IOTP/1.0 April 2000
バーデット[75ページ]情報のRFC2801IOTP/2000年4月1日
then the Consumer can later use the record of the Payment or
Delivery to prove that it occurred. This could be used, for
example, for customer care purposes.
そして、Consumerは、後でそれが起こったと立証するのにPaymentかDeliveryに関する記録を使用できます。 例えば、顧客ケア目的にこれを使用できました。
A non-exhaustive list of the reasons why digital signatures might not be used follows:
デジタル署名が使用されないかもしれない理由に関する非完全なりストは従います:
o trading roles are combined therefore changes to data made by the
consumer can be detected. One of the reasons for using signatures
is so that one trading role can determine if data has been changed
by the Consumer or some other party. However if the trading roles
have access to the necessary data, then it might be possible to
compare, for example, the payment information in the Payment
Request with the payment information in the Offer Response. Access
to the data necessary could be realised by, for example, the
Merchant and Payment Handler roles being carried out by the same
Organisation on the same system, or the Merchant and Payment
Handler roles being carried out on different systems but the
systems can communicate in some way. (Note this type of
communication is outside the current scope of IOTP)
o 取り引き役割は結合しています、したがって、消費者によって作られたデータへの変化を検出できます。 署名を使用する理由の1つは、1つの取り引き役割が、データがConsumerかある他のパーティーによって変えられたかどうか決定できるためのそうです。 しかしながら、取り引き役割が必要なデータに近づく手段を持っているなら、比較するのは例えば可能であるかもしれません、決済情報がOffer ResponseにあるPayment Requestの決済情報。 例えば異系統の上で行われるマーチャントと同じシステムの上で同じOrganisationによって行われるPayment Handlerの役割か、マーチャントとPayment Handlerの役割でデータに必要なアクセスをわかられることができましたが、システムは何らかの方法で交信できます。 (IOTPの現在の範囲の外にこのタイプに関するコミュニケーションがあるというメモ)
o the processing cost of the cryptography is too high. For example,
if a payment is being made of only a few cents, the cost of
carrying out all the cryptography associated with generating and
checking digital signatures might make the whole transaction
uneconomic. Co-locating trading roles, could help avoid this
problem.
o 暗号の加工費は高過ぎます。 例えば、支払いがほんの数セントで済んでいるなら、デジタル署名を生成して、チェックすると関連しているすべての暗号を行う費用で、全体のトランザクションは非経済的になるかもしれません。 取り引き役割の共同場所を見つけて、助けはこの問題を避けることができますか?
5.2 Symmetric and Asymmetric Cryptography
5.2 左右対称の、そして、非対称の暗号
The advantage of using symmetric keys with IOTP is that no Public Key Infrastructure need be set up and just the Merchant, Payment Handler and Delivery Handler need to agree on the shared secrets to use.
IOTPがある対称鍵を使用する利点は公開鍵暗号基盤が全くセットアップされる必要はなくて、まさしくマーチャント、Payment Handler、およびDelivery Handlerが、使用する共有秘密キーに同意する必要があるということです。
However the disadvantage of symmetric cryptography is that the Consumer cannot easily check the credentials of the Merchant, Payment Handler, etc. that they are dealing with. This is likely to reduce, somewhat, the trust that the Consumer will have carrying out the transaction.
しかしながら、左右対称の暗号の不都合はConsumerが容易にマーチャント、それらが対処しているPayment Handlerなどの資格証明書をチェックできないということです。 これは、トランザクションを行いながら、Consumerが持っている信頼をいくらか減少させそうです。
However it should be noted that even if asymmetric cryptography is being used, the Consumer does not NEED to be provided with any digital certificates as the integrity of the transaction is determined by, for example, the Payment Handler checking the Offer Response Signature copied to the Payment Request.
しかしながら、非対称の暗号が使用されていても、トランザクションの保全が例えば、Payment RequestにコピーされたOffer Response SignatureをチェックするPayment Handlerによって決定されるのでどんなデジタル証明書もConsumerが提供される必要はないことに注意されるべきです。
Note that symmetric, asymmetric or both types of cryptography may be used in a single transaction.
注意、そんなに左右対称で、非対称、または、暗号のタイプが中古のコネが単一取引であったならそうするかもしれない両方。
Burdett Informational [Page 76] RFC 2801 IOTP/1.0 April 2000
バーデット[76ページ]情報のRFC2801IOTP/2000年4月1日
5.3 Data Privacy
5.3 データプライバシー
Privacy of information is provided by sending IOTP Messages between the various Trading Roles using a secure channel such as [SSL/TLS]. Use of a secure channel within IOTP is optional.
[SSL/TLS]などの安全なチャンネルを使用することで様々なTrading Rolesの間にIOTP Messagesを送ることによって、情報のプライバシーを提供します。 IOTPの中の安全なチャンネルの使用は任意です。
5.4 Payment Protocol Security
5.4 支払いプロトコルセキュリティ
IOTP is designed to be completely blind to the payment protocol being used to effect a payment. From the security perspective, this means that IOTP neither helps, nor hinders, the achievement of payment security.
IOTPは、支払いプロトコルに支払いに作用するのに使用されることで完全に盲目であるために設計されています。 セキュリティ見解、IOTPが援助でない、また妨げないこの手段、支払いセキュリティの達成から。
If it is necessary to consider payment security from an IOTP perspective, then this should be included in the payment protocol supplement which describes how IOTP supports that payment protocol.
IOTP見解から支払いセキュリティを考えるのが必要であるなら、これはIOTPがどうその支払いプロトコルをサポートするかを説明する支払いプロトコル補足に含まれるべきです。
However what IOTP is designed to do is to use digital signatures to bind together the record, contained in a "response" message, of each trading exchange in a transaction. For example IOTP can bind together: an Offer, a Payment and a Delivery.
しかしながら、IOTPがするように設計されていることは記録を一緒にくくるのにデジタル署名を使用することになっています、トランザクションにおけるそれぞれの取り引き交換に関する「応答」メッセージに含まれて。 例えば、IOTPは一緒に付くことができます: 申し出、支払い、および配送。
6. Digital Signatures and IOTP
6. デジタル署名とIOTP
IOTP can work successfully without using any digital signatures although in an open networking environment it will be less secure - see 5. Security Considerations for a description of the factors that need to be considered.
開いているネットワーク環境で、それほど安全になりませんが、どんなデジタル署名も使用しないで、IOTPは首尾よく働くことができます--5を見てください。 考えられる必要がある要素の記述のためのセキュリティConsiderations。
However, this section describes how to use digital signatures in the many situations when they will be needed. Topics covered are:
しかしながら、このセクションはそれらが必要であるときに、多くの状況でデジタル署名を使用する方法を説明します。 カバーされた話題は以下の通りです。
o an overview of how IOTP uses digital signatures
o IOTPがどうデジタル署名を使用するかに関する概要
o how to check a signature is correctly calculated
o どう署名をチェックするかは正しく計算されます。
o how Payment Handlers and Delivery Handlers check they can carry
out payments or deliveries on behalf of a Merchant.
o 彼らがマーチャントを代表して支払いか配送から運ぶことができるどのようにPayment HandlersとDelivery Handlersチェック。
6.1 How IOTP uses Digital Signatures
6.1 IOTPはどうDigital Signaturesを使用するか。
In general, signatures when used with IOTP:
一般に、署名IOTPと共に使用されると:
o are always treated as IOTP Components (see section 7)
o いつもIOTP Componentsとして扱われます。(セクション7を見ます)
o contain digests of one or more IOTP Components or Trading Blocks,
possibly including other Signature Components, in any IOTP message
within the same IOTP Transaction
o 1IOTP ComponentsかTrading Blocksのダイジェストを含んでください、ことによると他のSignature Componentsを含んでいて、同じIOTP Transactionの中のどんなIOTPメッセージでも
Burdett Informational [Page 77] RFC 2801 IOTP/1.0 April 2000
バーデット[77ページ]情報のRFC2801IOTP/2000年4月1日
o identify:
o 特定します:
- which Organisation signed (originated) the signature, and
- そしてどのOrganisationが署名であると署名されるか、(溯源されます)。
- which Organisation(s) should process the signature in order to
check that the Action the Organisation should take can occur.
- どのOrganisation(s)がAction Organisationが取るはずであるのをチェックするために署名を処理するはずであるかは起こることができます。
Digital certificates may be associated with digital signatures if asymmetric cryptography is being used. However if symmetric cryptography is being used, then the digital certificate will be replaced by some identifier of the secret key to use.
非対称の暗号が使用されるなら、デジタル証明書はデジタル署名に関連しているかもしれません。 しかしながら、左右対称の暗号を使用していると、デジタル証明書を使用する秘密鍵に関する何らかの識別子に取り替えるでしょう。
Burdett Informational [Page 78] RFC 2801 IOTP/1.0 April 2000
バーデット[78ページ]情報のRFC2801IOTP/2000年4月1日
The way in which Signatures Components digest one or more elements is illustrated in the figure below.
Signatures Componentsが1つ以上の要素を消化する方法は以下の図で例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE SIGNATURE COMPONENT
IOTPメッセージ署名の部品
IOTP Message Signature Id = P1.3
|-Trans Ref Block digest TransRefBlk |-Manifest
| | ID=P1.1-----------------------------|->|-Digest of P1.1--
| |-Trans Id Comp digest TransIdComp | | |
| | ID = M1.2----------------------------|->|-Digest of M1.2--|
| |-Msg Id Comp. digest Signature | | |
| | ID = P1 -------------------|->|-Digest of M1.5--|
| | digest element | | |
|-Signatures Block | -----------------|->|-Digest of M1.7--|
| | ID=P1.2 | | digest element | | |
| |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--|
| |-Signature ID=M1.5---- | | | | |
| |-Signature ID=P1.4 | | Points to | -RecipientInfo* |
| |-Certificate ID=M1.6<---|-|---------------|------CertRef=M1.6 |
| | | | Certs to use | Sig.ValueRef=P1.4 |
| | | | | | |
| | | | | | |
|-Trading Block. ID=P1.5 | | | v |
| |-Comp. ID=M1.7---------- | -Value* ID=P1.4: |
| | | JtvwpMdmSfMbhK<--
| |-Comp. ID=P1.6 | r1Ln3vovbMQttbBI
| | | J8pxLjoSRfe1o6k
| |-Comp. ID=C1.4------------ OGG7nTFzTi+/0<-
| |-Comp. ID=C1.5
Digital signature of Manifest element
using certificate identified by CertRef
IOTPメッセージ署名イド=P1.3|-移-Ref BlockダイジェストTransRefBlk|-顕現| | IDはP1.1と等しいです。-----------------------------|、-、>|、-P1.1のダイジェスト--| |-移-Id CompダイジェストTransIdComp| | | | | IDはM1.2と等しいです。----------------------------|、-、>|、-M1.2のダイジェスト--| | |-エムエスジーId CompダイジェストSignature| | | | | IDはP1と等しいです。-------------------|、-、>|、-M1.5のダイジェスト--| | | ダイジェスト要素| | | |-署名ブロック| -----------------|、-、>|、-M1.7のダイジェスト--| | | IDはP1.2と等しいです。| | ダイジェスト要素| | | | |-署名ID=P1.3| | ---------------|、-、>|、-C1.4のダイジェスト--| | |-署名ID=M1.5---- | | | | | | |-署名ID=P1.4| | 示します。| -RecipientInfo*| | |-証明書ID=M1.6<。---|-|---------------|------CertRef=M1.6| | | | | 使用する本命| Sig.ValueRef=P1.4| | | | | | | | | | | | | | | |-ブロックを取り引きします。 IDはP1.5と等しいです。| | | v| | |-コンピュータ。 IDはM1.7と等しいです。---------- | -値*IDはP1.4と等しいです: | | | | JtvwpMdmSfMbhK<--| |-コンピュータ。 IDはP1.6と等しいです。| r1Ln3vovbMQttbBI| | | J8pxLjoSRfe1o6k| |-コンピュータ。 IDはC1.4と等しいです。------------ OGG7nTFzTi+/0<、-| |-コンピュータ。 IDは、CertRefによって特定された証明書を使用することでManifest要素のC1.5Digital署名と等しいです。
Elements that are digested can be in any IOTP Message
within the same IOTP Transaction
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
同じIOTP Transaction***********************************の中に消化される要素がどんなIOTP Messageにもあることができます。
Figure 10 Signature Digests
図10 署名ダイジェスト
Burdett Informational [Page 79] RFC 2801 IOTP/1.0 April 2000
バーデット[79ページ]情報のRFC2801IOTP/2000年4月1日
Note: The classic example of one signature signing another in IOTP, is when an Offer is first signed by a Merchant creating an "Offer Response" signature, which is then later signed by a Payment Handler together with a record of the payment creating a "Payment Receipt" signature. In this way, the payment in an IOTP Transaction is bound to the Merchant's offer.
以下に注意してください。 IOTPで別のものに署名する1つの署名に関する典型例はOfferが最初に次に後で「支払い領収書」署名を作成する支払いに関する記録と共にPayment Handlerが署名される「申し出応答」署名を作成するマーチャントによって署名される時です。 このように、IOTP Transactionの支払いはマーチャントの申し出に縛られます。
Note that one Manifest may be associated with multiple signature "Value" elements where each Value element contains a digital signature over the same Manifest, perhaps using the same (or different) signature algorithm but using a different certificate or shared secret key. Specifically it will allow the Merchant to agree on different shared secrets keys with their Payment Handler and Delivery Handler.
1ManifestがそれぞれのValue要素が同じManifestの上のデジタル署名を含む複数の署名「値」要素に関連しているかもしれないことに注意してください、恐らく同じで(異なる)の署名アルゴリズムを使用しますが、異なった証明書か共有された秘密鍵を使用して。 明確にそれで、マーチャントはそれらのPayment HandlerとDelivery Handlerがある異なった共有秘密キーキーに同意できるでしょう。
The detailed definitions of a Signature component are contained in section 7.19.
Signatureの部品の詳細な定義はセクション7.19に含まれています。
The remainder of this section contains:
このセクションの残りは以下を含んでいます。
o an example of how IOTP uses signatures
o IOTPがどう署名を使用するかに関する例
o how the OriginatorInfo and RecipientInfo elements within a
Signature Component are used to identify the Organisations
associated with the signature
o Signature Componentの中のOriginatorInfoとRecipientInfo要素は、署名に関連しているOrganisationsを特定するのにどう使用されるか。
o how IOTP uses signatures to prove actions complete successfully
o IOTPは、動きが完全であると首尾よく立証するのにどう署名を使用するか。
6.1.1 IOTP Signature Example
6.1.1 IOTP署名の例
An example of how signatures are used is illustrated in the figure below which shows how the various components and elements in a Baseline Purchase relate to one another. Refer to this example in the later description of how signatures are used to check a payment or delivery can occur (see section 6.3).
署名がどう使用されているかに関する例は以下の図で例証されます(Baseline Purchaseの様々なコンポーネントと要素がどうお互いに関連するかを示しています)。 署名が支払いをチェックするのに使用されるか、または配送がどう起こることができるかに関する(セクション6.3を見てください)後の記述におけるこの例を参照してください。
Note: A Baseline Purchase transaction has been used for illustration purposes. The usage of the elements and attributes is the same for all types of IOTP Transactions.
以下に注意してください。 Baseline Purchaseトランザクションはイラスト目的に使用されました。 IOTP Transactionsのすべてのタイプに、要素と属性の用法は同じです。
Burdett Informational [Page 80] RFC 2801 IOTP/1.0 April 2000
バーデット[80ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
TPO SELECTION BLOCK TPO BLOCK IOTPSIGNATURE BLOCK
| (Offer Response)
Brand Selection Organisation<--- |------Signature
Component Component | | Component
| | | -Manifest
|BrandList -Trading Role | |
| Ref Element | Originator |-Orig.
v (Merchant) ------------|--Info
Brand List Ref |
>Component |
| |-Protocol ------> Organisation Recipient |-Recipient
| | Amount Elem | Component <------------------|--Info
| | | | | Refs |
| |Pay|Protocol |Action -Trading Role |
| | | Ref |OrgRef Element |
| | v | (Payment Handler) |
| -PayProtocol-- |
| Elem ->Organisation Recipient |-Recipient
| | Component <--------------------Info
| | | Refs
| | -Trading Role
| | Element
| | (Delivery Handler
|
| OFFER RESPONSE BLOCK
| |
|BrandListRef |ActionOrgRef
| |
--Payment ---Delivery
Component Component
TPO選択ブロックTPOブロックIOTPSIGNATUREブロック| (申し出応答) ブランド選択機構<。--- |------署名コンポーネントコンポーネント| | コンポーネント| | | -顕現|BrandList取り引き役割| | | 審判要素| 創始者|-Orig v(商人)------------|--インフォメーションブランドリスト審判| >の部品| | |-プロトコル------>機構の受取人|-受取人| | 量のElem| コンポーネント<。------------------|--インフォメーション| | | | | 審判| | |賃金|プロトコル|動作の取り引き役割| | | | 審判|OrgRef要素| | | v| (支払い操作者) | | -PayProtocol--| | Elem>の機構の受取人|-受取人| | コンポーネント<。--------------------インフォメーション| | | 審判| | -取り引き役割| | 要素| | (配送操作者| | ブロック| | | BrandListRef| 応答ActionOrgRefを提供してください|、|、--、支払い、-、--、配送コンポーネントコンポーネント
The Manifest element in the Signature Component contains digests of: the Trans Ref Block (not shown); the Transaction ID Component (not shown); Organisation Components (Merchant, Payment Handler, Delivery Handler); the Brand List Component; the Order Component, the Payment Component the Delivery Component and the Brand Selection Component (if a Brand Dependent Purchase).
Signature ComponentのManifest要素は以下のダイジェストを含んでいます。 Trans Ref Block(目立ちません)。 Transaction ID Component(目立ちません)。 機構コンポーネント(商人、支払い操作者、配送操作者)。 ブランドリストコンポーネント。 オーダーコンポーネント、支払いコンポーネント、配送コンポーネントとブランド選択コンポーネント(ブランドの依存する購入であるなら)。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 11 Example use of Signatures for Baseline Purchase
図11 SignaturesのBaseline PurchaseのExample使用
Burdett Informational [Page 81] RFC 2801 IOTP/1.0 April 2000
バーデット[81ページ]情報のRFC2801IOTP/2000年4月1日
6.1.2 OriginatorInfo and RecipientInfo Elements
6.1.2 OriginatorInfoとRecipientInfo Elements
The OriginatorRef attribute of the OriginatorInfo element in the Signature Component contains an Element Reference (see section 3.5) that points to the Organisation Component of the Organisation which generated the Signature. In this example its the Merchant.
Signature ComponentのOriginatorInfo要素のOriginatorRef属性はSignatureを生成したOrganisationのOrganisation Componentを示すElement Reference(セクション3.5を見る)を含んでいます。 この例では、それはマーチャントです。
Note that the value of the content of the Attribute element with a Type attribute set to IOTP Signature Type must match the Trading Role of the Organisation which signed it. If it does not, then it is an error. Valid combinations are given in the table below.
IOTP Signature Typeに設定されたType属性があるAttribute要素の内容の値がそれに署名したOrganisationのTrading Roleに合わなければならないことに注意してください。 そうしないなら、それは誤りです。 テーブルで有効な組み合わせを以下に与えます。
IOTP Signature Type Valid Trading Role
IOTPの署名のタイプの有効な取り引き役割
OfferResponse Merchant
OfferResponse商人
PaymentResponse PaymentHandler
PaymentResponse PaymentHandler
DeliveryResponse DeliveryHandler
DeliveryResponse DeliveryHandler
AuthenticationRequest any role
AuthenticationRequestはあらゆる役割です。
AuthenticationResponse any role
AuthenticationResponseはあらゆる役割です。
PingRequest any role
PingRequestはあらゆる役割です。
PingResponse any role
PingResponseはあらゆる役割です。
The RecipientRefs attribute of the RecipientInfo element in the Signature Component contains Element References to the Organisation Components of the Organisations that should use the signature to verify that:
Signature ComponentのRecipientInfo要素のRecipientRefs属性は以下のことを確かめるのに署名を使用するはずであるOrganisationsのOrganisation ComponentsにElement Referencesを含んでいます。
o they have a pre-existing relationship with the Organisation that
generated the signature,
o 彼らには、署名を生成したOrganisationとの先在の関係があります。
o the data which is secured by the signature has not been changed,
o 署名で保証されるデータは変えられていません。
o the data has been signed correctly, and
o そしてデータが正しく署名された。
o the action they are required to undertake on behalf of the
Merchant is therefore authorised.
o したがって、彼らがマーチャントを代表して引き受けていなければならない動作は認可されます。
Note that if symmetric cryptography is being used then a separate RecipientInfo and Value elements for each different set of shared secret keys are likely within the Signature Component.
左右対称の暗号が使用されているならそれぞれの異なったセットの共有秘密キーキーのための別々のRecipientInfoとValue要素がSignature Componentの中でありそうであることに注意してください。
Burdett Informational [Page 82] RFC 2801 IOTP/1.0 April 2000
バーデット[82ページ]情報のRFC2801IOTP/2000年4月1日
Alternatively if asymmetric cryptography is being used then the RecpientRefs attribute of one RecipientInfo element may refer to multiple Organisation Components if they are all using the same certificates.
あるいはまた、非対称の暗号が使用されているなら、同じ証明書を使用することで1つのRecipientInfo要素のRecpientRefs属性は彼らがすべてなら複数のOrganisation Componentsについて言及するかもしれません。
6.1.3 Using signatures to Prove Actions Complete Successfully
6.1.3 Prove Actions Complete Successfullyに署名を使用すること。
Proving an action completed successfully, is achieved by signing data on Response messages. Specifically:
操作がResponseメッセージに関するデータに署名しながら首尾よく完了して、達成されると立証します。 明確に:
o on the Offer Response, when a Merchant is making an Offer to the
Consumer which can then be sent to either:
o Offer Responseでは、マーチャントがそしてときにそうすることができるConsumerに申し出ているときにはどちらかに送ってください:
- a Payment Handler to prove that the Merchant authorises
Payment, or
- またはマーチャントがPaymentを認可すると立証するPayment Handler。
- a Delivery Handler to prove that Merchant authorises Delivery,
provided other necessary authorisations are complete (see
below)
- 他の必要な免許が完全であるなら、そのマーチャントを立証するDelivery HandlerはDeliveryを認可します。(以下を見ます)
o on the Payment Response, when a Payment Handler is generating a
Payment Receipt which can be sent to either:
o Payment Responseでは、Payment HandlerがそうすることができるPayment Receiptを生成しているときにはどちらかに送ってください:
- a Delivery Handler, in a Delivery Request Block to authorise
Delivery together with the Offer Response signature, or
- またはOffer Response署名と共にDeliveryを認可するDelivery Request BlockのDelivery Handler。
- another Payment Handler, in a second Payment Request, to
authorise the second payment in a Value Exchange IOTP
Transaction
- 別のもの、Payment Handler、aでは、Payment Requestを後援して、Value Exchange IOTP Transactionにおける2番目の支払いを認可してください。
o Delivery Response, when a Delivery Handler is generating a
Delivery Note. This can be used to prove after the event what the
Delivery Handler said they would do
o Delivery HandlerがDelivery Noteを生成しているときの配送Response。 イベントの後に彼らが何をするかをDelivery Handlerが、言った立証するのにこれを使用できます。
o Authentication Response. One method of authenticating another
party to a trade is to send an Authentication Request specifying
that a Digital Signature should be used for authentication
o 認証応答。 別のパーティーを取り引きに認証する1つのメソッドはAuthentication RequestにDigital Signatureが認証に使用されるべきであると指定させることです。
o Transaction Status Inquiry. The Inquiry Response Block may be
digitally signed to attest to the authenticity of the response
o トランザクション資産調査。 Inquiry Response Blockは、応答の信憑性を証明するためにデジタルに署名されるかもしれません。
o Ping. The Ping Response may be digitally signed so that checks can
be made that the signature can be understood.
o 確認してください。 チェックをすることができる署名があることができるそうはPing Responseに理解されていた状態でデジタルに署名されるかもしれません。
This proof of an action may, in future versions of IOTP, also be used to prove after the event that the IOTP transaction occurred. For example to a Customer Care Provider.
また、動作のこの証拠は、イベントの後にIOTPトランザクションが起こったと立証するのにIOTPの将来のバージョンで使用されるかもしれません。 例えば、Customer Care Providerに。
Burdett Informational [Page 83] RFC 2801 IOTP/1.0 April 2000
バーデット[83ページ]情報のRFC2801IOTP/2000年4月1日
6.2 Checking a Signature is Correctly Calculated
6.2 Signatureをチェックするのは、Correctly Calculatedです。
Checking a signature is correctly calculated is part of checking for Message Level Errors (see section 4.3.2). It is included here so that all signature and security related considerations are kept together.
チェックして、署名は正しく計算されているのが、Message Level Errorsがないかどうかチェックする一部(セクション4.3.2を見る)であるということです。 それがここに含まれているので、すべての署名とセキュリティ関連する問題は一緒に保たれます。
Before a Trading Role can check a signature it must identify which of the potentially multiple Signature elements should be checked. The steps involved are as follows:
以前、Trading Roleはそれが特定しなければならない潜在的に複数のSignature要素についてチェックされるべきである署名をチェックできます。 かかわったステップは以下の通りです:
o check that a Signature Block is present and it contains one or
more Signature Components
o Signature Blockが存在していて、1Signature Componentsを含むのをチェックしてください。
o identify the Organisation Component which contains an OrgId
attribute for the Organisation which is carrying out the signature
check. If no or more than one Organisation Component is found then
it is an error
o 署名チェックを行っているOrganisationのためにOrgId属性を含むOrganisation Componentを特定してください。 いいえか1Organisation Componentが見つけられるなら、それは誤りです。
o use the ID attribute of the Organisation Component to find the
RecipientInfo element that contains a RecipientRefs attribute that
refers to that Organisation Component. Note there may be no
signatures to verify
o Organisation ComponentのID属性を使用して、そのOrganisation Componentについて言及するRecipientRefs属性を含むRecipientInfo要素を見つけてください。 確かめる署名が全くないかもしれないことに注意してください。
o check the Signature Component that contains the identified
RecipientInfo element as follows:
o 以下の特定されたRecipientInfo要素を含むSignature Componentをチェックしてください:
- use the SignatureValueRef and the SignatureAlgorithmRef
attributes to identify, respectively: the Value element that
contains the signature to be checked and the Signature
Algorithm element that describes the signature algorithm to be
used to verify the Signature, then
- それぞれ特定するSignatureValueRefとSignatureAlgorithmRef属性を使用してください: そして、チェックされるべき署名を含むValue要素とSignatureについて確かめるのに使用されるために署名アルゴリズムを説明するSignature Algorithm要素
- if the Signature Algorithm element indicates that asymmetric
cryptography is being used then use the SignatureCertRef to
identify the Certificate to be used by the signature algorithm
- Signature Algorithm要素が、非対称の暗号が使用されているのを示すならSignatureCertRefを使用して、Certificateを特定して、署名アルゴリズムで使用されてください。
- if Signature Algorithm element indicates that symmetric
cryptography is being used then the content of the
RecipientInfo element is used to identify the correct shared
secret key to use
- Signature Algorithm要素が、左右対称の暗号が使用されているのを示すなら、RecipientInfo要素の内容は、使用するために主要な正しい共有秘密キーを特定するのに使用されます。
- use the specified signature algorithm to check that the Value
Element correctly signs the Manifest Element
- 指定された署名アルゴリズムを使用して、Value Elementが正しくManifest Elementに署名するのをチェックしてください。
- check that the Digest Elements in the Manifest Element are
correctly calculated where Components or Blocks referenced by
the Digest have been received by the Organisation checking the
signature.
- Digestによって参照をつけられたComponentsかBlocksが署名をチェックするOrganisationによって受け取られたところでManifest ElementのDigest Elementsが正しく計算されるのをチェックしてください。
Burdett Informational [Page 84] RFC 2801 IOTP/1.0 April 2000
バーデット[84ページ]情報のRFC2801IOTP/2000年4月1日
6.3 Checking a Payment or Delivery can occur
6.3 PaymentかDeliveryをチェックするのは起こることができます。
This section describes the processes required for a Payment Handler or Delivery Handler to check that a payment or delivery can occur. This may include checking signatures if this is specified by the Merchant.
このセクションはPayment HandlerかDelivery Handlerが支払いか配送が起こることができるのをチェックしなければならなかったプロセスについて説明します。 これは、これがマーチャントによって指定されるなら署名をチェックするのを含むかもしれません。
In outline the steps are:
アウトラインでは、ステップは以下の通りです。
o check that the Payment Request or Delivery Request has been sent
to the correct Organisation
o Payment RequestかDelivery Requestが正しいOrganisationに送られたのをチェックしてください。
o check that correct IOTP components are present in the request, and
o そして正しいIOTPの部品が要求に存在しているのをチェックしてください。
o check that the payment or delivery is authorised
o 支払いか配送が認可されているのをチェックしてください。
For clarity and brevity the following terms or phrases are used in this section:
明快と簡潔さのために、以下の用語か句がこのセクションで使用されます:
o a "Request Block" is used to refer to either a Payment Request
Block (see section 8.7) or a Delivery Request Block (see section
8.10) unless specified to the contrary
o それと反対に指定されない場合、「要求ブロック」は、Payment Request Block(セクション8.7を見る)かDelivery Request Block(セクション8.10を見る)のどちらかについて言及するのに使用されます。
o a "Response Block" is used to refer to either a Payment Response
Block (see section 8.9) or a Delivery Response Block (see section
8.11)
o 「応答ブロック」は、Payment Response Block(セクション8.9を見る)かDelivery Response Blockのどちらかについて言及するのに使用されます。(セクション8.11を見ます)
o an "Action" is used to refer to an action which occurs on receipt
of a Request Block. Actions can be either a Payment or a Delivery
o 「動作」は、Request Blockを受け取り次第起こる動作について言及するのに使用されます。 動作は、PaymentかDeliveryのどちらかであるかもしれません。
o an "Action Organisation", is used to refer to the Payment Handler
or Delivery Handler that carries out an Action
o 「動作機構」は、Actionを行うPayment HandlerかDelivery Handlerについて言及するのに使用されます。
o a "Signer of an Action", is used to refer to the Organisations
that sign data about an Action to authorise the Action, either in
whole or in part
o 「動作の署名者」は、Actionを全体か一部認可するためにActionに関するデータに署名するOrganisationsについて言及するのに使用されます。
o a "Verifier of an Action", is used to refer to the Organisations
that verify data to determine if they are authorised to carry out
the Action
o 「動作の検証」は、彼らがActionを行うのが認可されるかどうか決定するためにデータについて確かめるOrganisationsについて言及するのに使用されます。
o an ActionOrgRef attribute contains Element References which can be
used to identify the "Action Organisation" that should carry out
an Action
o ActionOrgRef属性はActionを行うべきである「動作機構」を特定するのに使用できるElement Referencesを含んでいます。
Burdett Informational [Page 85] RFC 2801 IOTP/1.0 April 2000
バーデット[85ページ]情報のRFC2801IOTP/2000年4月1日
6.3.1 Check Request Block sent Correct Organisation
6.3.1 チェックRequest BlockはCorrect Organisationを送りました。
Checking the Request Block was sent to the correct Organisation varies depending on whether the request refers to a Payment or a Delivery.
要求がPaymentかDeliveryについて言及するかどうかによって、Request Blockが送られた照合は正しいOrganisationに異なります。
6.3.1.1 Payment
6.3.1.1 支払い
In outline a Payment Handler checks if it can accept or make a payment by identifying the Payment Component in the Payment Request Block it has received, then using the ID of the Payment Component to track through the Brand List and Brand Selection Components to identify the Organisation selected by the Consumer and then checking that this Organisation is itself.
アウトラインでは、Payment Handlerは、それがそれが受けたPayment Request BlockでPayment Componentを特定することによって支払いを受け入れるか、または済ませることができるかをチェックします、次に、Consumerによって選択されたOrganisationを特定するためにBrand ListとBrand Selection Componentsを通して追跡するのにPayment ComponentのIDを使用して、次に、このOrganisationがそれ自体であることをチェックして。
Burdett Informational [Page 86] RFC 2801 IOTP/1.0 April 2000
バーデット[86ページ]情報のRFC2801IOTP/2000年4月1日
The way data is accessed to do this is illustrated in the figure below.
データがこれをするためにアクセスされる方法は以下の図で例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Start
|
v
Brand List<--------------------------+-----------Payment
Component BrandListRef | Component
| |
|-Brand<-------------------------- |
| Element BrandRef | |
| | Brand Selection
| |Protocol Component
| | AmountRefs | |
| v Protocol | |
|-Protocol Amount<---------------- |
| Element---------- AmountRef |
| | | |
| |Currency |Pay |
| | AmountRefs |Protocol |
| v |Ref |
|-Currency Amount | |
| Element<---------|----------------
| |
-PayProtocol<-----
Element---------------------->Organisation
Action Component
OrgRef |
-Trading Role
Element
(Payment Handler)
*始め| Brand List<に対して--------------------------+-----------支払いコンポーネントBrandListRef| コンポーネント| | |-ブランド<。-------------------------- | | 要素BrandRef| | | | ブランド選択| |プロトコルコンポーネント| | AmountRefs| | | プロトコルに対して| | |-プロトコル量の<。---------------- | | 要素---------- AmountRef| | | | | | |通貨|賃金| | | AmountRefs|プロトコル| | v|審判| |-貨幣額| | | 要素<。---------|---------------- | | -PayProtocol<。----- 要素---------------------->機構動作コンポーネントOrgRef| -取り引き役割の要素(支払い操作者)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 12 Checking a Payment Handler can carry out a Payment
図12 Checking a Payment HandlerはPaymentを行うことができます。
The following describes the steps involved and the checks which need to be made:
以下は作られている必要があるかかわったステップとチェックについて説明します:
o Identify the Payment Component (see section 7.9) in the Payment
Request Block that was received.
o 受け取られたPayment Request BlockでPayment Component(セクション7.9を見る)を特定してください。
o Identify the Brand List and Brand Selection Components for the
Payment Component. This involves:
o 支払いコンポーネントのためにブランドリストとブランド選択コンポーネントを特定してください。 これは以下にかかわります。
Burdett Informational [Page 87] RFC 2801 IOTP/1.0 April 2000
バーデット[87ページ]情報のRFC2801IOTP/2000年4月1日
- identifying the Brand List Component (see section 7.7) where
the value of its ID attribute matches the BrandListRef
attribute of the Payment Component. If no or more than one
Brand List Component is found there is an error.
- ID属性の値がPayment ComponentのBrandListRef属性に合っているところでBrand List Componentを特定します(セクション7.7を見ます)。 いいえか1Brand List Componentが見つけられるなら、誤りがあります。
- identifying the Brand Selection Component (see section 7.8)
where the value of its BrandListRef attribute matches the
BrandListRef of the Payment Component. If no or more than one
matching Brand Selection Component is found there is an error.
- BrandListRef属性の値がPayment ComponentのBrandListRefに合っているところでBrand Selection Componentを特定します(セクション7.8を見ます)。 いいえか1合っているBrand Selection Componentが見つけられるなら、誤りがあります。
o Identify the Brand, Protocol Amount, Pay Protocol and Currency
Amount elements within the Brand List that have been selected by
the Consumer as follows:
o 以下のConsumerによって選択されたBrand Listの中でBrand、プロトコルAmount、Payプロトコル、およびCurrency Amount要素を特定してください:
- the Brand Element (see section 7.7.1) selected is the element
where the value of its Id attribute matches the value of the
BrandRef attribute in the Brand Selection. If no or more than
one matching Brand Element is found then there is an error.
- 選択されたBrand Element(セクション7.7.1を見る)はId属性の値がBrand SelectionのBrandRef属性の値に合っている要素です。 いいえか1合っているBrand Elementが見つけられるなら、誤りがあります。
- the Protocol Amount Element (see section 7.7.3) selected is the
element where the value of its Id attribute matches the value
of the ProtocolAmountRef attribute in the Brand Selection
Component. If no or more than one matching Protocol Amount
Element is found there is an error
- Amount Element(セクション7.7.3を見る)が選択したプロトコルはId属性の値がBrand Selection ComponentのProtocolAmountRef属性の値に合っている要素です。 ノーか1合っているプロトコルAmount Elementが見つけられるなら、誤りがあります。
- the Pay Protocol Element (see section 7.7.5) selected is the
element where the value of its Id attribute matches the value
of the PayProtocolRef attribute in the identified Protocol
Amount Element. If no or more than one matching Pay Protocol
Element is found there is an error
- プロトコルElement(セクション7.7.5を見る)が選択したPayはId属性の値が特定されたプロトコルAmount ElementのPayProtocolRef属性の値に合っている要素です。 ノーか1合っているPayプロトコルElementが見つけられるなら、誤りがあります。
- the Currency Amount Element (see section 7.7.4) selected is the
element where the value of its Id attribute matches the value
of the CurrencyAmountRef attribute in the Brand Selection
Component. If no or more than one matching Currency Amount
element is found there is an error
- 選択されたCurrency Amount Element(セクション7.7.4を見る)はId属性の値がBrand Selection ComponentのCurrencyAmountRef属性の値に合っている要素です。 ノーか1つ以上の合っているCurrency Amount要素が見つけられるなら、誤りがあります。
o Check the consistency of the references in the Brand List and
Brand Selection Components:
o Brand ListとBrand Selection Componentsの参照の一貫性をチェックしてください:
- check that an Element Reference exists in the
ProtocolAmountRefs attribute of the identified Brand Element
that matches the Id attribute of the identified Protocol Amount
Element. If no or more than one matching Element Reference can
be found there is an error
- Element Referenceが特定されたプロトコルAmount ElementのId属性に合っている特定されたBrand ElementのProtocolAmountRefs属性で存在するのをチェックしてください。 いいえか1合っているElement Referenceを見つけることができるなら、誤りがあります。
Burdett Informational [Page 88] RFC 2801 IOTP/1.0 April 2000
バーデット[88ページ]情報のRFC2801IOTP/2000年4月1日
- check that the CurrencyAmountRefs attribute of the identified
Protocol Amount element contains an element reference that
matches the Id attribute of the identified Currency Amount
element. If no or more than one matching Element Reference is
found there is an error.
- 特定されたプロトコルAmount要素のCurrencyAmountRefs属性が特定されたCurrency Amount要素のId属性に合っている要素参照を含むのをチェックしてください。 いいえか1合っているElement Referenceが見つけられるなら、誤りがあります。
- check the consistency of the elements in the Brand List.
Specifically, the selected Brand, Protocol Amount, Pay Protocol
and Currency Amount Elements are all child elements of the
identified Brand List Component. If they are not there is an
error.
- Brand Listの要素の粘性をチェックしてください。 明確に、選択されたBrand、プロトコルAmount、Payプロトコル、およびCurrency Amount Elementsはすべて特定されたBrand List Componentの子供要素です。 それらがそうなら、誤りがありません。
o Check that the Payment Handler that received the Payment Request
Block is the Payment Handler selected by the Consumer. This
involves:
o Payment Request Blockを受けたPayment HandlerがConsumerによって選択されたPayment Handlerであることをチェックしてください。 これは以下にかかわります。
- identifying the Organisation Component for the Payment Handler.
This is the Organisation Component where its ID attribute
matches the ActionOrgRef attribute in the identified Pay
Protocol Element. If no or more than one matching Organisation
Component is found there is an error
- Payment HandlerのためにOrganisation Componentを特定します。 これはID属性が特定されたPayプロトコルElementでActionOrgRef属性に合っているOrganisation Componentです。 いいえか1合っているOrganisation Componentが見つけられるなら、誤りがあります。
- checking the Organisation Component has a Trading Role Element
with a Role attribute of PaymentHandler. If not there is an
error
- Organisation Componentをチェックするのにおいて、PaymentHandlerのRole属性があるTrading Role Elementがあります。 そうでなければ、誤りがあります。
- finally, if the identified Organisation Component is not the
same as the Organisation that received the Payment Request
Block, then there is an error.
- 最終的に、特定されたOrganisation ComponentがPayment Request Blockを受けたOrganisationと同じでないなら、誤りがあります。
Burdett Informational [Page 89] RFC 2801 IOTP/1.0 April 2000
バーデット[89ページ]情報のRFC2801IOTP/2000年4月1日
6.3.1.2 Delivery
6.3.1.2 配送
The way data is accessed by a Delivery Handler in order to check that it may carry out a delivery is illustrated in the figure below.
データが配送を行うかもしれないのをチェックするためにDelivery Handlerによってアクセスされる方法は以下の図で例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Start
|
v
Delivery
Component
|
|ActionOrgRef
|
v
Organisation
Component
|
-Trading Role
Element
(Delivery Handler)
*始め| Delivery Componentに対して| |ActionOrgRef| Organisation Componentに対して| -取り引き役割の要素(配送操作者)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 13 Checking a Delivery Handler can carry out a Delivery
図13 Checking a Delivery HandlerはDeliveryを行うことができます。
The steps involved are as follows:
かかわったステップは以下の通りです:
o Identify the Delivery Component in the Delivery Request Block. If
there is no or more than one matching Delivery Component there is
an error
o 配送要求ブロックで配送コンポーネントを特定してください。 あれば、そこのいいえか1合っているDelivery Componentが誤りです。
o Use the ActionOrgRef attribute of the Delivery Component to
identify the Organisation Component of the Delivery Handler. If
there is no or more than one matching Organisation Component there
is an error
o Delivery ComponentのActionOrgRef属性を使用して、Delivery HandlerのOrganisation Componentを特定してください。 あれば、そこのいいえか1合っているOrganisation Componentが誤りです。
o If the Organisation Component for the Delivery Handler does not
have a Trading Role Element with a Role attribute of
DeliveryHandler there is an error
o Delivery HandlerにはDeliveryHandlerのRole属性がそこにある状態でTrading Role ElementがないのでOrganisation Componentが誤りであるなら
o Finally, if the Organisation that received the Delivery Request
Block does not identify the Organisation Component for the
Delivery Handler as itself, then there is an error.
o 最終的に、Delivery Request Blockを受けたOrganisationが、Delivery HandlerのためのOrganisation Componentがそれ自体であると認識しないなら、誤りがあります。
Burdett Informational [Page 90] RFC 2801 IOTP/1.0 April 2000
バーデット[90ページ]情報のRFC2801IOTP/2000年4月1日
6.3.2 Check Correct Components present in Request Block
6.3.2 Request Blockの現在のCorrect Componentsをチェックしてください。
Check that the correct components are present in the Payment Request Block (see section 8.7) or in the Delivery Request Block (see section 8.10).
正しいコンポーネントがPayment Request Block(セクション8.7を見る)かDelivery Request Blockに存在しているのをチェックしてください(セクション8.10を見てください)。
If components are missing, there is an error.
コンポーネントがなくなるなら、誤りがあります。
6.3.3 Check an Action is Authorised
6.3.3 チェックしてください、ActionはAuthorisedです。
The previous steps identified the Action Organisation and that all the necessary components are present. This step checks that the Action Organisation is authorised to carry out the Action.
前のステップは、Action Organisationであって、すべての必要なコンポーネントが存在しているのを特定しました。 このステップは、Action OrganisationがActionを行うのが認可されるのをチェックします。
In outline the Action Organisation will identifies the Merchant, checks that it has a pre-existing agreement with the Merchant that allows it carry out the Action and that any constraints implied by that agreement are being followed, then, if signatures are required, it checks that they sign the correct data.
Action Organisationが望んでいるアウトラインは、中では、マーチャントを特定して、次に、それにはActionからそれにキャリーを許すマーチャントとの先在の協定があって、その協定で含意されたどんな規制も続かれているのをチェックします、署名が必要であるなら正しいデータに署名するのはチェックします。
The steps involved are as follows:
かかわったステップは以下の通りです:
o Identify the Merchant. This is the Organisation Component with a
Trading Role Element which has a Role attribute with a value of
Merchant. If no or more than one Trading Role Element is found,
there is an error
o 商人を特定してください。 これはマーチャントの値があるRole属性を持っているTrading Role ElementとOrganisation Componentです。 いいえか1Trading Role Elementが見つけられるなら、誤りがあります。
o Check the Action Organisation's agreements with the Merchant
allows the Action to be carried out. To do this the Action
Organisation must check that:
o マーチャントとのAction Organisationの協定が行われるのをActionを許容するチェック。 これをするために、Action Organisationは、以下のことをチェックしなければなりません。
- the Merchant is known and a pre-existing agreement exists for
the Action Organisation to be their agent for the payment or
delivery
- マーチャントは知られています、そして、先在の協定は、Action Organisationが支払いか配送のための彼らのエージェントであるために存在しています。
- they are allowed to take part in the type of IOTP transaction
that is occurring. For example a Payment Handler may have
agreed to accept payments as part of a Baseline Purchase, but
not make payments as part of a Baseline Refund
- 彼らは起こっているIOTPトランザクションのタイプに参加できます。 例えば、Payment Handlerは、Baseline Purchaseの一部として支払いを認めますが、Baseline Refundの一部として支払いをしないのに同意したかもしれません。
- any constraints in their agreement with the Merchant are being
followed, for example, whether or not an Offer Response
signature is required
- Offer Response署名が必要であるか否かに関係なく、マーチャントとの彼らの協定におけるどんな規制にも例えば、続かれています。
o Check the signatures are correct. If signatures are required then
they need to be checked. This involves:
o チェックしてください。署名は正しいです。 署名が必要であるなら、それらは、チェックされる必要があります。 これは以下にかかわります。
Burdett Informational [Page 91] RFC 2801 IOTP/1.0 April 2000
バーデット[91ページ]情報のRFC2801IOTP/2000年4月1日
- Identifying the correct signatures to check. This involves the
Action Organisation identifying the Signature Components that
contain references to the Action Organisation (see 6.3.1).
Depending on the IOTP Transaction being carried out (see
section 9) either one or two signatures may be identified
- チェックするために正しい署名を特定します。 これはAction Organisationの参照を含むSignature Componentsを特定するAction Organisationにかかわります(6.3に.1を見てください)。 行われる(セクション9を見ます)IOTP Transactionによって、どちらかか2つの署名が特定されるかもしれません。
- checking that the Signature Components are correct. This
involves checking that Digest elements exist within the
Manifest Element that refer to the necessary Trading Components
(see section 6.3.3.1).
- Signature Componentsが正しいのをチェックします。 セクション6.3を見てください。これが、Digest要素が必要なTrading Componentsについて言及するManifest Elementの中に存在するのをチェックすることを伴う、(.3 .1)。
6.3.3.1 Check the Signatures Digests are correct
6.3.3.1 チェックしてください、Signatures Digestsは正しいです。
All Signature Components contained within IOTP Messages must include Digest elements that refer to:
IOTP Messagesの中に含まれたすべてのSignature Componentsが以下のことに参照されるDigest要素を含まなければなりません。
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Signature Component. This binds the
globally unique IotpTransId to other components which make up the
IOTP Transaction
o Signature Componentを含むIOTPメッセージのTransaction Id Component(セクション3.3.1を見ます)。 これはIOTP Transactionを作る他のコンポーネントにグローバルにユニークなIotpTransIdを縛ります。
o the Transaction Reference Block (see section 3.3) of the first
IOTP Message that contained the signature. This binds the
IotpTransId with information about the IOTP Message contained
inside the Message Id Component (see section 3.3.2).
o 署名を含んだ最初のIOTP MessageのTransaction Reference Block(セクション3.3を見ます)。 これはMessage Id Componentの中に含まれたIOTP Messageの情報でIotpTransIdを縛ります(セクション3.3.2を見てください)。
Check that each Signature Component contains Digest elements that refer to the correct data required.
各Signature Componentが必要である正しいデータを示すDigest要素を含むのをチェックしてください。
The Digest elements that need to be present depend on the Trading Role of the Organisation which generated (signed) the signature:
存在している必要があるDigest要素を署名を生成した(署名されます)OrganisationのTrading Roleに依存します:
o if the signer of the signature is a Merchant then:
o その時署名の署名者がマーチャントであるなら:
- Digest elements must be present for all the components in the
Request Block apart from the Brand Selection Component which is
optional
- 任意のBrand Selection Componentは別として、ダイジェスト要素はRequest Blockのすべてのコンポーネントのために存在していなければなりません。
o if the signer of the signature is a Payment Handler then Digest
elements must be present for:
o 署名の署名者がPayment Handlerであるなら、Digest要素は以下のために存在していなければなりません。
- the Signature Component signed by the Merchant, and optionally
- マーチャントによって任意に署名されたSignature Component
- one or more Signature Components signed by the previous Payment
Handler(s) in the Transaction.
- 1Signature ComponentsがTransactionの前のPayment Handler(s)で署名しました。
Burdett Informational [Page 92] RFC 2801 IOTP/1.0 April 2000
バーデット[92ページ]情報のRFC2801IOTP/2000年4月1日
7. Trading Components
7. 取り引きコンポーネント
This section describes the Trading Components used within IOTP. Trading Components are the child XML elements which occur immediately below a Trading Block as illustrated in the diagram below.
このセクションはIOTPの中で使用されたTrading Componentsについて説明します。 取り引きComponentsは以下のダイヤグラムで例証されるようにTrading Blockのすぐ下に現れる子供XML要素です。
Burdett Informational [Page 93] RFC 2801 IOTP/1.0 April 2000
バーデット[93ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE <----------- IOTP Message - an XML Document
| which is transported between the
| Trading Roles
|-Trans Ref Block <----- Trans Ref Block - contains
| | information which describes the
| | IOTP Transaction and the IOTP
Message.
--------> | |-Trans Id Comp. <--- Transaction Id Component -
| | | uniquely identifies the IOTP
| | | Transaction. The Trans Id
| | | Components are the same across
| | | all IOTP messages that comprise
| | | a single IOTP transaction.
| | |-Msg Id Comp. <----- Message Id Component -
| | identifies and describes an IOTP
| | Message within an IOTP
| | Transaction
| |-Signature Block <----- Signature Block (optional) -
| | | contains one or more Signature
| | | Components and their associated
| | | Certificates
| ---> | |-Signature Comp. <-- Signature Component - contains
| | | | digital signatures. Signatures
| | | | may sign digests of the Trans Ref
| | | | Block and any Trading Component
| | | | in any IOTP Message in the same
| | | | IOTP Transaction.
| | | |-Certificate Comp. <- Certificate Component. Used to
| | | check the signature.
Trading |-Trading Block <-------- Trading Block - an XML Element
Components | |-Trading Comp. within an IOTP Message that
| | | |-Trading Comp. contains a predefined set of
| ---> | |-Trading Comp. Trading Components
| | |-Trading Comp.
| | |-Trading Comp. <----- Trading Components - XML
| | Elements within a Trading Block
| |-Trading Block that contain a predefined set of
--------> | |-Trading Comp. XML elements and attributes
| |-Trading Comp. containing information required
| |-Trading Comp. to support a Trading Exchange
| |-Trading Comp.
| |-Trading Comp.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
IOTPメッセージ<。----------- IOTPメッセージ--XMLドキュメント| どれが間に輸送されるか。| 取り引き役割|-移-審判ブロック<。----- 移-Ref Block--、含有| | 情報、どれ、説明| | IOTPトランザクションとIOTPメッセージ。 -------->| |-移-イドコンピュータ。 <-- トランザクションイドコンポーネント、-| | | 唯一、IOTPを特定します。| | | トランザクション。 移-イド| | | コンポーネントは横切って同じです。| | | それが包括するすべてのIOTPメッセージ| | | ただ一つのIOTPトランザクション。 | | |-エムエスジーイドコンピュータ。 <、-、-、-、-- メッセージイドコンポーネント、-| | IOTPを特定して、説明します。| | IOTPの中のメッセージ| | トランザクション| |-署名欄<。----- 署名欄(任意の)、-| | | 1Signatureを含んでいます。| | | そして、コンポーネント、それら、関連| | | 証明書| --->| |-署名コンピュータ。 <-- 署名Component--、含有| | | | デジタル署名。 署名| | | | Trans Refのダイジェストに署名するかもしれません。| | | | ブロックとどんなTrading Component| | | | 同じくらいのどんなIOTP Messageでも| | | | IOTPトランザクション。 | | | |-コンピュータを証明してください。 <。 コンポーネントを証明してください。 以前はよく| | | 署名をチェックしてください。 取り引き|-通商圏<。-------- 通商圏--XML要素成分| |-取り引きComp、IOTP Message、それ| | | |-取り引きComp、事前に定義されたセットを含んでいます。| --->| |-コンピュータを取り引きします。 取り引きコンポーネント| | |-コンピュータを取り引きします。 | | |-コンピュータを取り引きします。 <、-、-、-、-- 取り引きコンポーネント--XML| | 通商圏の中のElements| |-Blockを取り引きすることそれが事前に定義されたセットを含む。-------->| |-コンピュータを取り引きします。 XML要素と属性| |-取り引きComp情報を含むのが必要です。| |-取り引きComp Trading Exchangeをサポートするために| |-コンピュータを取り引きします。 | |-コンピュータを取り引きします。 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 14 Trading Components
図14 取り引きコンポーネント
Burdett Informational [Page 94] RFC 2801 IOTP/1.0 April 2000
バーデット[94ページ]情報のRFC2801IOTP/2000年4月1日
The Trading Components described in this section are listed below in approximately the sequence they are likely to be used:
このセクションで説明されたTrading Componentsはおそらく使用されるために以下におよそ系列で記載されています:
o Protocol Options Component
o プロトコルオプションコンポーネント
o Authentication Request Component
o 認証要求コンポーネント
o Authentication Response Component
o 認証応答コンポーネント
o Trading Role Information Request Component
o 取り引き役割の情報要求コンポーネント
o Order Component
o オーダーコンポーネント
o Organisation Component
o 機構コンポーネント
o Brand List Component
o ブランドリストコンポーネント
o Brand Selection Component
o ブランド選択コンポーネント
o Payment Component
o 支払いコンポーネント
o Payment Scheme Component
o 支払い体系コンポーネント
o Payment Receipt Component
o 支払い領収書の部品
o Delivery Component
o 配送コンポーネント
o Delivery Data Component
o 配送データ構成要素
o Delivery Note Component
o 納品受領書の部品
o Signature Component
o 署名コンポーネント
o Certificate Component
o 証明書の部品
o Error Component
o 誤りコンポーネント
Note that the following components are listed in other sections of this specification:
以下のコンポーネントがこの仕様の他のセクションで記載されていることに注意してください:
o Transaction Id Component (see section 3.3.1)
o トランザクションイドコンポーネント(セクション3.3.1を見ます)
o Message Id Component (see section 3.3.2)
o メッセージイドコンポーネント(セクション3.3.2を見ます)
Burdett Informational [Page 95] RFC 2801 IOTP/1.0 April 2000
バーデット[95ページ]情報のRFC2801IOTP/2000年4月1日
7.1 Protocol Options Component
7.1 プロトコルオプションコンポーネント
Protocol options are options which apply to the IOTP Transaction as a whole. Essentially it provides a short description of the entire transaction and the net location which the Consumer role should branch to if the IOTP Transaction is successful.
プロトコルオプションは全体でIOTP Transactionに適用されるオプションです。 IOTP Transactionがうまくいくなら、本質的にはそれはConsumerの役割が分岐するべきである全体のトランザクションとネットの位置の短い記述を提供します。
The definition of a Protocol Options Component is as follows.
プロトコルOptions Componentの定義は以下の通りです。
<!ELEMENT ProtocolOptions EMPTY >
<!ATTLIST ProtocolOptions
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
SenderNetLocn CDATA #IMPLIED
SecureSenderNetLocn CDATA #IMPLIED
SuccessNetLocn CDATA #REQUIRED >
<!ELEMENT ProtocolOptions EMPTY><!ATTLIST ProtocolOptions ID ID#REQUIRED xml: lang NMTOKEN#REQUIRED ShortDesc CDATA#REQUIRED SenderNetLocn CDATA#IMPLIED SecureSenderNetLocn CDATA#IMPLIED SuccessNetLocn CDATA#REQUIRED>。
Attributes:
属性:
ID An identifier which uniquely identifies the
Protocol Options Component within the IOTP
Transaction.
IOTP Transactionの中で唯一プロトコルOptions Componentを特定するID An識別子。
Xml:lang Defines the language used by attributes or child
elements within this component, unless
overridden by an xml:lang attribute on a child
element. See section 3.8 Identifying Languages.
Xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
ShortDesc This contains a short description of the IOTP
Transaction in the language defined by xml:lang.
Its purpose is to provide an explanation of what
type of IOTP Transaction is being conducted by
the parties involved.
ShortDesc Thisはxmlによって定義された言語における、IOTP Transactionの短い記述を含んでいます: lang。 目的はIOTP Transactionのどんなタイプがかかわったパーティーによって指導されるかに関する説明を提供することです。
It is used to facilitate selecting an individual
transaction from a list of similar transactions,
for example from a database of IOTP transactions
which has been stored by a Consumer, Merchant,
etc.
それは同様のトランザクションのリストから個々のトランザクションを選択するのを容易にするのに使用されます、例えばConsumer、マーチャントなどに保存されたIOTPトランザクションに関するデータベースから
SenderNetLocn This contains the non secured net location of
the sender of the TPO Block in which the
Protocol Options Component is contained.
SenderNetLocn ThisはプロトコルOptions Componentが含まれているTPO Blockの送付者の非機密保護しているネットの位置を含んでいます。
It is the net location to which the recipient of
the TPO block should send a TPO Selection Block
if required.
それは必要なら、TPOブロックの受取人がTPO Selection Blockを送るべきであるネットの位置です。
Burdett Informational [Page 96] RFC 2801 IOTP/1.0 April 2000
バーデット[96ページ]情報のRFC2801IOTP/2000年4月1日
The content of this attribute is dependent on
the Transport Mechanism see the Transport
Mechanism Supplement.
この属性の内容はTransport Mechanismの上の扶養家族がTransport Mechanism Supplementを見るということです。
SecureSenderNetLocn This contains the secured net location of the
sender of the TPO Block in which the Protocol
Options Component is contained.
SecureSenderNetLocn ThisはプロトコルOptions Componentが含まれているTPO Blockの送付者の機密保護しているネットの位置を含んでいます。
The content of this attribute is dependent on
the Transport Mechanism see the Transport
Mechanism Supplement.
この属性の内容はTransport Mechanismの上の扶養家族がTransport Mechanism Supplementを見るということです。
SuccessNetLocn This contains the net location that should be
displayed after the IOTP Transaction has
successfully completed.
SuccessNetLocn Thisは首尾よく完成されていた状態でIOTP Transactionが表示した後に表示するべきであるネットの位置を含んでいます。
The content of this attribute is dependent on
the Transport Mechanism see the Transport
Mechanism Supplement.
この属性の内容はTransport Mechanismの上の扶養家族がTransport Mechanism Supplementを見るということです。
Either SenderNetLocn, SecureSenderNetLocn or both must be present.
SenderNetLocn、SecureSenderNetLocnまたは両方が存在していなければなりません。
7.2 Authentication Request Component
7.2 認証要求コンポーネント
This Trading Component contains parameter data that is used in an Authentication of one Trading Role by another. Its definition is as follows.
このTrading Componentは1Trading RoleのAuthenticationで別のものによって使用されるパラメタデータを含んでいます。 定義は以下の通りです。
<!ELEMENT AuthReq (Algorithm, PackagedContent*)>
<!ATTLIST AuthReq
ID ID #REQUIRED
AuthenticationId CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!要素AuthReq(アルゴリズム、PackagedContent*)><!ATTLIST AuthReqの必要なAuthenticationId CDATA#必要なContentSoftwareId CDATA ID ID##、は>を含意しました。
If required the Algorithm may use the challenge data, contained in the Packaged Content elements within the Authentication Request Component in its calculation. The format of the Packaged Contents are Algorithm dependent.
必要ならAlgorithmはAuthentication Request Componentの中にPackaged Content要素に計算に含まれた挑戦データを使用するかもしれません。 Packaged Contentsの形式はAlgorithm扶養家族です。
Attributes:
属性:
ID An identifier which uniquely identifies the
Authentication Request Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Authentication Request Componentを特定するID An識別子。
AuthenticationId An identifier specified by the Authenticator
which, if returned by the Organisation that
receives the Authentication Request, will enable
AuthenticationId An識別子は、AuthenticatorでAuthentication Requestを受けるOrganisationによって返されるとどれが可能にされるかを指定しました。
Burdett Informational [Page 97] RFC 2801 IOTP/1.0 April 2000
バーデット[97ページ]情報のRFC2801IOTP/2000年4月1日
the Authenticator to identify which Authentication
is being referred to.
どのAuthenticationを特定するかAuthenticatorは言及されています。
ContentSoftwareId See section 14.Glossary
ContentSoftwareId See部の14.Glossary
Content:
内容:
PackagedContent This contains the challenge data as one or more
Packaged Content (see section 3.7) that is to be
responded to using the Algorithm defined by the
Algorithm element.
PackagedContent ThisはAlgorithm要素によって定義されたAlgorithmを使用すると反応することになっている1Packaged Content(セクション3.7を見る)として挑戦データを含んでいます。
Algorithm This contains information which describes the
Algorithm (see 7.19 Signature Components) that
must be used to generate the Authentication
Response.
アルゴリズムThisはAuthentication Responseを生成するのに使用しなければならないAlgorithm(7.19Signature Componentsを見る)について説明する情報を含んでいます。
The Algorithms that may be used are identified by
the Name attribute of the Algorithm element. For
valid values see section 12. IANA Considerations.
使用されるかもしれないAlgorithmsはAlgorithm要素のName属性によって特定されます。 有効値に関しては、セクション12を見てください。 IANA問題。
7.3 Authentication Response Component
7.3 認証応答コンポーネント
The Authentication Response Component contains the results of an authentication request. It uses the Algorithm contained in the Authentication Request Component (see section 7.2) selected from the Authentication Request Block (see section 8.4).
Authentication Response Componentは認証要求の結果を含んでいます。 それはAuthentication Request Blockから選択されたAuthentication Request Component(セクション7.2を見る)に含まれたAlgorithmを使用します(セクション8.4を見てください)。
Depending on the Algorithm selected, the results of applying the algorithm will either be contained in a Signature Component that signs both the Authentication Response and potentially other data, or in the Packaged Content elements within the Authentication Response Component. Its definition is as follows.
選択されたAlgorithmによって、アルゴリズムを適用するという結果は両方がAuthentication Responseであると署名するSignature Componentと潜在的に他のデータ、またはAuthentication Response Componentの中のPackaged Content要素に含まれるでしょう。 定義は以下の通りです。
<!ELEMENT AuthResp (PackagedContent*) >
<!ATTLIST AuthResp
ID ID #REQUIRED
AuthenticationId CDATA #REQUIRED
SelectedAlgorithmRef NMTOKEN #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!要素AuthResp(PackagedContent*)><!必要なATTLIST AuthRespの必要なSelectedAlgorithmRef NMTOKEN#必要なContentSoftwareId CDATA ID ID#AuthenticationId CDATA##、は>を含意しました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Authentication Response Component within the
IOTP Transaction.
IOTP Transactionの中で唯一Authentication Response Componentを特定するID An識別子。
Burdett Informational [Page 98] RFC 2801 IOTP/1.0 April 2000
バーデット[98ページ]情報のRFC2801IOTP/2000年4月1日
AuthenticationId The Authentication identifier specified by the
Authenticator that was included in the
Authentication Request Component(see section
7.2). This will enable the Authenticator to
identify the Authentication that is being
referred to.
Authentication識別子がAuthentication Request Component(セクション7.2を見る)に含まれていたAuthenticatorで指定したAuthenticationId。 これは、Authenticatorが言及されているAuthenticationを特定するのを可能にするでしょう。
SelectedAlgorithmRef An Element Reference that identifies the
Algorithm element used to generate the
Authentication Response.
Algorithm要素を特定するSelectedAlgorithmRef An Element Referenceが以前はよくAuthentication Responseを生成していました。
ContentSoftwareId See section 14.Glossary.
ContentSoftwareId See部の14.Glossary。
Content:
内容:
PackagedContent This may contain the response generated as a
result of applying the Algorithm selected from the
Authentication Request Component see section 7.2.
PackagedContent Thisは生成された応答を含むかもしれません、その結果、選び抜かれたAlgorithmを適用するのにおいて、Authentication Request Componentがセクション7.2を見ます。
For example, for a payment specific scheme, it may
contain scheme-specific data. Refer to the scheme-
specific supplemental documentation for
definitions of its content.
例えば、支払いの特定の体系のために、それは体系特有のデータを含むかもしれません。 内容の定義について体系の特定の補足のドキュメンテーションを参照してください。
7.4 Trading Role Information Request Component
7.4 取り引き役割の情報要求コンポーネント
This Trading Component contains a list of Trading Roles (see section 2.1) about which information is being requested. The result of a Trading Role Request is a set of Organisation Components (see section 7.6) that describe each of the Trading Roles requested.
このTrading Componentは情報が要求されているTrading Roles(セクション2.1を見る)のリストを含んでいます。 Trading Role Requestの結果は要求されていた状態でそれぞれのTrading Rolesについて説明するOrganisation Components(セクション7.6を見る)の1セットです。
Example usage includes:
例の用法は:
o a Merchant requesting that a Consumer provides Organisation
Components for the Consumer and DelivTo Trading Roles
o ConsumerがConsumerとDelivTo Trading RolesにOrganisation Componentsを供給するよう要求するマーチャント
o a Consumer requesting from a Merchant, information about the
Payment Handlers and Delivery Handlers that the Merchant uses.
o マーチャントから要求するConsumer、マーチャントが使用するPayment HandlersとDelivery Handlersの情報。
Its definition is as follows.
定義は以下の通りです。
<!ELEMENT TradingRoleInfoReq EMPTY>
<!ATTLIST TradingRoleInfoReq
ID ID #REQUIRED
TradingRoleList NMTOKENS #REQUIRED >
空の<!のID ID#必要なTradingRoleList NMTOKENS要素TradingRoleInfoReq><!ATTLIST TradingRoleInfoReq#、は>を必要としました。
Burdett Informational [Page 99] RFC 2801 IOTP/1.0 April 2000
バーデット[99ページ]情報のRFC2801IOTP/2000年4月1日
Attributes:
属性:
ID An identifier which uniquely identifies the
Trading Role Information Request Component within
the IOTP Transaction.
IOTP Transactionの中で唯一Trading Role情報Request Componentを特定するID An識別子。
TradingRoleList Contains a list of one or more Trading Roles (see
the TradingRole attribute of the Trading Role
Element - section 7.6.2) for which information is
being requested.
情報が要求されている1Trading Roles(Trading Role ElementのTradingRole属性を見てください--7.6に.2を区分する)のTradingRoleList Contains aリスト。
7.5 Order Component
7.5 オーダーコンポーネント
An Order Component contains information about an order. Its definition is as follows.
Order Componentはオーダーの情報を含んでいます。 定義は以下の通りです。
<!ELEMENT Order (PackagedContent*) >
<!ATTLIST Order
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ApplicableLaw CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT Order(PackagedContent*)><!ATTLIST Order ID ID#REQUIRED xml: lang NMTOKEN#REQUIRED OrderIdentifier CDATA#REQUIRED ShortDesc CDATA#REQUIRED OkFrom CDATA#REQUIRED OkTo CDATA#REQUIRED ApplicableLaw CDATA#REQUIRED ContentSoftwareId CDATA#IMPLIED>。
Attributes:
属性:
ID An identifier which uniquely identifies the Order
Component within the IOTP Transaction.
IOTP Transactionの中で唯一Order Componentを特定するID An識別子。
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages.
xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
OrderIdentifier This is a code, reference number or other
identifier which the creator of the Order may use
to identify the order. It must be unique within an
IOTP Transaction. If it is used in this way, then
it may remove the need to specify any content for
the Order element as the reference can be used to
look up the necessary information in a database.
OrderIdentifier ThisはOrderのクリエイターがオーダーを特定するのに使用するかもしれないコード、参照番号または他の識別子です。 それはIOTP Transactionの中でユニークであるに違いありません。 このように使用されるなら、それはデータベースの必要事項を調べるのに参照を使用できるようにOrder要素のためのどんな内容も指定する必要性を取り除くかもしれません。
ShortDesc A short description of the order in the language
defined by xml:lang. It is used to facilitate
selecting an individual order from a list of
xmlによって定義された言語における、オーダーのShortDescのA短い記述: lang。 それは、リストからの個々のオーダーを選択するのを容易にするのに使用されます。
Burdett Informational [Page 100] RFC 2801 IOTP/1.0 April 2000
バーデット[100ページ]情報のRFC2801IOTP/2000年4月1日
orders, for example from a database of orders
which has been stored by a Consumer, Merchant,
etc.
例えばConsumer、マーチャントなどに保存された命令に関するデータベースからの命令
OkFrom The date and time in [UTC] format after which the
offer made by the Merchant lapses.
申し出が作ったものがマーチャントで経過した後に[UTC]形式における日時のOkFrom。
OkTo The date and time in [UTC] format before which a
Value Acquirer may accept the offer made by the
Merchant is not valid.
どのa Value Acquirerが申し出を受け入れるかもしれないかがマーチャントを作る前の[UTC]形式における日時のOkToは有効ではありません。
ApplicableLaw A phrase in the language defined by xml:lang which
describes the state or country of jurisdiction
which will apply in resolving problems or
disputes.
言語のApplicableLaw A句は、xml: langでどれが問題か論争を解決する際に適用される管轄の州か国について説明するかを定義しました。
ContentSoftwareId See section 14.Glossary.
ContentSoftwareId See部の14.Glossary。
Content:
内容:
PackagedContent An optional description of the order information
as one or more Packaged Contents (see section
3.7).
1Packaged Contents(セクション3.7を見る)としてのオーダー情報のPackagedContent Anの任意の記述。
7.5.1 Order Description Content
7.5.1 オーダー記述内容
The Packaged Content element will normally be required, however it may be omitted where sufficient information about the purchase can be provided in the ShortDesc attribute. If the full Order Description requires it several Packaged Content elements may be used.
通常、Packaged Content要素が必要であるだろう、しかしながら、それは購買に関する十分な情報をShortDesc属性に提供できるところで省略されるかもしれません。 完全なOrder記述がそれを必要とするなら、数個のPackaged Content要素が使用されるかもしれません。
Although the amount and currency are likely to appear in the Packaged Content of the Order Description it is the amount and currency contained in the payment related trading components (Brand List, Brand Selection and Payment) that is authoritative. This means it is important that the amount actually being paid (as contained in the payment related trading components) is prominently displayed to the Consumer.
量と通貨はそれがOrder記述のPackaged Contentに現れるためには、量であり、支払いに含まれた通貨が取り引きコンポーネント(ブランドList、Brand Selection、およびPayment)を関係づけた傾向がありますが、それは正式です。 これは、実際に支払われる(コンポーネントを取り引きする関係づけられた支払いに含まれているように)額をConsumerに顕著に表示するのが重要であることを意味します。
For interoperability, implementations must support Plain Text, HTML and XML as a minimum so that it can be easily displayed.
相互運用性、実装が容易にそれを表示できるように最小限としてPlain Text、HTML、およびXMLをサポートしなければならないので。
7.5.2 OkFrom and OkTo Timestamps
7.5.2 OkFromとOkToタイムスタンプ
Note that:
以下のことに注意してください。
o the OkFrom date may be later than the OkFrom date on the Payment
Component (see section 7.9) associated with this order, and
o そしてOkFrom日付より遅く、OkFrom日付がこのオーダーに関連しているPayment Component(セクション7.9を見る)にあるかもしれない。
Burdett Informational [Page 101] RFC 2801 IOTP/1.0 April 2000
バーデット[101ページ]情報のRFC2801IOTP/2000年4月1日
o similarly, the OkTo date may be earlier that the OkTo date on the
Payment Component (see section 7.9).
o 同様に、OkToは、より早いのがOkToがデートするPayment Componentであったかもしれないならデートします(セクション7.9を見てください)。
Note: Disclaimer. The following information provided in this note does not represent formal advice of any of the authors of this specification. Readers of this specification must form their own views and seek their own legal counsel on the usefulness and applicability of this information.
以下に注意してください。 注意書き。 この注意に提供された以下の情報はこの仕様の作者のどれかの正式なアドバイスを表しません。 この仕様の読者は、この情報の有用性と適用性でそれら自身の視点を形成して、それら自身の弁護士を探さなければなりません。
The merchant in the context of Internet commerce with anonymous consumers initially frames the terms of the offer on the web page, and in order to obtain the goods or services, the consumer must accept them.
匿名の消費者とのインターネット商業の文脈の商人は初めはウェブページで申し出に関する諸条件を縁どります、そして、商品かサービスを入手するために、消費者はそれらを受け入れなければなりません。
If there is to be a time-limited offer, it is recommended that merchants communicate this to the consumer and state in the order description in a manner which is clear to the consumer that:
期日申し出があれば、商人が、これを消費者に伝えて、オーダー記述で以下のことと消費者にとって、明確な方法で述べることが勧められます。
o the offer is time limited
o 申し出は期日です。
o the OkFrom and OkTo timestamps specify the validity of the offer
o OkFromとOkToタイムスタンプは申し出の正当性を指定します。
o the clock, e.g., the merchant's clock, that will be used to
determine the validity of the offer
o 時計、例えば申し出の正当性を決定するのに使用される商人の時計
Also note that although the OkFrom and OkTo dates are likely to appear in the Packaged Content of the Order Description it is the dates contained in the Order Component that is authoritative. This means it is important that the OkFrom and OkTo dates actually being used is prominently displayed to the Consumer.
また、OkFromとOkTo期日がOrder記述のPackaged Contentに現れそうですが、正式であるのが、Order Componentに含まれた日付であることに注意してください。 これは、実際に使用されるOkFromとOkTo日付をConsumerに顕著に表示するのが重要であることを意味します。
7.6 Organisation Component
7.6 機構コンポーネント
The Organisation Component provides information about an individual or an Organisation. This can be used for a variety of purposes. For example:
Organisation Componentは個人かOrganisationの情報を提供します。 さまざまな目的にこれを使用できます。 例えば:
o to describe the merchant who is selling the goods,
o 商品を販売している商人について説明するために
o to identify who made a purchase,
o だれが仕入れたかを特定するために
o to identify who will take delivery of goods,
o だれが品物を受け取るかを特定するために
o to provide a customer care contact,
o 顧客を提供するには、接触について気にかけてください。
o to describe who will be the Payment Handler.
o だれがPayment Handlerになるかを説明するために。
Burdett Informational [Page 102] RFC 2801 IOTP/1.0 April 2000
バーデット[102ページ]情報のRFC2801IOTP/2000年4月1日
Note that the Organisation Components which must be present in an IOTP Message are dependent on the particular transaction being carried out. Refer to section 9. Internet Open Trading Protocol Transactions, for more details.
IOTP Messageに存在しなければならないOrganisation Componentsが行われる特定の取引に依存していることに注意してください。 セクション9を参照してください。 その他の詳細のためのインターネットオープンTradingプロトコルTransactions。
Its definition is as follows.
定義は以下の通りです。
<!ELEMENT Org (TradingRole+, ContactInfo?,
PersonName?, PostalAddress?)>
<!ATTLIST Org
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrgId CDATA #REQUIRED
LegalName CDATA #IMPLIED
ShortDesc CDATA #IMPLIED
LogoNetLocn CDATA #IMPLIED >
<!要素Org(TradingRole+、ContactInfo?、PersonName?、PostalAddress?)><!ATTLIST Org ID ID#REQUIRED xml: lang NMTOKEN#REQUIRED OrgId CDATA#REQUIRED LegalName CDATA#IMPLIED ShortDesc CDATA#IMPLIED LogoNetLocn CDATA#IMPLIED>。
Attributes:
属性:
ID An identifier which uniquely identifies the
Organisation Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Organisation Componentを特定するID An識別子。
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages.
xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
OrgId A code which identifies the Organisation described
by the Organisation Component. See 7.6.1
Organisation IDs, below.
Organisation Componentによって説明されたOrganisationを特定するOrgId Aコード。 以下の7.6の.1Organisation IDを見てください。
LegalName For Organisations which are companies this is
their legal name in the language defined by
xml:lang. It is required for Organisations who
have a Trading Role other than Consumer or
DelivTo.
会社はどれです。LegalName For Organisations、xml: langによって定義された言語のそれらの法的な名前。 それがConsumerかDelivTo以外のTrading Roleを持っているOrganisationsに必要です。
ShortDesc A short description of the Organisation in the
language defined by xml:lang. It is typically the
name by which the Organisation is commonly known.
For example, if the legal name was "Blue Meadows
Financial Services Inc.". Then its short name
would likely be "Blue Meadows".
xmlによって定義された言語における、OrganisationのShortDescのA短い記述: lang。 通常、それはOrganisationが一般的に知られている名前です。 法的な名前が例えば「青いメドース金融サービス株式会社」であったなら。 そして、省略名はおそらく「青い草地」でしょう。
It is used to facilitate selecting an individual
Organisation from a list of Organisations, for
example from a database of Organisations involved
それはOrganisationsのリストから個々のOrganisationを選択するのを容易にするのに使用されます、例えば、Organisationsのかかわったデータベースから
Burdett Informational [Page 103] RFC 2801 IOTP/1.0 April 2000
バーデット[103ページ]情報のRFC2801IOTP/2000年4月1日
in IOTP Transactions which has been stored by a
consumer.
消費者によって保存されたIOTP Transactionsで。
LogoNetLocn The net location which can be used to download the
logo for the Organisation.
LogoNetLocn、Organisationのためにロゴをダウンロードするのに使用できるネットの位置。
See section 10 Retrieving Logos.
セクション10Retrieving Logosを見てください。
The content of this attribute must conform to
[RFC1738].
この属性の内容は[RFC1738]に従わなければなりません。
Content:
内容:
TradingRole See 7.6.2 Trading Role Element below.
以下のTradingRole See7.6.2Trading Role Element。
ContactInfo See 7.6.3 Contact Information Element below.
以下のContactInfo See7.6.3Contact情報Element。
PersonName See 7.6.4 Person Name below.
以下のPersonName See7.6.4Person Name。
PostalAddress See 7.6.5 Postal Address below.
以下のPostalAddress See7.6.5Postal Address。
7.6.1 Organisation IDs
7.6.1 機構ID
Organisation IDs are used by one IOTP Trading Role to identify another. In order to avoid confusion, this means that these IDs must be globally unique.
機構IDは、別のものを特定するのに1IOTP Trading Roleによって使用されます。 混乱を避けるために、これは、これらのIDがグローバルにユニークでなければならないことを意味します。
In principle this is achieved in the following way:
原則として、これは以下の方法で達成されます:
o the Organisation Id for all trading roles, apart from the Consumer
Trading Role, uses a domain name as their globally unique
identifier,
o Consumer Trading Roleは別として、すべての取り引き役割のためのOrganisation Idはそれらのグローバルにユニークな識別子としてドメイン名を使用します。
o the Organisation Id for a Consumer Trading Role is allocated by
one of the other Trading Roles in an IOTP Transaction and is made
unique by concatenating it with that other roles' Organisation Id,
o Consumer Trading RoleのためのOrganisation Idを他のTrading Rolesの1つがIOTP Transactionに割り当てて、その他の役割のOrganisation Idと共にそれを連結することによって、ユニークにします。
o once a Consumer is allocated an Organisation Id within an IOTP
Transaction the same Organisation Id is used by all the other
trading roles in that IOTP transaction to identify that Consumer.
o IOTP Transactionの中にいったんOrganisation IdをConsumerに割り当てるとそのIOTPトランザクションにおける他のすべての取り引き役割で同じOrganisation Idを使用して、そのConsumerを特定します。
Specifically, the content of the Organisation ID is defined as follows:
明確に、Organisation IDの内容は以下の通り定義されます:
OrgId ::= NonConsumerOrgId | ConsumerOrgId NonConsumerOrgId ::= DomainName ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId ConsumerOrgIdPrefix ::= "Consumer:"
OrgId:、:= NonConsumerOrgId| ConsumerOrgId NonConsumerOrgId:、:= ドメイン名ConsumerOrgId:、:= 」 「ConsumerOrgIdPrefix(namecharする)+」/NonConsumerOrgId ConsumerOrgIdPrefix:、:= 「消費者:」
Burdett Informational [Page 104] RFC 2801 IOTP/1.0 April 2000
バーデット[104ページ]情報のRFC2801IOTP/2000年4月1日
ConsumerOrgId The Organisation ID for a Consumer consists of:
o a standard prefix to identify that the
Organisation Id is for a consumer, followed by
ConsumerのためのConsumerOrgId Organisation IDは以下から成ります。 o 特定する続かれて、Organisation Idが消費者のためのものである標準の接頭語
o one or more characters which conform to the
definition of an XML "namechar". See [XML]
specifications, followed by
o the NonConsumerOrgId for the Organisation
which allocated the ConsumerOrgId. It is
normally the Merchant role.
o XML"namechar"の定義に従う1つ以上のキャラクタ。 ConsumerOrgIdを割り当てたOrganisationのために○ NonConsumerOrgIdによって従われた[XML]仕様を見てください。 通常、それはマーチャントの役割です。
Use of upper and lower case is not significant.
大文字と小文字の使用は重要ではありません。
NonConsumerOrgId If the Role is not Consumer then this contains the
Canonical Name for the non-consumer Organisation
being described by the Organisation Component. See
[DNS] optionally followed by additional
characters, if required, to make the
NonConsumerOrgId unique.
NonConsumerOrgId If RoleはConsumerでなく、次に、これはOrganisation Componentによって説明される非消費者OrganisationのためのCanonical Nameを含んでいます。 必要なら、添字が任意に[DNS]のあとに続いて、NonConsumerOrgIdをユニークにするのを見てください。
Note that a NonConsumerOrgId may not start with
the ConsumerOrgIdPrefix.
NonConsumerOrgIdがConsumerOrgIdPrefixから始まらないかもしれないことに注意してください。
Use of upper and lower case is not significant.
大文字と小文字の使用は重要ではありません。
Examples of Organisation Ids follow:
Organisation Idsに関する例は従います:
o newjerseybooks.com - a merchant Organisation id
o newjerseybooks.com--商人Organisationイド
o westernbank.co.uk - a Payment Handler Organisation id
o westernbank.co.uk--Payment Handler Organisationイド
o consumer:1000247ABH/newjerseybooks.com - a consumer Organisation
id allocated by a merchant
o 消費者: 1000247ABH/newjerseybooks.com--商人によって割り当てられた消費者Organisationイド
7.6.2 Trading Role Element
7.6.2 取り引き役割の要素
This identifies the Trading Role of an individual or Organisation in the IOTP Transaction. Note, an Organisation may have more than one Trading Role and several roles may be present in one Organisation element. Its definition is as follows:
これはIOTP Transactionで個人かOrganisationのTrading Roleを特定します。 注意、Organisationには1Trading Roleがあるかもしれません、そして、いくつかの役割が1つのOrganisation要素に存在しているかもしれません。 定義は以下の通りです:
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
ID ID #REQUIRED
TradingRole NMTOKEN #REQUIRED
IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED
ErrorNetLocn CDATA #IMPLIED
必要な必要なATTLIST TradingRoleの必要なCancelNetLocn CDATA#暗示しているErrorNetLocn CDATA ID ID#TradingRole NMTOKEN#IotpMsgIdPrefix NMTOKEN##、が含意した<!の要素TradingRole空の><!
Burdett Informational [Page 105] RFC 2801 IOTP/1.0 April 2000
バーデット[105ページ]情報のRFC2801IOTP/2000年4月1日
ErrorLogNetLocn CDATA #IMPLIED >
ErrorLogNetLocn CDATA#は>を含意しました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Trading Role Element within the IOTP Transaction.
IOTP Transactionの中で唯一Trading Role Elementを特定するID An識別子。
TradingRole The trading role of the Organisation. Valid values
are:
o Consumer. The person or Organisation that is
acting in the role of a consumer in the IOTP
Transaction.
o Merchant. The person or Organisation that is
acting in the role of merchant in the IOTP
Transaction.
o PaymentHandler. The financial institution or
other Organisation which is a Payment Handler
for the IOTP Transaction
o DeliveryHandler. The person or Organisation
that is the delivering the goods or services
for the IOTP Transaction
o DelivTo. The person or Organisation that is
receiving the delivery of goods or services in
the IOTP Transaction
o CustCare. The Organisation and/or individual
who will provide customer care for an IOTP
Transaction.
TradingRole、Organisationの取り引き役割。 有効値は以下の通りです。 o 消費者。 IOTP Transactionの消費者の役割で. ○ マーチャントを演じている人かOrganisation。 IOTP Transactionの商人の役割で. o PaymentHandlerを活動させている人かOrganisation。 IOTP Transaction o DeliveryHandlerのためのPayment Handlerである金融機関か他のOrganisation。 それは配送です。人かOrganisation、IOTP Transaction o DelivToのための商品かサービス。 IOTP Transaction o CustCareでの人、品物の配達を受けているOrganisationまたはサービス。 顧客ケアをIOTP Transactionに供給するOrganisation、そして/または、個人。
Values of TradingRole are controlled under the
procedures defined in section 12 IANA
Considerations which also allows user defined
values to be defined.
TradingRoleの値はまた、ユーザの定義された値が定義されるのを許容するセクション12IANA Considerationsで定義された手順の下で制御されます。
IotpMsgIdPrefix Contains the prefix which must be used for all
IOTP Messages sent by the Trading Role in this
IOTP Transaction. The values to be used are
defined in 3.4.1 IOTP Message ID Attribute
Definition.
IotpMsgIdPrefix Contains、このIOTP TransactionでTrading Roleによって送られたすべてのIOTP Messagesに使用しなければならない接頭語。 使用されるべき値は3.4.1IOTP Message ID Attribute Definitionで定義されます。
CancelNetLocn This contains the net location of where the
Consumer should go to if the Consumer cancels the
transaction for some reason. It can be used by the
Trading Role to provide a response which is more
tailored to the circumstances of a particular
transaction.
Consumerがある理由でトランザクションを取り消すなら、CancelNetLocn ThisはConsumerが行くはずであるところに関するネットの位置を含んでいます。 Trading Roleは、特定の取引の事情にさらに適合する応答を提供するのにそれを使用できます。
Burdett Informational [Page 106] RFC 2801 IOTP/1.0 April 2000
バーデット[106ページ]情報のRFC2801IOTP/2000年4月1日
This attribute:
o must not be present when TradingRole is set to
Consumer role or DelivTo,
この属性: o プレゼントがいつTradingRoleであったに違いないかときに、Consumerの役割かDelivToにはセットがあります。
o must be present when TradingRole is set to
Merchant, PaymentHandler or DeliveryHandler.
o プレゼントがいつであったに違いないかときに、TradingRoleはマーチャント、PaymentHandlerまたはDeliveryHandlerに用意ができています。
The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism
Supplement.
この属性の内容はTransport Mechanismの上の扶養家族がTransport Mechanism Supplementを見るということです。
ErrorNetLocn This contains the net location that should be
displayed by the Consumer after the Consumer has
either received or generated an Error Block
containing an Error Component with the Severity
attribute set to either:
o HardError,
o Warning but the Consumer decides to not
continue with the transaction
o TransientError and the transaction has
subsequently timed out.
ErrorNetLocn ThisはConsumerがSeverity属性セットでError Componentを含むError Blockを受けるか、または生成した後にConsumerによって表示されるはずであるネットの位置をどちらかに含んでいます: o HardErrorにもかかわらず、o Warningにもかかわらず、Consumerは、TransientErrorとトランザクションが次に外のトランザクションoを調節して続かないと決めます。
See section 7.21.1 Error Processing Guidelines for
more details.
その他の詳細に関してセクション7.21.1Error Processing Guidelinesを見てください。
This attribute:
o must not be present when TradingRole is set to
Consumer or DelivTo,
o must be present when TradingRole is set to
Merchant, PaymentHandler or DeliveryHandler.
この属性: o TradingRoleがマーチャント、PaymentHandlerまたはDeliveryHandlerに用意ができているとき、プレゼントがTradingRoleがいつConsumerに用意ができているか、そして、DelivToであったに違いないなら、oは存在していなければなりません。
The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism
Supplement.
この属性の内容はTransport Mechanismの上の扶養家族がTransport Mechanism Supplementを見るということです。
ErrorLogNetLocn Optional. This contains the net location that
Consumers should send IOTP Messages that contain
Error Blocks with an Error Component with the
Severity attribute set to either:
o HardError,
o Warning but the Consumer decides to not
continue with the transaction
o TransientError and the transaction has
subsequently timed out.
ErrorLogNetLocn任意です。 これはConsumersがSeverity属性セットでError ComponentとError Blocksをどちらかに含むIOTP Messagesを送るはずであるネットの位置を含んでいます: o HardErrorにもかかわらず、o Warningにもかかわらず、Consumerは、TransientErrorとトランザクションが次に外のトランザクションoを調節して続かないと決めます。
This attribute:
o must not be present when TradingRole is set to
Consumer role,
この属性: o プレゼントがいつTradingRoleであったに違いないかときに、Consumerの役割にはセットがあります。
Burdett Informational [Page 107] RFC 2801 IOTP/1.0 April 2000
バーデット[107ページ]情報のRFC2801IOTP/2000年4月1日
o must be present when TradingRole is set to
Merchant, PaymentHandler or DeliveryHandler.
o プレゼントがいつであったに違いないかときに、TradingRoleはマーチャント、PaymentHandlerまたはDeliveryHandlerに用意ができています。
The content of this attribute is dependent on the
Transport Mechanism see the Transport Mechanism
Supplement.
この属性の内容はTransport Mechanismの上の扶養家族がTransport Mechanism Supplementを見るということです。
The ErrorLogNetLocn can be used to send error
messages to the software company or some other
Organisation responsible for fixing problems in
the software which sent the incoming message. See
section 7.21.1 Error Processing Guidelines for
more details.
入力メッセージを送ったソフトウェアで問題を解決するのに原因となるソフトウェア会社かある他のOrganisationにエラーメッセージを送るのにErrorLogNetLocnを使用できます。 その他の詳細に関してセクション7.21.1Error Processing Guidelinesを見てください。
7.6.3 Contact Information Element
7.6.3 問い合わせ先要素
This contains information which can be used to contact an Organisation or an individual. All attributes are optional however at least one item of contact information should be present. Its definition is as follows.
これはOrganisationか個人に連絡するのに使用できる情報を含んでいます。 問い合わせ先の少なくとも1つの項目がどのように存在していても、すべての属性が任意です。 定義は以下の通りです。
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED
Fax CDATA #IMPLIED
Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED >
ATTLIST ContactInfo xml: lang NMTOKEN#IMPLIED Tel CDATA#IMPLIEDファックスCDATA#IMPLIEDがCDATA#IMPLIED NetLocn CDATA#IMPLIED>にメールする<!ELEMENT ContactInfo EMPTY><!
Attributes:
属性:
xml:lang Defines the language used by attributes within
this element. See section 3.8 Identifying
Languages.
xml: 言語がこの要素の中で属性で使用したlang Defines。 セクション3.8Identifying Languagesを見てください。
Tel A telephone number by which the Organisation may
be contacted. Note that this is a text field and
no validation is carried out on it.
Organisationが連絡されるかもしれないTel A電話番号。 これがテキストフィールドであり、合法化が全くそれで行われないことに注意してください。
Fax A fax number by which the Organisation may be
contacted. Note that this is a text field and no
validation is carried out on it.
ファックスで、Organisationが連絡されるかもしれないAファックス番号を送ってください。 これがテキストフィールドであり、合法化が全くそれで行われないことに注意してください。
Email An email address by which the Organisation may be
contacted. Note that this field should conform to
the conventions for address specifications
contained in [RFC822].
Organisationが連絡されるかもしれないAn Eメールアドレスをメールしてください。 この分野が[RFC822]に含まれたアドレス指定のためのコンベンションに従うべきであることに注意してください。
Burdett Informational [Page 108] RFC 2801 IOTP/1.0 April 2000
バーデット[108ページ]情報のRFC2801IOTP/2000年4月1日
NetLocn A location on the Internet by which information
about the Organisation may be obtained that can be
displayed using a web browser.
Organisationの情報が得られるかもしれないインターネットのウェブブラウザを使用することで表示できるNetLocn A位置。
The content of this attribute must conform to
[RFC1738].
この属性の内容は[RFC1738]に従わなければなりません。
7.6.4 Person Name Element
7.6.4 人の名前要素
This contains the name of an individual person. All fields are optional however as a minimum either the GivenName or the FamilyName should be present. Its definition is as follows.
これは人という個人の名前を含んでいます。 最小限として、GivenNameかFamilyNameのどちらかがどのように存在していても、すべての分野が任意です。 定義は以下の通りです。
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
FamilyName CDATA #IMPLIED >
<!ELEMENT PersonName EMPTY><!ATTLIST PersonName xml: lang NMTOKEN#IMPLIED Title CDATA#IMPLIED GivenName CDATA#IMPLIED Initials CDATA#IMPLIED FamilyName CDATA#IMPLIED>。
Attributes:
属性:
xml:lang Defines the language used by attributes within
this element. See section 3.8 Identifying
Languages.
xml: 言語がこの要素の中で属性で使用したlang Defines。 セクション3.8Identifying Languagesを見てください。
Title A distinctive name; personal appellation,
hereditary or not, denoting or implying office
(e.g., judge, mayor) or nobility (e.g., duke,
duchess, earl), or used in addressing or referring
to a person (e.g., Mr, Mrs, Miss)
タイトルのA特有の名。 人について演説するか、または言及する際にオフィス(例えば、市長は判断する)か高貴(例えば、公爵、公爵夫人、伯爵)を指示するか、含意する、または使用される個人的な遺伝的な名称(例えば、さん、夫人、さん)
GivenName The primary or main name by which a person is
known amongst and identified by their family,
friends and acquaintances. Otherwise known as
first name or Christian Name.
プライマリかメイン名義のGivenNameはどのa人によって彼らのファミリー、友人、および知人を、中で知られて、特定されているか。 別の方法で名かクリスチャンのNameとして知られています。
Initials The first letter of the secondary names (other
than the Given Name) by which a person is known
amongst or identified by their family, friends and
acquaintances.
人が彼らのファミリー、友人、および知人によって知られるか特定されているセカンダリ名前(Given Nameを除いた)の最初の手紙に頭文字をつけます。
FamilyName The name by which family of related individuals
are known. It is typically the part of an
individual's name which is passed on by parents to
their children.
FamilyName、関連する個人のファミリーが知られている名前。 通常、それは彼らの子供の両親によって伝えられる個人の名前の部分です。
Burdett Informational [Page 109] RFC 2801 IOTP/1.0 April 2000
バーデット[109ページ]情報のRFC2801IOTP/2000年4月1日
7.6.5 Postal Address Element
7.6.5 郵便のアドレス要素
This contains an address which can be used, for example, for the physical delivery of goods, services or letters. Its definition is as follows.
これは例えば商品、サービスまたは手紙の物理的な配送に使用できるアドレスを含んでいます。 定義は以下の通りです。
<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
xml:lang NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED
AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED
StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED
Country CDATA #IMPLIED
LegalLocation (True | False) 'False' >
<!ELEMENT PostalAddress EMPTY><!ATTLIST PostalAddress xml: lang NMTOKEN#IMPLIED AddressLine1 CDATA#IMPLIED AddressLine2 CDATA#IMPLIED CityOrTown CDATA#IMPLIED StateOrRegion CDATA#IMPLIED PostalCode CDATA#IMPLIED Country CDATA#IMPLIED LegalLocation、(本当である、| 偽) '誤った'>。
Attributes:
属性:
xml:lang Defines the language used by attributes within
this element. See section 3.8 Identifying
Languages.
xml: 言語がこの要素の中で属性で使用したlang Defines。 セクション3.8Identifying Languagesを見てください。
AddressLine1 The first line of a postal address. e.g., "The
Meadows"
AddressLine1は郵便の宛先例えば、「草地」の最初の系列です。
AddressLine2 The second line of a postal address. e.g., "Sandy
Lane"
AddressLine2はアドレス例えば、郵便の「サンディ・レーン」のセカンドラインです。
CityOrTown The city of town of the address. e.g., "Carpham"
CityOrTown、アドレスの町の都市、例えば、"Carpham"
StateOrRegion The state or region within a country where the
city or town is placed. e.g., "Surrey"
StateOrRegion、都市か町が置かれる国の中の州か領域、例えば、「サリー」
PostalCode The code known as, for example a post code or zip
code, that is typically used by Postal
Organisations to organise postal deliveries into
efficient sequences. e.g., "KT22 1AA"
PostalCode、知られているコード、例えば、aはコードか郵便番号を掲示して、それは、効率的な系列例えば、"KT22 1AA"に郵便物の配達を構成するのにPostal Organisationsによって通常使用されます。
Country The country for the address. e.g., "UK"
国、国、アドレス例えば、「イギリス」
LegalLocation This identifies whether the address is the
Registered Address for the Organisation. At least
one address for the Organisation must have a value
set to True unless the Trading Role is either
Consumer or DeliverTo.
LegalLocation Thisは、OrganisationのためにアドレスがRegistered Addressであるかどうか特定します。 Organisationのための少なくとも1つのアドレスで、Trading RoleがConsumerかDeliverToのどちらかでないならTrueに値を設定しなければなりません。
Burdett Informational [Page 110] RFC 2801 IOTP/1.0 April 2000
バーデット[110ページ]情報のRFC2801IOTP/2000年4月1日
7.7 Brand List Component
7.7 ブランドリストコンポーネント
Brand List Components are contained within the Trading Protocol Options Block (see section 8.1) of the IOTP Transaction. They contains lists of:
ブランドList ComponentsはIOTP TransactionのTradingプロトコルOptions Block(セクション8.1を見る)の中に含まれています。 それらは以下のリストを含んでいます。
o payment Brands (see also section 11.1 Brand Definitions and Brand
Selection),
o 支払いBrands(また、セクション11.1のBrand DefinitionsとBrand Selectionを見ます)
o amounts to be paid in the currencies that are accepted or offered
by the Merchant,
o 受け入れられる通貨で支払うか、またはマーチャントが提供する量
o the payment protocols which can be used to make payments with a
Brand, and
o そしてBrandとの支払いをするのに使用できる支払いプロトコル。
o the net locations of the Payment Handlers which accept payment for
a payment protocol
o 支払いプロトコルのための支払いを受け入れるPayment Handlersのネットの位置
The definition of a Brand List Component is as follows.
Brand List Componentの定義は以下の通りです。
<!ELEMENT BrandList (Brand+, ProtocolAmount+,
CurrencyAmount+, PayProtocol+) >
<!ATTLIST BrandList
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
PayDirection (Debit | Credit) #REQUIRED >
<!ELEMENT BrandList(+、ProtocolAmountに+と商標を付けてください、CurrencyAmount+、PayProtocol+)><!ATTLIST BrandList ID ID#REQUIRED xml: lang NMTOKEN#REQUIRED ShortDesc CDATA#REQUIRED PayDirection(借り方| クレジット)#REQUIRED>。
Attributes:
属性:
ID An identifier which uniquely identifies the Brand
List Component within the IOTP Transaction.
IOTP Transactionの中で唯一Brand List Componentを特定するID An識別子。
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages.
xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
ShortDesc A text description in the language defined by
xml:Lang giving details of the purpose of the
Brand List. This information must be displayed to
the receiver of the Brand List in order to assist
with making the selection. It is of particular
benefit in allowing a Consumer to distinguish the
purpose of a Brand List when an IOTP Transaction
involves more than one payment.
xmlによって定義された言語におけるShortDesc Aテキスト記述: Brand Listの目的の詳細を明らかにするラング。 選択をするのに補助するためにBrand Listの受信機にこの情報を表示しなければなりません。 IOTP Transactionが1つ以上の支払いにかかわるときConsumerがBrand Listの目的を区別するのを許容することにおいて、それは特別の利益のものです。
Burdett Informational [Page 111] RFC 2801 IOTP/1.0 April 2000
バーデット[111ページ]情報のRFC2801IOTP/2000年4月1日
PayDirection Indicates the direction in which the payment for
which a Brand is being selected is to be made. Its
values may be:
o Debit The sender of the Payment Request Block
(e.g., the Consumer) to which this Brand List
relates will make the payment to the Payment
Handler, or
o Credit The sender of the Payment Request Block
to which this Brand List relates will receive a
payment from the Payment Handler.
PayDirection Indicates、作られているBrandが選択されている支払いがことである方向。 値は以下の通りです。 o このBrand Listが関係するPayment Request Block(例えば、Consumer)の送付者を借り方に記入してください。○ 支払いをPayment Handlerにするか、またはこのBrand Listが関係するPayment Request Blockの送付者のCreditはPayment Handlerから支払いを受け取るでしょう。
Content:
内容:
Brand This describes a Brand. The sequence of the Brand
elements (see section 7.7.1) within the Brand List
does not indicate any preference. It is
recommended that software which processes this
Brand List presents Brands in a sequence which the
receiver of the Brand List prefers.
ブランドThisはBrandについて説明します。 Brand Listの中のBrand要素(セクション7.7.1を見る)の系列は少しの好みも示しません。 このBrand Listを処理するソフトウェアが次々にのBrand Listの受信機が好むBrandsを寄贈するのは、お勧めです。
ProtocolAmount This links a particular Brand to:
o the currencies and amounts in CurrencyAmount
elements that can be used with the Brand, and
o the Payment Protocols and Payment Handlers,
which can be used with those currencies and
amounts, and a particular Brand
ProtocolAmount Thisは以下のことのために特定のBrandをリンクします。 o 通貨、それらの通貨と量と共に使用できるoのBrand、Paymentプロトコル、およびPayment Handlersと共に使用できるCurrencyAmount要素の量、および特定のBrand
CurrencyAmount This contains a currency code and an amount.
CurrencyAmount Thisは通貨コードと量を含んでいます。
PayProtocol This contains information about a Payment Protocol
and the Payment Handler which may be used with a
particular Brand.
PayProtocol Thisは特定のBrandと共に使用されるかもしれないPaymentプロトコルとPayment Handlerの情報を含んでいます。
The relationships between the elements which make up the content of the Brand List is illustrated in the diagram below.
Brand Listの内容を作る要素の間の関係は以下のダイヤグラムで例証されます。
Burdett Informational [Page 112] RFC 2801 IOTP/1.0 April 2000
バーデット[112ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Brand List Component
ブランドリストコンポーネント
| ProtocolAmountRefs
|-Brand Element-----------------------------
| | |
| - Protocol Brand Element-------- |
| | |
| ProtocolId| |
| | |
|-Protocol Amount Element<----------+-------
| | | |
| | | |
| |CurrencyAmountRefs |Pay |
| | |Protocol |
| v |Ref |
|-Currency Amount Element | |
| Element | |
| | |
-PayProtocolElement<------<--------
| ProtocolAmountRefs|-ブランド要素----------------------------- | | | | - プロトコルブランド要素-------- | | | | | ProtocolId| | | | | |-プロトコル量の要素<。----------+------- | | | | | | | | | |CurrencyAmountRefs|賃金| | | |プロトコル| | v|審判| |-貨幣額要素| | | 要素| | | | | -PayProtocolElement<。------<、-、-、-、-、-、-、--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 15 Brand List Element Relationships
図15 ブランドリスト要素関係
Examples of complete Brand Lists are contained in section 11.2 Brand List Examples.
完全なBrand Listsに関する例はセクション11.2Brand List Examplesで含まれています。
7.7.1 Brand Element
7.7.1 ブランド要素
A Brand Element describes a brand that can be used for making a payment. One or more of these elements is carried in each Brand List Component that has the PayDirection attribute set to Debit. Exactly one Brand Element may be carried in a Brand List Component that has the PayDirection attribute set to Credit.
Brand Elementは支払いを済ませるのに使用できるブランドについて説明します。 これらの要素の1つ以上はPayDirection属性をDebitに設定させる各Brand List Componentで運ばれます。 ちょうど1Brand ElementがPayDirection属性をCreditに設定させるBrand List Componentで運ばれるかもしれません。
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
<!ATTLIST Brand
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandId CDATA #REQUIRED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED
ProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT Brand(ProtocolBrand*、PackagedContent*)><!ATTLIST Brand ID ID#REQUIRED xml: lang NMTOKEN#IMPLIED BrandId CDATA#REQUIRED BrandName CDATA#REQUIRED BrandLogoNetLocn CDATA#REQUIRED BrandNarrative CDATA#IMPLIED ProtocolAmountRefs IDREFS#REQUIRED ContentSoftwareId CDATA#IMPLIED>。
Burdett Informational [Page 113] RFC 2801 IOTP/1.0 April 2000
バーデット[113ページ]情報のRFC2801IOTP/2000年4月1日
Attributes:
属性:
ID Element identifier, potentially referenced in a
Brand Selection Component contained in a later
Payment Request message and uniquely identifies
the Brand element within the IOTP Transaction.
識別子であって、Brand Selection Componentで潜在的に参照をつけられたID Elementは後のPayment Requestにメッセージを含んでいて、IOTP Transactionの中で唯一Brand要素を特定します。
xml:lang Defines the language used by attributes and
content of this element. See section 3.8
Identifying Languages.
xml: 言語がこの要素の属性と内容で使用したlang Defines。 セクション3.8Identifying Languagesを見てください。
BrandId This contains a unique identifier for the brand
(or promotional brand). It is used to match
against a list of Payment Instruments which the
Consumer holds to determine whether or not the
Consumer can pay using the Brand.
BrandId Thisはブランド(または、宣伝のブランド)のためのユニークな識別子を含んでいます。 それは、ConsumerがConsumerがBrandを使用することで支払うことができるかどうか決定するために持っているPayment Instrumentsのリストに対して合うのに使用されます。
Values of BrandId are managed under the procedure
described in section 12 IANA Considerations.
BrandIdの値はセクション12IANA Considerationsで説明された手順の下で管理されます。
As values of BrandId are controlled under the
procedures defined in section 12 IANA
Considerations user defined values may be
defined.
BrandIdの値がユーザが定義したIANA Considerationsが定義されるかもしれないのを評価するセクション12で定義された手順の下で制御されるとき。
BrandName This contains the name of the brand, for example
MasterCard Credit. This is the description of the
Brand which is displayed to the consumer in the
Consumers language defined by xml:lang. For
example it might be "American Airlines Advantage
Visa". Note that this attribute is not used for
matching against the payment instruments held by
the Consumer.
BrandName Thisはブランド、例えば、マスターカードCreditという名前を含んでいます。 これはxmlによって定義されたConsumers言語で消費者に表示されるBrandの記述です: lang。 例えば、それは「アメリカン航空利点ビザ」であるかもしれません。 この属性がConsumerによって持たれていた支払い器具に対して合うのに使用されないことに注意してください。
BrandLogoNetLocn The net location which can be used to download
the logo for the Organisation. See section
Retrieving Logos (see section 10).
BrandLogoNetLocn、Organisationのためにロゴをダウンロードするのに使用できるネットの位置。 セクションRetrieving Logosを見てください(セクション10を見てください)。
The content of this attribute must conform to
[RFC1738].
この属性の内容は[RFC1738]に従わなければなりません。
BrandNarrative This optional attribute is designed to be used by
the Merchant to indicate some special conditions
or benefit which would apply if the Consumer
selected that brand. For example "5% discount",
"free shipping and handling", "free breakage
insurance for 1 year", "double air miles apply",
etc.
Consumerがそのブランドを選択するなら申請される何らかの特別な状態か利益を示すのにマーチャントによって使用されるように、BrandNarrative Thisの任意の属性は設計されています。 例えば、「5%は値段をひく」、「送料・手数料無料」、「1年間の自由な破損保険」、「二倍の空路マイルは適用されますなど」。
Burdett Informational [Page 114] RFC 2801 IOTP/1.0 April 2000
バーデット[114ページ]情報のRFC2801IOTP/2000年4月1日
ProtocolAmountRefs Identifies the protocols and related currencies
and amounts which can be used with this Brand.
Specified as a list of ID's of Protocol Amount
Elements (see section 7.7.3) contained within the
Brand List.
ProtocolAmountRefs Identifiesのプロトコルの、そして、関連する通貨とこのBrandと共に使用できる量。 Brand Listの中に含まれたプロトコルAmount Elements(セクション7.7.3を見る)のIDのリストとして、指定されています。
ContentSoftwareId See section 14.Glossary.
ContentSoftwareId See部の14.Glossary。
Content:
内容:
ProtocolBrand Protocol Brand elements contain brand information
to be used with a specific payment protocol (see
section 7.7.2)
ProtocolBrandプロトコルBrand要素は特定の支払いプロトコルと共に使用されるべきブランド情報を含んでいます。(セクション7.7.2を見ます)
PackagedContent Optional Packaged Content (see section 3.7)
elements containing information about the brand
which may be used by the payment protocol. The
content of this information is defined in the
supplement for a payment protocol which describes
how the payment protocol works with IOTP.
支払いで使用されるかもしれないブランドの情報を含むPackagedContent Optional Packaged Content(セクション3.7を見る)要素が議定書を作ります。 この情報の内容は支払いプロトコルがIOTPと共にどう働いているかを説明する支払いプロトコルのための補足で定義されます。
Example Brand Elements are contained in section 11.2 Brand List Examples.
例のBrand Elementsはセクション11.2Brand List Examplesで含まれています。
7.7.2 Protocol Brand Element
7.7.2 プロトコルブランド要素
The Protocol Brand Element contains information that is specific to the use of a particular Protocol with a Brand. Its definition is as follows.
プロトコルBrand ElementはBrandとの特定のプロトコルの使用に特定の情報を含んでいます。 定義は以下の通りです。
<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED >
<!要素ProtocolBrand(PackagedContent*)><!ATTLIST ProtocolBrand ProtocolId CDATAの#必要なProtocolBrandId CDATA#、は>を必要としました。
Attributes:
属性:
ProtocolId This must match the value of a ProtocolId
attribute in a Pay Protocol Element (see section
7.7.5).
ProtocolId ThisはPayプロトコルElementのProtocolId属性の値に合わなければなりません(セクション7.7.5を見てください)。
The values of ProtocolId should be unique within a
Brand Element otherwise there is an error.
ProtocolIdの値はBrand Elementの中でユニークであるべきです。そうでなければ、誤りがあります。
Burdett Informational [Page 115] RFC 2801 IOTP/1.0 April 2000
バーデット[115ページ]情報のRFC2801IOTP/2000年4月1日
ProtocolBrandId This is the Payment Brand Id to be used with a
particular payment protocol. For example, SET and
EMV have their own well defined, yet different,
values for the Brand Id to be used with each
protocol.
ProtocolBrandId Thisは特定の支払いプロトコルと共に使用されるべきPayment Brand Idです。 例えば、SETとEMVはそれら自身のをよく定義させます、まだ異なっています、Brand Idが各プロトコルと共に使用される値。
The valid values of this attribute are defined in
the supplement for the payment protocol identified
by ProtocolId that describes how the payment
protocol works with IOTP.
この属性の有効値は支払いプロトコルがIOTPと共にどう働いているかを説明するProtocolIdによって特定された支払いプロトコルのための補足で定義されます。
Content:
内容:
PackagedContent Optional Packaged Content (see section 3.7)
elements containing information about the
protocol/brand which may be used by the payment
protocol. The content of this information is
defined in the supplement for a payment protocol
which describes how the payment protocol works
with IOTP.
支払いで使用されるかもしれないプロトコル/ブランドの情報を含むPackagedContent Optional Packaged Content(セクション3.7を見る)要素が議定書を作ります。 この情報の内容は支払いプロトコルがIOTPと共にどう働いているかを説明する支払いプロトコルのための補足で定義されます。
7.7.3 Protocol Amount Element
7.7.3 プロトコル量の要素
The Protocol Amount element links a Brand to:
プロトコルAmount要素は以下のことのためにBrandをリンクします。
o the currencies and amounts in Currency Amount Elements (see
section 7.7.4) that can be used with the Brand, and
o そしてBrandと共に使用できるCurrency Amount Elements(セクション7.7.4を見る)の通貨と量。
o the Payment Protocols and Payment Handlers defined in a Pay
Protocol Element (see section 7.7.5), which can be used with those
currencies and amounts.
o PaymentプロトコルとPayment HandlersはPayでプロトコルElement(セクション7.7.5を見る)を定義しました。(それらの通貨と量と共にElementを使用できます)。
Its definition is as follows:
定義は以下の通りです:
<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount
ID ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!要素ProtocolAmount(PackagedContent*)><!必要なATTLIST ProtocolAmountの必要なCurrencyAmountRefs IDREFS#必要なContentSoftwareId CDATA ID ID#PayProtocolRef IDREF##、は>を含意しました。
Attributes:
属性:
ID Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
contained in a later Payment Request message
which uniquely identifies the Protocol Amount
element within the IOTP Transaction.
Brand要素で潜在的に参照をつけられるID Element識別子。 または、後のPayment Requestメッセージに含まれたBrand Selection Componentでは、どれがIOTP Transactionの中で唯一プロトコルAmount要素を特定しますか?
Burdett Informational [Page 116] RFC 2801 IOTP/1.0 April 2000
バーデット[116ページ]情報のRFC2801IOTP/2000年4月1日
PayProtocolRef Contains an Element Reference (see section 3.5)
that refers to the Pay Protocol Element (see
section 7.7.5) that contains the Payment Protocol
and Payment Handlers that can be used with the
Brand.
PayProtocolRef Contains、Paymentプロトコルを含むPayプロトコルElement(セクション7.7.5を見る)とBrandと共に使用できるPayment Handlersについて言及するElement Reference(セクション3.5を見ます)。
CurrencyAmountRefs Contains a list of Element References (see
section 3.5) that refer to the Currency Amount
Element (see section 7.7.4) that describes the
currencies and amounts that can be used with the
Brand.
通貨について説明するCurrency Amount Element(セクション7.7.4を見る)とBrandと共に使用できる量について言及するElement References(セクション3.5を見る)のCurrencyAmountRefs Contains aリスト。
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Content:
内容:
PackagedContent Optional Packaged Content (see section 3.7)
elements containing information about the protocol
amount which may be used by the payment protocol.
The content of this information is defined in the
supplement for a payment protocol which describes
how the payment protocol works with IOTP.
支払いで使用されるかもしれないプロトコル量の情報を含むPackagedContent Optional Packaged Content(セクション3.7を見る)要素が議定書を作ります。 この情報の内容は支払いプロトコルがIOTPと共にどう働いているかを説明する支払いプロトコルのための補足で定義されます。
Examples of Protocol Amount Elements are contained in section 11.2 Brand List Examples.
プロトコルAmount Elementsの例はセクション11.2Brand List Examplesで含まれています。
7.7.4 Currency Amount Element
7.7.4 貨幣額要素
A Currency Amount element contains:
Currency Amount要素は以下を含んでいます。
o a currency code (and its type), and
o そして通貨コード(そして、タイプ)。
o an amount.
o 量。
One or more of these elements is carried in each Brand List Component. Its definition is as follows:
これらの要素の1つ以上は各Brand List Componentで運ばれます。 定義は以下の通りです:
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED >
空の<!のID#必要な量のCDATA要素CurrencyAmount><!ATTLIST CurrencyAmount ID#、はCurrCodeType NMTOKENの'ISO4217-A'#必要なCurrCode CDATA>を必要としました。
Attributes:
属性:
ID Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
Brand要素で潜在的に参照をつけられるID Element識別子。 または、ブランド選択コンポーネントで
Burdett Informational [Page 117] RFC 2801 IOTP/1.0 April 2000
バーデット[117ページ]情報のRFC2801IOTP/2000年4月1日
contained in a later Payment Request message which
uniquely identifies the Currency Amount Element
within the IOTP Transaction.
IOTP Transactionの中で唯一Currency Amount Elementを特定する後のPayment Requestメッセージでは、含まれています。
Amount Indicates the amount to be paid in whole and
fractional units of the currency. For example
$245.35 would be expressed "245.35". Note that
values smaller than the smallest denomination are
allowed. For example one tenth of a cent would be
"0.001".
量のIndicates、全部支払われる額と断片的なユニットの通貨。 例えば、245.35ドルは「245.35」言い表されるでしょう。 最も小さい宗派より小さい値が許容されていることに注意してください。 例えば、1セントの1/10は「0.001インチ」でしょう。
CurrCodeType Indicates the domain of the CurrCode. This
attribute is included so that the currency code
may support non-standard "currencies" such as
frequent flyer points, trading stamps, etc. Its
values may be:
o ISO4217-A (the default) indicates the currency
code is a three character alphabetic currency
code that conforms to [ISO 4217]
o IOTP indicates that values of CurrCode are
managed under the procedure described in
section 12 IANA Considerations
CurrCodeType Indicates、CurrCodeのドメイン。 この属性は、通貨コードがフリークエントフライヤーポイント、商品引換えスタンプなどの標準的でない「通貨」をサポートすることができるように、含まれています。 値は以下の通りです。 o ISO4217-A(デフォルト)は、通貨コードが[ISO4217]o IOTPに従う3のキャラクタのアルファベット通貨コードが、CurrCodeの値がセクション12IANA Considerationsで説明された手順の下で管理されるのを示すということであることを示します。
CurrCode A code which identifies the currency to be used in
the payment. The domain of valid currency codes is
defined by CurrCodeType
支払いに使用されるために通貨を特定するCurrCode Aコード。 有効な通貨コードのドメインはCurrCodeTypeによって定義されます。
As values of CurrCodeType are managed under the
procedure described in section 12 IANA
Considerations user defined values of CurrCodeType
may be defined.
CurrCodeTypeの値がセクション12IANA Considerationsで説明された手順の下で管理されて、CurrCodeTypeのユーザの定義された値が定義されるかもしれないということであるので。
Examples of Currency Amount Elements are contained in section 11.2 Brand List Examples.
Currency Amount Elementsの例はセクション11.2Brand List Examplesで含まれています。
7.7.5 Pay Protocol Element
7.7.5 プロトコル要素支払ってください。
A Pay Protocol element specifies details of a Payment Protocol and the Payment Handler that can be used with a Brand. One or more of these elements is carried in each Brand List.
Payプロトコル要素はBrandと共に使用できるPaymentプロトコルとPayment Handlerの細部を指定します。 これらの要素の1つ以上は各Brand Listで運ばれます。
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
<!ELEMENT PayProtocol(PackagedContent*)><!ATTLIST PayProtocol ID ID#REQUIRED xml: lang NMTOKEN#IMPLIED ProtocolId NMTOKEN#REQUIRED ProtocolName CDATA#REQUIRED ActionOrgRef NMTOKEN#REQUIRED
Burdett Informational [Page 118] RFC 2801 IOTP/1.0 April 2000
バーデット[118ページ]情報のRFC2801IOTP/2000年4月1日
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
PayReqNetLocn CDATA#は、SecPayReqNetLocn CDATA#が、ContentSoftwareId CDATA#が>を含意するのを含意したのを含意しました。
Attributes:
属性:
ID Element identifier, potentially referenced in a
Brand element; or in a Brand Selection Component
contained in a later Payment Request message which
uniquely identifies the Pay Protocol element
within the IOTP Transaction.
Brand要素で潜在的に参照をつけられるID Element識別子。 または、後のPayment Requestメッセージに含まれたBrand Selection Componentでは、どれがIOTP Transactionの中で唯一Payプロトコル要素を特定しますか?
xml:lang Defines the language used by attributes and
content of this element. See section 3.8
Identifying Languages.
xml: 言語がこの要素の属性と内容で使用したlang Defines。 セクション3.8Identifying Languagesを見てください。
ProtocolId Consists of a protocol name and version. For
example "SETv1.0".
プロトコル名とバージョンのProtocolId Consists。 例えば、"SETv1.0""。
The values of ProtocolId are defined by the
payment scheme/method owners in the document that
describes how to encapsulate a payment protocol
within IOTP.
ProtocolIdの値はIOTPの中で支払いプロトコルをカプセル化する方法を説明するドキュメントで支払い体系/メソッド所有者によって定義されます。
ProtocolName A narrative description of the payment protocol
and its version in the language identified by
xml:lang. For example "Secure Electronic
Transaction Version 1.0". Its purpose is to help
provide information on the payment protocol being
used if problems arise.
xmlによって特定された言語の支払いプロトコルとそのバージョンのProtocolName A物語記述: lang。 例えば、「安全な電子取引バージョン1インチ。」 目的は支払いプロトコルの情報を提供するのを問題が起こるなら使用されることで助けることです。
ActionOrgRef An Element Reference (see section 3.5) to the
Organisation Component for the Payment Handler for
the Payment Protocol.
PaymentプロトコルのためのPayment HandlerのためのOrganisation ComponentへのActionOrgRef An Element Reference(セクション3.5を見ます)。
PayReqNetLocn The Net Location indicating where an unsecured
Payment Request message should be sent if this
protocol choice is used.
このプロトコル選択が使用されているならunsecured Payment Requestメッセージがどこに送られるべきであるかを示すPayReqNetLocnネットLocation。
The content of this attribute is dependent on the
Transport Mechanism (such must conform to
[RFC1738].
この属性の内容はTransport Mechanismに依存しています。(そのようなものは[RFC1738]に従わなければなりません。
SecPayReqNetLocn The Net Location indicating where a secured
Payment Request message should be sent if this
protocol choice is used.
このプロトコル選択が使用されているなら機密保護しているPayment Requestメッセージがどこに送られるべきであるかを示すSecPayReqNetLocnネットLocation。
Burdett Informational [Page 119] RFC 2801 IOTP/1.0 April 2000
バーデット[119ページ]情報のRFC2801IOTP/2000年4月1日
A secured payment involves the use of a secure
channel such as [SSL/TLS] in order to communicate
with the Payment Handler.
機密保護している支払いは、Payment Handlerとコミュニケートするために[SSL/TLS]などの安全なチャンネルの使用にかかわります。
The content of this attribute must conform to
[RFC1738]. See also See section 3.9 Secure and
Insecure Net Locations.
この属性の内容は[RFC1738]に従わなければなりません。 また、See部3.9のSecureとInsecureネットLocationsを見てください。
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Content:
内容:
PackagedContent Optional Packaged Content elements (see section
3.7) containing information about the protocol
which is used by the payment protocol. The content
of this information is defined in the supplement
for a payment protocol which describes how the
payment protocol works with IOTP. An example of
its use could be to include a payment protocol
message.
支払いで使用されるプロトコルの情報を含むPackagedContent Optional Packaged Content要素(セクション3.7を見る)が議定書を作ります。 この情報の内容は支払いプロトコルがIOTPと共にどう働いているかを説明する支払いプロトコルのための補足で定義されます。 使用に関する例は支払いプロトコルメッセージを含むことであることができました。
Examples of Pay Protocol Elements are contained in section 11.2 Brand List Examples.
Pay Protocol Elementsの例はセクション11.2Brand List Examplesで含まれています。
7.8 Brand Selection Component
7.8 ブランド選択コンポーネント
A Brand Selection Component identifies the choice of payment brand, payment protocol and the Payment Handler. This element is used:
Brand Selection Componentは支払いブランド、支払いプロトコル、およびPayment Handlerの選択を特定します。 この要素は使用されています:
o in Payment Request messages within Baseline Purchase and Baseline
Value Exchange IOTP Transactions to identify the brand, protocol
and payment handler for a payment, or
o または支払いでブランド、プロトコル、および支払い操作者を特定するBaseline PurchaseとBaseline Value Exchange IOTP Transactionsの中のPayment Requestメッセージで。
o to, optionally, inform a merchant in a purchase of the payment
brand being used so that the offer and order details can be
amended accordingly.
o 支払いブランドの購入で商人にそれに従って、申し出とオーダーの詳細を修正できるように使用されることで任意に知らせるために。
In Baseline IOTP, the integrity of Brand Selection Components is not guaranteed. However, modification of Brand Selection Components can only cause denial of service if the payment protocol itself is secure against message modification, duplication, and swapping attacks.
Baseline IOTPでは、Brand Selection Componentsの保全は保証されません。 しかしながら、支払いプロトコル自体がメッセージ変更、複製、およびスワッピング攻撃に対して安全である場合にだけ、Brand Selection Componentsの変更はサービスの否定を引き起こす場合があります。
The definition of a Brand Selection Component is as follows.
Brand Selection Componentの定義は以下の通りです。
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
<!要素BrandSelection(BrandSelBrandInfo?、BrandSelProtocolAmountInfo?、BrandSelCurrencyAmountInfo?) ><!ATTLIST BrandSelection
Burdett Informational [Page 120] RFC 2801 IOTP/1.0 April 2000
バーデット[120ページ]情報のRFC2801IOTP/2000年4月1日
ID ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED
BrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >
必要な必要なIDの必要なProtocolAmountRef NMTOKEN#必要なCurrencyAmountRef NMTOKEN ID#BrandListRef NMTOKEN#BrandRef NMTOKEN##、は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the Brand
Selection Component within the IOTP Transaction.
IOTP Transactionの中で唯一Brand Selection Componentを特定するID An識別子。
BrandListRef The Element Reference (see section 3.5) of the
Brand List Component from which a Brand is being
selected
Brandが選択されているBrand List ComponentのBrandListRef Element Reference(セクション3.5を見ます)
BrandRef The Element Reference of a Brand element within
the Brand List Component that is being selected
that is to be used in the payment.
選択されているBrand List Componentの中の支払いに使用されることになっているBrand要素のBrandRef Element Reference。
ProtocolAmountRef The Element Reference of a Protocol Amount element
within the Brand List Component which is to be
used when making the payment.
支払いを済ませるとき使用されていることになっているBrand List Componentの中のプロトコルAmount要素のProtocolAmountRef Element Reference。
CurrencyAmountRef The Element Reference of a Currency Amount element
within the Brand List Component which is to be
used when making the payment.
支払いを済ませるとき使用されていることになっているBrand List Componentの中のCurrency Amount要素のCurrencyAmountRef Element Reference。
Content:
内容:
BrandSelBrandInfo, This contains any additional data that
BrandSelProtocolAmountInfo, may be required by a particular payment
BrandSelCurrencyAmountInfo brand or protocol. See sections 7.8.1,
7.8.2, and 7.8.3.
BrandSelBrandInfo、Thisはどんな追加データも含んでいます。そのBrandSelProtocolAmountInfoが特定の支払いBrandSelCurrencyAmountInfoブランドで必要であるかもしれませんか、または議定書を作ってください。 そして、見る、セクション7.8 .1 7.8 .2、7.8 .3。
The following rules apply:
以下の規則は適用されます:
o the BrandListRef must contain the ID of a Brand List Component in
the same IOTP Transaction
o BrandListRefは同じIOTP TransactionにBrand List ComponentのIDを含まなければなりません。
o every Brand List Component in the Trading Protocol Options Block
(see section 8.1) must be referenced by one and only one Brand
Selection Component
o 唯一無二の1Brand Selection ComponentがTradingプロトコルOptions Block(セクション8.1を見る)のあらゆるBrand List Componentに参照をつけなければなりません。
o the BrandRef must refer to the ID of a Brand contained within the
Brand List Component referred to by BrandListRef
o BrandRefはBrandListRefによって言及されたBrand List Componentの中に含まれたBrandのIDについて言及しなければなりません。
Burdett Informational [Page 121] RFC 2801 IOTP/1.0 April 2000
バーデット[121ページ]情報のRFC2801IOTP/2000年4月1日
o the ProtocolAmountRef must refer to one of the Element IDs listed
in the ProtocolAmountRefs attribute of the Brand element
identified by BrandRef
o ProtocolAmountRefはBrandRefによって特定されたBrand要素のProtocolAmountRefs属性で記載されたElement IDの1つについて言及しなければなりません。
o the CurrencyAmountRef must refer to one of the Element IDs listed
in the CurrencyAmountRefs attribute of the Protocol Amount Element
identified by ProtocolAmountRef.
o CurrencyAmountRefはProtocolAmountRefによって特定されたプロトコルAmount ElementのCurrencyAmountRefs属性で記載されたElement IDの1つについて言及しなければなりません。
An example of a Brand Selection Component is included in 11.2 Brand List Examples.
Brand Selection Componentに関する例は11.2Brand List Examplesに含まれています。
7.8.1 Brand Selection Brand Info Element
7.8.1 ブランド選択ブランドインフォメーション要素
The Brand Selection Brand Info Element contains any additional data that may be required by a particular payment brand. See the IOTP payment method supplement for a description of how and when it used.
Brand Selection Brand Info Elementは特定の支払いブランドによって必要とされる追加データを含んでいます。 IOTP支払い方法がどのように、いつに関する記述のために使用されていた状態でそれを補うかを見てください。
<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!要素BrandSelBrandInfo(PackagedContent+)><!ATTLIST BrandSelBrandInfoのIDのIDの#必要なContentSoftwareId CDATA#、は>を含意しました。
Attributes:
属性:
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Content:
内容:
PackagedContent Packaged Content elements (see section 3.7) that
contain additional data that may be required by a
particular payment brand. See the payment method
supplement for IOTP for rules on how this is used.
それが追加データであるかもしれないことを含むPackagedContent Packaged Content要素(セクション3.7を見る)が特定の支払いブランドが必要です。 IOTPに関してこれがどう使用されているかに関する規則に関して支払い方法補足を見てください。
7.8.2 Brand Selection Protocol Amount Info Element
7.8.2 ブランド選択プロトコル量のインフォメーション要素
The Brand Selection Protocol Amount Info Element contains any additional data that is payment protocol specific that may be required by a particular payment brand or payment protocol. See the IOTP payment method supplement for a description of how and when it used.
Brand SelectionプロトコルAmount Info Elementは特定の支払いブランドか支払いプロトコルによって必要とされるかもしれない支払いプロトコル詳細であるどんな追加データも含んでいます。 IOTP支払い方法がどのように、いつに関する記述のために使用されていた状態でそれを補うかを見てください。
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!要素BrandSelProtocolAmountInfo(PackagedContent+)><!ATTLIST BrandSelProtocolAmountInfoのIDのIDの#必要なContentSoftwareId CDATA#、は>を含意しました。
Burdett Informational [Page 122] RFC 2801 IOTP/1.0 April 2000
バーデット[122ページ]情報のRFC2801IOTP/2000年4月1日
Attributes:
属性:
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Content:
内容:
PackagedContent Packaged Content elements (see section 3.7) that
may contain additional data that may be required
by a particular payment brand. See the payment
method supplement for IOTP for rules on how this
is used.
それが追加データであるかもしれないことを含むかもしれないPackagedContent Packaged Content要素(セクション3.7を見る)が特定の支払いブランドが必要です。 IOTPに関してこれがどう使用されているかに関する規則に関して支払い方法補足を見てください。
7.8.3 Brand Selection Currency Amount Info Element
7.8.3 ブランド選択貨幣額インフォメーション要素
The Brand Selection Currency Amount Info Element contains any additional data that is payment brand and currency specific that may be required by a particular payment brand. See the IOTP payment method supplement for a description of how and when it used.
Brand Selection Currency Amount Info Elementは支払いブランドであるどんな追加データと特定の支払いブランドによって必要とされるかもしれない通貨詳細も含んでいます。 IOTP支払い方法がどのように、いつに関する記述のために使用されていた状態でそれを補うかを見てください。
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!要素BrandSelCurrencyAmountInfo(PackagedContent+)><!ATTLIST BrandSelCurrencyAmountInfoのIDのIDの#必要なContentSoftwareId CDATA#、は>を含意しました。
Attributes:
属性:
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Content:
内容:
PackagedContent Packaged Content elements (see section 3.7) that
contain additional data relating to the payment
brand and currency. See the payment method
supplement for IOTP for rules on how this is used.
支払いブランドと通貨に関連する追加データを含むPackagedContent Packaged Content要素(セクション3.7を見ます)。 IOTPに関してこれがどう使用されているかに関する規則に関して支払い方法補足を見てください。
7.9 Payment Component
7.9 支払いコンポーネント
A Payment Component contains information used to control how a payment is carried out. Its provides information on:
Payment Componentは支払いがどう行われるかを制御するのに使用される情報を含んでいます。 それ、以下で情報を提供します。
o the times within which a Payment with a Payment Handler may be
started
o Payment HandlerとPaymentが始動されるかもしれない回
o a reference to the Brand List (see section 7.7) which identifies
the Brands, protocols, currencies and amounts which can be used to
make a payment
o 支払いを済ませるのに使用できるBrand List(セクション7.7を見る)のBrandsを特定する参照、プロトコル、通貨、および量
o whether or not a payment receipt will be provided
o 支払い領収書を提供であるかどうか。
Burdett Informational [Page 123] RFC 2801 IOTP/1.0 April 2000
バーデット[123ページ]情報のRFC2801IOTP/2000年4月1日
o whether another payment precedes this payment.
o 別の支払いはこの支払いに先行であるかどうか
Its definition is as follows.
定義は以下の通りです。
<!ELEMENT Payment EMPTY >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt (True | False) #REQUIRED
StartAfterRefs NMTOKENS #IMPLIED >
空の必要な<!の必要なOkTo CDATA#必要なBrandListRef NMTOKEN要素支払い><!ATTLIST支払いID ID#OkFrom CDATA##、がSignedPayReceiptを必要とした、(本当に、| 偽) #必要なStartAfterRefs NMTOKENS#、は>を含意しました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Payment Component within the IOTP Transaction.
IOTP Transactionの中で唯一Payment Componentを特定するID An識別子。
OkFrom The date and time in [UTC] format after which a
Payment Handler may accept for processing a
Payment Request Block (see section 8.7) containing
the Payment Component.
Payment Componentを含んでいて、どのa Payment Handlerがそうしたかもしれないかの後に[UTC]形式における日時のOkFromは処理のために、Payment Request Block(セクション8.7を見る)を受け入れます。
OkTo The date and time in [UTC] format before which a
Payment Handler may accept for processing a
Payment Request Block containing the Payment
Component.
どのa Payment Handlerがそうするかもしれないかの前の[UTC]形式における日時のOkToは処理のためにPayment Componentを含むPayment Request Blockを受け入れます。
BrandListRef An Element Reference (see section 3.5) of a Brand
List Component (see section 7.7) within the TPO
Trading Block for the IOTP Transaction. The Brand
List identifies the alternative ways in which the
payment can be made.
IOTP TransactionのためのTPO Trading Blockの中のBrand List Component(セクション7.7を見る)のBrandListRef An Element Reference(セクション3.5を見ます)。 Brand Listは支払いが済むことができる代替の方法を特定します。
SignedPayReceipt Indicates whether or not the Payment Response
Block (see section 8.9) generated by the Payment
Handler for the payment must be digitally signed.
SignedPayReceipt Indicates、支払いでPayment Handlerによって生成されたPayment Response Block(セクション8.9を見る)にデジタルに署名でなければならないかどうか
StartAfter Contains Element References (see section 3.5) of
other Payment Components which describe payments
which must be complete before this payment can
start. If no StartAfter attribute is present then
there are no dependencies and the payment can
start immediately
この支払いの前に完全であるに違いない支払いについて説明する他のPayment ComponentsのStartAfter Contains Element References(セクション3.5を見る)は始まることができます。 どんなStartAfter属性も存在していないなら、依存が全くありません、そして、支払いはすぐに、始まることができます。
Burdett Informational [Page 124] RFC 2801 IOTP/1.0 April 2000
バーデット[124ページ]情報のRFC2801IOTP/2000年4月1日
7.10 Payment Scheme Component
7.10 支払い体系コンポーネント
A Payment Scheme Component contains payment protocol information for a specific payment scheme which is transferred between the parties involved in a payment for example a [SET] message. Its definition is as follows.
Payment Scheme Componentは特定の支払い体系のためのパーティーの間にどれを移すかが[SET]メッセージに例えば、支払いにかかわったという支払いプロトコル情報を含んでいます。 定義は以下の通りです。
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!要素PaySchemeData(PackagedContent+)><!ATTLIST PaySchemeDataのIDのIDの#必要なPaymentRef NMTOKEN#、は、ConsumerPaymentId CDATA#が、PaymentHandlerPayId CDATA#が、ContentSoftwareId CDATA#が>を含意するのを含意するのを含意したのを含意しました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Payment Scheme Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Payment Scheme Componentを特定するID An識別子。
PaymentRef An Element Reference (see section 3.5) to the
Payment Component (see section 7.9) to which
this Payment Scheme Component relates. It is
required unless the Payment Scheme Component is
part of an Transaction Inquiry Status
Transaction (see section 9.2.1).
このPayment Scheme Componentが関係するPayment Component(セクション7.9を見る)へのPaymentRef An Element Reference(セクション3.5を見ます)。 それがPayment Scheme ComponentがTransaction Inquiry Status Transactionの一部(セクション9.2.1を見る)でないなら必要です。
ConsumerPaymentId An identifier specified by the Consumer which,
if returned by the Payment Handler in another
Payment Scheme Component or by other means, will
enable the Consumer to identify which payment is
being referred to.
ConsumerPaymentId An識別子は、Consumerで別のPayment Scheme ComponentのPayment Handlerか他の手段で返すとどれが、Consumerが、どの支払いが言及されているかを特定するのを可能にするかを指定しました。
PaymentHandlerPayId An identifier specified by the Payment Handler
which, if returned by the Consumer in another
Payment Scheme Component, or by other means,
will enable the Payment Handler to identify
which payment is being referred to. It is
required on every Payment Scheme Component apart
from the one contained in a Payment Request
Block.
PaymentHandlerPayId An識別子は、Payment Handlerで別のPayment Scheme ComponentのConsumer、または他の手段で返すとどれが、Payment Handlerが、どの支払いが言及されているかを特定するのを可能にするかを指定しました。 Payment Request Blockに含まれたものは別として、それがあらゆるPayment Scheme Componentで必要です。
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Burdett Informational [Page 125] RFC 2801 IOTP/1.0 April 2000
バーデット[125ページ]情報のRFC2801IOTP/2000年4月1日
Content:
内容:
PackagedContent Contains payment scheme protocol information as
Packaged Content elements (see section 3.7). See
the payment scheme supplement for the definition
of its content.
Packaged Content要素(セクション3.7を見る)としてのPackagedContent Contains支払い体系プロトコル情報。 内容の定義のための支払い体系補足を見てください。
Note that:
o the values of the Name attribute of each
packaged content element are defined by the
Payment Protocol Supplement
o the value of each Name must be unique within a
Payment where a Payment is defined as all
Payment Scheme or Payment Receipt Components
with the same value of the PaymentRef attribute
以下のことに注意してください。 o それぞれのパッケージされた満足している要素のName属性の値はPaymentプロトコルSupplement oによって定義されて、それぞれのNameの値がPaymentで中PaymentがPaymentRef属性の同じ値ですべてのPayment SchemeかPayment Receipt Componentsと定義されるユニークであるに違いないということです。
7.11 Payment Receipt Component
7.11 支払い領収書の部品
A Payment Receipt is a record of a payment which demonstrates how much money has been paid or received. It is distinct from a purchase receipt in that it contains no record of what was being purchased.
Payment Receiptは多くのお金を支払うか、またはどう受け取ったかを示す支払いに関する記録です。 それは購入時の領収書と購入されていたものに関する記録を全く含んでいないという点において異なっています。
Typically the content of a Payment Receipt Component will contain data which describes:
通常、Payment Receipt Componentの内容は以下について説明するデータを含むでしょう。
o the amount paid and its currency
o 払込金額とその通貨
o the date and time of the payment
o 支払いの日時
o internal reference numbers which identify the payment to the
payment system
o 決済システムに支払いを特定する内部の参照番号
o potentially digital signatures generated by the payment method
which can be used to prove after the event that the payment
occurred.
o イベントの後に支払いが起こったと立証するのに使用できる支払い方法で生成された潜在的にデジタルの署名。
If the Payment Method being used provides the facility then the Payment Receipt Component should contain payment protocol messages, or references to messages, which prove the payment occurred.
使用されるPayment Methodが施設を提供するなら、Payment Receipt Componentは支払いが起こったと立証する支払いプロトコルメッセージ、またはメッセージの参照を含むはずです。
The precise definition of the content is Payment Method dependent. Refer to the supplement for the payment method being used to determine the rules that apply.
内容の厳密な定義はPayment Method扶養家族です。 適用される規則を決定するのに使用される支払い方法のための補足を参照してください。
Information contained in the Payment Receipt Component should be displayed or otherwise made available to the Consumer.
Payment Receipt Componentに含まれた情報を、表示するか、またはConsumerは別の方法で入手するはずです。
Burdett Informational [Page 126] RFC 2801 IOTP/1.0 April 2000
バーデット[126ページ]情報のRFC2801IOTP/2000年4月1日
Note: If the Payment Receipt Component contains Payment Protocol Messages, then the Messages will need to be processed by Payment Method software to convert it into a format which can be understood by the Consumer
以下に注意してください。 Payment Receipt ComponentがPaymentプロトコルMessagesを含んでいると、MessagesはPayment Methodソフトウェアによって処理されて、Consumerに解釈できる形式にそれを変換する必要があるでしょう。
The definition of a Payment Receipt Component is as follows.
Payment Receipt Componentの定義は以下の通りです。
<!ELEMENT PayReceipt (PackagedContent*) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
PayReceiptNameRefs NMTOKENS #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!要素PayReceipt(PackagedContent*)><!ATTLIST PayReceiptの必要なPaymentRef NMTOKEN#必要なPayReceiptNameRefs NMTOKENS ID ID##、は、ContentSoftwareId CDATA#が>を含意したのを含意しました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Payment Receipt Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Payment Receipt Componentを特定するID An識別子。
PaymentRef Contains an Element Reference (see section 3.5)
to the Payment Component (see section 7.9) to
which this payment receipt applies
PaymentRef Containsはこの支払い領収書が適用されるPayment Component(セクション7.9を見る)へのElement Reference(セクション3.5を見る)です。
PayReceiptNameRefs Optionally contains a list of the values of the
Name attributes of Packaged Content elements that
together make up the receipt. The Packaged
Content elements are contained either within:
o Payment Scheme Data components exchanged
between the Payment Handler and the Consumer
roles during the Payment, and/or
o the Payment Receipt component itself.
Note that:
o each payment scheme defines in its supplement
the Names of the Packaged Content elements
that must be listed in this attribute (if
any).
o if a Payment Scheme Component contains
Packaged Content elements with a name that
matches a name within PayReceiptNameRefs, then
those Payment Scheme Components must be
referenced by Digests in the Payment Response
signature component (if such a signature is
being used)
PayReceiptNameRefs Optionallyはそんなに一緒にいるPackaged Content要素の属性が領収書にするNameの値のリストを含んでいます。 Packaged Content要素は以下の中に含まれています。 o ○ Payment、そして/または、Payment Receiptの部品自体の間にPayment HandlerとConsumerの役割の間で交換された支払いScheme Dataの部品。 以下のことに注意してください。 o それぞれの支払い体系は補足でこの属性(もしあれば)で記載しなければならないPackaged Content要素のNamesを定義します。○ Payment Scheme ComponentがPayReceiptNameRefsの中で名前に合っている名前があるPackaged Content要素を含んでいるなら、Payment Response署名の部品におけるDigestsはそれらのPayment Scheme Componentsに参照をつけなければなりません。(そのような署名が使用されているなら)
The client software should save all the
components referenced so that the payment receipt
can be reconstructed when required.
クライアントソフトウェアは必要であると支払い領収書を再建できるように参照をつけられるすべてのコンポーネントを保存するはずです。
Burdett Informational [Page 127] RFC 2801 IOTP/1.0 April 2000
バーデット[127ページ]情報のRFC2801IOTP/2000年4月1日
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Content:
内容:
PackagedContent Optionally contains payment scheme payment receipt
information as Packaged Content elements (see
section 3.7). See the payment scheme supplement
for the definition of its content.
PackagedContent OptionallyはPackaged Content要素として支払い体系支払い領収書情報を含んでいます(セクション3.7を見てください)。 内容の定義のための支払い体系補足を見てください。
Note that:
o the values of the Name attribute of each
packaged content element are defined by the
Payment Protocol Supplement
o the value of each Name must be unique within a
Payment where a Payment is defined as all
Payment Scheme or Payment Receipt Components,
with the same value of the PaymentRef attribute
以下のことに注意してください。 o それぞれのパッケージされた満足している要素のName属性の値はPaymentプロトコルSupplement oによって定義されて、それぞれのNameの値がPaymentで中PaymentがすべてのPayment SchemeかPayment Receipt Componentsと定義されるユニークであるに違いありません、PaymentRef属性の同じ値でことです。
Note that either the PayReceiptNameRefs attribute, the PackagedContent element, or both must be present.
PayReceiptNameRefsが結果と考えるどちらか、PackagedContent要素、または両方が存在していなければならないことに注意してください。
7.12 Payment Note Component
7.12 支払い注意コンポーネント
The Payment Note Component contains additional, non payment related, information which the Payment Handler wants to provide to the Consumer. For example, if a withdrawal or deposit were being made then it could contain information on the remaining balance on the account after the transfer was complete. The information should duplicate information contained within the Payment Receipt Component.
Payment Note ComponentはPayment HandlerがConsumerに供給したがっている追加していて、非支払い関連する情報を含んでいます。 例えば、引き出しか預金をしているなら、転送が完全になった後にそれはアカウントの残高の情報を含むかもしれないでしょうに。 情報はPayment Receipt Componentの中に含まれた情報をコピーするべきです。
Information contained in the Payment Note Component should be displayed or otherwise made available to the Consumer. For interoperability, the Payment Note Component should support, as a minimum, the content types of "Plain Text", HTML and XML. Its definition is as follows.
Payment Note Componentに含まれた情報を、表示するか、またはConsumerは別の方法で入手するはずです。 相互運用性のために、Payment Note Componentは最小限として「プレーンテキスト」、HTML、およびXMLのcontent typeをサポートするはずです。 定義は以下の通りです。
<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!要素PaymentNote(PackagedContent+)><!ATTLIST PaymentNoteのIDのIDの#必要なContentSoftwareId CDATA#、は>を含意しました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Payment Receipt Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Payment Receipt Componentを特定するID An識別子。
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Burdett Informational [Page 128] RFC 2801 IOTP/1.0 April 2000
バーデット[128ページ]情報のRFC2801IOTP/2000年4月1日
Content:
内容:
PackagedContent Contains additional, non payment related,
information which the Payment Handler wants to
provide to the Consumer as one or more Packaged
Content elements (see section 3.7).
追加PackagedContent Contains非支払いは関係しました、Payment Handlerが1つ以上のPackaged Content要素としてConsumerに供給したがっている情報(セクション3.7を見てください)。
7.13 Delivery Component
7.13 配送コンポーネント
The Delivery Element contains information required to deliver goods or services. Its definition is as follows.
Delivery Elementは商品かサービスを提供するのに必要である情報を含んでいます。 定義は以下の通りです。
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
<!ATTLIST Delivery
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivExch (True | False) #REQUIRED
DelivAndPayResp (True | False) #REQUIRED
ActionOrgRef NMTOKEN #IMPLIED >
REQUIRED xml: <!ELEMENT Delivery(DeliveryData?、PackagedContent*)><!ATTLIST Delivery ID ID#lang NMTOKEN#REQUIRED DelivExch、(本当である、| 偽) #REQUIRED DelivAndPayResp、(本当である、| 偽) #REQUIRED ActionOrgRef NMTOKEN#IMPLIED>。
Attributes:
属性:
ID An identifier which uniquely identifies the
Delivery Component within the IOTP Transaction.
IOTP Transactionの中で唯一Delivery Componentを特定するID An識別子。
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages.
xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
DelivExch Indicates if this IOTP Transaction includes the
messages associated with a Delivery Exchange.
Valid values are:
o True indicates it does include a Delivery
Exchange
o False indicates it does not include a
Delivery Exchange
このIOTP Transactionがメッセージを含んでいるなら、DelivExch IndicatesはDelivery Exchangeと交際しました。 有効値は以下の通りです。 o 本当である、インクルードa Delivery Exchangeではなく、Falseがするのを示すDelivery Exchange oを含んでいるのを示します。
If set to true then a DeliveryData element must
be present. If set to false it may be absent.
本当に設定されるなら、DeliveryData要素は存在していなければなりません。 誤っているのに設定されるなら、欠けているかもしれません。
DelivAndPayResp Indicates if the Delivery Response Block (see
section 8.11) and the Payment Response Block (see
section 8.9 ) are combined into one IOTP Message.
Valid values are:
o True indicates both blocks will be in the
same IOTP Message, and
DelivAndPayResp IndicatesはDelivery Response Block(セクション8.11を見る)とPayment Response Block(セクション8.9を見る)であるなら1IOTP Messageに結合されます。 有効値は以下の通りです。 o そして本当である、両方のブロックが同じIOTP Messageにあるのを示す。
Burdett Informational [Page 129] RFC 2801 IOTP/1.0 April 2000
バーデット[129ページ]情報のRFC2801IOTP/2000年4月1日
o False indicates each block will be in a
different IOTP Message
o 偽は、各ブロックが異なったIOTP Messageにあるのを示します。
DelivAndPayResp should not be true if DelivExch
is False.
DelivAndPayRespはDelivExchがFalseであるなら本当であるはずがありません。
In practice combining the Delivery Response Block
and Payment Response Block is only likely to be
practical if the Merchant, the Payment Handler
and the Delivery Handler are the same
Organisation since:
o the Payment Handler must have access to Order
Component information so that they know what
to deliver, and
o the Payment Handler must be able to carry out
the delivery
実際には、Delivery Response BlockとPayment Response Blockを結合するのは以下以来マーチャント、Payment Handler、およびDelivery Handlerが同じOrganisationであるなら単に実用的である傾向があります。 o ○ Payment HandlerがOrder Component情報に近づく手段を持たなければならないので、彼らは、何を提供したらよいかを知っています、そして、Payment Handlerは配送を行うことができなければなりません。
ActionOrgRef An Element Reference to the Organisation
Component of the Delivery Handler for this
delivery.
この配送のためのDelivery HandlerのOrganisation ComponentへのActionOrgRef An Element Reference。
Content:
内容:
DeliveryData Contains details about how the delivery will be
carried out. See 7.13.1 Delivery Data Element
below.
配送がどう行われるかに関するDeliveryData Containsの詳細。 7.13に以下の.1Delivery Data Elementを見てください。
PackagedContent Contains "user" data defined for the Merchant
which is required by the Delivery Handler as one
or more Packaged Content Elements see section 3.7.
そうするマーチャントがDelivery Handlerが1Packaged ContentのElementsとして必要であるので、「ユーザ」データが定義したPackagedContent Containsはセクション3.7を見ます。
7.13.1 Delivery Data Element
7.13.1 配送データ要素
The DeliveryData element contains information about where and how goods are to be delivered. Its definition is as follows.
DeliveryData要素はどこと商品がどう提供されることになっているかの情報を含んでいます。 定義は以下の通りです。
<!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED
SecDelivReqNetLocn CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT DeliveryData(PackagedContent*)><!ATTLIST DeliveryData xml: lang NMTOKEN#IMPLIED OkFrom CDATA#REQUIRED OkTo CDATA#REQUIRED DelivMethod NMTOKEN#REQUIRED DelivToRef NMTOKEN#REQUIRED DelivReqNetLocn CDATA#REQUIRED SecDelivReqNetLocn CDATA#REQUIRED ContentSoftwareId CDATA#IMPLIED>。
Burdett Informational [Page 130] RFC 2801 IOTP/1.0 April 2000
バーデット[130ページ]情報のRFC2801IOTP/2000年4月1日
Attributes:
属性:
xml:lang Defines the language used by attributes within
this component. See section 3.8 Identifying
Languages.
xml: 言語がこのコンポーネントの中で属性で使用したlang Defines。 セクション3.8Identifying Languagesを見てください。
OkFrom The date and time in [UTC] format after which the
Delivery Handler may accept for processing a
Delivery Request Block (see section 8.10).
OkFrom、Delivery Handlerがそうするかもしれない[UTC]形式における日付と時間は処理のためにDelivery Request Blockを受け入れます(セクション8.10を見てください)。
OkTo The date and time in [UTC] format before which
the Delivery Handler may accept for processing a
Delivery Request Block.
OkTo、Delivery Handlerが処理のためにDelivery Request Blockを受け入れるかもしれない[UTC]形式における日時。
DelivMethod Indicates the method by which goods or services
may be delivered. Valid values are:
o Post the goods will be delivered by post or
courier
o Web the goods will be delivered
electronically in the Delivery Note Component
o Email the goods will be delivered
electronically by e-mail
DelivMethod Indicates、メソッドはどの商品かサービスで提供されるかもしれないか。 有効値は以下の通りです。 o 商品が郵便によって提供されるポストか商品が商品がメールで電子的に提供されるDelivery Note Component oメールで電子的に提供される急使oウェブ
Values of DelivMethod are managed under the
procedure described in section 12 IANA
Considerations which allows user defined codes to
be defined.
DelivMethodの値はユーザの定義されたコードが定義されるのを許容するセクション12IANA Considerationsで説明された手順の下で管理されます。
DelivToRef The Element Reference (see section 3.4) of an
Organisation Component within the IOTP
Transaction which has a role of DelivTo. The
information in this block is used to determine
where delivery is to be made. It must be
compatible with DelivMethod. Specifically if the
DelivMethod is:
o Post, then the there must be a Postal Address
Element containing sufficient information for
a postal delivery,
o Web, then there are no specific requirements.
The information will be sent in a web page
back to the Consumer
o Email, then there must be Contact Information
Element with a valid e-mail address
DelivToの役割を持っているIOTP Transactionの中のOrganisation ComponentのDelivToRef Element Reference(セクション3.4を見ます)。 このブロックの情報は、配送がどこで作られているかことであることを決定するのに使用されます。 それはDelivMethodと互換性があるに違いありません。 特にDelivMethodがそうなら: o 次に、掲示、郵便物の配達のための十分な情報を含むPostal Address Elementがあるに違いありません、oウェブ、次に、決められた一定の要求が全くありません。 ウェブページでConsumer oメールに情報を送って戻して、次に、有効なEメールアドレスがあるContact情報Elementがあるに違いありません。
DelivReqNetLocn This contains the Net Location to which an
unsecured Delivery Request Block (see section
8.10) which contains the Delivery Component
should be sent.
DelivReqNetLocn ThisはDelivery Componentを含むunsecured Delivery Request Block(セクション8.10を見る)が送られるべきであるネットLocationを含んでいます。
Burdett Informational [Page 131] RFC 2801 IOTP/1.0 April 2000
バーデット[131ページ]情報のRFC2801IOTP/2000年4月1日
The content of this attribute is dependent on the
Transport Mechanism and must conform to
[RFC1738].
この属性の内容は、Transport Mechanismに依存していて、[RFC1738]に従わなければなりません。
SecDelivReqNetLocn This contains the Net Location to which a secured
Delivery Request Block (see section 8.10) which
contains the Delivery Component should be sent.
SecDelivReqNetLocn ThisはDelivery Componentを含む機密保護しているDelivery Request Block(セクション8.10を見る)が送られるべきであるネットLocationを含んでいます。
A secured delivery request involves the use of a
secure channel such as [SSL/TLS] in order to
communicate with the Payment Handler.
機密保護している配送要求は、Payment Handlerとコミュニケートするために[SSL/TLS]などの安全なチャンネルの使用にかかわります。
The content of this attribute is dependent on the
Transport Mechanism must conform to [RFC1738].
この属性の内容はTransport Mechanismの上の扶養家族が[RFC1738]に従わなければならないということです。
See also Section 3.9 Secure and Insecure Net
Locations.
また、セクション3.9 SecureとInsecureネットLocationsを見てください。
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Content:
内容:
PackagedContent Additional information about the delivery as one
or more Packaged Content elements (see section
3.7) provided to the Delivery Handler by the
merchant.
1つ以上のPackaged Content要素(セクション3.7を見る)としての配送のPackagedContent Additional情報は商人によるDelivery Handlerに供給されました。
7.14 Consumer Delivery Data Component
7.14 消費者配送データ構成要素
A Consumer Delivery Data Component is used by a Consumer to specify an identifier that can be used by the Consumer to identify the Delivery.
Consumer Delivery Data Componentは、ConsumerがDeliveryを特定するのに使用できる識別子を指定するのにConsumerによって使用されます。
Its definition is as follows:
定義は以下の通りです:
<!ELEMENT ConsumerDeliveryData EMPTY >
<!ATTLIST ConsumerDeliveryData
ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>
空の<!のID ID#必要なConsumerDeliveryId CDATA要素ConsumerDeliveryData><!ATTLIST ConsumerDeliveryData#、は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Consumer Delivery Data Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Consumer Delivery Data Componentを特定するID An識別子。
Burdett Informational [Page 132] RFC 2801 IOTP/1.0 April 2000
バーデット[132ページ]情報のRFC2801IOTP/2000年4月1日
ConsumerDeliveryId An identifier specified by the Consumer which, if
returned by the Delivery Handler will enable the
Consumer to identify which Delivery is being
referred to.
ConsumerDeliveryId An識別子がConsumerで指定した、どれ、戻って、Delivery Handlerが、ConsumerがどのDeliveryを特定するかを可能にするなら、言及されるのは、そうであるか。
7.15 Delivery Note Component
7.15 納品受領書の部品
A Delivery Note contains delivery instructions about the delivery of goods or services or potentially the actual Delivery Information itself. It is information which the person or Organisation receiving the Delivery Note can use when delivery occurs.
Delivery Noteは品物の配達かサービスに関する配送指示か潜在的に実際のDelivery情報自体を含んでいます。 それは人かOrganisationがDelivery Noteを受け取る場合配送が起こると使用されることができる情報です。
For interoperability, the Delivery Note Component Packaged Content should support both Plain Text, HTML and XML.
相互運用性のために、Delivery Note Component Packaged ContentはPlain Text、HTMLとXMLの両方をサポートするはずです。
It's definition is as follows.
定義は以下の通りということです。
<!ELEMENT DeliveryNote (PackagedContent+) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT DeliveryNote(PackagedContent+)><!ATTLIST DeliveryNote ID ID#REQUIRED xml: lang NMTOKEN#REQUIRED DelivHandlerDelivId CDATA#IMPLIED ContentSoftwareId CDATA#IMPLIED>。
Attributes:
属性:
ID An identifier which uniquely identifies the
Delivery Note Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Delivery Note Componentを特定するID An識別子。
xml:lang Defines the language used by attributes or child
elements within this component, unless
overridden by an xml:lang attribute on a child
element. See section 3.8 Identifying Languages.
xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
DelivHandlerDelivId An optional identifier specified by the Delivery
Handler which, if returned by the Consumer in
another Delivery Component, or by other means,
will enable the Delivery Handler to identify
which Delivery is being referred to. It is
required on every Delivery Component apart from
the one contained in a Delivery Request Block.
DelivHandlerDelivId Anの任意の識別子は、Delivery Handlerで別のDelivery ComponentのConsumer、または他の手段で返すとどれが、Delivery Handlerが、どのDeliveryが言及されているかを特定するのを可能にするかを指定しました。 Delivery Request Blockに含まれたものは別として、それがあらゆるDelivery Componentで必要です。
An example use of this attribute is to contain a
delivery tracking number.
この属性の例の使用は配送問い合わせ番号を含むことです。
ContentSoftwareId See section 14. Glossary.
ContentSoftwareId See部14。 用語集。
Burdett Informational [Page 133] RFC 2801 IOTP/1.0 April 2000
バーデット[133ページ]情報のRFC2801IOTP/2000年4月1日
Content:
内容:
PackagedContent Contains actual delivery note information as one
or more Packaged Content elements (see section
3.7).
1つ以上のPackaged Content要素(セクション3.7を見る)としてのPackagedContent Containsの実際の納品受領書情報。
Note: If the content of the Delivery Message is a Mime message then the Delivery Note may trigger an application which causes the actual delivery to occur.
以下に注意してください。 Delivery Messageの内容がMimeメッセージであるなら、Delivery Noteは実際の配送が起こるアプリケーションの引き金となるかもしれません。
7.16 Status Component
7.16 状態コンポーネント
A Status Component contains status information about the business success or failure (see section 4.2) of a process.
Status Componentはプロセスの営業上の成功か失敗(セクション4.2を見る)の状態情報を含んでいます。
Its definition is as follows.
定義は以下の通りです。
<!ELEMENT Status EMPTY >
<!ATTLIST Status
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
StatusType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessState (NotYetStarted | InProgress |
CompletedOk | Failed | ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED
StatusDesc CDATA #IMPLIED >
<!ELEMENT Status EMPTY><!ATTLIST Status ID ID#REQUIRED xml: lang NMTOKEN#REQUIRED StatusType NMTOKEN#REQUIRED ElRef NMTOKEN#IMPLIED ProcessState、(NotYetStarted|InProgress|CompletedOk|、| ProcessError) #REQUIRED CompletionCode NMTOKEN#IMPLIED ProcessReference CDATA#IMPLIED StatusDesc CDATA#IMPLIED>に失敗します。
Attributes:
属性:
ID An identifier which uniquely identifies the Status
Component within the IOTP Transaction.
IOTP Transactionの中で唯一Status Componentを特定するID An識別子。
xml:lang Defines the language used by attributes within
this component. See section 3.8 Identifying
Languages.
xml: 言語がこのコンポーネントの中で属性で使用したlang Defines。 セクション3.8Identifying Languagesを見てください。
StatusType Indicates the type of Document Exchange which the
Status is reporting on. It may be set to either
Offer, Payment, Delivery, Authentication or
Undefined.
Statusがオンであると報告しているDocument ExchangeのタイプのStatusType Indicates。 それはOffer、Payment、Delivery、AuthenticationまたはUndefinedに設定されるかもしれません。
Undefined means that the type of document exchange
could not be identified. This is caused by an
error in the initial input message of the
exchange.
ドキュメントのタイプが交換する未定義の手段を特定できませんでした。 これは交換の初期の入力メッセージにおける誤りで引き起こされます。
Burdett Informational [Page 134] RFC 2801 IOTP/1.0 April 2000
バーデット[134ページ]情報のRFC2801IOTP/2000年4月1日
Values of StatusType are managed under the
procedure described in section 12 IANA
Considerations which also allows user defined
values of StatusType to be defined.
StatusTypeの値はまた、StatusTypeのユーザの定義された値が定義されるのを許容するセクション12IANA Considerationsで説明された手順の下で管理されます。
ElRef If the StatusType is not set to Undefined then
ElRef contains an Element Reference (see section
3.5) to the Component for which the Status is
being described. It must refer to either:
o an Order Component (see section 7.5), if the
StatusType is Offer,
o a Payment Component (see section 7.9), if the
StatusType is Payment, or
o a Delivery Component (see section 7.13), if
the StatusType is Delivery
o an Authentication Request Component (see
section 7.2) if the StatusType is
Authentication.
ElRef If StatusTypeはUndefinedに用意ができていなくて、次に、ElRefはElement Reference(セクション3.5を見る)をStatusが説明されているComponentに含んでいます。 それはどちらかについて言及しなければなりません: o oのOrder Component(セクション7.5を見る)、StatusTypeがOfferであるか、そして、Payment Component(セクション7.9を見る)、StatusTypeがPaymentであるか、そして、またはo a Delivery Component(セクション7.13を見る)、StatusTypeであるなら、StatusTypeがAuthenticationであるなら、Delivery oはAuthentication Request Component(セクション7.2を見る)ですか?
ProcessState Contains a State Code which indicates the current
state of the process being carried out. Valid
values for ProcessState are:
o NotYetStarted. A Request Block has been
received but the process has not yet started
o InProgress. Processing of the Request Block
has started but it is not yet complete
o CompletedOk. The processing of the Request
Block has completed successfully without any
errors
o Failed. The processing of the Request Block
has failed because of a Business Error (see
section 4.2)
o ProcessError. This value is only used when the
Status Component is being used in connection
with an Inquiry Request Trading Block (see
section 8.12). It indicates there was a
Technical Error (see section 4.1) in the
Request Block which is being processed or some
internal processing error.
行われるプロセスの現状を示すProcessState Contains a州Code。 ProcessStateのための有効値は以下の通りです。 o NotYetStarted。 Request Blockを受け取りましたが、プロセスはまだo InProgressを始動していません。 Request Blockの処理は始まりましたが、それはまだ完全なo CompletedOkではありません。 Request Blockの処理は少しも誤りなしでo Failedを首尾よく完成しました。 Request Blockの処理はBusiness Error(セクション4.2を見ます)o ProcessErrorで失敗しました。 Status ComponentがInquiry Request Trading Blockで使用されているときだけ(セクション8.12を見てください)、この値は使用されます。 それは、処理されているRequest Blockか何らかの内部の整理過程の誤差にはTechnical Error(セクション4.1を見る)があったのを示します。
Note that this code reports on the processing of a
Request Block. Further, asynchronous processing
may occur after the Response Block associated with
the Process has been sent.
このコードがRequest Blockの処理に関して報告することに注意してください。 さらに、Processに関連しているResponse Blockを送った後に非同期処理は起こるかもしれません。
Burdett Informational [Page 135] RFC 2801 IOTP/1.0 April 2000
バーデット[135ページ]情報のRFC2801IOTP/2000年4月1日
CompletionCode Indicates how the process completed. Valid values
for the CompletionCode are given below together
with the conditions when it must be present and
indications on when recovery from failures are
possible.
CompletionCode Indicates、どのように、完了する過程。 それが存在していなければならなくて、失敗からの回復がいつかときに指摘が可能であるときに、状態と共にCompletionCodeのための有効値を以下に与えます。
A CompletionCode is a maximum of 14 characters
long.
長い間、CompletionCodeは最大14のキャラクタです。
ProcessReference This optional attribute holds a reference for the
process whose status is being reported. It may
hold the following values:
o when StatusType is set to Offer, it should
contain the OrderIdentifier from the Order
Component
o when StatusType is set to Payment, it should
contain the PaymentHandlerPayId from the
Payment Scheme Data Component
o when StatusType is set to Delivery, it should
contain the DelivHandlerDelivId from the
Delivery Note Component
o when StatusType is set to Authentication, it
should contain the AuthenticationId from the
Authentication Request Component
ProcessReference Thisの任意の属性は状態が報告されているプロセスの参照を保持します。 それは以下の値を保持するかもしれません: o それは、StatusTypeがOfferに用意ができているとき、StatusTypeがPaymentに用意ができているとき、Order Component oからのOrderIdentifierを含むべきであり、StatusTypeがDeliveryに用意ができているとき、Payment Scheme Data Component oからのPaymentHandlerPayIdを含むべきであり、StatusTypeがAuthenticationに用意ができているとき、Delivery Note Component oからのDelivHandlerDelivIdを含むべきであり、Authentication Request ComponentからのAuthenticationIdを含むべきです。
This attribute should be absent in the Inquiry
Request message when the Consumer has not been
given such a reference number by the IOTP Service
Provider.
IOTP Service Providerによるそのような参照番号がConsumerに与えられていないとき、この属性はInquiry Requestメッセージで欠けているべきです。
This attribute can be used inside an Inquiry
Response Block (see section 8.13) to give the
reference number for a transaction which has
previously been unavailable.
以前に入手できないトランザクションの参照番号を与えるのにInquiry Response Block(セクション8.13を見る)の中でこの属性を使用できます。
For example, the package tracking number might not
be assigned at the time a delivery response was
received. However, if the Consumer issues a
Baseline Transaction Status Inquiry later, the
Delivery Handler can put the package tracking
number into this attribute in the Inquiry Response
message and send it back to the Consumer.
例えば、配送応答を受けたとき、パッケージ問い合わせ番号を割り当てないかもしれません。 しかしながら、Consumerが後でBaseline Transaction Status Inquiryを発行するなら、Delivery HandlerはInquiry Responseメッセージのこの属性にパッケージ問い合わせ番号を入れて、それをConsumerに送り返すことができます。
StatusDesc An optional textual description of the current
status of the process in the language identified
by xml:lang.
xmlによって特定された言語における、プロセスの現在の状態のStatusDesc Anの任意の原文の記述: lang。
Burdett Informational [Page 136] RFC 2801 IOTP/1.0 April 2000
バーデット[136ページ]情報のRFC2801IOTP/2000年4月1日
7.16.1 Offer Completion Codes
7.16.1 完了コードを提供してください。
The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used and indicates whether or not recovery might be possible. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
ProcessState属性がFailedに設定される場合にだけ、Completion Codeが必要です。 以下のテーブルは使用されるかもしれなくて、回復が可能であるかもしれないかどうかを示すCompletionCodeのための有効値を含んでいます。 StatusDesc属性が適切であるところに詳細な説明を提供するのに使用されるのは、お勧めです。
Value Description
値の記述
AuthError Authentication Error. The check of the
Authentication Response which was carried out has
failed.
AuthError認証誤り。 行われるAuthentication Responseのチェックは失敗しました。
Recovery may be possible by the Consumer re-
submitting a new Authentication Response Block with
corrected information.
回復は修正された情報で新しいAuthentication Response Blockを再提出するConsumerが可能であるかもしれません。
ConsCancelled Consumer Cancelled. The Consumer decides to cancel
the transaction for some reason. This code is only
valid in a Status Component contained in a Cancel
Block or an Inquiry Response Block.
ConsCancelled消費者は取り消しました。 Consumerは、ある理由でトランザクションを取り消すと決めます。 このコードは単にキャンセルBlockかInquiry Response Blockに含まれたStatus Componentで有効です。
No recovery possible.
可能な回復がありません。
MerchCancelled Offer Cancelled. The Merchant declines to generate
an offer for some reason and cancels the
transaction. This code is only valid in a Status
Component contained in a Cancel Block or an Inquiry
Response Block.
MerchCancelled申し出は中止されました。 マーチャントは、いくつかの理由とキャンセルのための申し出がトランザクションであると生成するのを断ります。 このコードは単にキャンセルBlockかInquiry Response Blockに含まれたStatus Componentで有効です。
No recovery possible.
可能な回復がありません。
Unspecified Unspecified error. There is some unknown problem or
error which does not fall into one of the other
CompletionCodes.
不特定のUnspecified誤り。 他のCompletionCodesの1つにならない何らかの未知の問題か誤りがあります。
No recovery possible.
可能な回復がありません。
TimedOutRcvr Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
TimedOutRcvrの回復可能なタイムアウト。 メッセージを再送しましたが、応答は全く受信されませんでした。 したがって、ドキュメント交換には、「調節されたアウト」があります。 このコードは単にTransaction Inquiryで有効です。
Recovery is possible if the last message from the
other Trading Role is received again.
再びもう片方のTrading Roleからの最後のメッセージを受け取るなら、回復は可能です。
Burdett Informational [Page 137] RFC 2801 IOTP/1.0 April 2000
バーデット[137ページ]情報のRFC2801IOTP/2000年4月1日
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but
no response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
TimedOutNoRcvrの非回復可能なタイムアウト。 メッセージを再送しましたが、応答は全く受信されませんでした。 したがって、ドキュメント交換には、「調節されたアウト」があります。 このコードは単にTransaction Inquiryで有効です。
No recovery possible.
可能な回復がありません。
7.16.2 Payment Completion Codes
7.16.2 支払い完了コード
The CompletionCode is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used and indicates where recovery may be possible. It is recommended that the StatusDesc attribute is used by individual payment schemes to provide further explanation where appropriate.
ProcessState属性がFailedに設定される場合にだけ、CompletionCodeが必要です。 以下のテーブルは使用されるかもしれなくて、回復がどこで可能であるかもしれないかを示すCompletionCodeのための有効値を含んでいます。 StatusDesc属性が自己負担体系によって使用されて、適切であるところに詳細な説明を提供するのはお勧めです。
Value Description
値の記述
BrandNotSupp Brand not supported. The payment brand is not
supported by the Payment Handler.
サポートされなかったBrandNotSupp Brand。 支払いブランドはPayment Handlerによってサポートされません。
See below for recovery options.
回復オプションに関して以下を見てください。
CurrNotSupp Currency not supported. The currency in which the
payment is to be made is not supported by either
the Payment Instrument or the Payment Handler.
サポートされなかったCurrNotSupp Currency。 作られている支払いがことである通貨はPayment InstrumentかPayment Handlerのどちらかによって支えられません。
If the payment is Brand Independent, then the
Consumer may recover by selecting a different
currency, if available, or a different brand. Note
that this may involve a different Payment Handler.
支払いはBrand無党派、次に、Consumerが異なった通貨を選択することによって、回復するかもしれません、利用可能であるならことであるか、そして、異なったブランド。 これが異なったPayment Handlerにかかわるかもしれないことに注意してください。
ConsCancelled Consumer Cancelled. The Consumer decides to cancel
the payment for some reason. This code is only
valid in a Status Component contained in a Cancel
Block or an Inquiry Response Block.
ConsCancelled消費者は取り消しました。 Consumerは、ある理由で支払いを中止すると決めます。 このコードは単にキャンセルBlockかInquiry Response Blockに含まれたStatus Componentで有効です。
Recovery is not possible.
回復は可能ではありません。
PaymtCancelled Payment Cancelled. The Payment Handler declines to
complete the payment for some reason and cancels
the transaction. This code is only valid in a
Status Component contained in a Cancel Block or an
Inquiry Response Block.
PaymtCancelled支払いは中止されました。 Payment Handlerはある理由で支払いを終了するのを断って、トランザクションを取り消します。 このコードは単にキャンセルBlockかInquiry Response Blockに含まれたStatus Componentで有効です。
See below for recovery options.
回復オプションに関して以下を見てください。
Burdett Informational [Page 138] RFC 2801 IOTP/1.0 April 2000
バーデット[138ページ]情報のRFC2801IOTP/2000年4月1日
AuthError Authentication Error. The Payment Scheme specific
authentication check which was carried out has
failed.
AuthError認証誤り。 行われたPayment Schemeの特定の認証チェックは失敗しました。
Recovery may be possible. See the payment scheme
supplement to determine what is allowed.
回復は可能であるかもしれません。 支払い体系補足を見て、何が許容されているか決定してください。
InsuffFunds Insufficient funds. There are insufficient funds
available for the payment to be made.
InsuffFunds Insufficient基金。 済む支払いに利用可能な資金不足があります。
See below for recovery options.
回復オプションに関して以下を見てください。
InstBrandInvalid Payment Instrument not valid for Brand. A Payment
Instrument is being used which does not correspond
with the Brand selected. For example a Visa credit
card is being used when MasterCard was selected as
the Brand.
Brandには、有効でないInstBrandInvalid Payment Instrument。 Payment Instrumentは選択されるBrandに対応しない使用していることにされます。 マスターカードがBrandとして選定されたとき、例えばVisaクレジットカードは使用されています。
See below for recovery options.
回復オプションに関して以下を見てください。
InstNotValid Payment instrument not valid for trade. The
Payment Instrument cannot be used for the proposed
type of trade, for some reason.
貿易で有効でないInstNotValid Payment器具。 提案されたタイプの貿易、何らかの理由にPayment Instrumentを使用できません。
See below for recovery options.
回復オプションに関して以下を見てください。
BadInstrument Bad instrument. There is a problem with the
Payment Instrument being used which means that it
is unable to be used for the payment.
BadInstrument Bad器具。 支払いに使用できないことを意味する使用されるPayment Instrumentに関する問題があります。
See below for recovery options.
回復オプションに関して以下を見てください。
Unspecified Unspecified error. There is some unknown problem
or error which does not fall into one of the other
CompletionCodes. The StatusDesc attribute should
provide the explanation of the cause.
不特定のUnspecified誤り。 他のCompletionCodesの1つにならない何らかの未知の問題か誤りがあります。 StatusDesc属性は原因に関する説明を提供するべきです。
See below for recovery options.
回復オプションに関して以下を見てください。
TimedOutRcvr Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on
a Transaction Inquiry.
TimedOutRcvrの回復可能なタイムアウト。 メッセージを再送しましたが、応答は全く受信されませんでした。 したがって、ドキュメント交換には、「調節されたアウト」があります。 このコードは単にTransaction Inquiryで有効です。
Recovery is possible if the last message from the
other Trading Role is received again.
再びもう片方のTrading Roleからの最後のメッセージを受け取るなら、回復は可能です。
Burdett Informational [Page 139] RFC 2801 IOTP/1.0 April 2000
バーデット[139ページ]情報のRFC2801IOTP/2000年4月1日
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but
no response received. The document exchange has
therefore "Timed Out". This code is only valid on
a Transaction Inquiry.
TimedOutNoRcvrの非回復可能なタイムアウト。 メッセージを再送しましたが、応答は全く受信されませんでした。 したがって、ドキュメント交換には、「調節されたアウト」があります。 このコードは単にTransaction Inquiryで有効です。
No recovery possible.
可能な回復がありません。
If the Payment is Brand Independent, then recovery may be possible for some values of the Completion Code, by the Consumer selecting either a different payment brand or a different payment instrument for the same brand. Note that this might involve a different Payment Handler. The codes to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
PaymentがBrand無党派であるなら、Completion Codeのいくつかの値に、回復は可能であるかもしれません、同じブランドのために異なった支払いブランドか異なった支払い器具のどちらかを選択するConsumer。 これが異なったPayment Handlerにかかわるかもしれないことに注意してください。 これが適用されるコードは以下の通りです。 BrandNotSupp、PaymtCancelled、InsuffFunds、InstBrandInvalid、BadInstrumentの、そして、不特定のInstNotValid。
Recovery from Payments associated with Brand Dependent purchases is only possible, if the Brand Selection component sent by the Merchant to the Consumer does not change. In practice this means that the same Brand, Protocol Amount and PayProtocol elements must be used. All that can change is the Payment Instrument. Any other change will invalidate the Merchant's Offer as a changed selection will invalidate the Offer Response.
Brand Dependent購買に関連しているPaymentsからの回復は可能であるだけです、マーチャントによってConsumerに送られたBrand Selectionの部品が変化しないなら。 実際には、これは、同じBrand、プロトコルAmount、およびPayProtocol要素を使用しなければならないことを意味します。 変化できるすべてがPayment Instrumentです。 変えられた選択がOffer Responseを無効にするとき、いかなる他の変化もマーチャントのOfferを無効にするでしょう。
7.16.3 Delivery Completion Codes
7.16.3 配送完了コード
The following table contains the valid values for the CompletionCode attribute for a Delivery. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
以下のテーブルはDeliveryのためのCompletionCode属性のための有効値を含んでいます。 StatusDesc属性が適切であるところに詳細な説明を提供するのに使用されるのは、お勧めです。
Value Description
値の記述
BackOrdered Back Ordered. The goods to be delivered are on order
but they have not yet been received. Shipping will be
arranged when they are received. This is only valid
if ProcessState is CompletedOk.
注文された後部は注文しました。 オーダーには提供される商品がありますが、それらはまだ受け取られていません。 それらが受け取られているとき、送料はアレンジされるでしょう。 これはProcessStateがCompletedOkである場合にだけ有効です。
Recovery is not possible.
回復は可能ではありません。
PermNotAvail Permanently Not Available. The goods are permanently
unavailable and cannot be re-ordered. This is only
valid if ProcessState is Failed.
永久に利用可能でないPermNotAvail。 商品は、永久に、入手できなく、再注文できません。 これはProcessStateがFailedである場合にだけ有効です。
Recovery is not possible.
回復は可能ではありません。
TempNotAvail Temporarily Not Available. The goods are temporarily
unavailable and may become available if they can be
ordered. This is only valid if ProcessState is
CompletedOk.
一時利用可能でないTempNotAvail。 それらを注文できるなら、商品は、一時入手できなく、利用可能になるかもしれません。 これはProcessStateがCompletedOkである場合にだけ有効です。
Burdett Informational [Page 140] RFC 2801 IOTP/1.0 April 2000
バーデット[140ページ]情報のRFC2801IOTP/2000年4月1日
Recovery is not possible.
回復は可能ではありません。
ShipPending Shipping Pending. The goods are available and are
scheduled for shipping but they have not yet been
shipped. This is only valid if ProcessState is
CompletedOk.
未定の状態で出荷するShipPending。 商品は、利用可能であり、出荷のために予定されていますが、それらはまだ出荷されていません。 これはProcessStateがCompletedOkである場合にだけ有効です。
Recovery is not possible.
回復は可能ではありません。
Shipped Goods Shipped. The goods have been shipped.
Confirmation of delivery is awaited. This is only
valid if ProcessState is CompletedOk.
出荷された商品は出荷されました。 商品を出荷しました。 配送の確認は待たれます。 これはProcessStateがCompletedOkである場合にだけ有効です。
Recovery is not possible.
回復は可能ではありません。
ShippedNoConf Shipped - No Delivery Confirmation. The goods have
been shipped but it is not possible to confirm
delivery of the goods. This is only valid if
ProcessState is CompletedOk.
ShippedNoConfは出荷しました--配送確認がありません。 商品を出荷しましたが、商品の配送を確認するのは可能ではありません。 これはProcessStateがCompletedOkである場合にだけ有効です。
Recovery is not possible.
回復は可能ではありません。
ConsCancelled Consumer Cancelled. The Consumer decides to cancel
the delivery for some reason. This code is only valid
in a Status Component contained in a Cancel Block or
an Inquiry Response Block.
ConsCancelled消費者は取り消しました。 Consumerは、ある理由で配送を中止すると決めます。 このコードは単にキャンセルBlockかInquiry Response Blockに含まれたStatus Componentで有効です。
Recovery is not possible.
回復は可能ではありません。
DelivCancelled Delivery Cancelled. The Delivery Handler declines to
complete the Delivery for some reason and cancels the
transaction. This code is only valid in a Status
Component contained in a Cancel Block or an Inquiry
Response Block.
DelivCancelled配送は中止されました。 Delivery Handlerはある理由でDeliveryを完成するのを断って、トランザクションを取り消します。 このコードは単にキャンセルBlockかInquiry Response Blockに含まれたStatus Componentで有効です。
Recovery is not possible.
回復は可能ではありません。
Confirmed Confirmed. All goods have been delivered and
confirmation of their delivery has been received.
This is only valid if ProcessState is CompletedOk.
確認されていた状態で、確認されます。 すべての商品を提供しました、そして、彼らの配送の確認を受け取りました。 これはProcessStateがCompletedOkである場合にだけ有効です。
Recovery is not possible.
回復は可能ではありません。
Unspecified Unspecified error. There is some unknown problem or
error which does not fall into one of the other
CompletionCodes. The StatusDesc attribute should
provide the explanation of the cause.
不特定のUnspecified誤り。 他のCompletionCodesの1つにならない何らかの未知の問題か誤りがあります。 StatusDesc属性は原因に関する説明を提供するべきです。
Burdett Informational [Page 141] RFC 2801 IOTP/1.0 April 2000
バーデット[141ページ]情報のRFC2801IOTP/2000年4月1日
Recovery is not possible.
回復は可能ではありません。
TimedOutRcvr Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
TimedOutRcvrの回復可能なタイムアウト。 メッセージを再送しましたが、応答は全く受信されませんでした。 したがって、ドキュメント交換には、「調節されたアウト」があります。 このコードは単にTransaction Inquiryで有効です。
Recovery is possible if the last message from the
other Trading Role is received again.
再びもう片方のTrading Roleからの最後のメッセージを受け取るなら、回復は可能です。
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
TimedOutNoRcvrの非回復可能なタイムアウト。 メッセージを再送しましたが、応答は全く受信されませんでした。 したがって、ドキュメント交換には、「調節されたアウト」があります。 このコードは単にTransaction Inquiryで有効です。
No recovery possible.
可能な回復がありません。
Note: Recovery from failed, or partially completed deliveries is not possible. The Consumer should use the Transaction Status Inquiry Transaction (see section 9.2.1) to determine up-to- date information on the current state.
以下に注意してください。 失敗したか、部分的に完成した配送からの回復は可能ではありません。 Consumerは、上から日付への現状の情報を決定するのに、Transaction Status Inquiry Transaction(セクション9.2.1を見る)を使用するはずです。
7.16.4 Authentication Completion Codes
7.16.4 認証完了コード
The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
ProcessState属性がFailedに設定される場合にだけ、Completion Codeが必要です。 以下のテーブルは使用されるかもしれないCompletionCodeのための有効値を含んでいます。 StatusDesc属性が適切であるところに詳細な説明を提供するのに使用されるのは、お勧めです。
Value Description
値の記述
AutEeCancel Authenticatee Cancel. The Organisation being
authenticated declines to be authenticated for some
reason. This could be, for example because the
signature on an Authentication Request was invalid or
the Authenticator was not known or acceptable to the
Authenticatee.
AutEeCancel Authenticateeは取り消します。 認証されるOrganisationは、ある理由で認証されるのを断ります。 これはそうであるかもしれません、例えば、AuthenticatorがAuthenticateeにAuthentication Requestにおける署名が無効でなく、また知られない、また許容できなかったので。
Recovery is not possible.
回復は可能ではありません。
AutOrCancel Authenticator Cancel. The Organisation requesting
authentication declines to validate the
Authentication Response received for some reason and
cancels the transaction.
AutOrCancel固有識別文字キャンセル。 認証が、Authentication Responseを有効にするのを断るよう要求するOrganisationはある理由で受信して、トランザクションを取り消します。
Recovery is not possible.
回復は可能ではありません。
Burdett Informational [Page 142] RFC 2801 IOTP/1.0 April 2000
バーデット[142ページ]情報のRFC2801IOTP/2000年4月1日
NoAuthReq Authentication Request Not Available. The
Authenticatee does not have the data that must be
provided so that they may be successfully
authenticated. For example a password may have been
forgotten, the Authenticatee has not yet become a
member, or a smart card token is not present.
利用可能でないNoAuthReq認証要求。 Authenticateeには、首尾よくそれらを認証できるように提供しなければならないデータがありません。 例えばパスワードが忘れられたかもしれませんか、Authenticateeがまだメンバーになっていないか、またはスマートカードトークンは存在していません。
Recovery is not possible
回復は可能ではありません。
AuthFailed Authentication Failed. The Authenticator checked the
Authentication Response but the authentication failed
for some reason. For example a password may have been
incorrect.
AuthFailed認証は失敗しました。 AuthenticatorはAuthentication Responseをチェックしましたが、認証はある理由で失敗しました。 例えば、パスワードは不正確であったかもしれません。
Recovery may be possible by the Authenticatee re-
sending a revised Authentication Response with
corrected data.
回復は改訂されたAuthentication Responseを再送るAuthenticateeが直っているデータで可能であるかもしれません。
TradRolesIncon Trading Roles Inconsistent. The Trading Roles
contained within the TradingRoleList attribute of the
Trading Role Information Request Component (see
section 7.4) are inconsistent with the Trading Role
which the Authenticatee is taking in the IOTP
Transaction or is able to take. Examples of
inconsistencies include:
o asking a PaymentHandler for DeliveryHandler
information
o asking a Consumer for Merchant information
矛盾していた状態で役割を取り引きするTradRolesIncon。 Trading Role情報Request Component(セクション7.4を見る)のTradingRoleList属性の中に含まれたTrading RolesはAuthenticateeがIOTP Transactionで取っているか、または取ることができるTrading Roleに矛盾しています。 矛盾に関する例は: o マーチャント情報をConsumerに求めながら、DeliveryHandler情報oをPaymentHandlerに求めます。
Recovery may be possible by the Authenticator re-
sending a revised Authentication Request Block with
corrected information.
回復は改訂されたAuthentication Request Blockを再送るAuthenticatorが修正された情報で可能であるかもしれません。
Unspecified Unspecified error. There is some unknown problem or
error which does not fall into one of the other
CompletionCodes.
不特定のUnspecified誤り。 他のCompletionCodesの1つにならない何らかの未知の問題か誤りがあります。
Recovery is not possible.
回復は可能ではありません。
TimedOutRcvr Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
TimedOutRcvrの回復可能なタイムアウト。 メッセージを再送しましたが、応答は全く受信されませんでした。 したがって、ドキュメント交換には、「調節されたアウト」があります。 このコードは単にTransaction Inquiryで有効です。
Recovery is possible if the last message from the
other Trading Role is received again.
再びもう片方のTrading Roleからの最後のメッセージを受け取るなら、回復は可能です。
Burdett Informational [Page 143] RFC 2801 IOTP/1.0 April 2000
バーデット[143ページ]情報のRFC2801IOTP/2000年4月1日
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no
response received. The document exchange has
therefore "Timed Out". This code is only valid on a
Transaction Inquiry.
TimedOutNoRcvrの非回復可能なタイムアウト。 メッセージを再送しましたが、応答は全く受信されませんでした。 したがって、ドキュメント交換には、「調節されたアウト」があります。 このコードは単にTransaction Inquiryで有効です。
No recovery possible.
可能な回復がありません。
7.16.5 Undefined Completion Codes
7.16.5 未定義の完了コード
The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
ProcessState属性がFailedに設定される場合にだけ、Completion Codeが必要です。 以下のテーブルは使用されるかもしれないCompletionCodeのための有効値を含んでいます。 StatusDesc属性が適切であるところに詳細な説明を提供するのに使用されるのは、お勧めです。
Value Description
値の記述
InMsgHardError Input Message Hard Error. The type of Request Block
could not be identified or was inconsistent.
Therefore no single Document Exchange could be
identified. This will cause a Hard Error in the
transaction
InMsgHardErrorはメッセージの困難な誤りを入力しました。 Request Blockのタイプは、特定できませんでしたし、矛盾もしていました。 したがって、どんな独身のDocument Exchangeも特定できませんでした。 これはトランザクションでHard Errorを引き起こすでしょう。
7.16.6 Transaction Inquiry Completion Codes
7.16.6 取引照会完了コード
The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
ProcessState属性がFailedに設定される場合にだけ、Completion Codeが必要です。 以下のテーブルは使用されるかもしれないCompletionCodeのための有効値を含んでいます。 StatusDesc属性が適切であるところに詳細な説明を提供するのに使用されるのは、お勧めです。
Value Description
値の記述
UnAuthReq Unauthorised Request. The recipient of the
Transaction Status Request declines to respond to the
request.
UnAuthReqの権限のない要求。 Transaction Status Requestの受取人は、要求に応じるのを断ります。
7.17 Trading Role Data Component
7.17 取り引き役割のデータ構成要素
The Trading Role Data Component contains opaque data which needs to be communicated between the Trading Roles involved in an IOTP Transaction.
Trading Role Data ComponentはIOTP TransactionにかかわるTrading Rolesの間でコミュニケートする必要がある不明瞭なデータを含んでいます。
Trading Role Components identify:
取り引きRole Componentsは以下を特定します。
o the Organisation that generated the component, and
o そしてコンポーネントを生成したOrganisation。
o the Organisation that is to receive it.
o それを受けることになっているOrganisation。
Burdett Informational [Page 144] RFC 2801 IOTP/1.0 April 2000
バーデット[144ページ]情報のRFC2801IOTP/2000年4月1日
They are first generated and included in a "Response" Block, and then copied to the appropriate "Request" Block. For example a Payment Handler might need to inform a Delivery Handler that a credit card payment had been authorised but not captured. There may also be other information that the Payment Handler has generated where the format is privately agreed with the Delivery Handler which needs to be communicated. In another example a Merchant might need to provide a Payment Handler with some specific information about a Consumer so that consumer can acquire double loyalty points with the payment.
それらは、「応答」Blockで最初に、生成されて、含められていて、次に、適切な「要求」Blockにコピーされます。 例えば、Payment Handlerは、クレジットカードによる支払が認可されましたが、得られていなかったことをDelivery Handlerに知らせる必要があるかもしれません。 また、Payment Handlerが書式が個人的に同意されているところでコミュニケートする必要があるDelivery Handlerを生成した他の情報があるかもしれません。 別の例では、マーチャントは、その消費者が支払いがある二倍のロイヤルティポイントを取得できるようにConsumerに関する何らかの特殊情報をPayment Handlerに提供する必要があるかもしれません。
Its definition is as follows.
定義は以下の通りです。
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData
ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIRED
DestinationElRefs NMTOKENS #REQUIRED >
<!要素TradingRoleData(PackagedContent+)><!ATTLIST TradingRoleDataの必要なOriginatorElRef NMTOKEN#必要なDestinationElRefs NMTOKENS ID ID##、は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Trading Role Data Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Trading Role Data Componentを特定するID An識別子。
OrginatorElRef Contains an element reference to the Organisation
Component of the Organisation that created the
Trading Role Data Component and included it in a
"Response" Block (e.g., an Offer Response or a
Payment Response Block).
OrginatorElRef Contains、「応答」Block(例えば、Offer ResponseかPayment Response Block)にTrading Role Data Componentを作成して、それを含んでいたOrganisationのOrganisation Componentの要素参照。
DestinationElRefs Contains element references to the Organisation
Components of the Organisations that are to
receive the Trading Role Data Component in a
"Request" Block (e.g., either a Payment Request or
a Delivery Request Block).
OrganisationsのOrganisation Componentsの「要求」Block(例えば、Payment RequestかDelivery Request Blockのどちらか)にTrading Role Data Componentを受け取ることになっているDestinationElRefs Contains要素参照。
Content:
内容:
PackagedContent This contains the data which is to be sent between
the various Trading Roles as one or more
PackagedContent elements see section 3.7.
PackagedContent Thisは1つ以上のPackagedContent要素がセクション3.7を見るとき様々なTrading Rolesの間に送られることであるデータを含んでいます。
7.17.1 Who Receives a Trading Role Data Component
7.17.1 だれが取り引き役割のデータ構成要素を受け取りますか?
The rules for deciding what to do with Trading Role Data Components are described below.
Trading Role Data Componentsと共に何をしたらよいかを決めるための規則は以下で説明されます。
Burdett Informational [Page 145] RFC 2801 IOTP/1.0 April 2000
バーデット[145ページ]情報のRFC2801IOTP/2000年4月1日
o whenever a Trading Role Data Component is received in a "Response"
block identify the Organisation Components of the Organisations
that are to receive it as identified by the DestinationElRefs
attribute.
o 「応答」ブロックにTrading Role Data Componentを受け取るときはいつも、DestinationElRefs属性によって特定されるようにそれを受けることになっているOrganisationsのOrganisation Componentsを特定してください。
o whenever a "Request" Block is being sent, check to see if it is
being sent to one of the Organisations identified by the
DestinationElRefs attribute. If it is then include in the
"Request" block:
o 「要求」Blockを送るときはいつも、チェックして、それがDestinationElRefs属性によって特定されたOrganisationsの1つに送られるかどうかを見てください。 それがあるなら、「要求」ブロックで以下を含めてください。
- the Trading Role Data Component as well as,
- Trading Role Data Component、良いです。
- the Organisation Component of the Organisation identified by
the OriginatorElRef attribute (if not already present)
- OriginatorElRef属性によって特定されたOrganisationのOrganisation Component(まして、既にプレゼント)
7.18 Inquiry Type Component
7.18 問い合せタイプ成分
The Inquiry Type Component contains the information which indicates the type of process that is being inquired upon. Its definition is as follows.
Inquiry Type Componentはそれが問い合わせられているプロセスのタイプを示す情報を含んでいます。 定義は以下の通りです。
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
Type NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
ATTLIST InquiryType ID ID#がNMTOKENの必要な#暗示している#暗示している#ElRef NMTOKEN ProcessReference CDATA>をタイプするのを必要とした<!要素のInquiryTypeの空の><!
Attributes:
属性:
ID An identifier which uniquely identifies the
Inquiry Type Component within the IOTP
Transaction.
IOTP Transactionの中で唯一Inquiry Type Componentを特定するID An識別子。
Type Contains the type of inquiry. Valid values for
Type are:
o Offer. The inquiry is about the status of an
offer and is addressed to the Merchant.
o Payment. The inquiry is about the status of a
payment and is addressed to the Payment
Handler.
o Delivery. The inquiry is about the status of a
delivery and addressed to the Delivery Handler.
問い合せのタイプのContainsをタイプしてください。 Typeのための有効値は以下の通りです。 o 提供します。 問い合せは、申し出の状態に関してあって、マーチャントに扱われます。. o Payment。 問い合せは、支払いの状態に関してあって、Payment Handlerに扱われます。. o Delivery。 問い合せは、配送の状態に関してあって、Delivery Handlerに扱われます。
ElRef Contains an Element Reference (see section 3.5) to
the component to which this Inquiry Type Component
applies. That is,
o TPO Block when Type is Offer
ElRef Contains、このInquiry Type Componentが適用するコンポーネントへのElement Reference(セクション3.5を見ます)。 Typeであるときに、すなわち、o TPO BlockはOfferです。
Burdett Informational [Page 146] RFC 2801 IOTP/1.0 April 2000
バーデット[146ページ]情報のRFC2801IOTP/2000年4月1日
o Payment Component when Type is Payment
o Delivery Component when Type is Delivery
o TypeがDeliveryであるときに、TypeがPayment o Delivery Componentであることの支払いComponent
ProcessReference Optionally contains a reference to the process
being inquired upon. It should be set if the
information is available. For the definition of
the values it may contain, see the
ProcessReference attribute of the Status Component
(see section 7.16).
ProcessReference Optionallyは問い合わせられるプロセスの参照を含んでいます。 情報が利用可能であるなら、それは設定されるべきです。 それが含むかもしれない値の定義に関しては、Status ComponentのProcessReference属性を見てください(セクション7.16を見てください)。
7.19 Signature Component
7.19 署名コンポーネント
Note: Definitions of the XML structures for signatures and certificates are described in the document titled "Digital Signatures for the Internet Open Trading Protocol" by Kent Davidson and Yoshiaki Kawatsura published at the same time as this document - see [IOTPDSIG].
以下に注意してください。 署名と証明書のためのXML構造の定義はこのドキュメントと同時に発行されたケントディヴィッドソンとYoshiaki Kawatsuraによって「インターネットの開いている取り引きプロトコルのためのデジタル署名」と題をつけられたドキュメントで説明されます--[IOTPDSIG]を見てください。
In the future it is anticipated that future versions of IOTP will adopt a whatever method for digitally signing XML becomes the standard.
IOTPの将来のバージョンが採用するそれが予期される未来、いかなるメソッド、もデジタルに署名するために、XMLは規格になります。
Each Signature Component digitally signs one or more Blocks or Components including other Signature Components.
各Signature Componentは他のSignature Componentsを含む1BlocksかComponentsにデジタルに署名します。
The Signature Component:
署名コンポーネント:
o contains digests of one or more Blocks or Components in one or
more IOTP Messages within the same IOTP Transaction and places the
result in a Digest Element
o 同じIOTP Transactionの中の1IOTP Messagesに1BlocksかComponentsのダイジェストを含んでいて、結果をDigest Elementに置きます。
o concatenates these Digest elements with other information on the
type of signature, the originator and potential recipients of the
signature and details of the signature algorithms being used and
places them in a Manifest element, and
o そして署名アルゴリズムの署名と詳細の署名のタイプ、創始者、および潜在的受取人の他の情報が使用されている状態でこれらのDigest要素を連結して、Manifest要素にそれらを置く。
o signs the Manifest element using the optional certificate
identified in the Certificate element within the Signature Block
placing the result in a Value element within a Signature Component
o Signature Componentの中にValue要素に結果を置きながらSignature Blockの中でCertificate要素で特定された任意の証明書を使用することでManifest要素に署名します。
Note that there may be multiple Value elements that contain signatures of a Manifest Element.
Manifest Elementの署名を含む複数のValue要素があるかもしれないことに注意してください。
A Signature Component can be one of four types either:
Signature Componentは4つのタイプのひとりであることができます:
o an Offer Response Signature,
o 申し出応答署名
o a Payment Response Signature,
o 支払い応答署名
Burdett Informational [Page 147] RFC 2801 IOTP/1.0 April 2000
バーデット[147ページ]情報のRFC2801IOTP/2000年4月1日
o a Delivery Response Signature, or
o または配送応答署名。
o an Authentication Response Signature.
o 認証応答署名。
For a general explanation of signatures see section 6 Digital Signatures.
署名の一般的な説明に関しては、セクション6Digital Signaturesを見てください。
7.19.1 IOTP usage of signature elements and attributes
7.19.1 署名要素と属性のIOTP用法
Definitions of the elements and attributes are contained in [IOTPDSIG]. The following contains additional information that describes how these elements and attributes are used by IOTP.
要素と属性の定義は[IOTPDSIG]に含まれています。 以下はこれらの要素と属性がIOTPによってどう使用されるかを説明する追加情報を含んでいます。
SIGNATURE ELEMENT
署名要素
The ID attribute is mandatory.
ID属性は義務的です。
MANIFEST ELEMENT
要素を表してください。
The optional LocatorHrefBase attribute contains text which should be concatenated before the text contained in the LocatorHREF attribute of all Digest elements within the Manifest.
任意のLocatorHrefBase属性はManifestの中にすべてのDigestのLocatorHREF属性に要素を含む前に連結されるべきであるテキストを含んでいます。
Its purpose is to reduce the size of LocatorHREF attribute values since the first part of the LocatorHREF attributes in the same signature are likely to be the same.
目的はLocatorHREFのサイズを減少させるために、同じ署名におけるLocatorHREF属性の最初の部分以来の属性値が同じである傾向があるということです。
Typically, within IOTP, it will contain all the characters in a
LocatorHref attribute up to the sharp ("#") character (see
immediately below).
IOTPの中では、通常、それはLocatorHref属性にすべてのキャラクタを鋭い(「#」)キャラクタまで含むでしょう(至急、以下を見てください)。
ALGORITHM AND PARAMETER ELEMENTS
アルゴリズムANDパラメタ要素
The algorithm element identifies the algorithms used in generating the signature. The type of the algorithm is defined by the value of the Type attribute which indicates if it is to be used as a Digest algorithm, a Signature algorithm or a Key Agreement algorithm.
アルゴリズム要素は署名を生成する際に使用されるアルゴリズムを特定します。 アルゴリズムのタイプはそれがDigestアルゴリズム、SignatureアルゴリズムまたはKey Agreementアルゴリズムとして使用されるつもりであるかどうかを示すType属性の値によって定義されます。
The following Digest algorithms must be implemented:
以下のDigestアルゴリズムを実装しなければなりません:
o a [DOM-HASH] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:ibm:dom-hash"
o [ドム-HASH]アルゴリズム。 これは、「つぼ: ibm: dom-ハッシュ」にAlgorithm要素のName属性を設定することによって、特定されます。
o a [SHA1] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:fips:sha1", and
o [SHA1]アルゴリズム。 そして、これがAlgorithm要素のName属性を設定することによって特定される、「つぼ:fips:sha1"、」
o a [MD5] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:rsa:md5"
o [MD5]アルゴリズム。 これは、「つぼ:rsa:md5"」にAlgorithm要素のName属性を設定することによって、特定されます。
Burdett Informational [Page 148] RFC 2801 IOTP/1.0 April 2000
バーデット[148ページ]情報のRFC2801IOTP/2000年4月1日
o The following Signature algorithms must be implemented:
o 以下のSignatureアルゴリズムを実装しなければなりません:
o a [DSA] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:us.gov:dsa"
o [DSA]アルゴリズム。 これは、「つぼ:us.gov:dsa」にAlgorithm要素のName属性を設定することによって、特定されます。
o a [HMAC] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:ibm:hmac"
o [HMAC]アルゴリズム。 これは、「つぼ:ibm:hmac」にAlgorithm要素のName属性を設定することによって、特定されます。
It is recommended that the following Signature algorithm is also implemented:
また、以下のSignatureアルゴリズムが実装されるのは、お勧めです:
o a [RSA] algorithm. This is identified by setting the Name
attribute of the Algorithm element to "urn:rsa:rsa"
o [RSA]アルゴリズム。 これは、「つぼ:rsa:rsa」にAlgorithm要素のName属性を設定することによって、特定されます。
In addition other payment scheme specific algorithms may be used. In this case the value of the name attribute to use is specified in the payment scheme supplement for that algorithm.
追加他の支払い体系では、特定のアルゴリズムは使用されるかもしれません。 この場合、使用する名前属性の値はそのアルゴリズムのための支払い体系補足で指定されます。
One algorithm may make use of other algorithms by use of the Parameter element, for example:
例えば、1つのアルゴリズムがParameter要素の使用で他のアルゴリズムを利用するかもしれません:
<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
<Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1">
</Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
<Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>
「A1<Algorithm ID=タイプは「ダイジェスト」名=の「つぼ: ibm: dom-ハッシュ「><Parameterは=をタイプする'AlgorithmRef'A2>A2</パラメタ></アルゴリズム><Algorithm ID=タイプは」 ダイジェストと等しく」名前=「A3つぼ:fips:sha1"></アルゴリズム><Algorithm ID=タイプは」 署名と等しく」名前=「つぼ:ibm:hmac「><Parameterタイプ='AlgorithmRef'>A1</パラメタ></アルゴリズム>'と等しいです」
DIGEST ELEMENT
ダイジェスト要素
The LocatorHREF attribute identifies the IOTP element which is being digitally signed. Specifically it consists of:
LocatorHREF属性はデジタルに署名されているIOTP要素を特定します。 明確にそれは以下から成ります。
o the value of the IotpTransId attribute of the Transaction ID
Component, followed by:
o 以下によるTransaction ID Componentであって、続きにされるののIotpTransId属性の値
o a sharp character, i.e. "#", followed by
o すなわち、「#」という鋭いキャラクタは続きました。
o an Element Reference (see section 3.5) to the element within the
IOTP Transaction which is the subject of the digest.
o ダイジェストの対象であるIOTP Transactionの中の要素へのElement Reference(セクション3.5を見ます)。
Before analysing the structure of the LocatorHREF attribute, it must be concatenated with the value of the LocatorHrefBase attribute of the Manifest element (see immediately above).
LocatorHREF属性の構造を分析する前に、Manifest要素のLocatorHrefBase属性の値でそれを連結しなければなりません(至急、上を見てください)。
Burdett Informational [Page 149] RFC 2801 IOTP/1.0 April 2000
バーデット[149ページ]情報のRFC2801IOTP/2000年4月1日
ATTRIBUTE ELEMENT
属性要素
There must be one and only one Attribute Element that contains a Type attribute with a value of IOTP Signature Type and with content set to either: OfferResponse, PaymentResponse, DeliveryResponse,
IOTP Signature Typeの値とどちらかに設定された内容があるType属性を含む唯一無二の1Attribute Elementがあるに違いありません: OfferResponse、PaymentResponse、DeliveryResponse
AuthenticationRequest, AuthenticationResponse, PingRequest or PingResponse; depending on the type of the signature.
AuthenticationRequest、AuthenticationResponse、PingRequestまたはPingResponse。 署名のタイプに頼っています。
Values of the content of the Attribute element are controlled under the procedures defined in section 12 IANA Considerations which also allows user defined values to be defined.
Attribute要素の内容の値はまた、ユーザの定義された値が定義されるのを許容するセクション12IANA Considerationsで定義された手順の下で制御されます。
The Critical attribute must be set to true.
Critical属性を本当に設定しなければなりません。
ORIGINATORINFO ELEMENT
ORIGINATORINFO要素
The OriginatorRef attribute of the OriginatorInfo element must always be present and contain an Element Reference (see section 3.5) to the Organisation Component of the Organisation that generated the Signature Component.
OriginatorInfo要素のOriginatorRef属性は、Signature Componentを生成したOrganisationのOrganisation Componentにいつも存在していて、Element Referenceを含まなければなりません(セクション3.5を見ます)。
RECIPIENTINFO ELEMENT
RECIPIENTINFO要素
The RecipientRefs attribute contains a list of Element References (see section 3.5), that point to the Organisations that might need to validate the signature. For details see below.
RecipientRefs属性はElement References(セクション3.5を見ます)(署名を有効にする必要があるかもしれないOrganisationsへのそのポイント)のリストを含んでいます。 詳細に関しては、以下を見てください。
7.19.2 Offer Response Signature Component
7.19.2 応答署名コンポーネントを提供してください。
The Manifest Element of a signature which has a type of OfferResponse should contain Digest elements for the following Components:
一種のOfferResponseを持っている署名のManifest Elementは以下のComponentsのためのDigest要素を含むはずです:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Offer Response Signature
o Offer Response Signatureを含むIOTPメッセージのTransaction Id Component(セクション3.3.1を見ます)
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Offer Response Signature
o Offer Response Signatureを含むIOTP MessageのTransaction Reference Block(セクション3.3を見ます)
o from the TPO Block:
o TPOから、以下を妨げてください。
- the Protocol Options Component
- プロトコルオプションコンポーネント
- each of the Organisation Components
- それぞれのOrganisation Components
- each of the Brand List Components
- それぞれのBrand List Components
Burdett Informational [Page 150] RFC 2801 IOTP/1.0 April 2000
バーデット[150ページ]情報のRFC2801IOTP/2000年4月1日
o optionally, all the Brand Selection Components if they were sent
to the Merchant in a TPO Selection Block
o 任意に、彼らであるならすべてのBrand Selection ComponentsをTPO Selection Blockのマーチャントに送りました。
o from the Offer Response Block:
o 申し出応答ブロックから:
- the Order Component
- オーダーコンポーネント
- each of the Payment Components
- それぞれのPayment Components
- the Delivery Component
- 配送コンポーネント
- each of the Authentication Request Components
- それぞれのAuthentication Request Components
- any Trading Role Data Components
- どんなTrading Role Data Components
The Offer Response Signature should also contain Digest elements for the components that describe each of the Organisations that may or will need to verify the signature. This involves:
また、Offer Response Signatureは必要があるか、または署名について確かめる必要があるそれぞれのOrganisationsについて説明するコンポーネントのためのDigest要素を含むはずです。 これは以下にかかわります。
o if the Merchant has received a TPO Selection Block containing
Brand Selection Components, then generate a Digest element for the
Payment Handler identified by the Brand Selection Component and
the Delivery Handler identified by the Delivery Component. See
section 6.3.1 Check Request Block sent Correct Organisation for a
description of how this can be done.
o マーチャントがBrand Selection Componentsを含むTPO Selection Blockを受け取ったなら、Brand Selection Componentによって特定されたPayment HandlerとDelivery Componentによって特定されたDelivery HandlerのためにDigest要素を生成してください。 Correct Organisationがどうこれができるかに関する記述のためにセクション6.3.1Check Request Blockに送られるのを見てください。
o if the Merchant is not expecting to receive a TPO Selection Block
then generate a Digest element for the Delivery Handler and all
the Payment Handlers that are involved.
o マーチャントが、TPO Selection Blockを受け取ると予想していないなら、かかわるDelivery HandlerとすべてのPayment HandlersのためにDigest要素を生成してください。
7.19.3 Payment Receipt Signature Component
7.19.3 支払い領収書署名の部品
The Manifest Element of the Payment Receipt Signature Component should contain Digest Elements for the following Components:
Payment Receipt Signature ComponentのManifest Elementは以下のComponentsのためのDigest Elementsを含むはずです:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Payment Receipt Signature
o Payment Receipt Signatureを含むIOTPメッセージのTransaction Id Component(セクション3.3.1を見ます)
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Payment Receipt Signature
o Payment Receipt Signatureを含むIOTP MessageのTransaction Reference Block(セクション3.3を見ます)
o the Offer Response Signature Component
o 申し出応答署名コンポーネント
o the Payment Receipt Component
o 支払い領収書の部品
o the Payment Note Component
o 支払い注意コンポーネント
o the Status Component
o 状態コンポーネント
Burdett Informational [Page 151] RFC 2801 IOTP/1.0 April 2000
バーデット[151ページ]情報のRFC2801IOTP/2000年4月1日
o the Brand Selection Component.
o ブランド選択コンポーネント。
o any Trading Role Data Components
o どんなTrading Role Data Components
7.19.4 Delivery Response Signature Component
7.19.4 配送応答署名コンポーネント
The Manifest Element of the Delivery Response Signature Component should contain Digest Elements for the following Components:
Delivery Response Signature ComponentのManifest Elementは以下のComponentsのためのDigest Elementsを含むはずです:
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Delivery Response Signature
o Delivery Response Signatureを含むIOTPメッセージのTransaction Id Component(セクション3.3.1を見ます)
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Delivery Response Signature
o Delivery Response Signatureを含むIOTP MessageのTransaction Reference Block(セクション3.3を見ます)
o the Consumer Delivery Data component contained in the preceding
Delivery Request (if any)
o 前のDelivery Requestに含まれたConsumer Delivery Dataの部品(もしあれば)
o the Signature Components contained in the preceding Delivery
Request (if any)
o 前のDelivery Requestに含まれたSignature Components(もしあれば)
o the Status Component
o 状態コンポーネント
o the Delivery Note Component
o 納品受領書の部品
7.19.5 Authentication Request Signature Component
7.19.5 認証要求署名コンポーネント
The Manifest Element of the Authentication Request Signature Component should contain Digest Elements for the following Components:
Authentication Request Signature ComponentのManifest Elementは以下のComponentsのためのDigest Elementsを含むはずです:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message that contains information that describes the IOTP Message
and IOTP Transaction
o IOTP MessageとIOTP Transactionについて説明する情報を含むIOTP MessageのためのTransaction Reference Block(セクション3.3を見ます)
o the Transaction Id Component (see section 3.3.1) which globally
uniquely identifies the IOTP Transaction
o 唯一IOTP Transactionをグローバルに特定するTransaction Id Component(セクション3.3.1を見ます)
o the following components of the TPO Block :
o TPO Blockの以下の部品:
- the Protocol Options Component
- プロトコルオプションコンポーネント
- the Organisation Component
- 機構コンポーネント
o the following components of the Authentication Request Block:
o Authentication Request Blockの以下の部品:
- the Authentication Request Component(s) (if present)
- 認証要求コンポーネント(存在しているなら)
Burdett Informational [Page 152] RFC 2801 IOTP/1.0 April 2000
バーデット[152ページ]情報のRFC2801IOTP/2000年4月1日
- the Trading Role Information Request Component (if present)
- 取り引き役割の情報要求コンポーネント(存在しているなら)
7.19.6 Authentication Response Signature Component
7.19.6 認証応答署名コンポーネント
The Manifest Element of the Authentication Response Signature Component should contain Digest Elements for the following Components:
Authentication Response Signature ComponentのManifest Elementは以下のComponentsのためのDigest Elementsを含むはずです:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message that contains information that describes the IOTP Message
and IOTP Transaction
o IOTP MessageとIOTP Transactionについて説明する情報を含むIOTP MessageのためのTransaction Reference Block(セクション3.3を見ます)
o the Transaction Id Component (see section 3.3.1) which globally
uniquely identifies the IOTP Transaction
o 唯一IOTP Transactionをグローバルに特定するTransaction Id Component(セクション3.3.1を見ます)
o the following components of the Authentication Request Block:
o Authentication Request Blockの以下の部品:
- the Authentication Request Component that was used in the
Authentication (if present)
- Authenticationで使用されたAuthentication Request Component(存在しているなら)
- the Trading Role Information Request Component (if present)
- 取り引き役割の情報要求コンポーネント(存在しているなら)
o the Organisation Components contained in the Authentication
Response Block
o Authentication Response Blockに含まれたOrganisation Components
7.19.7 Inquiry Request Signature Component
7.19.7 問い合せ要求署名コンポーネント
If the Inquiry Request is being signed (see section 9.2.1) the Manifest Element of the Inquiry Request Signature Component should contain Digest elements of the Inquiry Type Component, and if present, the Payment Scheme Component.
Inquiry Requestが署名されているなら(セクション9.2.1を見てください)、Inquiry Type Component、存在しているなら、Inquiry Request Signature ComponentのManifest ElementはDigest要素を含むはずです、Payment Scheme Component。
7.19.8 Inquiry Response Signature Component
7.19.8 問い合せ応答署名コンポーネント
If the Inquiry Response is being signed (see section 9.2.1) the Manifest Element of the Inquiry Response Signature Component should contain Digest elements of the Trading Response Block and the Status Component.
Inquiry Responseが署名されているなら(セクション9.2.1を見てください)、Inquiry Response Signature ComponentのManifest ElementはTrading Response BlockとStatus ComponentのDigest要素を含むはずです。
7.19.9 Ping Request Signature Component
7.19.9 ピング要求署名コンポーネント
If the Ping Request is being singed (see section 9.2.2), the Manifest Element of the Ping Request Signature Component should contain Digest elements for all the Organisation Components.
Ping Requestが表面を焼かれているなら(セクション9.2.2を見てください)、Ping Request Signature ComponentのManifest ElementはすべてのOrganisation ComponentsのためのDigest要素を含むはずです。
Burdett Informational [Page 153] RFC 2801 IOTP/1.0 April 2000
バーデット[153ページ]情報のRFC2801IOTP/2000年4月1日
7.19.10 Ping Response Signature Component
7.19.10 ピング応答署名コンポーネント
If the Ping Response is being singed (see section 9.2.2), the Manifest Element of the Ping Response Signature Component should contain Digest elements fir all the Organisation Components.
Ping Responseであるなら、表面を焼かれます(セクション9.2.2を見ます)、Ping Response Signature ComponentのManifest ElementがDigest要素モミを含むはずであるということであることはすべて、Organisation Componentsですか?
7.20 Certificate Component
7.20 証明書の部品
Note: Definitions of the XML structures for signatures and certificates are described in the paper "Digital Signatures for the Internet Open Trading Protocol", see [IOTPDSIG].
以下に注意してください。 署名と証明書のためのXML構造の定義は紙「インターネットの開いている取り引きプロトコルのためのデジタル署名」で説明されます、と[IOTPDSIG]は見ます。
See note at the start of section 7.19 Signature Component for more details.
セクション7.19Signature Componentの始めでその他の詳細に関して注意を見てください。
A Certificate Component contains a Digital Certificate. They are used only when required, for example, when asymmetric cryptography is being used and the recipient of the signature that needs to check has not already received the Public Key.
Certificate ComponentはDigital Certificateを含んでいます。 非対称の暗号が使用されているとき、例えば、必要である場合にだけ、それらは使用されています、そして、チェックする必要がある署名の受取人は既にPublic Keyを受け取っていません。
The structure of a Certificate Component is defined in [IOTPDSIG].
Certificate Componentの構造は[IOTPDSIG]で定義されます。
7.20.1 IOTP usage of signature elements and attributes
7.20.1 署名要素と属性のIOTP用法
Detailed definitions of the above elements and attributes are contained in [IOTPDSIG]. The following contains additional information that describes how these elements and attributes are used by IOTP.
上の要素と属性の詳細な定義は[IOTPDSIG]に含まれています。 以下はこれらの要素と属性がIOTPによってどう使用されるかを説明する追加情報を含んでいます。
CERTIFICATE COMPONENT
証明書の部品
The ID attribute is mandatory.
ID属性は義務的です。
VALUE ELEMENT
価値要素
The ID attribute is mandatory.
ID属性は義務的です。
7.21 Error Component
7.21 誤りコンポーネント
The Error Component contains information about Technical Errors (see section 4.1) in an IOTP Message which has been received by one of the Trading Roles involved in the trade.
Error Componentは取り引きにかかわるTrading Rolesのひとりによって受け取られたIOTP MessageにTechnical Errors(セクション4.1を見る)の情報を含んでいます。
For clarity two phrases are defined which are used in the description of an Error Component:
明快において、2つの句が定義されます(Error Componentの記述に使用されます):
o message in error. An IOTP message which contains or causes an
error of some kind
o 間違いメッセージ。 ある種の誤りを含んでいるか、または引き起こすIOTPメッセージ
Burdett Informational [Page 154] RFC 2801 IOTP/1.0 April 2000
バーデット[154ページ]情報のRFC2801IOTP/2000年4月1日
o message reporting the error. An IOTP message that contains an
Error Component that describes the error found in a message in
error.
o 誤りを報告するメッセージ。 メッセージで見つけられた誤りについて間違って説明するError Componentを含むIOTPメッセージ。
The definition of the Error Component is as follows.
Error Componentの定義は以下の通りです。
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
<!ELEMENT ErrorComp(ErrorLocation+、PackagedContent*)><!ATTLIST ErrorComp ID NMTOKEN#REQUIRED xml: lang NMTOKEN#REQUIRED ErrorCode NMTOKEN#REQUIRED ErrorDesc CDATA#REQUIRED Severity(警告|TransientError|HardError)#REQUIRED MinRetrySecs CDATA#IMPLIED SwVendorErrorRef CDATA#IMPLIED>。
Attributes:
属性:
ID An identifier which uniquely identifies the Error
Component within the IOTP Transaction.
IOTP Transactionの中で唯一Error Componentを特定するID An識別子。
xml:lang Defines the language used by attributes or child
elements within this component, unless overridden
by an xml:lang attribute on a child element. See
section 3.8 Identifying Languages.
xml: xmlによってくつがえされない場合属性か子供要素に従って言語がこのコンポーネントの中で使用したlang Defines: 子供要素のlang属性。 セクション3.8Identifying Languagesを見てください。
ErrorCode Contains an error code which indicates the nature
of the error in the message in error. Valid values
for the ErrorCode are given in section 7.21.2
Error Codes.
メッセージにおける誤りの本質を間違って示す誤りがコード化するErrorCode Contains。 セクション7.21.2Error CodesでErrorCodeのための有効値を与えます。
ErrorDesc Contains a narrative description of the error in
the language defined by xml:lang. The content of
this attribute is defined by the vendor/developer
of the software which generated the Error
Component
言語における、誤りの物語の記述がxmlで定義したErrorDesc Contains: lang。 この属性の内容はError Componentを生成したソフトウェアのベンダー/開発者によって定義されます。
Severity Indicates the severity of the error. Valid values
are:
o Warning. This indicates that although there is
a message in error the IOTP Transaction can
still continue.
o TransientError. This indicates that the error
in the message in error may be recovered if the
message in error that is referred to by the
ErrorLocation element is resent
厳しさIndicates、誤りの厳しさ。 有効値は以下の通りです。 o 警告。 これは、メッセージが間違ってありますが、IOTP Transactionがまだ. o TransientErrorを続けることができるのを示します。 これは、間違いErrorLocation要素によって示されるメッセージを再送するなら間違いメッセージにおける誤りを回復するかもしれないのを示します。
Burdett Informational [Page 155] RFC 2801 IOTP/1.0 April 2000
バーデット[155ページ]情報のRFC2801IOTP/2000年4月1日
o HardError. This indicates that there is an
unrecoverable error in the message in error and
the IOTP Transaction must stop.
o HardError。 これは、回復不能エラーが間違いメッセージとIOTP Transaction欠かせない立ち寄り先にあるのを示します。
MinRetrySecs This attribute should be present if Severity is
set to TransientError. It is the minimum number of
whole seconds which the IOTP aware application
which received the message reporting the error
should wait before re-sending the message in error
identified by the ErrorLocation element.
SeverityがTransientErrorに用意ができているなら、MinRetrySecs This属性は存在しているべきです。 それはErrorLocation要素に従ってメッセージを間違って再送する前に誤りを報告するメッセージを受け取ったアプリケーションが待つべきであるのを意識しているIOTPが特定した全体の秒の最小の数です。
If Severity is not set to TransientError then the
value of this attribute is ignored.
SeverityがTransientErrorに用意ができていないなら、この属性の値は無視されます。
SwVendorErrorRef This attribute is a reference whose value is set
by the vendor/developer of the software which
generated the Error Component. It should contain
data which enables the vendor to identify the
precise location in their software and the set of
circumstances which caused the software to
generate a message reporting the error. See also
the SoftwareId attribute of the Message Id element
in the Transaction Reference Block (section 3.3).
SwVendorErrorRef This属性は値がError Componentを生成したソフトウェアのベンダー/開発者によって設定される参照です。 それはベンダーがソフトウェアに誤りを報告するメッセージを生成させたそれらのソフトウェアと事情のセットで正確な位置を特定するのを可能にするデータを含むべきです。 また、Transaction Reference Block(セクション3.3)のMessage Id要素のSoftwareId属性を見てください。
Content:
内容:
ErrorLocation This identifies the IOTP Transaction Id of the
message in error and, where possible, the element
and attribute in the message in error that caused
the Error Component to be generated.
ErrorLocation Thisは間違いメッセージの可能であるところのError Componentを生成した間違いメッセージのIOTP Transaction Id、要素、および属性を特定します。
If the Severity of the error is not
TransientError, more than one ErrorLocation may be
specified as appropriate depending on the nature
of the error (see section 7.21.2 Error Codes) and
at the discretion of the vendor/developer of the
IOTP Aware Application.
誤りのSeverityがTransientErrorでないなら、1ErrorLocationが、誤り(セクション7.21.2Error Codesを見る)の本質とIOTP Aware Applicationのベンダー/開発者の裁量において適宜よりながら、指定されるかもしれません。
PackagedContent This contains additional data which can be used to
understand the error. Its content may vary as
appropriate depending on the nature of the error
(see section 7.21.2 Error Codes) and at the
discretion of the vendor/developer of the IOTP
Aware Application. For a definition of
PackagedContent see section 3.7.
PackagedContent Thisは誤りを理解するのに使用できる追加データを含んでいます。 内容は、誤り(セクション7.21.2Error Codesを見る)の本質とIOTP Aware Applicationのベンダー/開発者の裁量において適宜よりながら、異なるかもしれません。 PackagedContentの定義に関しては、セクション3.7を見てください。
Burdett Informational [Page 156] RFC 2801 IOTP/1.0 April 2000
バーデット[156ページ]情報のRFC2801IOTP/2000年4月1日
7.21.1 Error Processing Guidelines
7.21.1 エラー処理ガイドライン
If there is more than one Error Component in a message reporting the error, carry out the actions appropriate for the Error Component with the highest severity. In this context, HardError has a higher severity than TransientError, which has a higher severity than Warning.
誤りを報告するメッセージに1Error Componentがあれば、Error Componentに、最も高い厳しさで適切な動きを行ってください。 このような関係においては、HardErrorには、Warningより高い厳しさを持っているTransientErrorより高い厳しさがあります。
7.21.1.1 Severity - Warning
7.21.1.1 厳しさ--警告
If an IOTP aware application is generating a message reporting the error with an Error Component where the Severity attribute is set to Warning, then if the message reporting the error does not contain another Error Component with a severity higher than Warning, the IOTP Message must also include the Trading Blocks and Trading Components that would have been included if no error was being reported.
また、IOTPの意識しているアプリケーションがSeverity属性がWarningに設定されるError Componentと共に誤りを報告するメッセージを生成していて、厳しさがWarningより高い状態で誤りを報告するメッセージが別のError Componentを含んでいないなら、IOTP Messageは誤りが全く報告されていなかったなら含まれているTrading BlocksとTrading Componentsを含まなければなりません。
If a message reporting the error is received with an Error Component where Severity is set to Warning, then:
次にSeverityがWarningに用意ができているError Componentと共に誤りを報告するメッセージを受け取るなら:
o it is recommended that information about the error is either
logged, or otherwise reported to the user,
o 誤りの情報が登録されるか、または別の方法でユーザに報告されるのが、お勧めです。
o the implementer of the IOTP aware application must either, at
their or the user's discretion:
o IOTPの意識しているアプリケーションのimplementerはそれらかユーザの裁量でそうしなければなりません:
- continue the IOTP transaction as normal, or
- または正常なIOTP同じくらいトランザクションを続けてください。
- fail the IOTP transaction by generating a message reporting the
error with an Error Component with Severity set to HardError
(see section 7.21.1.3).
- セクション7.21を見てください。SeverityとError Componentとの誤りがHardErrorにセットしたと報告するメッセージを生成することによってIOTPトランザクションに失敗してください、(.1 .3)。
If the intention is to continue the IOTP transaction then, if there are no other Error Components with a higher severity, check that the necessary Trading Blocks and Trading Components for normal processing of the transaction to continue are present. If they are not then generate a message reporting the error with an Error Component with Severity set to HardError.
意志がIOTPトランザクションを続けることであり、他のError Componentsが全くより高い厳しさと共になければ、続けているトランザクションの正常処理のための必要なTrading BlocksとTrading Componentsが存在しているのをチェックしてください。 彼らがいないなら、SeverityとError Componentとの誤りがHardErrorにセットしたと報告するメッセージを生成してください。
7.21.1.2 Severity - Transient Error
7.21.1.2 厳しさ--一時的エラー
If an IOTP Aware Application is generating a message reporting the error with an Error Component where the Severity attribute is set to TransientError, then there should be only one Error Component in the message reporting the error. In addition, the MinRetrySecs attribute should be present.
IOTP Aware ApplicationがSeverity属性がTransientErrorに設定されるError Componentと共に誤りを報告するメッセージを生成しているなら、誤りを報告するメッセージには1Error Componentしかあるはずがありません。 さらに、MinRetrySecs属性は存在しているべきです。
Burdett Informational [Page 157] RFC 2801 IOTP/1.0 April 2000
バーデット[157ページ]情報のRFC2801IOTP/2000年4月1日
If a message reporting the error is received with an Error Component where Severity is set to TransientError then:
Severityがその時TransientErrorに用意ができているError Componentと共に誤りを報告するメッセージを受け取るなら:
o if the MinRetrySecs attribute is present and a valid number, then
use the MinRetrySecs value given. Otherwise if MinRetrySecs is
missing or is invalid, then:
o MinRetrySecs属性がプレゼントと有効な数であるなら、与えられたMinRetrySecs値を使用してください。 そうでなさ、MinRetrySecsがなくなるか、または次に、無効であるなら:
- generate a message reporting the error containing an Error
Component with a Severity of Warning and send it on the next
IOTP message (if any) to be sent to the Trading Role which sent
the message reporting the error with the invalid MinRetrySecs,
and
- そしてWarningのSeverityと共にError Componentを含む誤りを報告するメッセージを生成してくださいといって、次のメッセージに無効のMinRetrySecsとの誤りを報告させたTrading Roleに送られるべきIOTPメッセージ(もしあれば)にそれを送ってください。
- use a value for MinRetrySecs which is set by the
vendor/developer of the IOTP Aware Application.
- IOTP Aware Applicationのベンダー/開発者が用意ができさせるMinRetrySecsに値を使用してください。
o check that only one ErrorLocation element is contained within the
Error Component and that it refers to an IOTP Message which was
sent by the recipient of the Error Component with a Severity of
TransientError. If more than one ErrorLocation is present then
generate a message reporting the error with a Severity of
HardError.
o 1つのErrorLocation要素だけがError Componentの中に含まれていて、TransientErrorのSeverityと共にError Componentの受取人によって送られたIOTP Messageについて言及するのをチェックしてください。 1ErrorLocationが存在しているなら、HardErrorのSeverityとの誤りを報告するメッセージを生成してください。
7.21.1.3 Severity - Hard Error
7.21.1.3 厳しさ--困難な誤り
If an IOTP Aware Application is generating a message reporting the error with an Error Component where the Severity attribute set to HardError, then there should be only one Error Component in the message reporting the error.
IOTP Aware ApplicationがSeverity属性がHardErrorにセットしたError Componentと共に誤りを報告するメッセージを生成しているなら、誤りを報告するメッセージには1Error Componentしかあるはずがありません。
If a message reporting the error is received with an Error Component where Severity is set to HardError then terminate the IOTP Transaction.
SeverityがHardErrorに用意ができているError Componentと共に誤りを報告するメッセージを受け取るなら、IOTP Transactionを終えてください。
7.21.2 Error Codes
7.21.2 エラーコード
The following table contains the valid values for the ErrorCode attribute of the Error Component. The first sentence of the description contains the text that should be used to describe the error when displayed or otherwise reported. Individual implementations may translate this into alternative languages at their discretion.
以下のテーブルはError ComponentのErrorCode属性のための有効値を含んでいます。 記述の最初の文は表示するか、または別の方法で報告すると誤りについて説明するのに使用するべきであるテキストを含んでいます。 個々の実装は自己判断で代替の言語にこれを翻訳するかもしれません。
An Error Code must not be more that 14 characters long.
Error Codeは14のキャラクタが切望する以上であるはずがありません。
Burdett Informational [Page 158] RFC 2801 IOTP/1.0 April 2000
バーデット[158ページ]情報のRFC2801IOTP/2000年4月1日
Value Description
値の記述
Reserved Reserved. This error is reserved by the
vendor/developer of the software. Contact the
vendor/developer of the software for more information
See the SoftwareId attribute of the Message Id
element in the Transaction Reference Block(section
3.3).
予約されていた状態で、予約されます。 この誤りはソフトウェアのベンダー/開発者によって控えられます。 See SoftwareIdが結果と考えるTransaction Reference Block(セクション3.3)のMessage Id要素に関する詳しい情報のためのソフトウェアのベンダー/開発者に連絡してください。
XmlNotWellFrmd XML not well formed. The XML document is not well
formed. See [XML] for the meaning of "well formed".
Even if the XML is not well formed, it should still
be scanned to find the Transaction Reference Block so
that a properly formed Error Response may be
generated.
XmlNotWellFrmd XML、整形式ではありません。 XMLドキュメントは整形式ではありません。 「整形式」の意味に関して[XML]を見てください。 XMLが整形式でなくても、Transaction Reference Blockを見つけるのは、適切に形成されたError Responseを生成することができるようにまだスキャンされているべきです。
XmlNotValid XML not valid. The XML document is well formed but
the document is not valid. See [XML] for the meaning
of "valid". Specifically:
o the XML document does not comply with the
constraints defined in the IOTP document type
declaration (DTD) (see section 13 Internet Open
Trading Protocol Data Type Definition), and
o the XML document does not comply with the
constraints defined in the document type
declaration of any additional [XML Namespace] that
are declared.
XmlNotValid XML、有効ではありません。 XMLドキュメントは整形式ですが、ドキュメントは有効ではありません。 「有効」の意味に関して[XML]を見てください。 明確に: o ○ XMLドキュメントはIOTPドキュメント型の宣言(DTD)で定義される規制に応じません、そして、(セクション13インターネットオープンTradingプロトコルData Type Definitionを見てください)XMLドキュメントは宣言されるどんな追加[XML Namespace]のドキュメント型の宣言でも定義される規制に応じません。
As for XML not well formed, attempts should still be
made to extract the Transaction Reference Block so
that a properly formed Error Response may be
generated.
XMLのように、整形式ではありません、適切に形成されたError Responseは生成することができるようにTransaction Reference Blockを抽出するのをまだ試みをしているべきです。
ElUnexpected Unexpected element. Although the XML document is well
formed and valid, an element is present that is not
expected in the particular context according to the
rules and constraints contained in this
specification.
ElUnexpected Unexpected要素。 XMLドキュメントは、整形式であって有効ですが、要素は、規則に従って特定の文脈で予想されないプレゼントとこの仕様に含まれた規制です。
ElNotSupp Element not supported. Although the document is well
formed and valid, an element is present that:
o is consistent with the rules and constraints
contained in this specification, but
o is not supported by the IOTP Aware Application
which is processing the IOTP Message.
サポートされなかったElNotSupp Element。 ドキュメントは、整形式であって有効ですが、要素はそれを提示することです: o この仕様に含まれている規則と規制と一致しています、oだけがIOTP Messageを処理しているIOTP Aware Applicationによってサポートされません。
Burdett Informational [Page 159] RFC 2801 IOTP/1.0 April 2000
バーデット[159ページ]情報のRFC2801IOTP/2000年4月1日
ElMissing Element missing. Although the document is well formed
and valid, an element is missing that should have
been present if the rules and constraints contained
in this specification are followed.
ElMissing Elementの取り逃がすこと。 ドキュメントは、整形式であって有効ですが、要素はこの仕様に含まれた規則と規制が従われているなら存在するべきであった取り逃がすことです。
In this case set the PackagedContent of the Error
Component to the type of the missing element.
この場合、なくなった要素のタイプにError ComponentのPackagedContentを設定してください。
ElContIllegal Element content illegal. Although the document is
well formed and valid, the element Content contains
values which do not conform to the rules and
constraints contained in this specification.
ElContIllegal Elementの満足している不法入国者。 ドキュメントは、整形式であって有効ですが、要素Contentは規則に従わない値とこの仕様に含まれた規制を含んでいます。
EncapProtErr Encapsulated protocol error. Although the document is
well formed and valid, the PackagedContent of an
element contains data from an encapsulated protocol
which contains errors.
EncapProtErr Encapsulatedは誤りについて議定書の中で述べます。 ドキュメントは、整形式であって有効ですが、要素のPackagedContentは誤りを含むカプセル化されたプロトコルからのデータを含んでいます。
AttUnexpected Unexpected attribute. Although the XML document is
well formed and valid, the presence of the attribute
is not expected in the particular context according
to the rules and constraints contained in this
specification.
AttUnexpected Unexpected属性。 XMLドキュメントは、整形式であって有効ですが、この仕様に含まれた規則と規制に従って、属性の存在は特定の文脈で予想されません。
AttNotSupp Attribute not supported. Although the XML document is
well formed and valid, and the presence of the
attribute in an element is consistent with the rules
and constraints contained in this specification, it
is not supported by the IOTP Aware Application which
is processing the IOTP Message.
サポートされなかったAttNotSupp Attribute。 XMLドキュメントは、整形式であって有効です、そして、要素での属性の存在はこの仕様に含まれている規則と規制と一致していますが、それはIOTP Messageを処理しているIOTP Aware Applicationによってサポートされません。
AttMissing Attribute missing. Although the document is well
formed and valid, an attribute is missing that should
have been present if the rules and constraints
contained in this specification are followed.
AttMissing Attributeの取り逃がすこと。 ドキュメントは、整形式であって有効ですが、属性はこの仕様に含まれた規則と規制が従われているなら存在するべきであった取り逃がすことです。
In this case set the PackagedContent of the Error
Component to the type of the missing attribute.
この場合、なくなった属性のタイプにError ComponentのPackagedContentを設定してください。
AttValIllegal Attribute value illegal. The attribute contains a
value which does not conform to the rules and
constraints contained in this specification.
AttValIllegal Attributeは不法入国者を評価します。 属性は規則に従わない値とこの仕様に含まれた規制を含んでいます。
AttValNotRecog Attribute Value Not Recognised. The attribute
contains a value which the IOTP Aware Application
generating the message reporting the error could not
recognise.
AttValNotRecogは認識されなかった値を結果と考えます。 属性はメッセージ報告が誤りであると生成するIOTP Aware Applicationが含むことができた値を含んでいます。認識しません。
Burdett Informational [Page 160] RFC 2801 IOTP/1.0 April 2000
バーデット[160ページ]情報のRFC2801IOTP/2000年4月1日
MsgTooLarge Message too large. The message is too large to be
processed by the IOTP Aware Application.
MsgTooLarge Message、大き過ぎます。 メッセージはIOTP Aware Applicationが処理できないくらい大きいです。
ElTooLarge Element too large. The element is too large to be
processed by the IOTP Aware Application
ElTooLarge Element、大き過ぎます。 要素はIOTP Aware Applicationが処理できないくらい大きいです。
ValueTooSmall Value too small or early. The value of all or part of
the Content of an element or an attribute, although
valid, is too small.
ValueTooSmall Value、小さ過ぎるか、または早いです。 有効ですが、すべての値か要素のContentの一部か属性が小さ過ぎます。
ValueTooLarge Value too large or in the future. The value of all or
part of the Content of an element or an attribute,
although valid, is too large.
または、ValueTooLarge Value、大き過ぎる、将来。 有効ですが、すべての値か要素のContentの一部か属性がかなり過ぎます。
ElInconsistent Element Inconsistent. Although the document is well
formed and valid, according to the rules and
constraints contained in this specification:
o the content of an element is inconsistent with the
content of other elements or their attributes, or
o the value of an attribute is inconsistent with the
value of one or more other attributes.
ElInconsistent要素矛盾しています。 この仕様に含まれた規則と規制に従って、ドキュメントは、整形式であって有効ですが: o ○ 要素の内容は他の要素かそれらの属性の内容に反しているか、または属性の値が他の1つ以上の属性の値に反しています。
In this case create ErrorLocation elements which
identify all the attributes or elements which are
inconsistent.
この場合、すべての属性を特定するErrorLocation要素か首尾一貫しない要素を作成してください。
TransportError Transport Error. This error code is used to indicate
that there is a problem with the Transport Mechanism
which is preventing the message from being received.
It is typically associated with a Transient Error.
Explanation of the Transport Error is contained
within the ErrorDesc attribute. The values which can
be used inside ErrorDesc with a TransportError is
specified in the IOTP supplement for the Transport
mechanism.
TransportErrorは誤りを輸送します。 このエラーコードは、メッセージが受け取られるのを防いでいるTransport Mechanismに関する問題があるのを示すのに使用されます。 それはTransient Errorに通常関連しています。 Transport Errorに関する説明はErrorDesc属性の中に含まれています。 TransportErrorと中古の内部のErrorDescがTransportメカニズムのためのIOTP補足で指定されるということであるかもしれない値。
MsgBeingProc Message Being Processed. This error code is only used
with a Severity of Transient Error. It indicates that
the previous message, which may be an exchange
message or a request message, is being processed and,
if no response is received by the time indicated by
the MinRetrySecs attribute, then the original message
should be resent.
処理されるMsgBeingProcメッセージ。 このエラーコードはTransient ErrorのSeverityと共に使用されるだけです。 それは、前のメッセージ(交換メッセージか要求メッセージであるかもしれない)が処理されていて、どんな応答もMinRetrySecs属性によって示される時までに受け取られていないならオリジナルのメッセージが再送されるべきであるのを示します。
SystemBusy System Busy. This error code is only used with a
Severity of Transient Error. It indicates that the
server that received a message is currently too busy
to handle the message. If no response is received by
SystemBusyシステム忙しいです。 このエラーコードはTransient ErrorのSeverityと共に使用されるだけです。 それは、メッセージを受け取ったサーバが現在メッセージを扱うことができないくらい忙しいのを示します。 どんな応答でも受け取らないなら
Burdett Informational [Page 161] RFC 2801 IOTP/1.0 April 2000
バーデット[161ページ]情報のRFC2801IOTP/2000年4月1日
the time indicated by the MinRetrySecs attribute,
then the original message should be resent.
時間がMinRetrySecs属性によって示されて、そして、オリジナルのメッセージを再送するべきです。
Note: If the server/system handling the Transport Mechanism (e.g., HTTP) is busy then a Transport Specific error message should be used instead of an IOTP Error message. This code should be used in association with IOTP servers/systems or other servers/systems to which the IOTP server is connected.
以下に注意してください。 Transport Mechanism(例えば、HTTP)を扱うサーバ/システムが忙しいなら、Transport SpecificエラーメッセージはIOTP Errorメッセージの代わりに使用されるべきです。 このコードはIOTPサーバが関連しているIOTPサーバ/システムか他のサーバ/システムと関連して使用されるべきです。
UnknownError Unknown Error. Indicates that the transaction cannot
complete for some reason that is not covered
explicitly by any of the other errors. The ErrorDesc
attribute should be used to indicate the nature of
the problem.
UnknownErrorの未知の誤り。 トランザクションがいくつかのために他の誤りのいずれでも明らかにカバーされていない理由を完成できないのを示します。 ErrorDesc属性は、問題の性格を示すのに使用されるべきです。
This could be used to indicate, for example, an
internal error in a backend server or client process
of some kind.
ある種のバックエンドサーバかクライアントプロセスで例えば内部エラーを示すのにこれを使用できました。
7.21.3 Error Location Element
7.21.3 誤り位置の要素
An Error Location Element identifies an element and optionally an attribute in the message in error which is associated with the error. It contains a reference to the IOTP Message, Trading Block, Trading Component, element and attribute, which is in error.
Error Location Elementは任意に要素を特定します。間違い誤りに関連しているメッセージの属性。 それはIOTP Message、Trading Block、Trading Component、要素、および属性の参照を含んでいます。(それは、間違っています)。
<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED >
空の<!の<!ATTLIST ErrorLocation ElementType NMTOKEN#必要なIotpMsgRef NMTOKEN要素ErrorLocation>#、は、BlkRef NMTOKEN#が、CompRef NMTOKEN#が、ElementRef NMTOKEN#が、AttName NMTOKEN#が>を含意するのを含意するのを含意するのを含意したのを含意しました。
Attributes:
属性:
ElementType This is the name of the type of the element where
the error is located. For example if the element
was declared as <!ELEMENT Org ... then its name is
"Org".
ElementType Thisは誤りが位置している要素のタイプの名前です。 例えば、要素が<!ELEMENT Orgとして…申告されたなら、名前は"Org"です。
IotpMsgRef This is the value of the ID attribute of the of
the Message Id Component (see section 3.3.2) of
the message in error to which this Error Component
applies.
IotpMsgRef ThisがID属性の値である、間違いこのError Componentが適用するメッセージのMessage Id Component(セクション3.3.2を見る)について。
Burdett Informational [Page 162] RFC 2801 IOTP/1.0 April 2000
バーデット[162ページ]情報のRFC2801IOTP/2000年4月1日
BlkRef If the error is associated with a specific Trading
Block, then this is the value of the ID attribute
of the Trading Block where the error is located.
BlkRef If、誤りが特定のTrading Blockに関連している、そして、これは誤りが位置しているTrading BlockのID属性の値です。
CompRef If the error is associated with a specific Trading
Component, then this is the value of the ID
attribute of the Trading Component where the error
is located.
CompRef If、誤りが特定のTrading Componentに関連している、そして、これは誤りが位置しているTrading ComponentのID属性の値です。
ElementRef If the error is associated with a specific element
within a Trading Component then, if the element
has an attribute with an "attribute type" (see
[XML]) of "ID", then this is the value of that
attribute.
ElementRef If、誤りがその時Trading Componentの中の特定の要素に関連している、要素に「ID」の「属性タイプ」([XML]を見る)がある属性があるなら、これはその属性の値です。
AttName If the error is associated with the value of an
attribute, then this is the name of that
attribute. In this case the PackagedContent of the
Error Component should contain the value of the
attribute.
AttName If、誤りが属性の値に関連している、そして、これはその属性の名前です。 この場合、Error ComponentのPackagedContentは属性の値を含むはずです。
Note that as many as the attributes as possible should be included. For example if an attribute in a child element of a Trading Component contains an incorrect value, then all the attributes of ErrorLocation should be present.
可能であるとしての属性と同じくらい多くが含まれるべきであることに注意してください。 例えば、Trading Componentの子供要素の属性が不正確な値を含んでいるなら、ErrorLocationのすべての属性が存在しているべきです。
8. Trading Blocks
8. 通商圏
Trading Blocks are child elements of the top level IOTP Messages that are sent in the form of [XML] documents directly between the different Trading Roles that are taking part in a trade.
取り引きBlocksは取り引きに参加している異なったTrading Rolesの直接間の[XML]ドキュメントの形で送られる最高平らなIOTP Messagesの子供要素です。
Each Trading Blocks consist of one or more Trading Components (see section 7). This is illustrated in the diagram below.
各Trading Blocksは1Trading Componentsから成ります(セクション7を見てください)。 これは以下のダイヤグラムで例証されます。
Burdett Informational [Page 163] RFC 2801 IOTP/1.0 April 2000
バーデット[163ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE <-----------IOTP Message - an XML Document
| which is transported between the
| Trading Roles
|-Trans Ref Block <----- Trans Ref Block - contains
| | information which describes the
| | IOTP Transaction and the IOTP
| | Message.
| |-Trans Id Comp. <--- Transaction Id Component -
| | uniquely identifies the IOTP
| | Transaction. The Trans Id
| | Components are the same across
| | all IOTP messages that comprise a
| | single IOTP transaction.
| |-Msg Id Comp. <----- Message Id Component - identifies
| and describes an IOTP Message
| within an IOTP Transaction
|-Signature Block <----- Signature Block (optional) -
| | contains one or more Signature
| | Components and their associated
| | Certificates
| |-Signature Comp. <-- Signature Component - contains
| | digital signatures. Signatures
| | may sign digests of the Trans Ref
| | Block and any Trading Component
| | in any IOTP Message in the same
| | IOTP Transaction.
| |-Certificate Comp. <-Certificate Component. Used to
| check the signature. (Optional)
------> |-Trading Block <--------Trading Block - an XML Element
| | |-Trading Comp. within an IOTP Message that
Trading | |-Trading Comp. contains a predefined set of
Blocks | |-Trading Comp. Trading Components
| | |-Trading Comp.
| | |-Trading Comp. <-----Trading Components - XML Elements
| | within a Trading Block that
------> |-Trading Block contain a predefined set of XML
| |-Trading Comp. elements and attributes
| |-Trading Comp. containing information required
| |-Trading Comp. to support a Trading Exchange
| |-Trading Comp.
| |-Trading Comp.
|
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
IOTPメッセージ<。-----------IOTPメッセージ--XMLドキュメント| どれが間に輸送されるか。| 取り引き役割|-移-審判ブロック<。----- 移-Ref Block--、含有| | 情報、どれ、説明| | IOTPトランザクションとIOTP| | メッセージ。 | |-移-イドコンピュータ。 <-- トランザクションイドコンポーネント、-| | 唯一、IOTPを特定します。| | トランザクション。 移-イド| | コンポーネントは横切って同じです。| | aを包括するすべてのIOTPメッセージ| | ただ一つのIOTPトランザクション。 | |-エムエスジーイドコンピュータ。 <、-、-、-、-- メッセージId Component--、特定| IOTP Messageについて説明します。| IOTPトランザクションの中で|-署名欄<。----- 署名欄(任意の)、-| | 1Signatureを含んでいます。| | そして、コンポーネント、それら、関連| | 証明書| |-署名コンピュータ。 <-- 署名Component--、含有| | デジタル署名。 署名| | Trans Refのダイジェストに署名するかもしれません。| | ブロックとどんなTrading Component| | 同じくらいのどんなIOTP Messageでも| | IOTPトランザクション。 | |-コンピュータを証明してください。 <。コンポーネントを証明してください。 以前はよく| 署名をチェックしてください。 (任意)です。 ------>、|、-、通商圏、<。--------通商圏--XML要素| | |-取り引きComp IOTP Messageの中でそのTrading| |-取り引きComp、Blocksの事前に定義されたセットを含んでいます。| |-コンピュータを取り引きします。 取り引きコンポーネント| | |-コンピュータを取り引きします。 | | |-コンピュータを取り引きします。 <、-、-、-、--取り引きコンポーネント--XML Elements| | Trading Block、それ------>、|、-、取り引き、BlockはXMLの事前に定義されたセットを含んでいます。| |-取り引きComp要素と属性| |-取り引きComp情報を含むのが必要です。| |-取り引きComp Trading Exchangeをサポートするために| |-コンピュータを取り引きします。 | |-コンピュータを取り引きします。 | *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 16 Trading Blocks
図16 通商圏
Burdett Informational [Page 164] RFC 2801 IOTP/1.0 April 2000
バーデット[164ページ]情報のRFC2801IOTP/2000年4月1日
Trading Blocks are defined as part of the definition of an IOTP Message (see section 3.1.1). The definition of an IOTP Message element is repeated here:
取り引きBlocksはIOTP Messageの定義の一部と定義されます(セクション3.1.1を見てください)。 IOTP Message要素の定義はここで繰り返されます:
<!ELEMENT IotpMessage
( TransRefBlk,
SigBlk?,
ErrorBlk?,
( AuthReqBlk |
AuthRespBlk |
AuthStatusBlk |
CancelBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk
)*
) >
<!要素IotpMessage(TransRefBlk、SigBlk?、ErrorBlk(AuthReqBlk|AuthRespBlk|AuthStatusBlk|CancelBlk|DeliveryReqBlk|DeliveryRespBlk|InquiryReqBlk|InquiryRespBlk|OfferRespBlk|PayExchBlk|PayReqBlk|PayRespBlk|PingReqBlk|PingRespBlk|TpoBlk| TpoSelectionBlk) *)? >。
The remainder of this section defines the Trading Blocks in this version of IOTP. They are:
このセクションの残りはIOTPのこのバージョンでTrading Blocksを定義します。 それらは以下の通りです。
o Authentication Request Block
o 認証要求ブロック
o Authentication Response Block
o 認証応答ブロック
o Authentication Status Block
o 認証状態ブロック
o Cancel Block
o キャンセルブロック
o Delivery Request Block
o 配送要求ブロック
o Delivery Response Block
o 配送応答ブロック
o Error Block
o 誤りブロック
o Inquiry Request Block
o 問い合せ要求ブロック
o Inquiry Response Block
o 問い合せ応答ブロック
Burdett Informational [Page 165] RFC 2801 IOTP/1.0 April 2000
バーデット[165ページ]情報のRFC2801IOTP/2000年4月1日
o Offer Response Block
o 申し出応答ブロック
o Payment Exchange Block
o 支払い交換ブロック
o Payment Request Block
o 支払請求書ブロック
o Payment Response Block
o 支払い応答ブロック
o Signature Block
o 署名欄
o Trading Protocol Options Block
o 取り引きプロトコルオプションブロック
o TPO Selection Block
o TPO選択ブロック
The Transaction Reference Block is described in section 3.3.
Transaction Reference Blockはセクション3.3で説明されます。
8.1 Trading Protocol Options Block
8.1 オプションが妨げる取り引きプロトコル
The TPO Trading Block contains options which apply to the IOTP Transaction. The definition of a TPO Trading Block is as follows.
TPO Trading BlockはIOTP Transactionに適用されるオプションを含んでいます。 TPO Trading Blockの定義は以下の通りです。
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
<!要素TpoBlk(ProtocolOptions、BrandList*、Org*)><!ATTLIST TpoBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Trading Protocol Options Block within the IOTP
Transaction (see section 3.4 ID Attributes).
IOTP Transaction(セクション3.4ID Attributesを見る)の中で唯一TradingプロトコルOptions Blockを特定するID An識別子。
Content:
内容:
ProtocolOptions The Protocol Options Component (see section
7.1)defines the options which apply to the whole
IOTP Transaction (see section 9).
ProtocolOptionsプロトコルOptions Component(セクション7.1を見る)は全体のIOTP Transactionに適用されるオプションを定義します(セクション9を見てください)。
BrandList This Brand List Component contains one or more
payment brands and protocols which may be selected
(see section 7.7).
BrandList This Brand List Componentは選択されるかもしれない1つ以上の支払いブランドとプロトコルを含んでいます(セクション7.7を見てください)。
Org The Organisation Components (see section 7.6)
identify the Organisations and their roles in the
IOTP Transaction. The roles and Organisations
which must be present will depend on the
particular type of IOTP Transaction. See the
definition of each transaction in section 9.
Internet Open Trading Protocol Transactions.
Org Organisation Components(セクション7.6を見る)はIOTP TransactionにおけるOrganisationsと彼らの役割を特定します。 存在しなければならない役割とOrganisationsはIOTP Transactionの特定のタイプに頼るでしょう。 セクション9のそれぞれのトランザクションの定義を見てください。 インターネットの開いている取り引きプロトコルトランザクション。
Burdett Informational [Page 166] RFC 2801 IOTP/1.0 April 2000
バーデット[166ページ]情報のRFC2801IOTP/2000年4月1日
The TPO Block should contain:
TPO Blockは以下を含むはずです。
o the Protocol Options Component
o プロトコルオプションコンポーネント
o the Organisation Component with the Trading Role of Merchant
o 商人の取り引き役割がある機構コンポーネント
o the Organisation Component with the Trading Role of Consumer
o 消費者の取り引き役割がある機構コンポーネント
o optionally, the Organisation Component with the Trading Role of
DeliverTo, if there is a Delivery included in the IOTP Transaction
o DeliverToそこであるなら、任意に、Trading RoleとOrganisation ComponentはIOTP Transactionに含まれていたDeliveryです。
o Brand List Components for each payment in the IOTP Transaction
o IOTP Transactionの各支払いのためのブランドList Components
o Organisation Components for all the Payment Handlers involved
o すべてのPayment HandlersのためのComponentsがかかわった機構
o optionally, Organisation Components for the Delivery Handler (if
any) for the transaction
o 任意に、トランザクションのためのDelivery Handler(もしあれば)のためのOrganisation Components
o additional Organisation Components that the Merchant may want to
include. For example
o マーチャントが含みたがっているかもしれない追加Organisation Components。 例えば
- a Customer Care Provider
- 顧客介添え人
- an Certificate Authority that offers Merchant "Credentials" or
some other warranty on the goods or services being offered.
- 提供される商品かサービスのときにマーチャント「資格証明書」かある他の保証を提供するCertificate Authority。
8.2 TPO Selection Block
8.2TPO選択ブロック
The TPO Selection Block contains the results of selections made from the options contained in the Trading Protocol Options Block (see section 8.1).The definition of a TPO Selection Block is as follows.
TPO Selection BlockはTradingプロトコルOptions Block(セクション8.1を見る)に含まれたオプションからされた選択ではTPO Selection Blockの.The定義が以下の通りという結果を含んでいます。
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk
ID ID #REQUIRED >
<!要素TpoSelectionBlk(BrandSelection+)><!ATTLIST TpoSelectionBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the TPO
Selection Block within the IOTP Transaction.
IOTP Transactionの中で唯一TPO Selection Blockを特定するID An識別子。
Content:
内容:
BrandSelection This identifies the choice of payment brand and
payment protocol to be used in a payment within
the IOTP Transaction. There is one Brand Selection
Component (see section 7.8) for each payment to be
made in the IOTP Transaction.
BrandSelection Thisは、IOTP Transactionの中の支払いに使用されるために支払いブランドと支払いプロトコルの選択を特定します。 1Brand Selection ComponentがIOTP Transactionで済む各支払いであります(セクション7.8を見ます)。
Burdett Informational [Page 167] RFC 2801 IOTP/1.0 April 2000
バーデット[167ページ]情報のRFC2801IOTP/2000年4月1日
The TPO Selection Block should contain one Brand Selection Component for each Brand List in the TPO Block.
TPO Selection BlockはTPO Blockに各Brand Listあたり1Brand Selection Componentを含むはずです。
8.3 Offer Response Block
8.3申し出応答ブロック
The Offer Response Block contains details of the goods, services, amount, delivery instructions or financial transaction which is to take place. Its definition is as follows.
Offer Response Blockは商品、サービス、量、配送指示または行われることになっている金融取引の詳細を含んでいます。 定義は以下の通りです。
<!ELEMENT OfferRespBlk (Status, Order?, Payment*,
Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
ID ID #REQUIRED >
<!要素OfferRespBlk(状態、注文?、支払い*、配送?、TradingRoleData*)><!ATTLIST OfferRespBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the Offer
Response Block within the IOTP Transaction.
IOTP Transactionの中で唯一Offer Response Blockを特定するID An識別子。
Content:
内容:
Status Contains status information about the business
success (see section 4.2) or failure of the
generation of the Offer. Note that in an Offer
Response Block, a ProcessState of NotYetStarted or
InProgress are illegal values.
Offerの世代の営業上の成功(セクション4.2を見る)か失敗の状態Contains状態情報。 不法な値がOffer Response Block、NotYetStartedかInProgressのProcessStateに、あることに注意してください。
Order The Order Component contains details about the
goods, services or financial transaction which is
taking place see section 7.5.
注文してください。Order Componentは商品に関する詳細を含んでいて、行われているサービスか金融取引がセクション7.5を見ます。
The Order Component must be present unless the
ProcessState attribute of the Status Component is
set to Failed.
Status ComponentのProcessState属性がFailedに設定されない場合、Order Componentは存在していなければなりません。
Payment The Payment Components contain information about
the payments which are to be made see section 7.9.
Payment Componentsが作られているためにそうする支払いの情報を含む支払いはセクション7.9を見ます。
Delivery The Delivery Component contains details of the
delivery to be made (see section 7.13).
Delivery Componentが作られている(セクション7.13を見る)ために配送の詳細を含む配送。
TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between the
Trading Roles involved in an IOTP Transaction (see
section 7.17).
TradingRoleData Trading Role Data ComponentはIOTP TransactionにかかわるTrading Rolesの間でコミュニケートするべき必要性である不明瞭なデータを含んでいます(セクション7.17を見てください)。
The Offer Response Block should contain:
Offer Response Blockは以下を含むはずです。
Burdett Informational [Page 168] RFC 2801 IOTP/1.0 April 2000
バーデット[168ページ]情報のRFC2801IOTP/2000年4月1日
o the Order Component for the IOTP Transaction
o IOTPトランザクションのためのオーダーコンポーネント
o Payment Components for each Payment in the IOTP Transaction
o IOTP Transactionの各Paymentのための支払いComponents
o the Delivery Component the IOTP Transaction requires (if any).
o IOTP Transactionが必要とする(もしあれば)Delivery Component。
8.4 Authentication Request Block
8.4認証要求ブロック
The Authentication Request Block contains the data which is used by one Trading Role to obtain information about and optionally authenticate another Trading Role.
Authentication Request Blockは周囲で情報を得て、任意に別のTrading Roleを認証するのに1Trading Roleによって使用されるデータを含んでいます。
In outline it contains:
アウトラインでは、それは以下を含んでいます。
o information about how the authentication itself will be carried
out, and/or
o そして/または認証自体がどう行われるかの情報。
o a request for additional information about the Organisation being
authenticated.
o 認証されるOrganisationに関する追加情報に関する要求。
Its definition is as follows.
定義は以下の通りです。
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
<!ATTLIST AuthReqBlk
ID ID #REQUIRED >
<!要素AuthReqBlk(AuthReq*、TradingRoleInfoReq?) ><!ATTLIST AuthReqBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Authentication Request Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Authentication Request Blockを特定するID An識別子。
Content:
内容:
AuthReq Each Authentication Request (see section 7.2)
component describes an alternative way in which
the recipient of the Authentication Request may
authenticate themselves by generating an
Authentication Response Component (see section
7.3).
AuthReq Each Authentication Request(セクション7.2を見る)の部品はAuthentication Requestの受取人がAuthentication Response Componentを生成することによって自分たちを認証するかもしれない代替の方法を述べます(セクション7.3を見てください)。
If one Authentication Request Component is
present then that Authentication Request
Component should be used.
1Authentication Request Componentが存在しているなら、そのAuthentication Request Componentは使用されるべきです。
Burdett Informational [Page 169] RFC 2801 IOTP/1.0 April 2000
バーデット[169ページ]情報のRFC2801IOTP/2000年4月1日
If more than one Authentication Request Component
is present then the recipient should choose one
of the components based on personal preference of
the recipient or their software.
1Authentication Request Componentが存在しているなら、受取人は受取人かそれらのソフトウェアの個人的な好みに基づくコンポーネントの1つを選ぶべきです。
If no Authentication Request Component is present
it means that the Authentication Request Block is
requesting the return of Organisation Components
as specified in the Trading Role Information
Request Component.
どんなAuthentication Request Componentも存在していないなら、それは、Authentication Request BlockがTrading Role情報Request Componentの指定されるとしてのOrganisation Componentsの復帰を要求していることを意味します。
TradingRoleInfoReq The Trading Role Information Request Component
(see section 7.4) contains a list of Trading
Roles about which information is being requested
TradingRoleInfoReq Trading Role情報Request Component(セクション7.4を見る)は情報が要求されているTrading Rolesのリストを含んでいます。
There must be at least one Component (either an Authentication Request or a Trading Role Information Request) within the Authentication Block otherwise it is an error.
Authentication Blockの中に少なくとも1Component(Authentication RequestかTrading Role情報Requestのどちらか)があるに違いありません。そうでなければ、それは誤りです。
8.5 Authentication Response Block
8.5認証応答ブロック
The Authentication Response Block contains the response which results from processing the Authentication Request Block. Its definition is as follows.
Authentication Response Blockは、Authentication Request Blockを処理するので、結果として生じる応答を含んでいます。 定義は以下の通りです。
<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk
ID ID #REQUIRED >
<!要素AuthRespBlk(AuthResp?、Org*)><!ATTLIST AuthRespBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Authentication Response Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Authentication Response Blockを特定するID An識別子。
Content:
内容:
AuthResp The optional Authentication Response Component
which contains the results of processing the
Authentication Request Component - see section
7.3.
Authentication Request Componentを処理するという結果を含むAuthRespの任意のAuthentication Response Component--セクション7.3を見てください。
Org Optional Organisation Components that contain
information corresponding to the Trading Roles as
requested by the TradingRoleList attribute of the
Trading Role Information Request component.
要求された通りTrading Role情報Requestの部品のTradingRoleList属性でTrading Rolesに対応する情報を含むOrg Optional Organisation Components。
Burdett Informational [Page 170] RFC 2801 IOTP/1.0 April 2000
バーデット[170ページ]情報のRFC2801IOTP/2000年4月1日
The components present in the Authentication Response Block must match the requirement of the corresponding Authentication Request Block otherwise it is an error.
Authentication Response Blockの現在のコンポーネントは対応するAuthentication Request Blockの要件に合わなければなりません。そうでなければ、それは誤りです。
8.6 Authentication Status Block
8.6認証状態ブロック
The Authentication Status Block indicates the success or failure of the validation of an Authentication Response Block by an Authenticator. Its definition is as follows.
Authentication Status BlockはAuthenticatorによるAuthentication Response Blockの合法化の成否を示します。 定義は以下の通りです。
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk
ID ID #REQUIRED >
<!要素AuthStatusBlk(状態)><!ATTLIST AuthStatusBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Authentication Status Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Authentication Status Blockを特定するID An識別子。
Content:
内容:
Status Contains status information about the business
success (see section 4.2) or failure of the
authentication
認証の営業上の成功(セクション4.2を見る)か失敗の状態Contains状態情報
8.7 Payment Request Block
8.7支払請求書ブロック
The Payment Request Block contains information which requests that a payment is started. Its definition is as follows.
Payment Request Blockは支払いが始められるよう要求する情報を含んでいます。 定義は以下の通りです。
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
<!要素PayReqBlk(状態+、BrandList、BrandSelection、支払い、PaySchemeData?、Org*、TradingRoleData*)><!ATTLIST PayReqBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Payment Request Block within the IOTP Transaction.
IOTP Transactionの中で唯一Payment Request Blockを特定するID An識別子。
Content:
内容:
Status Contains the Status Components (see section 7.13)
of the responses of the steps (e.g., an Offer
Response and/or a Payment Response) on which this
ステップ(例えば、Offer Response、そして/または、Payment Response)の応答の状態Contains Status Components(セクション7.13を見る)、オンである、どれ、これ
Burdett Informational [Page 171] RFC 2801 IOTP/1.0 April 2000
バーデット[171ページ]情報のRFC2801IOTP/2000年4月1日
step depends. It is used to indicate the success
or failure of those steps. Payment should only
occur if the previous steps were successful.
ステップはよります。 それは、それらのステップの成否を示すのに使用されます。 前のステップがうまくいく場合にだけ、支払いは起こるでしょうに。
BrandList The Brand List Component contains a list of one or
more payment brands and protocols which may be
selected (see section 7.7).
BrandList Brand List Componentは選択されるかもしれない1つ以上の支払いブランドとプロトコルのリストを含んでいます(セクション7.7を見てください)。
BrandSelection This identifies the choice of payment brand, the
payment protocol and the Payment Handler to be
used in a payment within the IOTP Transaction.
There is one Brand Selection Component (see
section 7.8) for each payment to be made in the
IOTP Transaction.
BrandSelection Thisは、IOTP Transactionの中の支払いに使用されるために支払いブランド、支払いプロトコル、およびPayment Handlerの選択を特定します。 1Brand Selection ComponentがIOTP Transactionで済む各支払いであります(セクション7.8を見ます)。
Payment The Payment Components contain information about
the payment which is being made see section 7.9.
支払い、Payment Componentsはどれが作られているかがセクション7.9を見るという支払いの情報を含んでいます。
PaySchemeData The Payment Scheme Component contains payment
scheme specific data see section 7.10.
PaySchemeData Payment Scheme Componentは特定のデータが7.10を区分するのを見る支払い体系を含んでいます。
Org The Organisation Component contains details of
Organisations involved in the payment (see section
7.6). The Organisations present are dependent on
the IOTP Transaction and the data which is to be
signed. See section 6 Digital Signatures for more
details.
Org Organisation Componentは支払いにかかわるOrganisationsの細部を含んでいます(セクション7.6を見てください)。 現在のOrganisationsはIOTP Transactionの上の扶養家族と署名されることであるデータです。 その他の詳細に関してセクション6Digital Signaturesを見てください。
TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between the
Trading Roles involved in an IOTP Transaction (see
section 7.17).
TradingRoleData Trading Role Data ComponentはIOTP TransactionにかかわるTrading Rolesの間でコミュニケートするべき必要性である不明瞭なデータを含んでいます(セクション7.17を見てください)。
The Payment Request Block should contain:
Payment Request Blockは以下を含むはずです。
o the Organisation Component with a Trading Role of Merchant
o 商人の取り引き役割がある機構コンポーネント
o the Organisation Component with the Trading Role of Consumer
o 消費者の取り引き役割がある機構コンポーネント
o the Payment Component for the Payment
o 支払いのための支払いコンポーネント
o the Brand List Component for the Payment
o 支払いのためのブランドリストコンポーネント
o the Brand Selection Component for the Brand List
o ブランドリストのためのブランド選択コンポーネント
o the Organisation Component for the Payment Handler of the Payment
o 支払いの支払い操作者のための機構コンポーネント
Burdett Informational [Page 172] RFC 2801 IOTP/1.0 April 2000
バーデット[172ページ]情報のRFC2801IOTP/2000年4月1日
o the Organisation Component (if any) for the Organisation which
carried out the previous step, for example another Payment Handler
o 前のステップを行ったOrganisation、例えば、別のPayment HandlerのためのOrganisation Component(もしあれば)
o the Organisation Component for the Organisation which is to carry
out the next step, if any. This may be, for example, either a
Delivery Handler or a Payment Handler.
o 次のステップを行うことになっているOrganisationのためのもしあればOrganisation Component 例えば、これは、Delivery HandlerかPayment Handlerのどちらかであるかもしれません。
o the Organisation Components for any additional Organisations that
the Merchant has included in the Offer Response Block
o マーチャントがOffer Response Blockに含んでいたどんな追加OrganisationsのためのOrganisation Components
o an Optional Payment Scheme Data Component, if required by the
Payment Method as defined in the IOTP supplement for the payment
method
o 必要なら支払い方法のためのIOTP補足で定義されるPayment MethodによるOptional Payment Scheme Data Component
o any Trading Role Data Components that may be required (see section
7.17.1).
o それがどんなTrading Role Data Componentsであるかもしれないことも必要です(セクション7.17.1を見てください)。
8.8 Payment Exchange Block
8.8支払い交換ブロック
The Payment Exchange Block contains payment scheme specific data which is exchanged between two of the roles in a trade. Its definition is as follows.
Payment Exchange Blockは取り引きにおける2つの役割の間で交換される支払いの体系の特定のデータを含んでいます。 定義は以下の通りです。
<!ELEMENT PayExchBlk (PaySchemeData+) >
<!ATTLIST PayExchBlk
ID ID #REQUIRED >
<!要素PayExchBlk(PaySchemeData+)><!ATTLIST PayExchBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Payment Exchange Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Payment Exchange Blockを特定するID An識別子。
Content:
内容:
PaySchemeData This Trading Component contains payment scheme
specific data see section 7.10 Payment Scheme
Component.
PaySchemeData This Trading Componentは特定のデータが7.10Payment Scheme Componentを区分するのを見る支払い体系を含んでいます。
8.9 Payment Response Block
8.9支払い応答ブロック
This Payment Response Block contains a information about the Payment Status, an optional Payment Receipt, and an optional payment protocol message. Its definition is as follows.
このPayment Response BlockはPayment Status、任意のPayment Receipt、および任意の支払いプロトコルメッセージの情報を含んでいます。 定義は以下の通りです。
Burdett Informational [Page 173] RFC 2801 IOTP/1.0 April 2000
バーデット[173ページ]情報のRFC2801IOTP/2000年4月1日
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk
ID ID #REQUIRED >
<!要素PayRespBlk(状態、PayReceipt?、PaySchemeData?、PaymentNote?、TradingRoleData*)><!ATTLIST PayRespBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Payment Response Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Payment Response Blockを特定するID An識別子。
Content:
内容:
Status Contains status information about the business
success (see section 4.2) or failure of the
payment. Note that in a Pay Response Block, a
ProcessState of NotYetStarted or InProgress are
illegal values.
支払いの営業上の成功(セクション4.2を見る)か失敗の状態Contains状態情報。 不法な値がPay Response Block、NotYetStartedかInProgressのProcessStateに、あることに注意してください。
PayReceipt Contains payment scheme specific data which can be
used to verify the payment occurred. See section
7.11 Payment Receipt Component. It must be present
if the ProcessState attribute of the Status
Component is set to CompletedOk. PayReceipt is
optional for other values as specified by the
appropriate Payment Scheme supplement.
支払いについて確かめるのに使用できるPayReceipt Containsの支払いの体系の特定のデータは現れました。 セクション7.11Payment Receipt Componentを見てください。 Status ComponentのProcessState属性がCompletedOkに設定されるなら、存在していなければなりません。 指定されるとしての適切なPayment Scheme補足による他の値に、PayReceiptは任意です。
PaySchemeData Contains payment scheme specific data see section,
for example a payment protocol message. See 7.10
Payment Scheme Component.
PaySchemeData Containsの支払いの体系の特定のデータはセクション、例えば支払いプロトコルメッセージを見ます。 7.10支払い体系コンポーネントを見てください。
PaymentNote Contains additional, non payment related,
information which the Payment Handler wants to
provide to the Consumer. For example, if a
withdrawal or deposit were being made then it
could contain information on the remaining balance
on the account after the transfer was complete.
See section 7.12 Payment Note Component.
Payment HandlerがConsumerに供給したがっているPaymentNote Containsの追加していて、非支払い関連する情報。 例えば、引き出しか預金をしているなら、転送が完全になった後にそれはアカウントの残高の情報を含むかもしれないでしょうに。 セクション7.12Payment Note Componentを見てください。
TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between the
Trading Roles involved in an IOTP Transaction (see
section 7.17).
TradingRoleData Trading Role Data ComponentはIOTP TransactionにかかわるTrading Rolesの間でコミュニケートするべき必要性である不明瞭なデータを含んでいます(セクション7.17を見てください)。
Burdett Informational [Page 174] RFC 2801 IOTP/1.0 April 2000
バーデット[174ページ]情報のRFC2801IOTP/2000年4月1日
8.10 Delivery Request Block
8.10配送要求ブロック
The Delivery Request Block contains details of the goods or services which are to be delivered together with a signature which can be used to check that delivery is authorised. Its definition is as follows.
Delivery Request Blockは商品の、または、配送が認可されているのをチェックするのに使用できる署名と共に提供されることであるサービスの詳細を含んでいます。 定義は以下の通りです。
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*) >
<!ATTLIST DeliveryReqBlk
ID ID #REQUIRED >
<!要素DeliveryReqBlk(状態+、注文、Org*、配送、ConsumerDeliveryData?、TradingRoleData*)><!ATTLIST DeliveryReqBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Delivery Request Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Delivery Request Blockを特定するID An識別子。
Content:
内容:
Status Contains the Status Components (see section
7.13) of the responses of the steps (e.g., a
Payment Response) on which this step is
dependent. It is used to indicate the success
or failure of those steps. Delivery should only
occur if the previous steps were successful.
このステップが依存しているステップ(例えば、Payment Response)の応答の状態Contains Status Components(セクション7.13を見ます)。 それは、それらのステップの成否を示すのに使用されます。 前のステップがうまくいく場合にだけ、配送は起こるでしょうに。
Order The Order Component contains details about the
goods, services or financial transaction which
is taking place see section 7.5.
注文してください。Order Componentは商品に関する詳細を含んでいて、行われているサービスか金融取引がセクション7.5を見ます。
The Organisation Components (see section 7.6)
identify the Organisations and their roles in
Org the IOTP Transaction. The roles and
Organisations which must be present will depend
on the particular type of IOTP Transaction. See
the definition of each transaction in section
9. Internet Open Trading Protocol Transactions.
Organisation Components(セクション7.6を見る)はOrg IOTP TransactionにおけるOrganisationsと彼らの役割を特定します。 存在しなければならない役割とOrganisationsはIOTP Transactionの特定のタイプに頼るでしょう。 セクション9のそれぞれのトランザクションの定義を見てください。 インターネットの開いている取り引きプロトコルトランザクション。
Delivery The Delivery Component contains details of the
delivery to be made (see section 7.13).
Delivery Componentが作られている(セクション7.13を見る)ために配送の詳細を含む配送。
ConsumerDeliveryData Optional. Contains an identifier specified by
the Consumer which, if returned by the Delivery
Handler will enable the Consumer to identify
which Delivery is being referred to.
ConsumerDeliveryData任意です。 Consumerによって指定された識別子を含んでいる、どれ、戻って、Delivery Handlerが、ConsumerがどのDeliveryを特定するかを可能にするなら、言及されるのは、そうであるか。
Burdett Informational [Page 175] RFC 2801 IOTP/1.0 April 2000
バーデット[175ページ]情報のRFC2801IOTP/2000年4月1日
TradingRoleData The Trading Role Data Component contains opaque
data which is needs to be communicated between
the Trading Roles involved in an IOTP
Transaction (see section 7.17).
TradingRoleData Trading Role Data ComponentはIOTP TransactionにかかわるTrading Rolesの間でコミュニケートするべき必要性である不明瞭なデータを含んでいます(セクション7.17を見てください)。
The Delivery Request Block contains:
Delivery Request Blockは以下を含んでいます。
o the Organisation Component with a Trading Role of Merchant
o 商人の取り引き役割がある機構コンポーネント
o the Organisation Component for the Consumer and DeliverTo Trading
Roles
o 消費者とDeliverToの取り引き役割のための機構コンポーネント
o the Delivery Component for the Delivery
o 配送のための配送コンポーネント
o the Organisation Component for the Delivery Handler. Specifically
the Organisation Component identified by the ActionOrgRef
attribute on the Delivery Component
o 配送操作者のための機構コンポーネント。 明確にDelivery ComponentのActionOrgRef属性によって特定されたOrganisation Component
o the Organisation Component (if any) for the Organisation which
carried out the previous step, for example a Payment Handler
o 前のステップを行ったOrganisation、例えば、Payment HandlerのためのOrganisation Component(もしあれば)
o the Organisation Components for any additional Organisations that
the Merchant has included in the Offer Response Block
o マーチャントがOffer Response Blockに含んでいたどんな追加OrganisationsのためのOrganisation Components
o any Trading Role Data Components that may be required (see section
7.17.1).
o それがどんなTrading Role Data Componentsであるかもしれないことも必要です(セクション7.17.1を見てください)。
8.11 Delivery Response Block
8.11配送応答ブロック
The Delivery Response Block contains a Delivery Note containing details on how the goods will be delivered. Its definition is as follows. Note that in a Delivery Response Block a Delivery Status Element with a DeliveryStatusCode of NotYetStarted or InProgress is invalid.
Delivery Response Blockは商品がどう提供されるかに関する詳細を含むDelivery Noteを含んでいます。 定義は以下の通りです。 Delivery Response Blockでは、NotYetStartedかInProgressのDeliveryStatusCodeとDelivery Status Elementが無効であることに注意してください。
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
ID ID #REQUIRED >
<!要素DeliveryRespBlk(状態、DeliveryNote)><!ATTLIST DeliveryRespBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Delivery Response Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Delivery Response Blockを特定するID An識別子。
Content:
内容:
Burdett Informational [Page 176] RFC 2801 IOTP/1.0 April 2000
バーデット[176ページ]情報のRFC2801IOTP/2000年4月1日
Status Contains status information about the business
success (see section 4.2) or failure of the
delivery. Note that in a Delivery Response Block,
a ProcessState of NotYetStarted or InProgress are
illegal values.
配送の営業上の成功(セクション4.2を見る)か失敗の状態Contains状態情報。 不法な値がDelivery Response Block、NotYetStartedかInProgressのProcessStateに、あることに注意してください。
DeliveryNote The Delivery Note Component contains details about
how the goods or services will be delivered (see
section 7.15).
DeliveryNote Delivery Note Componentは商品かサービスがどう提供されるかに関する(セクション7.15を見てください)詳細を含んでいます。
8.12 Inquiry Request Trading Block
8.12 問い合せ要求通商圏
The Inquiry Request Trading Block contains an Inquiry Type Component and an optional Payment Scheme Component to contain payment scheme specific inquiry messages.
Inquiry Request Trading Blockは支払いの体系の特定の問い合せメッセージを含むInquiry Type Componentと任意のPayment Scheme Componentを含んでいます。
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
ID ID #REQUIRED >
<!要素InquiryReqBlk(InquiryType、PaySchemeData?) ><!ATTLIST InquiryReqBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Inquiry Request Trading Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Inquiry Request Trading Blockを特定するID An識別子。
Content:
内容:
InquiryType Inquiry Type Component (see section 7.18) that
contains the type of inquiry.
問い合せのタイプを含むInquiryType Inquiry Type Component(セクション7.18を見ます)。
PaySchemeData Payment Scheme Component (see section 7.10) that
contains payment scheme specific inquiry messages
for inquiries on payments. This is present when
the Type attribute of Inquiry Type Component is
Payment.
支払いを含むPaySchemeData Payment Scheme Component(セクション7.10を見る)が支払いのときに問い合せへの特定の問い合せメッセージを計画します。 Inquiry Type ComponentのType属性がPaymentであるときに、これは存在しています。
8.13 Inquiry Response Trading Block
8.13 問い合せ応答通商圏
The Inquiry Response Trading Block contains a Status Component and an optional Payment Scheme Component to contain payment scheme specific inquiry messages. Its purpose is to enquire on the current status of an IOTP transaction at a server.
Inquiry Response Trading Blockは支払いの体系の特定の問い合せメッセージを含むStatus Componentと任意のPayment Scheme Componentを含んでいます。 目的はIOTPトランザクションの現在の状態でサーバで尋ねることです。
Burdett Informational [Page 177] RFC 2801 IOTP/1.0 April 2000
バーデット[177ページ]情報のRFC2801IOTP/2000年4月1日
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED >
<!要素InquiryRespBlk(状態、PaySchemeData?) ><!ATTLIST InquiryRespBlkのIDのIDの#必要なLastReceivedIotpMsgRef NMTOKEN#、は、LastSentIotpMsgRef NMTOKEN#が>を含意したのを含意しました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Inquiry Response Trading Block within the
IOTP Transaction.
IOTP Transactionの中で唯一Inquiry Response Trading Blockを特定するID An識別子。
LastReceivedIotpMsgRef Contains an Element Reference (see section
3.5) to the Message Id Component (see section
3.3.2) of the last message this server has
received from the Consumer. If there is no
previously received message from the Consumer
in the pertinent transaction, this attribute
should be contain the value Null. This
attribute exists for debugging purposes.
LastReceivedIotpMsgRef Contains、このサーバがConsumerから受け取った最後のメッセージのMessage Id Component(セクション3.3.2を見る)へのElement Reference(セクション3.5を見ます)。 適切なトランザクションにConsumerからのどんな以前に受信されたメッセージもなければ、この属性は値のNullを含むことであるべきです。 この属性はデバッグ目的のために存在しています。
LastSentIotpMsgRef Contains an Element Reference (see section
3.5) to the Message Id Component (see section
3.3.2) of the last message this server has
sent to the Consumer. If there is no
previously sent message to the Consumer in
the pertinent transaction, this attribute
should contain the value Null. This attribute
exists for debugging purposes.
LastSentIotpMsgRef Contains、このサーバがConsumerに送った最後のメッセージのMessage Id Component(セクション3.3.2を見る)へのElement Reference(セクション3.5を見ます)。 適切なトランザクションにConsumerへの以前に送られたメッセージが全くなければ、この属性は値のNullを含むべきです。 この属性はデバッグ目的のために存在しています。
Content:
内容:
Status Contains status information about the business
success (see section 4.2) or failure of a certain
trading exchange (i.e., Offer, Payment, or
Delivery).
ある取り引き交換(すなわち、Offer、Payment、またはDelivery)の営業上の成功(セクション4.2を見る)か失敗の状態Contains状態情報。
PaySchemeData Payment Scheme Component (see section 7.10) that
contains payment scheme specific inquiry messages
for inquiries on payments. This is present when
the Type attribute of StatusType attribute of the
Status Component is set to Payment.
支払いを含むPaySchemeData Payment Scheme Component(セクション7.10を見る)が支払いのときに問い合せへの特定の問い合せメッセージを計画します。 Status ComponentのStatusType属性のType属性がPaymentに設定されるとき、これは存在しています。
Burdett Informational [Page 178] RFC 2801 IOTP/1.0 April 2000
バーデット[178ページ]情報のRFC2801IOTP/2000年4月1日
8.14 Ping Request Block
8.14ピング要求ブロック
The Ping Request Block is used to determine if a Server is operating and whether or not cryptography is compatible.
Ping Request Blockは、Serverが作動しているかどうかと、暗号は互換性があるかどうか決定するのに使用されます。
The definition of a Ping Request Block is as follows.
Ping Request Blockの定義は以下の通りです。
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
ID ID #REQUIRED>
<!要素PingReqBlk(Org*)><!ATTLIST PingReqBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the Ping
Request Trading Block within the IOTP Transaction.
IOTP Transactionの中で唯一Ping Request Trading Blockを特定するID An識別子。
Content:
内容:
Org Optional Organisation Components (see section
7.6).
Org Optional Organisation Components(セクション7.6を見ます)。
If no Organisation Component is present then the
Ping Request is anonymous and simply determines if
the server is operating.
どんなOrganisation Componentも存在していないなら、Ping Requestは、匿名であり、サーバが作動しているかどうか単に決定します。
However if Organisation Components are present,
then it indicates that the sender of the Ping
Request wants to verify that digital signatures
can be handled.
しかしながら、Organisation Componentsが存在しているなら、それは、Ping Requestの送付者が、デジタル署名を扱うことができることを確かめたがっているのを示します。
In this case the sender includes:
o an Organisation Component that identifies
itself specifying the Trading Role(s) it is
taking in IOTP transactions (Merchant, Payment
Handler, etc.)
o an Organisation Component that identifies the
intended recipient of the message.
この場合、送付者は: o IOTPトランザクション(商人、Payment Handlerなど)oでメッセージの意図している受取人を特定するOrganisation Componentを取りながらTrading Role(s)を指定しながらそれ自体を特定するOrganisation Component。
These are then used to generate a signature over
the Ping Response Block.
そして、これらは、Ping Response Blockの上の署名を生成するのに使用されます。
8.15 Ping Response Block
8.15ピング応答ブロック
The Ping Response Trading Block provides the result of a Ping Request.
Ping Response Trading BlockはPing Requestの結果を提供します。
It contains an Organisation Component that identifies the sender of the Ping Response.
それはPing Responseの送付者を特定するOrganisation Componentを含んでいます。
Burdett Informational [Page 179] RFC 2801 IOTP/1.0 April 2000
バーデット[179ページ]情報のRFC2801IOTP/2000年4月1日
If the Ping Request to which this block is a response contained Organisation Components, then it also contains those Organisation Components.
また、このブロックが応答であるPing RequestがOrganisation Componentsを含んだなら、それはそれらのOrganisation Componentsを含んでいます。
<!ELEMENT PingRespBlk (Org+)>
<!ATTLIST PingRespBlk
ID ID #REQUIRED
PingStatusCode (Ok | Busy | Down) #REQUIRED
SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
xml:lang NMTOKEN #IMPLIED
PingStatusDesc CDATA #IMPLIED>
<!ELEMENT PingRespBlk(Org+)><!ATTLIST PingRespBlk ID ID#REQUIRED PingStatusCode OK| |忙しくしてください、そして、(ダウンする)#REQUIRED SigVerifyStatusCode(OK| NotSupported| 失敗する)#IMPLIED xml: lang NMTOKEN#IMPLIED PingStatusDesc CDATA#IMPLIED>。
Attributes:
属性:
ID An identifier which uniquely identifies the Ping
Request Trading Block within the IOTP
Transaction.
IOTP Transactionの中で唯一Ping Request Trading Blockを特定するID An識別子。
PingStatusCode Contains a code which shows the status of the
sender software which processes IOTP messages.
Valid values are:
o Ok. Everything with the service is working
normally, including the signature
verification.
o Busy. Things are working normally but there
may be some delays.
o Down. The server is not functioning fully but
can still provide a Ping response.
どれがIOTPメッセージを処理するかを送付者ソフトウェアの状態に示すPingStatusCode Contains aコード。 有効値は以下の通りです。 o OK。 署名検証o Busyを含んでいて、通常、サービスがあるすべてが働いています。 通常しかし、いろいろなことは何かが遅れo Downであったかもしれないならそこで働いています。 サーバは、完全に機能しているというわけではありませんが、まだPing応答を提供できます。
SigVerifyStatusCode Contains a code which shows the status of
signature verification. This is present only
when the message containing the Ping Request
Block also contains a Signature Block. Valid
values are:
o Ok. The signature has successfully been
verified and proved compatible.
o NotSupported The receiver of this Ping
Request Block does not support validation of
signatures.
o Fail. Signature verification failed.
署名照合の状態を示しているSigVerifyStatusCode Contains aコード。 また、Ping Request Blockを含むメッセージがSignature Blockを含むときだけ、これは存在しています。 有効値は以下の通りです。 o OK。 署名は、首尾よく確かめられて、互換性があると立証されました。このPing Request Blockの受信機がするo NotSupportedは署名o Failの合法化をサポートしません。 署名照合は失敗しました。
Xml:lang Defines the language used in PingStatusDesc.
This is present when PingStatusDesc is present.
Xml: 言語がPingStatusDescで使用したlang Defines。 PingStatusDescが存在しているとき、これは存在しています。
PingStatusDesc Contains a short description of the status of
the server which sends this Ping Response Block.
Servers, if their designers want, can use this
このPing Response Blockを送るサーバの状態のPingStatusDesc Containsのa短い記述。 彼らのデザイナーが望んでいるなら、サーバはこれを使用できます。
Burdett Informational [Page 180] RFC 2801 IOTP/1.0 April 2000
バーデット[180ページ]情報のRFC2801IOTP/2000年4月1日
attribute to send more refined status
information than PingStatusCode which can be
used for debugging purposes, for example.
例えば、デバッグ目的に使用できるPingStatusCodeより洗練された状態情報を送る属性。
Content:
内容:
Org These are Organisation Components (see section
7.6).
Org TheseはOrganisation Components(セクション7.6を見る)です。
The Organisation Components of the sender of the
Ping Response is always included in addition to
the Organisation Components sent in the Ping
Request.
Ping Responseの送付者のOrganisation ComponentsはいつもPing Requestで送られたOrganisation Componentsに加えて含まれています。
Note: Ping Status Code values do not include a value such as Fail, since, when the software receiving the Ping Request message is not working at all, no Ping Response message will be sent back.
以下に注意してください。 ピングStatus Code値はFailなどの値を含んでいません、Ping Requestメッセージを受け取るソフトウェアが全く動作していないとき、Ping Responseメッセージが全く返送されないので。
8.16 Signature Block
8.16署名欄
The Signature Block contains one or more Signature Components and associated Certificates (if required) which sign data associated with the IOTP Transaction. For a general discussion and introduction to how IOTP uses signatures, see section 6 Digital Signatures. The definition of the Signature Component and certificates is contained in the paper "Digital Signatures for the Internet Open Trading Protocol", see [IOTPDSIG]. Descriptions of how these are used by IOTP is contained in sections 7.19 and 7.20.
Signature BlockはIOTP Transactionに関連しているデータに署名する1Signature Componentsと関連Certificates(必要なら)を含んでいます。 IOTPがどう署名を使用するかへの一般的な議論と序論に関しては、セクション6Digital Signaturesを見てください。 Signature Componentと証明書の定義は紙「インターネットの開いている取り引きプロトコルのためのデジタル署名」に含まれています、と[IOTPDSIG]は見ます。 これらがIOTPによってどう使用されるかに関する記述はセクション7.19と7.20で含まれています。
The definition of a Signature Block is as follows:
Signature Blockの定義は以下の通りです:
<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED >
<!要素IotpSignatures(署名+、証明書*)><!ATTLIST IotpSignatures ID ID#は>を含意しました。
Attributes:
属性:
ID An identifier which uniquely identifies the
Signature Block within the IOTP Transaction.
IOTP Transactionの中で唯一Signature Blockを特定するID An識別子。
Content:
内容:
Signature A Signature Component. See section 7.19.
署名A署名コンポーネント。 セクション7.19を見てください。
Certificate A Certificate Component. See section 7.20.
証明書の部品を証明してください。 セクション7.20を見てください。
Burdett Informational [Page 181] RFC 2801 IOTP/1.0 April 2000
バーデット[181ページ]情報のRFC2801IOTP/2000年4月1日
The contents of a Signature Block depends on the Trading Block that is contained in the same IOTP Message as the Signature Block.
Signature BlockのコンテンツはSignature Blockと同じIOTP Messageに含まれているTrading Blockによります。
8.16.1 Signature Block with Offer Response
8.16.1 申し出応答がある署名欄
A Signature Block which is in the same message as an Offer Response Block contains just an Offer Response Signature Component (see section 7.19.2).
Offer Response Blockと同じメッセージにあるSignature BlockはまさしくOffer Response Signature Componentを含んでいます(セクション7.19.2を見てください)。
8.16.2 Signature Block with Payment Request
8.16.2 支払請求書がある署名欄
A Signature Block which is in the same message as a Payment Request Block contains:
Payment Request Blockと同じメッセージにあるSignature Blockは以下を含んでいます。
o an Offer Response Signature Component (see section 7.19.2), and
o そしてOffer Response Signature Component(セクション7.19.2を見る)。
o if the Payment is dependent on an earlier step (as indicated by
the StartAfter attribute on the Payment Component), then the
Payment Receipt Signature Component (see section 7.19.3) generated
by the previous step
o Paymentが以前のステップに依存しているなら(Payment ComponentでStartAfter属性によって示されるように)、生成されたPayment Receipt Signature Component(セクション7.19.3を見る)は前で踏みます。
8.16.3 Signature Block with Payment Response
8.16.3 支払い応答がある署名欄
A Signature Block which is in the same message as a Payment
Response Block contains just a Payment Receipt Signature Component
(see section 7.19.3) generated by the step.
Payment Response Blockと同じメッセージにあるSignature Blockはまさしくステップで生成されたPayment Receipt Signature Component(セクション7.19.3を見る)を含んでいます。
8.16.4 Signature Block with Delivery Request
8.16.4 配送要求がある署名欄
A Signature Block which is in the same message as a Delivery
Request Block contains:
Delivery Request Blockと同じメッセージにあるSignature Blockは以下を含んでいます。
o an Offer Response Signature Component (see section 7.19.2), and
o そしてOffer Response Signature Component(セクション7.19.2を見る)。
o the Payment Receipt Signature Component (see section 7.19.3)
generated by the previous step.
o 前のステップで生成されたPayment Receipt Signature Component(セクション7.19.3を見ます)。
8.16.5 Signature Block with Delivery Response
8.16.5 配送応答がある署名欄
A Signature Block which is in the same message as a Delivery Response Block contains just a Delivery Response Signature component (see section 7.19.4) generated by the step.
Delivery Response Blockと同じメッセージにあるSignature Blockはまさしくステップで生成されたDelivery Response Signatureの部品(セクション7.19.4を見る)を含んでいます。
Burdett Informational [Page 182] RFC 2801 IOTP/1.0 April 2000
バーデット[182ページ]情報のRFC2801IOTP/2000年4月1日
8.17 Error Block
8.17誤りブロック
The Error Trading Block contains one or more Error Components (see section 7.21) which contain information about Technical Errors (see section 4.1) in an IOTP Message which has been received by one of the Trading Roles involved in the trade.
Error Trading Blockは取り引きにかかわるTrading Rolesのひとりによって受け取られたIOTP MessageにTechnical Errors(セクション4.1を見る)の情報を含む1Error Components(セクション7.21を見る)を含んでいます。
For clarity two phrases are defined which are used in the description of an Error Trading Block:
明快において、2つの句が定義されます(Error Trading Blockの記述に使用されます):
o message in error. An IOTP message which contains or causes an
error of some kind
o 間違いメッセージ。 ある種の誤りを含んでいるか、または引き起こすIOTPメッセージ
o message reporting the error. An IOTP message that contains an
Error Trading Block that describes the error found in a message in
error.
o 誤りを報告するメッセージ。 メッセージで見つけられた誤りについて間違って説明するError Trading Blockを含むIOTPメッセージ。
An Error Trading Block may be contained in any message reporting the error. The action which then follows depends on the severity of the error. See the definition of an Error Component, for an explanation of the different types of severity and the actions which can then occur.
Error Trading Blockは誤りを報告するどんなメッセージにも含まれるかもしれません。 その時続く動作は誤りの厳しさに依存します。 Error Componentの定義を見てください、異なったタイプの厳しさに関する説明と次に現れることができる動作のために。
in3 Note: Although, an Error Trading Block can report multiple different errors using multiple Error Components, there is no obligation on a developer of an IOTP Aware Application to do so.
in3 Note: Error Trading Blockが複数のError Componentsを使用することで複数の異なった誤りを報告できるので、するIOTP Aware Applicationの開発者の上の義務が全くありません。
The structure of an Error Trading Block is as follows.
Error Trading Blockの構造は以下の通りです。
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
ID ID #REQUIRED >
<!要素ErrorBlk(ErrorComp+、PaySchemeData*)><!ATTLIST ErrorBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the Error
Trading Block within the IOTP Transaction.
IOTP Transactionの中で唯一Error Trading Blockを特定するID An識別子。
Content:
内容:
ErrorComp An Error Components (see section 7.21) that
contains information about an individual Technical
Error.
個々のTechnical Errorの情報を含むErrorComp An Error Components(セクション7.21を見ます)。
PaySchemeData An optional Payment Scheme Component (see section
7.10) which contains a Payment Scheme Message. See
the appropriate payment scheme supplement to
Payment Scheme Messageを含むPaySchemeData Anの任意のPayment Scheme Component(セクション7.10を見ます)。 適切な支払い体系が補うのを確実にしてください。
Burdett Informational [Page 183] RFC 2801 IOTP/1.0 April 2000
バーデット[183ページ]情報のRFC2801IOTP/2000年4月1日
determine whether or not this component needs to
be present and for the definition of what it must
contain.
このコンポーネントが、存在している必要であるかどうか決定して、それが何を含まなければならないかに関する定義のために。
8.18 Cancel Block
8.18キャンセルブロック
The Cancel Block is used by one Trading Role to inform any other that a transaction has been cancelled. Example usage includes:
キャンセルBlockは、トランザクションが取り消されたことをいかなる他のも知らせるのに1Trading Roleによって使用されます。 例の用法は:
o a Consumer Role informing a non-Consumer role that it no longer
plans to continue with the transaction. This will allow the server
to close down the transaction tidily without a waiting for a
time-out to occur
o もうトランザクションを続行するのを計画していないことを非消費者の役割に知らせるConsumer Role。 これで、サーバは、タイムアウトが起こるように待ちなしでトランザクションを小ぎれいに閉鎖できるでしょう。
o a non-Consumer Role to inform a Consumer role that the Transaction
is being stopped. In this case, the Consumer is then unlikely to
re-send the previous message that was sent in the mistaken
understanding that the original was not received.
o Transactionが止められていることをConsumerの役割に知らせる非消費者Role。 そして、この場合、Consumerはオリジナルが受け取られなかったという間違われた理解で送られた前のメッセージを再送しそうにはありません。
Its definition is as follows.
定義は以下の通りです。
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk
ID ID #REQUIRED >
<!要素CancelBlk(状態)><!ATTLIST CancelBlk ID ID#は>を必要としました。
Attributes:
属性:
ID An identifier which uniquely identifies the Cancel
Block within the IOTP Transaction.
IOTP Transactionの中で唯一キャンセルBlockを特定するID An識別子。
Content:
内容:
Status Contains status information indicating that the
IOTP transaction has been cancelled.
IOTPトランザクションが取り消されたのを示す状態Contains状態情報。
9. Internet Open Trading Protocol Transactions
9. インターネットの開いている取り引きプロトコルトランザクション
The Baseline Internet Open Trading Protocol supports three types of transactions for different purposes. These are
BaselineインターネットオープンTradingプロトコルは異なる役割のために3つのタイプのトランザクションをサポートします。 これらはそうです。
o an Authentication IOTP transaction which supports authentication
of one party in a trade by another and/or requests information
about another Trading Role
o 別のもので取り引きにおける1回のパーティーの認証をサポートする、そして/または、別のTrading Roleの周りで情報を要求するAuthentication IOTPトランザクション
Burdett Informational [Page 184] RFC 2801 IOTP/1.0 April 2000
バーデット[184ページ]情報のRFC2801IOTP/2000年4月1日
o IOTP Transactions that involve one or more payments. Specifically:
o 1つ以上の支払いにかかわるIOTP Transactions。 明確に:
- Deposit
- 預金
- Purchase
- 購買
- Refund
- 還付
- Withdrawal, and
- 退出
- Value Exchange
- 値の交換
o IOTP Transactions designed to check the correct function of the
IOTP infrastructure. Specifically:
o IOTP TransactionsはIOTPインフラストラクチャの正しい機能をチェックに設計しました。 明確に:
- Transaction Status Inquiry, and
- そしてトランザクション資産調査。
- Ping
- ピング
Although the Authentication IOTP Transaction can operate on its own, authentication can optionally precede any of the "payment" transactions. Therefore, the rest of this section is divided into two parts covering:
Authentication IOTP Transactionはそれ自身のものを作動させることができますが、認証は任意に「支払い」トランザクションのいずれにも先行できます。 したがって、このセクションの残りは以下をカバーする2つの部品に分割されます。
o Authentication and Payment transactions (Authentication, Deposit,
Purchase, Refund, Withdrawal and Value Exchange)
o 認証とPaymentトランザクション(認証、預金、購買、還付、退出、および値の交換)
o Infrastructure Transactions (Transaction Status Inquiry and Ping)
that are designed to support inquiries on whether or not a
transaction has succeeded or a Trading Role's servers are
operating correctly, and
o そしてトランザクションが成功したかどうかに関する問い合せをサポートするように設計されているインフラストラクチャTransactions(トランザクションStatus InquiryとPing)かTrading Roleのサーバが正しく作動している。
9.1 Authentication and Payment Related IOTP Transactions
9.1 認証と支払いの関連IOTPトランザクション
The Authentication and Payment related IOTP Transactions consist
of six Document Exchanges which are then combined in sequence to
implement a specific transaction.
AuthenticationとPaymentの関連するIOTP Transactionsは次に特定のトランザクションを実装するために連続して結合される6Document Exchangesから成ります。
Generally, there is a close, but not exact, correspondence between
a Document Exchange and a Trading Exchange. The main difference is
that some Document Exchanges implement part or all of two Trading
Exchanges simultaneously in order to minimise the number of actual
IOTP Messages which must be sent over the Internet.
一般に、Document ExchangeとTrading Exchangeとの近い、しかし、正確でない通信があります。 主な違いはいくつかのDocument Exchangesが同時にインターネットの上に送らなければならない実際のIOTP Messagesの数を最小とならせるように2Trading Exchangesの部分かすべてを実装するということです。
The six Document Exchanges are:
6Document Exchangesは以下の通りです。
o Authentication. This is a direct implementation of the
Authentication Trading Exchange
o 認証。 これはAuthentication Trading Exchangeのダイレクト実装です。
Burdett Informational [Page 185] RFC 2801 IOTP/1.0 April 2000
バーデット[185ページ]情報のRFC2801IOTP/2000年4月1日
o Brand Dependent Offer. This is the Offer Trading Exchange combined
with the Brand Selection part of the Payment Trading Exchange. Its
purpose is to provide the Merchant with information on the Brand
selected so that the content of the Offer Response may be adapted
accordingly
o 依存する申し出に商標を付けてください。 これはPayment Trading ExchangeのBrand Selection部分に結合されたOffer Trading Exchangeです。 目的はそれに従って、Offer Responseの内容を適合させることができるように選択されたBrandの情報をマーチャントに提供することです。
o Brand Independent Offer. This is also an Offer Trading Exchange.
However, in this instance, the content of the Offer Response does
not depend on the Brand selected.
o 独立している申し出に商標を付けてください。 また、これはOffer Trading Exchangeです。 しかしながら、この場合、Offer Responseの内容は選択されたBrandによりません。
o Payment. This is a direct implementation of the Payment part of a
Payment Trading Exchange
o 支払い。 これはPayment Trading ExchangeのPayment部分のダイレクト実装です。
o Delivery. This is a direct implementation of the Delivery Exchange
o 配送。 これはDelivery Exchangeのダイレクト実装です。
o Delivery with Payment. This is an implementation of combined
Payment and Delivery Trading Exchanges
o 支払いとの配送。 これは結合したPaymentとDelivery Trading Exchangesの実装です。
These Document Exchanges are combined together in different sequences to implement each IOTP Transaction. The way in which they may be combined is illustrated by the diagram below.
These Document Exchanges are combined together in different sequences to implement each IOTP Transaction. The way in which they may be combined is illustrated by the diagram below.
Burdett Informational [Page 186] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 186] RFC 2801 IOTP/1.0 April 2000
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- | |
| | | |
| -------------- | ------------- |
v v v v |
------------------- ----------------- |
| BRAND INDEPENDENT | | BRAND DEPENDENT | |
| OFFER | | OFFER | |
------------------- ----------------- |
| | | | |
| --------------- | | |
| | | | |
| -------------- | -- | |
v v v v |
--------- -------------- |
| PAYMENT | | PAYMENT WITH | |
| (first) | | DELIVERY | |
--------- -------------- |
| | |
----------------------------- | |
v v | | |
---------- --------- | | |
| DELIVERY | | PAYMENT | | | |
| | | {second)| | | |
---------- --------- | | |
| | | | v
----------------------------------------------> STOP
START ----------------------------------------------------- | v | ---------------- | | AUTHENTICATION | | ---------------- -------------------------------------- | | | | | | | -------------- | ------------- | v v v v | ------------------- ----------------- | | BRAND INDEPENDENT | | BRAND DEPENDENT | | | OFFER | | OFFER | | ------------------- ----------------- | | | | | | | --------------- | | | | | | | | | -------------- | -- | | v v v v | --------- -------------- | | PAYMENT | | PAYMENT WITH | | | (first) | | DELIVERY | | --------- -------------- | | | | ----------------------------- | | v v | | | ---------- --------- | | | | DELIVERY | | PAYMENT | | | | | | | {second)| | | | ---------- --------- | | | | | | | v ----------------------------------------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 17 Payment and Authentication Message Flow Combinations
Figure 17 Payment and Authentication Message Flow Combinations
The combinations of Document Exchanges that are valid depend on the particular IOTP transaction.
The combinations of Document Exchanges that are valid depend on the particular IOTP transaction.
The remainder of this sub-section describes:
The remainder of this sub-section describes:
o each Document Exchange in more detail including descriptions of
the content of each Trading Block in the Document Exchanges, and
o each Document Exchange in more detail including descriptions of the content of each Trading Block in the Document Exchanges, and
o descriptions of how each IOTP Transaction uses the Document
Exchanges to effect the desired result.
o descriptions of how each IOTP Transaction uses the Document Exchanges to effect the desired result.
Burdett Informational [Page 187] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 187] RFC 2801 IOTP/1.0 April 2000
Note: The descriptions of the Document Exchanges which follow describe the ways in which various Business Errors (see section 4.2) are handled. No reference is made however to the handling of Technical Errors (see section 4.1) in any of the messages since these are handled the same way irrespective of the context in which the message is being sent. See section 4 for more details.
Note: The descriptions of the Document Exchanges which follow describe the ways in which various Business Errors (see section 4.2) are handled. No reference is made however to the handling of Technical Errors (see section 4.1) in any of the messages since these are handled the same way irrespective of the context in which the message is being sent. See section 4 for more details.
9.1.1 Authentication Document Exchange
9.1.1 Authentication Document Exchange
The Authentication Document Exchange is a direct implementation of the Authentication Trading Exchange (see section 2.2.4). It involves:
The Authentication Document Exchange is a direct implementation of the Authentication Trading Exchange (see section 2.2.4). It involves:
o an Authenticator - the Organisation which is requesting the
authentication, and
o an Authenticator - the Organisation which is requesting the authentication, and
o an Authenticatee - the Organisation being authenticated.
o an Authenticatee - the Organisation being authenticated.
The authentication consists of:
The authentication consists of:
o an Authentication Request being sent by the Authenticator to the
Authenticatee,
o an Authentication Request being sent by the Authenticator to the Authenticatee,
o an Authentication Response being sent in return by the
Authenticatee to the Authenticator which is then checked, and
o an Authentication Response being sent in return by the Authenticatee to the Authenticator which is then checked, and
o an Authentication Status being sent by the Authenticator to the
Authenticatee to provide an indication of the success or failure
of the authentication.
o an Authentication Status being sent by the Authenticator to the Authenticatee to provide an indication of the success or failure of the authentication.
An Authentication Document Exchange also:
An Authentication Document Exchange also:
o provides an Authenticatee with an Organisation Component which
describes the Authenticator, and
o provides an Authenticatee with an Organisation Component which describes the Authenticator, and
o optionally provides the Authenticator with Organisation Components
which describe the Authenticatee.
o optionally provides the Authenticator with Organisation Components which describe the Authenticatee.
The Authentication Request may also be digitally signed which allows the Authenticatee to verify the credentials of the Authenticator.
The Authentication Request may also be digitally signed which allows the Authenticatee to verify the credentials of the Authenticator.
The IOTP Messages which are involved are illustrated by the diagram below.
The IOTP Messages which are involved are illustrated by the diagram below.
Burdett Informational [Page 188] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 188] RFC 2801 IOTP/1.0 April 2000
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Organisation 1
(Authenticatee)
| Organisation 2
| (Authenticator)
STEP | |
1. First Organisation takes an action (for example by
pressing a button on an HTML page) which requires that
the Organisation is authenticated
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Organisation 1 (Authenticatee) | Organisation 2 | (Authenticator) STEP | | 1. First Organisation takes an action (for example by pressing a button on an HTML page) which requires that the Organisation is authenticated
1 --> 2 Authentication Need (outside scope of IOTP)
1 --> 2 Authentication Need (outside scope of IOTP)
2. The second Organisation generates: an Authentication
Request Block containing one or more Authentication
Request Components and/or a Trading Role Information
Request Component, then sends it to the first
Organisation
2. The second Organisation generates: an Authentication Request Block containing one or more Authentication Request Components and/or a Trading Role Information Request Component, then sends it to the first Organisation
1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block;
Signature Block (optional); TPO Block; Auth Request Block
1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block; Signature Block (optional); TPO Block; Auth Request Block
3. IOTP aware application started. If a Signature Block is
present, the first Organisation may use this to check the
credentials of the second Organisation. If credentials are
OK, the first Organisation selects an Authentication
Request to use (if present and more than one), then uses
the authentication algorithm selected to generate an
Authentication Response Block. If present, the Trading
Role Information Request Component is used to generate
Organisation Components. Finally a Signature Component is
created if required and all components are then sent back
to the second Organisation for validation.
3. IOTP aware application started. If a Signature Block is present, the first Organisation may use this to check the credentials of the second Organisation. If credentials are OK, the first Organisation selects an Authentication Request to use (if present and more than one), then uses the authentication algorithm selected to generate an Authentication Response Block. If present, the Trading Role Information Request Component is used to generate Organisation Components. Finally a Signature Component is created if required and all components are then sent back to the second Organisation for validation.
1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block;
Signature Block (optional) ; Auth Response Block
1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block; Signature Block (optional) ; Auth Response Block
4. The second Organisation checks the Authentication
Response against the data in the Authentication Request
Block to check that the first Organisation is who they
appear to be, and sends an Authentication Status Block to
the first Organisation to indicate the result then
stops.
4. The second Organisation checks the Authentication Response against the data in the Authentication Request Block to check that the first Organisation is who they appear to be, and sends an Authentication Status Block to the first Organisation to indicate the result then stops.
1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block;
Signature Block (optional); Auth Response Block
1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block; Signature Block (optional); Auth Response Block
Burdett Informational [Page 189] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 189] RFC 2801 IOTP/1.0 April 2000
5. The first Organisation checks the authentication Status
Block and optionally keeps information on the IOTP
transaction for record keeping purposes and stops.
5. The first Organisation checks the authentication Status Block and optionally keeps information on the IOTP transaction for record keeping purposes and stops.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 18 Authentication Document Exchange
Figure 18 Authentication Document Exchange
9.1.1.1 Message Processing Guidelines
9.1.1.1 Message Processing Guidelines
On receiving a TPO & Authentication Request IOTP Message (see below), an Authenticatee may either:
On receiving a TPO & Authentication Request IOTP Message (see below), an Authenticatee may either:
o generate and send an Authentication Response IOTP Message back to
the Authenticator, or
o generate and send an Authentication Response IOTP Message back to the Authenticator, or
o indicate failure to comply with the Authentication Request by
sending a Cancel Block back to the Authenticator containing a
Status Component with a StatusType of Authentication a
ProcessState of Failed and the CompletionCode (see section 7.16.4)
set to either: AutEeCancel, NoAuthReq, TradRolesIncon or
Unspecified.
o indicate failure to comply with the Authentication Request by sending a Cancel Block back to the Authenticator containing a Status Component with a StatusType of Authentication a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: AutEeCancel, NoAuthReq, TradRolesIncon or Unspecified.
On receiving an Authentication Response IOTP Message (see below), an Authenticator should send in return, an Authentication Status IOTP Message (see below) containing a Status Block with a Status Component where the StatusType is set to Authentication, and:
On receiving an Authentication Response IOTP Message (see below), an Authenticator should send in return, an Authentication Status IOTP Message (see below) containing a Status Block with a Status Component where the StatusType is set to Authentication, and:
o the ProcessState attribute of the Status Component is set to
CompletedOk which indicates a successful completion, or
o the ProcessState attribute of the Status Component is set to CompletedOk which indicates a successful completion, or
o the ProcessState attribute is set to Failed and the CompletionCode
attribute is set to either: AutOrCancel, AuthFailed or Unspecified
which indicates a failed authentication,
o the ProcessState attribute is set to Failed and the CompletionCode attribute is set to either: AutOrCancel, AuthFailed or Unspecified which indicates a failed authentication,
On receiving an Authentication Status IOTP Message (see below), the Authenticatee should check the Status Component in the Status Block. If this indicates:
On receiving an Authentication Status IOTP Message (see below), the Authenticatee should check the Status Component in the Status Block. If this indicates:
o a successful authentication, then the Authenticatee should either:
o a successful authentication, then the Authenticatee should either:
- continue with the next step in the IOTP Transaction of which
the Authentication Document Exchange is part (if any), or
- continue with the next step in the IOTP Transaction of which the Authentication Document Exchange is part (if any), or
Burdett Informational [Page 190] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 190] RFC 2801 IOTP/1.0 April 2000
- indicate a failure to continue with the rest of the IOTP
Transaction, by sending back to the Authenticator a Cancel
Block containing a Status Component with a StatusType of
Authentication, a ProcessState of Failed and the CompletionCode
(see section 7.16.4) set to AutEeCancel.
- indicate a failure to continue with the rest of the IOTP Transaction, by sending back to the Authenticator a Cancel Block containing a Status Component with a StatusType of Authentication, a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to AutEeCancel.
o a failed authentication, then the failure should be reported to
the Authenticatee and any further processing stopped.
o a failed authentication, then the failure should be reported to the Authenticatee and any further processing stopped.
If the Authenticator receives an IOTP Message containing a Cancel block from a Consumer, then the Authenticatee may go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Authenticator contained in the Trading Protocol Options Block.
If the Authenticator receives an IOTP Message containing a Cancel block from a Consumer, then the Authenticatee may go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Authenticator contained in the Trading Protocol Options Block.
9.1.1.2 TPO & Authentication Request IOTP Message
9.1.1.2 TPO & Authentication Request IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
o a Trading Protocol Options Block (see section 8.1)
o a Trading Protocol Options Block (see section 8.1)
o an Authentication Request Block (see section 8.4), and
o an Authentication Request Block (see section 8.4), and
o an optional Signature Block (see section 8.16).
o an optional Signature Block (see section 8.16).
Each of these are described below.
Each of these are described below.
TRADING PROTOCOL OPTIONS BLOCK
TRADING PROTOCOL OPTIONS BLOCK
The Trading Protocol Options Block (see section 8.1) must contain the following Trading Components:
The Trading Protocol Options Block (see section 8.1) must contain the following Trading Components:
o one Protocol Options Component (see Section 7.1) which defines the
options which apply to the whole Authentication Document Exchange.
o one Protocol Options Component (see Section 7.1) which defines the options which apply to the whole Authentication Document Exchange.
o one Organisation Component (see section 7.6) which describes the
Authenticator. The Trading Role on the Organisation Component
should indicate the role which the Authenticator is taking in the
Trade, for example a Merchant or a Consumer.
o one Organisation Component (see section 7.6) which describes the Authenticator. The Trading Role on the Organisation Component should indicate the role which the Authenticator is taking in the Trade, for example a Merchant or a Consumer.
AUTHENTICATION REQUEST BLOCK
AUTHENTICATION REQUEST BLOCK
The Authentication Request Block (see section 8.4) must contain the following Trading Components:
The Authentication Request Block (see section 8.4) must contain the following Trading Components:
o one Authentication Request Component (see section 7.2), and
o one Authentication Request Component (see section 7.2), and
Burdett Informational [Page 191] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 191] RFC 2801 IOTP/1.0 April 2000
SIGNATURE BLOCK (AUTHENTICATION REQUEST)
SIGNATURE BLOCK (AUTHENTICATION REQUEST)
If the Authentication Request is being digitally signed then a Signature Block must be included. It contains Digests of the following XML elements:
If the Authentication Request is being digitally signed then a Signature Block must be included. It contains Digests of the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message that contains information that describes the IOTP Message
and IOTP Transaction
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which globally
uniquely identifies the IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
o the following components of the TPO Block :
o the following components of the TPO Block :
- the Protocol Options Component
- the Protocol Options Component
- the Organisation Component
- the Organisation Component
o the following components of the Authentication Request Block:
o the following components of the Authentication Request Block:
- the Authentication Request Component
- the Authentication Request Component
- the Trading Role Information Request Component
- the Trading Role Information Request Component
9.1.1.3 Authentication Response IOTP Message
9.1.1.3 Authentication Response IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
o an Authentication Response Block (see section 8.5), and
o an Authentication Response Block (see section 8.5), and
o an optional Signature Block (see section 8.16).
o an optional Signature Block (see section 8.16).
Each of these are described below.
Each of these are described below.
AUTHENTICATION RESPONSE BLOCK
AUTHENTICATION RESPONSE BLOCK
The Authentication Response Block must contain the following Trading Component:
The Authentication Response Block must contain the following Trading Component:
o one Authentication Response Component (see section 7.3)
o one Authentication Response Component (see section 7.3)
o one Organisation Component for every Trading Role identified in
the TradingRoleList attribute of the Trading Role Information
Request Component contained in the Authentication Request Block.
o one Organisation Component for every Trading Role identified in the TradingRoleList attribute of the Trading Role Information Request Component contained in the Authentication Request Block.
Burdett Informational [Page 192] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 192] RFC 2801 IOTP/1.0 April 2000
SIGNATURE BLOCK (AUTHENTICATION RESPONSE)
SIGNATURE BLOCK (AUTHENTICATION RESPONSE)
If the Algorithm element (see section 12. IANA Considerations) within the Authentication Request Component contained in the Authentication Request Block indicates that the Authentication Response should consist of a digital signature then a Signature Block must be included in the same IOTP message that contains an Authentication Response Block. The Signature Component contains Digest Elements for the following XML elements:
If the Algorithm element (see section 12. IANA Considerations) within the Authentication Request Component contained in the Authentication Request Block indicates that the Authentication Response should consist of a digital signature then a Signature Block must be included in the same IOTP message that contains an Authentication Response Block. The Signature Component contains Digest Elements for the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message that contains information that describes the IOTP Message
and IOTP Transaction
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which globally
uniquely identifies the IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
o the following components of the Authentication Request Block:
o the following components of the Authentication Request Block:
- the Authentication Request Component
- the Authentication Request Component
- the Trading Role Information Request Component
- the Trading Role Information Request Component
o the Organisation Components contained in the Authentication
Response Block
o the Organisation Components contained in the Authentication Response Block
Note: It should not be assumed that all trading roles can support the signing of data. Particularly it should not be assumed that Consumers support the signing of data.
Note: It should not be assumed that all trading roles can support the signing of data. Particularly it should not be assumed that Consumers support the signing of data.
9.1.1.4 Authentication Status IOTP Message
9.1.1.4 Authentication Status IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
o an Authentication Status Block (see section 8.5), and
o an Authentication Status Block (see section 8.5), and
o an optional Signature Block (see section 8.16).
o an optional Signature Block (see section 8.16).
Each of these are described below.
Each of these are described below.
AUTHENTICATION STATUS BLOCK
AUTHENTICATION STATUS BLOCK
The Authentication Status Block (see section 8.6) must contain the following Trading Components:
The Authentication Status Block (see section 8.6) must contain the following Trading Components:
o one Status Component (see section 7.16) with a ProcessState
attribute set to CompletedOk.
o one Status Component (see section 7.16) with a ProcessState attribute set to CompletedOk.
Burdett Informational [Page 193] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 193] RFC 2801 IOTP/1.0 April 2000
SIGNATURE BLOCK (AUTHENTICATION STATUS)
SIGNATURE BLOCK (AUTHENTICATION STATUS)
If the Authentication Status Block is being digitally signed then
a Signature Block must be included that contains a Signature
Component with Digest elements for the following XML elements:
If the Authentication Status Block is being digitally signed then a Signature Block must be included that contains a Signature Component with Digest elements for the following XML elements:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message that contains information that describes the IOTP Message
and IOTP Transaction
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which globally
uniquely identifies the IOTP Transaction
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
o the following components of the Authentication Status Block:
o the following components of the Authentication Status Block:
- the Status Component (see section 7.16).
- the Status Component (see section 7.16).
Note: If the Authentication Document Exchange is followed by an Offer Document Exchange (see section 9.1.2) then the Authentication Status Block and the Signature Block (Authentication Status) may be combined with either:
Note: If the Authentication Document Exchange is followed by an Offer Document Exchange (see section 9.1.2) then the Authentication Status Block and the Signature Block (Authentication Status) may be combined with either:
o a TPO IOTP Message (see section 9.1.2.3), or
o a TPO IOTP Message (see section 9.1.2.3), or
o a TPO and Offer Response IOTP Message (see section 9.1.2.6)
o a TPO and Offer Response IOTP Message (see section 9.1.2.6)
9.1.2 Offer Document Exchange
9.1.2 Offer Document Exchange
The Offer Document Exchange occurs in two basic forms:
The Offer Document Exchange occurs in two basic forms:
o Brand Dependent Offer Exchange. Where the content of the offer,
e.g., the order details, amount, delivery details, etc., are
dependent on the payment brand and protocol selected by the
consumer, and
o Brand Dependent Offer Exchange. Where the content of the offer, e.g., the order details, amount, delivery details, etc., are dependent on the payment brand and protocol selected by the consumer, and
o Brand Independent Offer Exchange. Where the content of the offer
is not dependent on the payment brand and protocol selected.
o Brand Independent Offer Exchange. Where the content of the offer is not dependent on the payment brand and protocol selected.
Each of these types of Offer Document Exchange may be preceded by
an Authentication Document Exchange (see section 9.1.1).
Each of these types of Offer Document Exchange may be preceded by an Authentication Document Exchange (see section 9.1.1).
9.1.2.1 Brand Dependent Offer Document Exchange
9.1.2.1 Brand Dependent Offer Document Exchange
In a Brand Dependent Offer Document Exchange the TPO Block and the
Offer Response Block are sent separately by the Merchant to the
Consumer, i.e.:
In a Brand Dependent Offer Document Exchange the TPO Block and the Offer Response Block are sent separately by the Merchant to the Consumer, i.e.:
Burdett Informational [Page 194] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 194] RFC 2801 IOTP/1.0 April 2000
o the Brand List Component is sent to the Consumer in a TPO Block,
o the Brand List Component is sent to the Consumer in a TPO Block,
o the Consumer selects a Payment Brand, Payment Protocol and
optionally a Currency and amount from the Brand List Component
o the Consumer selects a Payment Brand, Payment Protocol and optionally a Currency and amount from the Brand List Component
o the Consumer sends the selected brand, protocol and
currency/amount back to the Merchant in a TPO Selection Block, and
o the Consumer sends the selected brand, protocol and currency/amount back to the Merchant in a TPO Selection Block, and
o the Merchant uses the information received to define the content
of and then send the Offer Response Block to the Consumer.
o the Merchant uses the information received to define the content of and then send the Offer Response Block to the Consumer.
Burdett Informational [Page 195] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 195] RFC 2801 IOTP/1.0 April 2000
This is illustrated by the diagram below.
This is illustrated by the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Merchant
STEP | |
1. Consumer decides to trade and sends to the Merchant
information (e.g., using HTML) that enables the Merchant
to create an offer,
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Consumer | Merchant STEP | | 1. Consumer decides to trade and sends to the Merchant information (e.g., using HTML) that enables the Merchant to create an offer,
C --> M Offer information - outside scope of IOTP
C --> M Offer information - outside scope of IOTP
2. Merchant decides which payment brand protocols,
currencies and amounts apply, places then in a Brand List
Component inside a TPO Block and sends to Consumer
2. Merchant decides which payment brand protocols, currencies and amounts apply, places then in a Brand List Component inside a TPO Block and sends to Consumer
C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block
C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block
3. IOTP aware application started. Consumer selects the
payment brand, payment protocol and currency/amount to
use. Records selection in a Brand Selection Component and
sends back to Merchant.
3. IOTP aware application started. Consumer selects the payment brand, payment protocol and currency/amount to use. Records selection in a Brand Selection Component and sends back to Merchant.
C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection
Block
C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection Block
4. Merchant uses selected payment brand, payment protocol,
currency/amount and the offer information to create an
Offer Response Block containing details about the IOTP
Transaction including price, etc. Optionally signs it and
sends to the Consumer
4. Merchant uses selected payment brand, payment protocol, currency/amount and the offer information to create an Offer Response Block containing details about the IOTP Transaction including price, etc. Optionally signs it and sends to the Consumer
C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block
(optional); Offer Response Block
C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block (optional); Offer Response Block
5. Consumer checks the Offer is OK, then combines components
from the TPO Block, the TPO Selection Block and the Offer
Response Block to create the next IOTP Message for the
Transaction and sends it together with the Signature
block if present to the required Trading Role
5. Consumer checks the Offer is OK, then combines components from the TPO Block, the TPO Selection Block and the Offer Response Block to create the next IOTP Message for the Transaction and sends it together with the Signature block if present to the required Trading Role
CONTINUED ...
CONTINUED ...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 19 Brand Dependent Offer Document Exchange
Figure 19 Brand Dependent Offer Document Exchange
Burdett Informational [Page 196] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 196] RFC 2801 IOTP/1.0 April 2000
Note, a Consumer identifies a Brand Dependent Offer Document Exchange, by the absence of an Offer Response Block in the first IOTP Message.
Note, a Consumer identifies a Brand Dependent Offer Document Exchange, by the absence of an Offer Response Block in the first IOTP Message.
MESSAGE PROCESSING GUIDELINES
MESSAGE PROCESSING GUIDELINES
On receiving a TPO IOTP Message (see below), the Consumer may either:
On receiving a TPO IOTP Message (see below), the Consumer may either:
o generate and send a TPO Selection IOTP Message back to the
Merchant, or
o generate and send a TPO Selection IOTP Message back to the Merchant, or
o indicate failure to continue with the IOTP Transaction by sending
a Cancel Block back to the Merchant containing a Status Component
with a StatusType of Offer, a ProcessState of Failed and the
CompletionCode (see section 7.16.4) set to either: ConsCancelled
or Unspecified.
o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Merchant containing a Status Component with a StatusType of Offer, a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: ConsCancelled or Unspecified.
On receiving a TPO Selection IOTP Message (see below) the Merchant may either:
On receiving a TPO Selection IOTP Message (see below) the Merchant may either:
o generate and send an Offer Response IOTP Message back to the
Consumer, or
o generate and send an Offer Response IOTP Message back to the Consumer, or
o indicate failure to continue with the IOTP Transaction by sending
a Cancel Block back to the Consumer containing a Status Component
with a StatusType of Offer, a ProcessState of Failed and the
CompletionCode (see section 7.16.4) set to either: MerchCancelled
or Unspecified.
o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Offer, a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: MerchCancelled or Unspecified.
On receiving an Offer Response IOTP Message (see below) the Consumer may either:
On receiving an Offer Response IOTP Message (see below) the Consumer may either:
o generate and send the next IOTP Message in the IOTP transaction
and send it to the required Trading Role. This is dependent on the
IOTP Transaction, or
o generate and send the next IOTP Message in the IOTP transaction and send it to the required Trading Role. This is dependent on the IOTP Transaction, or
o indicate failure to continue with the IOTP Transaction by sending
a Cancel Block back to the Merchant containing a Status Component
with a StatusType of Offer, a ProcessState of Failed and the
CompletionCode (see section 7.16.4) set to either: ConsCancelled
or Unspecified.
o indicate failure to continue with the IOTP Transaction by sending a Cancel Block back to the Merchant containing a Status Component with a StatusType of Offer, a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: ConsCancelled or Unspecified.
If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant.
If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant.
Burdett Informational [Page 197] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 197] RFC 2801 IOTP/1.0 April 2000
If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken.
If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken.
9.1.2.2 Brand Independent Offer Document Exchange
9.1.2.2 Brand Independent Offer Document Exchange
In a Brand Independent Offer Document Exchange the TPO Block and the Offer Response Block are sent together by the Merchant to the Consumer, i.e. there is one IOTP Message that contains both a TPO Block, and an Offer Response Block.
In a Brand Independent Offer Document Exchange the TPO Block and the Offer Response Block are sent together by the Merchant to the Consumer, i.e. there is one IOTP Message that contains both a TPO Block, and an Offer Response Block.
The message flow is illustrated by the diagram below:
The message flow is illustrated by the diagram below:
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Merchant
STEP | |
1. Consumer decides to trade and sends to the Merchant
information (e.g., using HTML) that enables the Merchant
to create an offer,
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Consumer | Merchant STEP | | 1. Consumer decides to trade and sends to the Merchant information (e.g., using HTML) that enables the Merchant to create an offer,
C --> M Offer information - outside scope of IOTP
C --> M Offer information - outside scope of IOTP
2. Merchant decides which payment brand protocols,
currencies and amounts apply, places then in a Brand List
Component inside a TPO Block, creates an Offer Response
containing details about the IOTP Transaction including
price, etc., optionally signs it and sends to Consumer
2. Merchant decides which payment brand protocols, currencies and amounts apply, places then in a Brand List Component inside a TPO Block, creates an Offer Response containing details about the IOTP Transaction including price, etc., optionally signs it and sends to Consumer
C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature
Block; TPO Block; Offer Response Block
C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block; TPO Block; Offer Response Block
3. IOTP aware application started. Consumer selects the
payment brand, payment protocol and currency/amount to
use. Records selection in a Brand Selection Component,
checks offer is OK, combines the Brand Selection
Component with information from the TPO Block and Offer
Response Block to create the next IOTP Message for the
Transaction and sends it together with the Signature
Block if present to the required Trading Role.
3. IOTP aware application started. Consumer selects the payment brand, payment protocol and currency/amount to use. Records selection in a Brand Selection Component, checks offer is OK, combines the Brand Selection Component with information from the TPO Block and Offer Response Block to create the next IOTP Message for the Transaction and sends it together with the Signature Block if present to the required Trading Role.
CONTINUED ...
CONTINUED ...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 20 Brand Independent Offer Exchange
Figure 20 Brand Independent Offer Exchange
Burdett Informational [Page 198] RFC 2801 IOTP/1.0 April 2000
Burdett Informational [Page 198] RFC 2801 IOTP/1.0 April 2000
Note that a Brand Independent Offer Document Exchange always occurs when only one payment brand, protocol and currency/amount is being offered to the Consumer by the Merchant. It is also likely to, but will not necessarily, occur when multiple brands are being offered, the Payment Handler is the same, and all brands use the same set of protocols.
Note that a Brand Independent Offer Document Exchange always occurs when only one payment brand, protocol and currency/amount is being offered to the Consumer by the Merchant. It is also likely to, but will not necessarily, occur when multiple brands are being offered, the Payment Handler is the same, and all brands use the same set of protocols.
Note that the TPO Block and the Offer Response Block can be sent in separate IOTP messages (see Brand Dependent Offer Document Exchange) even if the Offer Response Block does not change. However this increases the number of messages in the transaction and is therefore likely to increase transaction response times.
Note that the TPO Block and the Offer Response Block can be sent in separate IOTP messages (see Brand Dependent Offer Document Exchange) even if the Offer Response Block does not change. However this increases the number of messages in the transaction and is therefore likely to increase transaction response times.
IOTP aware applications supporting the Consumer Trading Role must check for the existence of an Offer Response Block in the first IOTP Message to determine whether the Offer Document Exchange is brand dependent or not.
IOTP aware applications supporting the Consumer Trading Role must check for the existence of an Offer Response Block in the first IOTP Message to determine whether the Offer Document Exchange is brand dependent or not.
MESSAGE PROCESSING GUIDELINES
MESSAGE PROCESSING GUIDELINES
On receiving a TPO and Offer Response IOTP Message (see below), the Consumer may either:
TPOとOffer Response IOTP Message(以下を見る)を受けると、Consumerはそうするかもしれません:
o generate and send the next IOTP Message in the IOTP transaction
and send it to the required Trading Role. This is dependent on the
IOTP Transaction, or
o IOTPトランザクションで次のIOTP Messageを生成して、送ってください、そして、必要なTrading Roleにそれを送ってください。 またはこれがIOTP Transactionに依存している。
o indicate failure to continue with the IOTP Transaction by sending
a Cancel Block back to the Merchant containing a Status Component
with a StatusType of Offer, a ProcessState of Failed and the
CompletionCode (see section 7.16.1) set to either: ConsCancelled
or Unspecified.
o OfferのStatusType、FailedのProcessState、およびCompletionCode(セクション7.16.1を見る)と共にStatus Componentを含むマーチャントにキャンセルBlockを送り返すことによってIOTP Transactionを続行しないことがどちらかにセットしたのを示してください: ConsCancelledか不特定です。
If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant.
マーチャントがキャンセルブロックを含むIOTP Messageを受け取るなら、ConsumerはOrganisation ComponentのTrading Role Elementでマーチャントに指定されたCancelNetLocnに行きそうです。
9.1.2.3 TPO IOTP Message
9.1.2.3 TPO IOTPメッセージ
The TPO IOTP Message is only used with a Brand Dependent Offer Document Exchange. Apart from a Transaction Reference Block (see section 3.3), this message consists of just a Trading Protocol Options Block (see section 8.1) which is described below.
TPO IOTP MessageはBrand Dependent Offer Document Exchangeと共に使用されるだけです。 Transaction Reference Block(セクション3.3を見る)は別として、このメッセージはまさしく以下で説明されるTradingプロトコルOptions Block(セクション8.1を見る)から成ります。
Burdett Informational [Page 199] RFC 2801 IOTP/1.0 April 2000
バーデット[199ページ]情報のRFC2801IOTP/2000年4月1日
TPO (TRADING PROTOCOL OPTIONS) BLOCK
TPO(取り引きプロトコルオプション)ブロック
The Trading Protocol Options Block (see section 8.1) must contain the following Trading Components:
TradingプロトコルOptions Block(セクション8.1を見る)は以下のTrading Componentsを含まなければなりません:
o one Protocol Options Component which defines the options which
apply to the whole IOTP Transaction. See Section 7.1.
o 全体のIOTP Transactionに適用されるオプションを定義する1プロトコルOptions Component。 セクション7.1を見てください。
o one Brand List Component (see section 7.7) for each Payment in the
IOTP Transaction that contain one or more payment brands and
protocols which may be selected for use in each payment
o 各支払いにおける使用のために選択されるかもしれない1つ以上の支払いブランドとプロトコルを含むIOTP Transactionの各Paymentあたり1Brand List Component(セクション7.7を見ます)
o Organisation Components (see section 7.6) with the following
roles:
o 以下の役割がある機構Components(セクション7.6を見ます):
- Merchant who is making the offer
- 申し出をしている商人
- Consumer who is carrying out the transaction
- トランザクションを行っている消費者
- the PaymentHandler(s) for the payment. The "ID" of the Payment
Handler Organisation Component is contained within the PhOrgRef
attribute of the Payment Component
- 支払いのためのPaymentHandler(s)。 支払い操作者機構コンポーネントの「ID」は支払いコンポーネントのPhOrgRef属性の中に含まれています。
If the IOTP Transaction includes a Delivery then the TPO Block must also contain:
また、IOTP TransactionがDeliveryを含んでいるなら、TPO Blockは以下を含まなければなりません。
o Organisation Components with the following roles:
o 以下の役割がある機構Components:
- DeliveryHandler who will be delivering the goods or services
- 商品かサービスを提供するDeliveryHandler
- DelivTo i.e. the person or Organisation which is to take
delivery
- すなわち、人のDelivToか配送を取ることになっているOrganisation
AUTHENTICATION STATUS AND SIGNATURE BLOCKS
認証状態と署名欄
If the Offer Document Exchange was preceded by an Authentication Document Exchange, then the TPO IOTP Message may also contain:
また、Offer Document ExchangeがAuthentication Document Exchangeによって先行されたなら、TPO IOTP Messageは以下を含むかもしれません。
o an Authentication Status Block (see section 8.6), and
o そしてAuthentication Status Block(セクション8.6を見る)。
o an optional Signature Block (Authentication Status) Signature
Block
o 任意のSignature Block(認証Status)署名Block
See section 9.1.1.4 Authentication Status IOTP Message for more details.
セクション9.1を見てください。.1 その他の詳細のための.4Authentication Status IOTP Message。
Burdett Informational [Page 200] RFC 2801 IOTP/1.0 April 2000
バーデット[200ページ]情報のRFC2801IOTP/2000年4月1日
9.1.2.4 TPO Selection IOTP Message
9.1.2.4 TPO選択IOTPメッセージ
The TPO Selection IOTP Message is only used with a Brand Dependent Offer Document Exchange. Apart from a Transaction Reference Block (see section 3.3), this message consists of just a TPO Selection Block (see section 8.1) which is described below.
TPO Selection IOTP MessageはBrand Dependent Offer Document Exchangeと共に使用されるだけです。 Transaction Reference Block(セクション3.3を見る)は別として、このメッセージはまさしく以下で説明されるTPO Selection Block(セクション8.1を見る)から成ります。
TPO SELECTION BLOCK
TPO選択ブロック
The TPO Selection Block (see section 8.2) contains:
TPO Selection Block(セクション8.2を見る)は以下を含んでいます。
o one Brand Selection Component (see section 7.8) for use in a
later Payment Exchange. It contains the results of the consumer
selecting a Payment Brand, Payment Protocol and currency/amount
from the list provided in the Brand List Component.
o 後のPayment Exchangeにおける使用のための1Brand Selection Component(セクション7.8を見ます)。 それは消費者がPayment Brandを選択するという結果を含んでいます、とリストからのPaymentプロトコルと通貨/量はBrand List Componentに供給しました。
9.1.2.5 Offer Response IOTP Message
9.1.2.5 応答IOTPメッセージを提供してください。
The Offer Response IOTP Message is only used with a Brand Dependent Offer Document Exchange. Apart from a Transaction Reference Block (see section 3.3), this message consists of:
Offer Response IOTP MessageはBrand Dependent Offer Document Exchangeと共に使用されるだけです。 Transaction Reference Block(セクション3.3を見る)は別として、このメッセージは以下から成ります。
o an Offer Response Block (see section 8.1) and
o そしてOffer Response Block(セクション8.1を見る)。
o an optional Signature Block (see section 8.16).
o 任意のSignature Block(セクション8.16を見ます)。
OFFER RESPONSE BLOCK
申し出応答ブロック
The Offer Response Block (see section 8.3) contains the following components:
Offer Response Block(セクション8.3を見る)は以下のコンポーネントを含んでいます:
o one Status Component (see section 7.16) which indicates the status
of the Offer Response. The ProcessState attribute should be set to
CompletedOk
o Offer Responseの状態を示す1Status Component(セクション7.16を見ます)。 ProcessState属性はCompletedOkに設定されるべきです。
o one Order Component (see section 7.5) which contains details about
the goods and services which are being purchased or the financial
transaction which is taking place
o 商品に関する詳細と購入されているサービスか行われている金融取引を含む1Order Component(セクション7.5を見ます)
o one or more Payment Component(s) (see section 7.9) for each
payment which is to be made
o 作られていることである各支払いあたり1Payment Component(s)(セクション7.9を見ます)
o zero or one Delivery Components (see section 7.13) containing
details of the delivery to be made if the IOTP Transaction
includes a delivery
o IOTP Transactionが配送を含んでいるならされる配送の詳細を含むゼロか1Delivery Components(セクション7.13を見ます)
o zero or more Trading Role Data Components (see section 7.17) if
required by the Merchant.
o 必要ならマーチャントによるゼロか、より多くのTrading Role Data Components(セクション7.17を見ます)。
Burdett Informational [Page 201] RFC 2801 IOTP/1.0 April 2000
バーデット[201ページ]情報のRFC2801IOTP/2000年4月1日
SIGNATURE BLOCK (OFFER RESPONSE)
署名欄(申し出応答)
If the Authentication Status Block is being digitally signed then a Signature Block must be included that contains a Signature Component (see section 7.19) with Digest Elements for the following XML elements:
Authentication Status Blockがデジタルに署名されているなら、以下のXML要素のためのDigest Elementsと共にSignature Componentを含む(セクション7.19を見ます)Signature Blockを含まなければなりません:
If the Offer Response is being digitally signed then a Signature Block must be included that contains a Signature Component (see section 7.19) with Digest Elements for the following XML elements:
Offer Responseがデジタルに署名されているなら、以下のXML要素のためのDigest Elementsと共にSignature Componentを含む(セクション7.19を見ます)Signature Blockを含まなければなりません:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message that contains information that describes the IOTP Message
and IOTP Transaction
o IOTP MessageとIOTP Transactionについて説明する情報を含むIOTP MessageのためのTransaction Reference Block(セクション3.3を見ます)
o the Transaction Id Component (see section 3.3.1) which globally
uniquely identifies the IOTP Transaction
o 唯一IOTP Transactionをグローバルに特定するTransaction Id Component(セクション3.3.1を見ます)
o the following components of the TPO Block :
o TPO Blockの以下の部品:
- the Protocol Options Component, and
- そしてプロトコルオプションコンポーネント。
- the Brand List Component
- ブランドリストコンポーネント
- all the Organisation Components present
- すべてのOrganisation Componentsプレゼント
o the following components of the Offer Response Block:
o Offer Response Blockの以下の部品:
- the Order Component
- オーダーコンポーネント
- all the Payment Components present
- すべてのPayment Componentsプレゼント
- the Delivery Component if present
- Delivery Component、現在
- any Trading Role Data Components present
- どんなTrading Role Data Componentsプレゼント
9.1.2.6 TPO and Offer Response IOTP Message
9.1.2.6 TPOと申し出応答IOTPメッセージ
The TPO and Offer Response IOTP Message is only used with a Brand Independent Offer Document Exchange. Apart from a Transaction Reference Block (see section 3.3), this message consists of:
TPOとOffer Response IOTP MessageはBrand無党派Offer Document Exchangeと共に使用されるだけです。 Transaction Reference Block(セクション3.3を見る)は別として、このメッセージは以下から成ります。
o a Trading Protocol Options Block (see section 8.1)
o 取り引きプロトコルオプションブロック(セクション8.1を見ます)
o an Offer Response Block (see section 8.1) and
o そしてOffer Response Block(セクション8.1を見る)。
o an optional Signature Block (see section 8.16).
o 任意のSignature Block(セクション8.16を見ます)。
Burdett Informational [Page 202] RFC 2801 IOTP/1.0 April 2000
バーデット[202ページ]情報のRFC2801IOTP/2000年4月1日
TPO (TRADING PROTOCOL OPTIONS) BLOCK
TPO(取り引きプロトコルオプション)ブロック
This is the same as the Trading Protocol Options Block described in TPO IOTP Message (see section 9.1.2.3).
セクション9.1を見てください。これがTradingプロトコルOptions BlockがTPO IOTP Messageで説明したのと同じである、(.2 .3)。
OFFER RESPONSE BLOCK
申し出応答ブロック
This the same as the Offer Response Block in the Offer Response IOTP Message (see section 9.1.2.5).
セクション9.1を見てください。Offer Response IOTP MessageのOffer Response Blockとこの同じくらい、(.2 .5)。
AUTHENTICATION STATUS
認証状態
If the Offer Document Exchange was preceded by an Authentication Document Exchange, then the TPO and Offer Response IOTP Message may also contain an Authentication Status Block (see section 8.6).
また、Offer Document ExchangeがAuthentication Document Exchangeによって先行されたなら、TPOとOffer Response IOTP MessageはAuthentication Status Blockを含むかもしれません(セクション8.6を見てください)。
SIGNATURE BLOCK
署名欄
This is the same as the Signature Block in the Offer Response IOTP Message (see section 9.1.2.5) with the addition that:
これがOffer Response IOTP MessageでSignature Blockと同じである、(追加がある.5が、)9.1に.2を区分するのを見る、それ:
o if the Offer Document Exchange is Brand Dependent then the
Signature Component in the Signature Block additionally contains a
Digest Element for the Brand Selection Component contained in the
TPO Selection Block
o Offer Document ExchangeがBrand Dependentであるなら、Signature BlockのSignature Componentはさらに、TPO Selection Blockに含まれたBrand Selection ComponentのためのDigest Elementを含んでいます。
o if the Offer Document Exchange was preceded by an Authentication
Document Exchange then the Signature Component in the Signature
Block additionally contains a Digest Element for the
Authentication Status Block.
o Offer Document ExchangeがAuthentication Document Exchangeによって先行されたなら、Signature BlockのSignature Componentはさらに、Authentication Status BlockのためのDigest Elementを含んでいます。
9.1.3 Payment Document Exchange
9.1.3 支払いドキュメント交換
The Payment Document Exchange is a direct implementation of the last part of a Payment Trading Exchange (see section 2.2.2) after the Brand has been selected by the Consumer. A Payment Exchange consists of:
BrandがConsumerによって選択された後にPayment Document ExchangeはPayment Trading Exchange(セクション2.2.2を見る)の最後の部分のダイレクト実装です。 Payment Exchangeは以下から成ります。
o the Consumer requesting that a payment starts by generating
Payment Request IOTP Message using information from previous IOTP
Messages in the Transaction and then sending it to the Payment
Handler
o 支払いがTransactionと次に、それを送ることにおける前のIOTP MessagesからPayment Handlerまで情報を使用することでPayment Request IOTP Messageを生成することによって始まるよう要求するConsumer
o the Payment Handler and the Consumer then swapping Payment
Exchange IOTP Messages encapsulating payment protocol messages
until the payment is complete, and finally
o 次に支払いが最終的に完全になるまで支払いプロトコルメッセージをカプセル化するPayment Exchange IOTP Messagesを交換するPayment HandlerとConsumer
Burdett Informational [Page 203] RFC 2801 IOTP/1.0 April 2000
バーデット[203ページ]情報のRFC2801IOTP/2000年4月1日
o the Payment Handler sending a Payment Response IOTP Message to the
Consumer containing a receipt for the payment.
o 支払いのための領収書を含むConsumerにPayment Response IOTP Messageを送るPayment Handler。
The IOTP Messages which are involved are illustrated by the diagram below.
かかわるIOTP Messagesは以下のダイヤグラムで例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Payment
| Handler
STEP | |
1. Consumer generates Pay Request Block encapsulating a
payment protocol message if required and sends to Payment
Handler with the Signature Block if present
*消費者| 支払い| 操作者ステップ| | 1. 消費者は、必要なら、Pay Request Block要約が支払いプロトコルメッセージであると生成して、存在しているなら、Signature Blockと共にPayment Handlerに発信します。
C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
Block (optional); Pay Request Block
支払請求書C-->P IotpMsg: 移-審判ブロック。 署名欄(任意の)。 賃金要求ブロック
2. Payment Handler processes Pay Request Block, checks
optional signature and starts exchanging payment protocol
messages encapsulated in a Pay Exchange Block, with the
Consumer
2. 支払いHandlerはPay Request Blockを処理して、任意の署名をチェックして、Pay Exchange Blockでカプセル化された支払いプロトコルメッセージを交換し始めます、Consumerと共に
C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
Block
C<->P支払い交換。 IotpMsg: 移-審判ブロック。 賃金交換ブロック
3. Consumer and Payment Handler keep on exchanging Payment
Exchange blocks until eventually payment protocol
messages finish so Payment Handler creates a Pay Receipt
Component inside a Pay Response Block, and an optional
Signature Component inside a Signature Block, sends them
to the Consumer and stops.
3. 結局までのPayment Exchangeブロックを交換するとき消費者とPayment Handlerが、支払いプロトコルメッセージが終わりであることを保って、Payment Handlerは、Pay Response Blockの中でPay Receipt Componentを作成して、Signature Blockの中で任意のSignature Componentを作成して、それらをConsumerに送るので、止まります。
C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature
Block (optional); Pay Response Block
C<--P支払い応答。 IotpMsg: 移-審判ブロック。 署名欄(任意の)。 賃金応答ブロック
4. Consumer checks Payment Response is OK. Optionally keeps
information on IOTP Transaction for record keeping
purposes and either stops or creates the next IOTP
message for the Transaction and sends it together with
the Signature Block, if present, to the required Trading
Role
4. 消費者チェックPayment ResponseはOKです。 必要なTrading Roleに存在しているなら、記録的なキープ目的のために任意にIOTP Transactionの情報を保って、止まるか、Transactionのために次のIOTPメッセージを作成して、またはSignature Blockと共にそれを送ります。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 21 Payment Document Exchange
図21 支払いドキュメント交換
Burdett Informational [Page 204] RFC 2801 IOTP/1.0 April 2000
バーデット[204ページ]情報のRFC2801IOTP/2000年4月1日
9.1.3.1 Message Processing Guidelines
9.1.3.1 メッセージ処理ガイドライン
On receiving a Payment Request IOTP Message, the Payment Handler should check that they are authorised to carry out the Payment (see section 6 Digital Signatures). They may then either:
Payment Request IOTP Messageを受けると、Payment Handlerは、彼らがPaymentを行うのが認可されるのをチェックするはずです(セクション6Digital Signaturesを見てください)。 それらがそうするかもしれない、次に、どちらか:
o generate and send a Payment Exchange IOTP Message back to the
Consumer, if more payment protocol messages need to be exchanged,
or
o またはPayment Exchange IOTP MessageをConsumerに生成して、送って戻してください、より多くの支払いプロトコルメッセージが、交換される必要があるなら。
o generate and send a Payment Response IOTP Message if the exchange
of payment protocol messages is complete, or
o または支払いプロトコルメッセージの交換が完全であるなら、Payment Response IOTP Messageを生成して、送ってください。
o indicate failure to continue with the Payment by sending a Cancel
Block back to the Consumer containing a Status Component with a
StatusType of Payment, a ProcessState of Failed and the
CompletionCode (see section 7.16.4) set to either: BrandNotSupp,
CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds,
InstBrandInvalid, InstNotValid, BadInstrument or Unspecified.
o PaymentのStatusType、FailedのProcessState、およびCompletionCode(セクション7.16.4を見る)と共にStatus Componentを含むConsumerにキャンセルBlockを送り返すことによってPaymentを続行しないことがどちらかにセットしたのを示してください: BrandNotSupp、CurrNotSupp、PaymtCancelled、AuthError、InsuffFunds、InstBrandInvalid、BadInstrumentの、または、不特定のInstNotValid。
On receiving a Payment Exchange IOTP Message, the Consumer may either:
Payment Exchange IOTP Messageを受けると、Consumerはそうするかもしれません:
o generate and send a Payment Exchange Message back to the Payment
Handler or
o またはPayment Exchange MessageをPayment Handlerに生成して、送って戻してください。
o indicate failure to continue with the Payment by sending a Cancel
Block back to the Payment Handler containing a Status Component
with a StatusType of Payment, a ProcessState of Failed and the
CompletionCode (see section 7.16.2) set to either: ConsCancelled
or Unspecified.
o PaymentのStatusType、FailedのProcessState、およびCompletionCode(セクション7.16.2を見る)と共にStatus Componentを含むPayment HandlerにキャンセルBlockを送り返すことによってPaymentを続行しないことがどちらかにセットしたのを示してください: ConsCancelledか不特定です。
On receiving a Payment Exchange IOTP Message, the Payment Handler may either:
Payment Exchange IOTP Messageを受けると、Payment Handlerはそうするかもしれません:
o generate and send a Payment Exchange IOTP Message back to the
Consumer, if more payment protocol messages need to be exchanged,
or
o またはPayment Exchange IOTP MessageをConsumerに生成して、送って戻してください、より多くの支払いプロトコルメッセージが、交換される必要があるなら。
o generate and send a Payment Response IOTP Message if the exchange
of payment protocol messages is complete, or
o または支払いプロトコルメッセージの交換が完全であるなら、Payment Response IOTP Messageを生成して、送ってください。
o indicate failure to continue with the Payment by sending a Cancel
Block back to the Consumer containing a Status Component with a
StatusType of Payment, a ProcessState of Failed and the
CompletionCode (see section 7.16.2) set to either: PaymtCancelled
or Unspecified.
o PaymentのStatusType、FailedのProcessState、およびCompletionCode(セクション7.16.2を見る)と共にStatus Componentを含むConsumerにキャンセルBlockを送り返すことによってPaymentを続行しないことがどちらかにセットしたのを示してください: PaymtCancelledか不特定です。
Burdett Informational [Page 205] RFC 2801 IOTP/1.0 April 2000
バーデット[205ページ]情報のRFC2801IOTP/2000年4月1日
On receiving a Payment Response IOTP Message, the Consumer may
either:
Payment Response IOTP Messageを受けると、Consumerはそうするかもしれません:
o generate and send the next IOTP Message in the IOTP transaction
and send it to the required Trading Role. This is dependent on the
IOTP Transaction,
o IOTPトランザクションで次のIOTP Messageを生成して、送ってください、そして、必要なTrading Roleにそれを送ってください。 これはIOTP Transactionに依存しています。
o stop, since the IOTP Transaction has ended, or
o またはIOTP Transactionが終わったので止まってください。
o indicate failure to continue with the IOTP Transaction by sending
a Cancel Block back to the Merchant containing a Status Component
with a StatusType of Payment, a ProcessState of Failed and the
CompletionCode (see section 7.16.1) set to either: ConsCancelled
or Unspecified.
o PaymentのStatusType、FailedのProcessState、およびCompletionCode(セクション7.16.1を見る)と共にStatus Componentを含むマーチャントにキャンセルBlockを送り返すことによってIOTP Transactionを続行しないことがどちらかにセットしたのを示してください: ConsCancelledか不特定です。
If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken.
Consumerがキャンセルブロックを含むIOTP Messageを受けるなら、IOTP Messageに含まれた情報はConsumerを取りますが、取られなかったどんなさらなる行動も報告されるべきです。
If the Payment Handler receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Payment Handler from which any further action may take place.
Payment Handlerがキャンセルブロックを含むIOTP Messageを受けるなら、ConsumerはOrganisation ComponentのTrading Role Elementでどんなさらなる動作も行われるPayment Handlerに指定されたCancelNetLocnに行きそうです。
If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer should have completed the payment but not continuing with the transaction for some reason. In this case the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant from which any further action may take place.
マーチャントがキャンセルブロックを含むIOTP Messageを受け取るなら、Consumerはある理由で続行ではなく、トランザクションがある支払いを終了するはずでした。 この場合、ConsumerはOrganisation ComponentのTrading Role Elementでどんなさらなる動作も行われるマーチャントに指定されたCancelNetLocnに行きそうです。
9.1.3.2 Payment Request IOTP Message
9.1.3.2 支払請求書IOTPメッセージ
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
Transaction Reference Block(セクション3.3を見る)は別として、このメッセージは以下から成ります。
o a Payment Request Block, and
o そして支払請求書ブロック。
o an optional Signature Block
o 任意のSignature Block
PAYMENT REQUEST BLOCK
支払請求書ブロック
The Payment Request Block (see section 8.7) contains:
Payment Request Block(セクション8.7を見る)は以下を含んでいます。
o the following components copied from the Offer Response Block from
the preceding Offer Document Exchange:
o 以下のコンポーネントはOffer Response Blockから前のOffer Document Exchangeからコピーされました:
- the Status Component
- 状態コンポーネント
Burdett Informational [Page 206] RFC 2801 IOTP/1.0 April 2000
バーデット[206ページ]情報のRFC2801IOTP/2000年4月1日
- the Payment Component for the payment which is being carried
out
- 行われている支払いのためのPayment Component
o the following components from the TPO Block:
o TPO Blockからの以下のコンポーネント:
- the Organisation Components with the roles of Merchant and for
the PaymentHandler that is being sent the Payment Request Block
- マーチャントの役割とPayment Request Blockが送られるPaymentHandlerのためのOrganisation Components
- the Brand List Component for the payment, i.e. the Brand List
referred to by the BrandListRef attribute on the Payment
Component
- 支払いのためのBrand List Component、すなわち、Payment ComponentでBrandListRef属性によって言及されたBrand List
o one Brand Selection Component for the Brand List, i.e. the Brand
Selection Component where BrandListRef attribute points to the
Brand List. This component can be either:
o Brand List(すなわち、BrandListRefがポイントをBrand Listの結果と考えるBrand Selection Component)のための1Brand Selection Component。 このコンポーネントはどちらかであるかもしれません:
- copied from the TPO Selection Block if the payment was preceded
by a Brand Dependent Offer Document Exchange (see section
9.1.2.1), or
- または支払いがBrand Dependent Offer Document Exchangeによって先行されたならTPO Selection Blockからコピーされる、(見る、セクション9.1 .2 .1、)。
- created by the Consumer, containing the payment brand, payment
protocol and currency/amount selected from the Brand List, if
the payment was preceded by a Brand Independent Offer Document
Exchange (see section 9.1.2.2)
- 支払いがBrand無党派Offer Document Exchangeによって先行されたならBrand Listから選択された支払いブランド、支払いプロトコル、および通貨/量を含んでいて、Consumerによって作成されます。(.2は、)9.1に.2を区分するのを見ます。
o an optional Payment Scheme Component (see section 7.10) if
required by the payment method used (see the Payment Method
supplement to determine if this is needed).
o 必要ならメソッドが使用した(これが必要であるかどうか決定するためにPayment Method補足を見ます)支払いによる任意のPayment Scheme Component(セクション7.10を見ます)。
o zero or more Trading Role Data Components (see section 7.17).
o ゼロか、より多くのTrading Role Data Components(セクション7.17を見ます)。
Note that:
以下のことに注意してください。
o if there is more than one Payment Components in an Offer Response
Block, then the second payment is the one within the Offer
Response Block that contains a StartAfter attribute (see section
7.9) that identifies the Payment Component for the first payment
o 1Payment ComponentsがOffer Response Blockにあれば、2番目の支払いは最初の支払いでPayment Componentを特定するStartAfter属性(セクション7.9を見る)を含むOffer Response Blockの中のものです。
o the Payment Handler to include is identified by the Brand
Selection Component (see section 7.8) for the payment. Also see
section 6.3.1 Check Request Block sent Correct Organisation for an
explanation on how Payment Handlers are identified
o インクルードへのPayment Handlerは支払いでBrand Selection Component(セクション7.8を見る)によって特定されます。 また、Correct OrganisationがPayment Handlersがどう特定されるかに関する説明のためにセクション6.3.1Check Request Blockに送られるのを見てください。
o the Brand List Component to include is the one identified by the
BrandListRef attribute of the Payment Component for the identified
payment
o インクルードへのBrand List Componentは特定された支払いでPayment ComponentのBrandListRef属性によって特定されたものです。
Burdett Informational [Page 207] RFC 2801 IOTP/1.0 April 2000
バーデット[207ページ]情報のRFC2801IOTP/2000年4月1日
o the Brand Selection Component to include from the Offer Response
Block is the one that contains an BrandListRef attribute (see
section 3.5) which identifies the Brand List Component for the
second payment.
o Offer Response BlockからのインクルードへのBrand Selection Componentは2番目の支払いでBrand List Componentを特定するBrandListRef属性(セクション3.5を見る)を含むものです。
SIGNATURE BLOCK (PAYMENT REQUEST)
署名欄(支払請求書)
If the either the preceding Offer Document Exchange included an Offer Response Signature (see section 9.1.2.5 Offer Response IOTP Message), or a preceding Payment Exchange included a Payment Response Signature
前のOffer Document ExchangeがOffer Response Signatureを含んでいた、(.5Offer Response IOTP Messageが、9.1に.2を区分するのを見る、)、前のPayment ExchangeはPayment Response Signatureを含んでいました。
(see section 9.1.3.4 Payment Response IOTP Message) then they should both be copied to the Signature Block in the Payment Request IOTP Message.
セクション9.1を見てください。(.3 .4 Payment Response IOTP Message) 次に、それらはともにPayment Request IOTP MessageのSignature Blockにコピーされるべきです。
9.1.3.3 Payment Exchange IOTP Message
9.1.3.3 支払い交換IOTPメッセージ
Apart from a Transaction Reference Block (see section 3.3), this message consists of just a Payment Exchange Block.
Transaction Reference Block(セクション3.3を見る)は別として、このメッセージはまさしくPayment Exchange Blockから成ります。
PAYMENT EXCHANGE BLOCK
支払い交換ブロック
The Payment Exchange Block (see section 8.8) contains:
Payment Exchange Block(セクション8.8を見る)は以下を含んでいます。
o one Payment Scheme Component (see section 7.10) which contains
payment method specific data. See the Payment Method supplement
for the payment method being used to determine what this should
contain.
o 支払い方法の特定のデータを含む1Payment Scheme Component(セクション7.10を見ます)。 これが何を含むべきであるかを決定するのに使用される支払い方法のためのPayment Method補足を見てください。
9.1.3.4 Payment Response IOTP Message
9.1.3.4 支払い応答IOTPメッセージ
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
Transaction Reference Block(セクション3.3を見る)は別として、このメッセージは以下から成ります。
o a Payment Response Block, and
o そして支払い応答ブロック。
o an optional Signature Block
o 任意のSignature Block
PAYMENT RESPONSE BLOCK
支払い応答ブロック
The Payment Response Block (see section 8.9) contains:
Payment Response Block(セクション8.9を見る)は以下を含んでいます。
o one Payment Receipt Component (see section 7.11) which contains
scheme specific data which can be used to verify the payment
occurred
o 支払いについて確かめるのに使用できる体系の特定のデータを含む1Payment Receipt Component(セクション7.11を見る)が起こりました。
Burdett Informational [Page 208] RFC 2801 IOTP/1.0 April 2000
バーデット[208ページ]情報のRFC2801IOTP/2000年4月1日
o one Payment Scheme Component (see section 7.10) if required which
contains payment method specific data. See the Payment Method
supplement for the payment method being used to determine what
this should contain
o 1Payment Scheme Component、(セクション7.10を見ます) 必要ならどれが支払い方法の特定のデータを含んでいますか? これが何を含むべきであるかを決定するのに使用される支払い方法のためのPayment Method補足を見てください。
o an optional Payment Note Component (see section 7.12)
o 任意のPayment Note Component(セクション7.12を見ます)
o zero or more Trading Role Data Components (see section 7.17).
o ゼロか、より多くのTrading Role Data Components(セクション7.17を見ます)。
SIGNATURE BLOCK (PAYMENT RESPONSE)
署名欄(支払い応答)
If a signed Payment Receipt is being provided, indicated by the SignedPayReceipt attribute of the Payment Component being set to True, then the Signature Block should contain a Signature Component which contains Digest Elements for the following:
Trueに用意ができているPayment ComponentのSignedPayReceipt属性によって示されて、署名しているPayment Receiptを提供しているなら、Signature Blockは以下のためのDigest Elementsを含むSignature Componentを含むはずです:
o the Transaction Reference Block (see section 3.3) for the IOTP
Message which contains the first usage of the Payment Response
Block,
o Payment Response Blockの最初の使用法を含むIOTP MessageのためのTransaction Reference Block(セクション3.3を見ます)
o the Transaction Id Component (see section 3.3.1) within the
Transaction Reference Block that globally uniquely identifies the
IOTP Transaction,
o 唯一IOTP Transactionをグローバルに特定するTransaction Reference Blockの中のTransaction Id Component(セクション3.3.1を見ます)
o the Payment Receipt Component from the Payment Response Block,
o 支払い応答ブロックからの支払い領収書の部品
o the Payment Note Component from the Payment Response Block,
o 支払い応答ブロックからの支払い注意コンポーネント
o the other Components referenced by the PayReceiptNameRefs
attribute (if present) of the Payment Receipt Component,
o Payment Receipt ComponentのPayReceiptNameRefs属性(存在しているなら)によって参照をつけられる他のComponents
o the Status Component from the Payment Response Block,
o 支払い応答ブロックからの状態コンポーネント
o any Trading Role Data Components in the Payment Response Block,
and
o そしてPayment Response BlockのどんなTrading Role Data Components、も。
o all the Signature Components contained in the Payment Request
Block if present.
o 存在しているならPayment Request Blockに含まれたすべてのSignature Components。
9.1.4 Delivery Document Exchange
9.1.4 配送ドキュメント交換
The Delivery Document Exchange is a direct implementation of a Delivery Trading Exchange (see section 2.2.3). It consists of:
Delivery Document ExchangeはDelivery Trading Exchangeのダイレクト実装(セクション2.2.3を見る)です。 それは以下から成ります。
o the Consumer requesting a Delivery by generating Delivery Request
IOTP Message using information from previous IOTP Messages in the
Transaction and then sending it to the Delivery Handler
o Transactionと次に、それを送ることにおける前のIOTP MessagesからDelivery Handlerまで情報を使用することでDelivery Request IOTP Messageを生成することによってDeliveryを要求するConsumer
Burdett Informational [Page 209] RFC 2801 IOTP/1.0 April 2000
バーデット[209ページ]情報のRFC2801IOTP/2000年4月1日
o the Delivery Handler sending a Delivery Response IOTP Message to
the Consumer containing details about the Handler's response to
the request together with an optional signature.
o 任意の署名と共に要求へのHandlerの応答に関する詳細を含むConsumerにDelivery Response IOTP Messageを送るDelivery Handler。
The message flow is illustrated by the diagram below.
メッセージ流動は以下のダイヤグラムで例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Delivery
| Handler
STEP | |
1. Consumer generates Delivery Request Block and sends it to
the Delivery Handler with the Signature Block if present
*消費者| 配送| 操作者ステップ| | 1. 存在しているなら、消費者は、Signature BlockとDelivery HandlerにDelivery Request Blockを生成して、それを送ります。
C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature
Block; Delivery Request Block
配送要求C-->D IotpMsg: 移-審判ブロック。 署名欄。 配送要求ブロック
2. Delivery Handler checks the Status and Order Components
in the Delivery Request and the optional Signatures,
creates a Delivery Response Block, sends to the Consumer
and stops.
2. 配送HandlerはDelivery Requestと任意のSignaturesでStatusとOrder Componentsをチェックして、Delivery Response Blockを作成して、Consumerに発信して、止まります。
C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature
Block; Delivery Response Block
C<--D配送応答。 IotpMsg: 移-審判ブロック。 署名欄。 配送応答ブロック
3. Consumer checks Delivery Response Block and optional
Signature Block are OK. Optionally keeps information on
IOTP Transaction for record keeping purposes and stops.
3. 消費者チェックのDelivery Response Blockと任意のSignature BlockはOKです。 記録的なキープ目的のために任意にIOTP Transactionの情報を保って、止まります。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 22 Delivery Document Exchange
図22 配送ドキュメント交換
9.1.4.1 Message Processing Guidelines
9.1.4.1 メッセージ処理ガイドライン
On receiving a Delivery Request IOTP Message, the Delivery Handler should check that they are authorised to carry out the Delivery (see section 6 Digital Signatures). They may then either:
Delivery Request IOTP Messageを受けると、Delivery Handlerは、彼らがDeliveryを行うのが認可されるのをチェックするはずです(セクション6Digital Signaturesを見てください)。 それらがそうするかもしれない、次に、どちらか:
o generate and send a Delivery Response IOTP Message to the
Consumer, or
o またはDelivery Response IOTP MessageをConsumerに生成して、送ってください。
o indicate failure to continue with the Delivery by sending a Cancel
Block back to the Consumer containing a Status Component with a
StatusType of Delivery, a ProcessState of Failed and the
CompletionCode (see section 7.16.4) set to either: DelivCanceled,
or Unspecified.
o DeliveryのStatusType、FailedのProcessState、およびCompletionCode(セクション7.16.4を見る)と共にStatus Componentを含むConsumerにキャンセルBlockを送り返すことによってDeliveryを続行しないことがどちらかにセットしたのを示してください: DelivCanceled、または不特定です。
Burdett Informational [Page 210] RFC 2801 IOTP/1.0 April 2000
バーデット[210ページ]情報のRFC2801IOTP/2000年4月1日
On receiving a Delivery Response IOTP Message, the Consumer should just stop since the IOTP Transaction is complete.
Delivery Response IOTP Messageを受けると、IOTP Transactionが完全であるので、Consumerはただ止まるはずです。
If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken.
Consumerがキャンセルブロックを含むIOTP Messageを受けるなら、IOTP Messageに含まれた情報はConsumerを取りますが、取られなかったどんなさらなる行動も報告されるべきです。
9.1.4.2 Delivery Request IOTP Message
9.1.4.2 配送要求IOTPメッセージ
The Delivery Request IOTP Message consists of:
Delivery Request IOTP Messageは以下から成ります。
o a Delivery Request Block, and
o そして配送要求ブロック。
o an optional Signature Block
o 任意のSignature Block
DELIVERY REQUEST BLOCK
配送要求ブロック
The Delivery Request Block (see section 8.10) contains:
Delivery Request Block(セクション8.10を見る)は以下を含んでいます。
o the following components copied from the Offer Response Block:
o 以下のコンポーネントはOffer Response Blockからコピーされました:
- the Status Component (see section 7.16)
- 状態コンポーネント(セクション7.16を見ます)
- the Order Component (see section 7.5)
- オーダーコンポーネント(セクション7.5を見ます)
- the Organisation Component (see section 7.6) with the roles of:
Merchant, DeliveryHandler and DeliverTo
- 以下の役割があるOrganisation Component(セクション7.6を見ます) 商人、DeliveryHandler、およびDeliverTo
- the Delivery Component (see section 7.13)
- 配送コンポーネント(セクション7.13を見ます)
o the following Component from the Payment Response Block:
o Payment Response Blockからの以下のComponent:
- the Status Component (see section 7.16).
- Status Component(セクション7.16を見ます)。
o zero or more Trading Role Data Components (see section 7.17).
o ゼロか、より多くのTrading Role Data Components(セクション7.17を見ます)。
SIGNATURE BLOCK (DELIVERY REQUEST)
署名欄(配送要求)
If the preceding Offer Document Exchange included an Offer Response Signature or the Payment Document Exchange included a Payment Response Signature, then they should both be copied to the Signature Block.
前のOffer Document ExchangeがOffer Response Signatureを含んでいたか、またはPayment Document ExchangeがPayment Response Signatureを含んでいるなら、それらはともにSignature Blockにコピーされるでしょうに。
9.1.4.3 Delivery Response IOTP Message
9.1.4.3 配送応答IOTPメッセージ
The Delivery Response IOTP Message contains a Delivery Response Block and an optional Signature Block.
Delivery Response IOTP MessageはDelivery Response Blockと任意のSignature Blockを含んでいます。
Burdett Informational [Page 211] RFC 2801 IOTP/1.0 April 2000
バーデット[211ページ]情報のRFC2801IOTP/2000年4月1日
DELIVERY RESPONSE BLOCK
配送応答ブロック
The Delivery Response Block contains:
Delivery Response Blockは以下を含んでいます。
o one Delivery Note Component (see section 7.15) which contains
delivery instructions about the delivery of goods or services
o 品物の配達かサービスに関する配送指示を含む1Delivery Note Component(セクション7.15を見ます)
in3 SIGNATURE BLOCK (DELIVERY RESPONSE)
in3 SIGNATURE BLOCK(配送応答)
The Signature Block should contain one Signature Component that
contains Digest elements that refer to
Signature Blockはそれが示すDigest要素を含む1Signature Componentを含むはずです。
o the Transaction Id Component (see section 3.3.1) of the IOTP
message that contains the Delivery Response Signature
o Delivery Response Signatureを含むIOTPメッセージのTransaction Id Component(セクション3.3.1を見ます)
o the Transaction Reference Block (see section 3.3) of the IOTP
Message that contains the Delivery Response Signature
o Delivery Response Signatureを含むIOTP MessageのTransaction Reference Block(セクション3.3を見ます)
o the Consumer Delivery Data component contained in the Delivery
Request Block (if any)
o Delivery Request Blockに含まれたConsumer Delivery Dataの部品(もしあれば)
o the Signature Components contained in the Delivery Request Block
(if any)
o Delivery Request Blockに含まれたSignature Components(もしあれば)
o the Status Component
o 状態コンポーネント
o the Delivery Note Component
o 納品受領書の部品
9.1.5 Payment and Delivery Document Exchange
9.1.5 支払いと配送ドキュメント交換
The Payment and Delivery Document Exchange is a combination of the last part of the Payment Trading Exchange (see section 2.2.2) and a Delivery Trading Exchange (see section 2.2.3). It consists of:
PaymentとDelivery Document ExchangeはPayment Trading Exchange(セクション2.2.2を見る)とDelivery Trading Exchangeの最後の部分の組み合わせです(セクション2.2.3を見てください)。 それは以下から成ります。
o the Consumer requesting that a payment starts by generating
Payment Request IOTP Message using information from previous IOTP
Messages in the Transaction and then sending it to the Payment
Handler
o 支払いがTransactionと次に、それを送ることにおける前のIOTP MessagesからPayment Handlerまで情報を使用することでPayment Request IOTP Messageを生成することによって始まるよう要求するConsumer
o the Payment Handler and the Consumer then swapping Payment
Exchange IOTP Messages encapsulating payment protocol messages
until the payment is complete, and finally
o 次に支払いが最終的に完全になるまで支払いプロトコルメッセージをカプセル化するPayment Exchange IOTP Messagesを交換するPayment HandlerとConsumer
o the Payment Handler sending to the Consumer in one IOTP Message:
o 1IOTP MessageのConsumerに発信するPayment Handler:
- a Payment Response Block containing a receipt for the payment,
and
- そして支払いのための領収書を含むPayment Response Block。
Burdett Informational [Page 212] RFC 2801 IOTP/1.0 April 2000
バーデット[212ページ]情報のRFC2801IOTP/2000年4月1日
- a Delivery Response Block containing details of the goods or
services to be delivered
- 提供される商品の、または、サービスの詳細を含むDelivery Response Block
The IOTP Messages which are involved are illustrated by the diagram below.
かかわるIOTP Messagesは以下のダイヤグラムで例証されます。
Burdett Informational [Page 213] RFC 2801 IOTP/1.0 April 2000
バーデット[213ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Payment
| Handler
STEP | |
1. Consumer generates Pay Request Block encapsulating a
payment protocol message if required and sends to Payment
Handler with the Signature Block if present
*消費者| 支払い| 操作者ステップ| | 1. 消費者は、必要なら、Pay Request Block要約が支払いプロトコルメッセージであると生成して、存在しているなら、Signature Blockと共にPayment Handlerに発信します。
C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
Block; Pay Request Block
支払請求書C-->P IotpMsg: 移-審判ブロック。 署名欄。 賃金要求ブロック
2. Payment Handler processes Pay Request Block, checks
optional signature and starts exchanging payment protocol
messages encapsulated in a Pay Exchange Block, with the
Consumer
2. 支払いHandlerはPay Request Blockを処理して、任意の署名をチェックして、Pay Exchange Blockでカプセル化された支払いプロトコルメッセージを交換し始めます、Consumerと共に
C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
Block
C<->P支払い交換。 IotpMsg: 移-審判ブロック。 賃金交換ブロック
3. Consumer and Payment Handler keep on exchanging Payment
Exchange blocks until eventually payment protocol
messages finish so Payment Handler creates a Pay Receipt
Component inside a Pay Response Block, and an optional
Signature Component inside a Signature Block, then uses
information from the Offer Response Bock to create a
Delivery Response Block and sends both to the Consumer
and stops.
3. 結局までのPayment Exchangeブロックを交換するとき消費者とPayment Handlerが、支払いプロトコルメッセージが終わりであることを保って、Payment Handlerは、Pay Response Blockの中でPay Receipt Componentを作成して、Signature Blockの中で任意のSignature Componentを作成して、次に、Delivery Response Blockを作成するのにOffer Response Bockから情報を使用して、両方をConsumerに送るので、止まります。
C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref
Block; Signature Block; Pay Response Block; Delivery
Response Block
C<--P支払い応答と配送応答。 IotpMsg: 移-審判ブロック。 署名欄。 応答ブロックして支払ってください。 配送応答ブロック
4. Consumer checks Payment Response and Delivery Response
Blocks are OK. Optionally keeps information on IOTP
Transaction for record keeping purposes and either stops
or creates the next IOTP message for the Transaction and
sends it together with the Signature Block, if present,
to the required Trading Role
4. 消費者チェックのPayment ResponseとDelivery Response BlocksはOKです。 必要なTrading Roleに存在しているなら、記録的なキープ目的のために任意にIOTP Transactionの情報を保って、止まるか、Transactionのために次のIOTPメッセージを作成して、またはSignature Blockと共にそれを送ります。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 23 Payment and Delivery Document Exchange
図23 支払いと配送ドキュメント交換
Burdett Informational [Page 214] RFC 2801 IOTP/1.0 April 2000
バーデット[214ページ]情報のRFC2801IOTP/2000年4月1日
The Delivery Response Block and the Payment Response Block may be combined into the same IOTP Message only if the Payment Handler has the information available so that she can send the Delivery Response Block. This is likely to, but will not necessarily, occur when the Merchant, the Payment Handler and the Delivery Handler Roles are combined.
彼女がDelivery Response Blockを送ることができるようにPayment Handlerに利用可能な情報がある場合にだけ、Delivery Response BlockとPayment Response Blockは同じIOTP Messageに結合されるかもしれません。 これは必ずそうするというわけではなくて、マーチャントであるときに起こるのを除いたPayment Handlerにありそうです、そして、Delivery Handler Rolesは結合されています。
The DelivAndPayResp attribute of the Delivery Component (see section 7.13) contained within the Offer Response Block (see section 8.3) is set to True if the Delivery Response Block and the Payment Response Block are combined into the same IOTP Message and is set to False if the Delivery Response Block and the Payment Response Block are sent in separate IOTP Messages.
Offer Response Blockの中に含まれたDelivery Component(セクション7.13を見る)のDelivAndPayResp属性をDelivery Response BlockとPayment Response Blockを同じIOTP Messageに結合するならTrueに設定して(セクション8.3を見ます)、別々のIOTP MessagesでDelivery Response BlockとPayment Response Blockを送るなら、Falseに設定します。
9.1.5.1 Message Processing Guidelines
9.1.5.1 メッセージ処理ガイドライン
On receiving a Payment Request IOTP Message or a Payment Exchange IOTP Message, the Payment Handler should carry out the same actions as for a Payment Document Exchange (see section 9.1.3.1).
セクション9.1を見てください。Payment Request IOTP MessageかPayment Exchange IOTP Messageを受けるときPayment HandlerがPayment Document Exchangeのように同じ動作を行うはずである、(.3 .1)。
On receiving a Payment Exchange IOTP Message, the Consumer should also carry out the same actions as for a Payment Document Exchange (see section 9.1.3.1).
セクション9.1を見てください。また、Payment Exchange IOTP Messageを受けるときConsumerがPayment Document Exchangeのように同じ動作を行うはずである、(.3 .1)。
On receiving a Payment Response and Delivery Response IOTP Message then the IOTP Transaction is complete and should take no further action.
その時Payment ResponseとDelivery Response IOTP Messageを受けると、IOTP Transactionは完全であり、これ以上行動を取るはずがありません。
If the Consumer receives an IOTP Message containing a Cancel block, then the information contained in the IOTP Message should be reported to the Consumer but no further action taken.
Consumerがキャンセルブロックを含むIOTP Messageを受けるなら、IOTP Messageに含まれた情報はConsumerを取りますが、取られなかったどんなさらなる行動も報告されるべきです。
If the Payment Handler receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Payment Handler from which any further action may take place.
Payment Handlerがキャンセルブロックを含むIOTP Messageを受けるなら、ConsumerはOrganisation ComponentのTrading Role Elementでどんなさらなる動作も行われるPayment Handlerに指定されたCancelNetLocnに行きそうです。
If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer should have completed the payment but not continuing with the transaction for some reason. In this case the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant from which any further action may take place.
マーチャントがキャンセルブロックを含むIOTP Messageを受け取るなら、Consumerはある理由で続行ではなく、トランザクションがある支払いを終了するはずでした。 この場合、ConsumerはOrganisation ComponentのTrading Role Elementでどんなさらなる動作も行われるマーチャントに指定されたCancelNetLocnに行きそうです。
9.1.5.2 Payment Request IOTP Message
9.1.5.2 支払請求書IOTPメッセージ
The content of this message is the same as for a Payment Request IOTP Message in a Payment Document Exchange (see section 9.1.3.2).
セクション9.1を見てください。このメッセージの内容がPayment Request IOTP MessageのようにPayment Document Exchangeで同じである、(.3 .2)。
Burdett Informational [Page 215] RFC 2801 IOTP/1.0 April 2000
バーデット[215ページ]情報のRFC2801IOTP/2000年4月1日
9.1.5.3 Payment Exchange IOTP Message
9.1.5.3 支払い交換IOTPメッセージ
The content of this message is the same as for a Payment Exchange IOTP Message in a Payment Document Exchange (see section 9.1.3.3).
セクション9.1を見てください。このメッセージの内容がPayment Exchange IOTP MessageのようにPayment Document Exchangeで同じである、(.3 .3)。
9.1.5.4 Payment Response and Delivery Response IOTP Message
9.1.5.4 支払い応答と配送応答IOTPメッセージ
The content of this message consists of:
このメッセージの内容は以下から成ります。
o a Payment Response Block,
o 支払い応答ブロック
o an optional Signature Block (Payment Response), and
o そして任意のSignature Block(支払いResponse)。
o a Delivery Response Block.
o 配送応答ブロック。
PAYMENT RESPONSE BLOCK
支払い応答ブロック
The content of this block is the same as the Payment Response Block in the Payment Response IOTP Message associated with a Payment Document Exchange (see section 9.1.3.4).
セクション9.1を見てください。このブロックの内容がPayment Response IOTP MessageのPayment Response BlockがPayment Document Exchangeと交際したのと同じである、(.3 .4)。
SIGNATURE BLOCK (PAYMENT RESPONSE)
署名欄(支払い応答)
The content of this block is the same as the Signature Block (Payment Response) in the Payment Response IOTP Message associated with a Payment Document Exchange (see section 9.1.3.4).
セクション9.1を見てください。このブロックの内容がPayment Response IOTP MessageのSignature Block(支払いResponse)がPayment Document Exchangeと交際したのと同じである、(.3 .4)。
DELIVERY RESPONSE BLOCK
配送応答ブロック
The content of this block is the same as the Delivery Response Block in the Delivery Response IOTP Message associated with a Delivery Document Exchange (see section 9.1.4.3).
セクション9.1を見てください。このブロックの内容がDelivery Response IOTP MessageのDelivery Response BlockがDelivery Document Exchangeと交際したのと同じである、(.4 .3)。
9.1.6 Baseline Authentication IOTP Transaction
9.1.6 基線認証IOTPトランザクション
A Baseline Authentication IOTP Transaction may occur at any time between any of the Trading Roles involved in IOTP Transactions. This means it could occur:
Baseline Authentication IOTP Transactionはいつでも、IOTP TransactionsにかかわるTrading Rolesのどれかの間に起こるかもしれません。 これは、それが起こることができたことを意味します:
o before another IOTP Transaction
o 別のIOTP Transactionの前で
o at the same time as another IOTP Transaction
o 別のIOTP Transactionと同時に
o independently of any other IOTP Transaction.
o いかなる他のIOTP Transactionの如何にかかわらず。
The Baseline Authentication IOTP Transaction consists of just an Authentication Document Exchange (see section 9.1.1) as illustrated by the diagram below.
Baseline Authentication IOTP Transactionは以下のダイヤグラムで例証されるようにまさしくAuthentication Document Exchange(セクション9.1.1を見る)から成ります。
Burdett Informational [Page 216] RFC 2801 IOTP/1.0 April 2000
バーデット[216ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -------------------------------------------------------
v
----------------
| AUTHENTICATION |
----------------
|
|
|
|
------------------- ----------------- |
| BRAND INDEPENDENT | | BRAND DEPENDENT | |
| OFFER | | OFFER | |
------------------- ----------------- |
|
|
|
|
|
--------- -------------- |
| PAYMENT | | PAYMENT WITH | |
| (first) | | DELIVERY | |
--------- -------------- |
|
|
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {second)| |
---------- --------- |
v
STOP
始め------------------------------------------------------- v---------------- | 認証| ---------------- | | | | ------------------- ----------------- | | ブランド独立者| | ブランド扶養家族| | | 申し出| | 申し出| | ------------------- ----------------- | | | | | | --------- -------------- | | 支払い| | 支払い| | | (最初に) | | 配送| | --------- -------------- | | | | ---------- --------- | | 配送| | 支払い| | | | | 2番目)、|、|、-、-、-、-、-、-、-、-、--、-、-、-、-、-、-、-、--、| v STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 24 Baseline Authentication IOTP Transaction
図24 基線認証IOTPトランザクション
Example uses of the Baseline Authentication IOTP Transaction include:
Baseline Authentication IOTP Transactionの例の用途は:
o when the Baseline Authentication IOTP Transaction takes place as
an early part of a session where strong continuity exists. For
example, a Financial Institution could:
o Baseline Authentication IOTP Transactionがセッションの早めの部分として強いところで行われるとき、連続は存在しています。 例えば、Financial Institutionはそうすることができました:
- set up a secure channel (e.g., using [SSL/TLS]) with a customer
- 顧客と共に安全なチャンネル(例えば、[SSL/TLS]を使用する)をセットアップしてください。
- authenticate the customer using the Baseline Authentication
IOTP Transaction, and then
- Baseline Authentication IOTP Transaction、およびその時を使用することで顧客を認証してください。
Burdett Informational [Page 217] RFC 2801 IOTP/1.0 April 2000
バーデット[217ページ]情報のRFC2801IOTP/2000年4月1日
- provide the customer with access to account information and
other services with the confidence that they are communicating
with a bona fide customer.
- アクセスを顧客に提供して、彼らが誠実な顧客とコミュニケートしているという自信をもって情報と他のサービスを説明してください。
o as a means of providing a Merchant role with Organisation
Components that contain information about Consumer and DelivTo
Trading Roles
o ConsumerとDelivTo Trading Rolesの情報を含むOrganisation Componentsをマーチャントの役割に提供する手段として
o so that a Consumer may authenticate a Payment Handler before
starting a payment.
o 支払いを始める前にConsumerがPayment Handlerを認証できるように。
9.1.7 Baseline Deposit IOTP Transaction
9.1.7 基線預金IOTPトランザクション
The Baseline Deposit IOTP Transaction supports the deposit of electronic cash with a Financial Institution.
Baseline Deposit IOTP TransactionはFinancial Institutionとの電子現金の預金をサポートします。
Note: The Financial Institution has, in IOTP terminology, a role of merchant in that a service (i.e. a deposit of electronic cash) is being offered in return for a fee, for example bank charges of some kind. The term "Financial Institution" is used in the diagrams and in the text for clarity.
以下に注意してください。 料金(例えば、ある種の銀行手数料)のお返しにサービス(すなわち、電子現金の預金)を提供しているので、Financial InstitutionはIOTP用語で商人の役割を持っています。 「金融機関」という用語はダイヤグラムと明快のためのテキストで使用されます。
The Baseline Deposit IOTP Transaction consists of the following Document Exchanges:
Baseline Deposit IOTP Transactionは以下のDocument Exchangesから成ります:
o an optional Authentication Document Exchange (see section 9.1.1)
o 任意のAuthentication Document Exchange(セクション9.1.1を見ます)
o an Offer Document Exchange (see section 9.1.2), and
o そしてOffer Document Exchange(セクション9.1.2を見る)。
o a Payment Document Exchange (see section 9.1.3).
o Payment Document Exchange(セクション9.1.3を見ます)。
The way in which these Document Exchanges may be combined together is illustrated by the diagram below.
これらのDocument Exchangesが一緒に結合されるかもしれない方法は以下のダイヤグラムで例証されます。
Burdett Informational [Page 218] RFC 2801 IOTP/1.0 April 2000
バーデット[218ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- |
| | |
| -------------- | -------------
v v v v
------------------- -----------------
| BRAND INDEPENDENT | | BRAND DEPENDENT |
| OFFER | | OFFER |
------------------- -----------------
| |
| |
| |
| -------------------
v v
--------- --------------
| PAYMENT | | PAYMENT WITH |
| (first) | | DELIVERY |
--------- --------------
|
----------------
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {second)| |
---------- --------- |
|
-----------------> STOP
始め----------------------------------------------------- | v| ---------------- | | 認証| | ---------------- -------------------------------------- | | | | | -------------- | ------------- v対vに------------------- ----------------- | ブランド独立者| | ブランド扶養家族| | 申し出| | 申し出| ------------------- ----------------- | | | | | | | ------------------- vに対して--------- -------------- | 支払い| | 支払い| | (最初に) | | 配送| --------- -------------- | ---------------- | ---------- --------- | | 配送| | 支払い| | | | | {second)| | ---------- --------- | | -----------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 25 Baseline Deposit IOTP Transaction
図25 基線預金IOTPトランザクション
See section 9.1.12 "Valid Combinations of Document Exchanges" to determine which combination of document exchanges apply to a particular instance of an IOTP Transaction
セクション9.1.12回のドキュメントのどの組み合わせを決定するか「ドキュメント交換の有効な組み合わせ」交換がIOTP Transactionの特定のインスタンスに適用されるのを見てください。
Note that:
以下のことに注意してください。
o a Merchant (Financial Institution) may be able to accept a deposit
in several different types of electronic cash although, since the
Consumer role that is depositing the electronic cash usually knows
what type of cash they want to deposit, it is usually constrained
o マーチャント(財政的なInstitution)がいくつかの異なったタイプの電子現金における預金を受け入れることができるかもしれない、すなわち、Consumerの役割以来、通常、電子現金を預けるのは、彼らがどんなタイプの現金を預けたがっているかを知って、通常、それは抑制されます。
Burdett Informational [Page 219] RFC 2801 IOTP/1.0 April 2000
バーデット[219ページ]情報のRFC2801IOTP/2000年4月1日
in practice to only one type. However, there may be several
different protocols which may be used for the same "brand" of
electronic cash. In this case a Brand Dependent Offer may be
appropriate to negotiate the protocol to be used.
1つだけへの習慣では、タイプしてください。 しかしながら、電子現金の同じ「ブランド」に使用されるかもしれないいくつかの異なったプロトコルがあるかもしれません。 この場合、Brand Dependent Offerは使用されるためにプロトコルを交渉するのが適切であるかもしれません。
o the Merchant (Financial Institution) may use the results of the
authentication to identify not only the consumer but also the
account to which the payment is to be deposited. If no single
account can be identified, then it must be obtained by other
means. For example:
o マーチャント(財政的なInstitution)は、消費者だけではなく、預けられる支払いがことであるアカウントも特定するのに認証の結果を使用するかもしれません。 どんなただ一つのアカウントも特定できないなら、他の手段でそれを得なければなりません。 例えば:
- the consumer could specify the account number prior to the
Baseline Deposit IOTP Transaction starting, or
- または消費者がBaseline Deposit IOTP Transaction始めの前に口座番号を指定できた。
- the consumer could have been identified earlier, for example
using a Baseline Authentication IOTP Transaction, and an
account selected from a list provided by the Financial
Institution.
- 消費者は、より早く特定されたかもしれません、例えば、Baseline Authentication IOTP Transaction、およびFinancial Institutionによって提供されたリストから選択されたアカウントを使用して。
o The Baseline Deposit IOTP Transaction without an Authentication
Document Exchange might be used:
o Authentication Document ExchangeのないBaseline Deposit IOTP Transactionは使用されるかもしれません:
- if a previous IOTP transaction, for example a Baseline
Withdrawal or a Baseline Authentication, authenticated the
consumer, and a secure channel has been maintained, therefore
the authenticity of the consumer is known
- 前のIOTPトランザクション(例えば、Baseline WithdrawalかBaseline Authentication)が消費者を認証して、安全なチャンネルが維持されて、したがって、消費者の信憑性が知られているなら
- if authentication is achieved as part of a proprietary payment
protocol and is therefore included in the Payment Document
Exchange
- 認証が独占支払いプロトコルの一部として達成されて、したがって、Payment Document Exchangeに含まれているなら
- if authentication of the consumer has been achieved by some
other means outside of the scope of IOTP, for example, by using
a pass phrase, or a proprietary banking software solution.
- 例えば、消費者の認証がパス句、または独占銀行業ソフトウェアソリューションを使用することによってある他の手段でIOTPの範囲の外に達成されたなら。
9.1.8 Baseline Purchase IOTP Transaction
9.1.8 基線購買IOTPトランザクション
The Baseline Purchase IOTP Transaction supports the purchase of goods or services using any payment method. It consists of the following Document Exchanges:
Baseline Purchase IOTP Transactionは、どんな支払い方法も使用することで商品の、または、サービスの購買をサポートします。 それは以下のDocument Exchangesから成ります:
o an optional Authentication Document Exchange (see section 9.1.1)
o 任意のAuthentication Document Exchange(セクション9.1.1を見ます)
o an Offer Document Exchange (see section 9.1.2)
o 申し出ドキュメント交換(セクション9.1.2を見ます)
o either:
o どちらか:
- a Payment Document Exchange (see section 9.1.3) followed by
- 続かれるPayment Document Exchange(セクション9.1.3を見ます)
Burdett Informational [Page 220] RFC 2801 IOTP/1.0 April 2000
バーデット[220ページ]情報のRFC2801IOTP/2000年4月1日
- a Delivery Document Exchange (see section 9.1.4)
- 配送ドキュメント交換(セクション9.1.4を見ます)
o a Payment Document Exchange only, or
o またはPayment Document Exchangeだけ。
o a combined Payment and Delivery Document Exchange (see section
9.1.5).
o 結合したPaymentとDelivery Document Exchange(セクション9.1.5を見ます)。
The ways in which these Document Exchanges are combined is illustrated by the diagram below.
これらのDocument Exchangesが結合されている方法は以下のダイヤグラムで例証されます。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- | |
| | | |
| -------------- | ------------- |
v v v v |
------------------- ----------------- |
| BRAND INDEPENDENT | | BRAND DEPENDENT | |
| OFFER | | OFFER | |
------------------- ----------------- |
| | | | |
| --------------- | | |
| | | | |
| -------------- | -- | |
v v v v |
--------- -------------- |
| PAYMENT | | PAYMENT WITH | |
| (first) | | DELIVERY | |
--------- -------------- |
| | |
----------------------------- | |
v | | |
---------- --------- | | |
| DELIVERY | | PAYMENT | | | |
| | | {second)| | | |
---------- --------- | | |
| | | v
----------------------------------------------> STOP
始め----------------------------------------------------- | v| ---------------- | | 認証| | ---------------- -------------------------------------- | | | | | | | -------------- | ------------- | v対vに| ------------------- ----------------- | | ブランド独立者| | ブランド扶養家族| | | 申し出| | 申し出| | ------------------- ----------------- | | | | | | | --------------- | | | | | | | | | -------------- | -- | | v対vに| --------- -------------- | | 支払い| | 支払い| | | (最初に) | | 配送| | --------- -------------- | | | | ----------------------------- | | v| | | ---------- --------- | | | | 配送| | 支払い| | | | | | | {second)| | | | ---------- --------- | | | | | | v ----------------------------------------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 26 Baseline Purchase IOTP Transaction
図26 基線購買IOTPトランザクション
Burdett Informational [Page 221] RFC 2801 IOTP/1.0 April 2000
バーデット[221ページ]情報のRFC2801IOTP/2000年4月1日
See section 9.1.12 "Valid Combinations of Document Exchanges" to determine which combination of document exchanges apply to a particular instance of an IOTP Transaction.
セクション9.1.12回のドキュメントのどの組み合わせを決定するか「ドキュメント交換の有効な組み合わせ」交換がIOTP Transactionの特定のインスタンスに適用されるのを見てください。
9.1.9 Baseline Refund IOTP Transaction
9.1.9 基線還付IOTPトランザクション
In business terms the refund process typically consists of:
取引条件で、還付プロセスは以下から通常成ります。
o a request for a refund being made by the Consumer to the Merchant,
typically supported by evidence to demonstrate:
o 示すのが証拠によって通常サポートされたマーチャントへのConsumerによってされる還付を求める要求:
- the original trade took place, for example by providing a
receipt for the original transaction
- オリジナル取り引きは、例えば、オリジナルのトランザクションに領収書を提供することによって、行われました。
- using some type of authentication, that the consumer requesting
the refund is the consumer, or a representative of the
consumer, who carried out the original trade
- タイプの認証を使用して、還付を要求する消費者が消費者、または消費者の代表であることが取り引きします。(その消費者は、オリジナルを行いました)。
- the reason why the merchant should make the refund
- 商人が還付をするべきである理由
o the merchant agreeing (or not) to the refund. This may involve
some negotiation between the Consumer and the Merchant, and, if
the merchant agrees,
o (or not)に還付に同意する商人。 そして、商人が同意するなら、これはConsumerとマーチャントとの何らかの交渉にかかわるかもしれません。
o a refund payment by the Merchant to the Consumer.
o Consumerへのマーチャントによる還付支払い。
The Baseline Refund IOTP Transaction supports a subset of the above, specifically it supports:
Baseline Refund IOTP Transactionは上記の部分集合をサポートして、明確にそれは以下をサポートします。
o stand alone authentication of the Consumer using a separate
Baseline Authentication IOTP Transaction (see section 9.1.6)
o 別々のBaseline Authentication IOTP Transactionを使用するConsumerのスタンドアロン認証(セクション9.1.6を見ます)
o a refund payment by the Merchant to the Consumer using the
following two Trading Exchanges:
o 以下の2Trading Exchangesを使用するConsumerへのマーチャントによる還付支払い:
- an optional Authentication Document Exchange (see section
9.1.1)
- 任意のAuthentication Document Exchange(セクション9.1.1を見ます)
- an Offer Document Exchange (see section 9.1.2), and
- そしてOffer Document Exchange(セクション9.1.2を見る)。
- a Payment Document Exchange (see section 9.1.3).
- Payment Document Exchange(セクション9.1.3を見ます)。
The ways in which these Document Exchanges are combined is illustrated by the diagram below.
これらのDocument Exchangesが結合されている方法は以下のダイヤグラムで例証されます。
Burdett Informational [Page 222] RFC 2801 IOTP/1.0 April 2000
バーデット[222ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- |
| | |
| -------------- | -------------
v v v v
------------------- -----------------
| BRAND INDEPENDENT | | BRAND DEPENDENT |
| OFFER | | OFFER |
------------------- -----------------
| |
| |
| |
| -------------------
v v
--------- --------------
| PAYMENT | | PAYMENT WITH |
| (first) | | DELIVERY |
--------- --------------
|
----------------
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {second)| |
---------- --------- |
|
-----------------> STOP
始め----------------------------------------------------- | v| ---------------- | | 認証| | ---------------- -------------------------------------- | | | | | -------------- | ------------- v対vに------------------- ----------------- | ブランド独立者| | ブランド扶養家族| | 申し出| | 申し出| ------------------- ----------------- | | | | | | | ------------------- vに対して--------- -------------- | 支払い| | 支払い| | (最初に) | | 配送| --------- -------------- | ---------------- | ---------- --------- | | 配送| | 支払い| | | | | {second)| | ---------- --------- | | -----------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 27 Baseline Refund IOTP Transaction
図27 基線還付IOTPトランザクション
A Baseline Refund IOTP Transaction without an Authentication Document Exchange might be used:
Authentication Document ExchangeのないBaseline Refund IOTP Transactionは使用されるかもしれません:
o when authentication of the consumer has been achieved by some
other means, for example, the consumer has entered some previously
supplied code in order to identify herself and the refund to which
the code applies. The code could be supplied, for example on a web
page or by e-mail.
o 消費者の認証がある他の手段で達成されたとき、例えば、消費者は、自分とコードが適用される還付を特定するために何らかの以前に供給されたコードを入れました。 例えば、ウェブページかメールでコードを供給できるでしょう。
Burdett Informational [Page 223] RFC 2801 IOTP/1.0 April 2000
バーデット[223ページ]情報のRFC2801IOTP/2000年4月1日
o when a previous IOTP transaction, for example a Baseline
Authentication, authenticated the consumer, and a secure channel
has been maintained, therefore the authenticity of the consumer is
known and therefore the previously agreed refund can be
identified.
o 前のIOTPトランザクション(例えば、Baseline Authentication)が消費者を認証して、安全なチャンネルが維持されたとき、したがって、消費者の信憑性を知っています、そして、したがって、以前に同意された還付は特定できます。
o when the authentication of the consumer is carried out by the
Payment Handler using a payment scheme authentication algorithm.
o 消費者の認証が支払いを使用することでPayment Handlerによって行われたら、認証アルゴリズムを計画してください。
9.1.10 Baseline Withdrawal IOTP Transaction
9.1.10 基線退出IOTPトランザクション
The Baseline Withdrawal IOTP Transaction supports the withdrawal of electronic cash from a Financial Institution.
Baseline Withdrawal IOTP TransactionはFinancial Institutionから電子現金の退出をサポートします。
Note: The Financial Institution has, in IOTP terminology, a role of merchant in that a service (i.e. a withdrawal of electronic cash) is being offered in return for a fee, for example bank charges of some kind. The term "Financial Institution" is used in the diagrams and in the text for clarity.
以下に注意してください。 料金(例えば、ある種の銀行手数料)のお返しにサービス(すなわち、電子現金の退出)を提供しているので、Financial InstitutionはIOTP用語で商人の役割を持っています。 「金融機関」という用語はダイヤグラムと明快のためのテキストで使用されます。
The Baseline Withdrawal IOTP Transaction consists of the following Document Exchanges:
Baseline Withdrawal IOTP Transactionは以下のDocument Exchangesから成ります:
o an optional Authentication Document Exchange (see section 9.1.1)
o 任意のAuthentication Document Exchange(セクション9.1.1を見ます)
o an Offer Document Exchange (see section 9.1.2), and
o そしてOffer Document Exchange(セクション9.1.2を見る)。
o a Payment Document Exchange (see section 9.1.3).
o Payment Document Exchange(セクション9.1.3を見ます)。
The way in which these Document Exchanges may be combined together is illustrated by the diagram below.
これらのDocument Exchangesが一緒に結合されるかもしれない方法は以下のダイヤグラムで例証されます。
Burdett Informational [Page 224] RFC 2801 IOTP/1.0 April 2000
バーデット[224ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- |
| | |
| -------------- | -------------
v v v v
------------------- -----------------
| BRAND INDEPENDENT | | BRAND DEPENDENT |
| OFFER | | OFFER |
------------------- -----------------
| |
| |
| |
| -------------------
v v
--------- --------------
| PAYMENT | | PAYMENT WITH |
| (first) | | DELIVERY |
--------- --------------
|
----------------
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {second)| |
---------- --------- |
|
-----------------> STOP
始め----------------------------------------------------- | v| ---------------- | | 認証| | ---------------- -------------------------------------- | | | | | -------------- | ------------- v対vに------------------- ----------------- | ブランド独立者| | ブランド扶養家族| | 申し出| | 申し出| ------------------- ----------------- | | | | | | | ------------------- vに対して--------- -------------- | 支払い| | 支払い| | (最初に) | | 配送| --------- -------------- | ---------------- | ---------- --------- | | 配送| | 支払い| | | | | {second)| | ---------- --------- | | -----------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 28 Baseline Withdrawal IOTP Transaction
図28 基線退出IOTPトランザクション
Note that:
以下のことに注意してください。
o a Merchant (Financial Institution) may be able to offer withdrawal
of several different types of electronic cash. In practice usually
only one form of electronic cash may be offered. However, there
may be several different protocols which may be used for the same
"brand" of electronic cash.
o マーチャント(財政的なInstitution)はいくつかの異なったタイプの電子現金の退出を提供できるかもしれません。 通常、実際には、1つの形式の電子現金だけを提供するかもしれません。 しかしながら、電子現金の同じ「ブランド」に使用されるかもしれないいくつかの異なったプロトコルがあるかもしれません。
Burdett Informational [Page 225] RFC 2801 IOTP/1.0 April 2000
バーデット[225ページ]情報のRFC2801IOTP/2000年4月1日
o the Merchant (Financial Institution) may use the results of the
authentication to identify not only the consumer but also the
account from which the withdrawal is to be made. If no single
account can be identified, then it must be obtained by other
means. For example:
o マーチャント(財政的なInstitution)は、消費者だけではなく、作られる退出がことであるアカウントも特定するのに認証の結果を使用するかもしれません。 どんなただ一つのアカウントも特定できないなら、他の手段でそれを得なければなりません。 例えば:
- the consumer could specify the account number prior to the
Baseline Withdrawal IOTP Transaction starting, or
- または消費者がBaseline Withdrawal IOTP Transaction始めの前に口座番号を指定できた。
- the consumer could have been identified earlier, for example
using a Baseline Authentication IOTP Transaction, and an
account selected from a list provided by the Financial
Institution.
- 消費者は、より早く特定されたかもしれません、例えば、Baseline Authentication IOTP Transaction、およびFinancial Institutionによって提供されたリストから選択されたアカウントを使用して。
o a Baseline Withdrawal without an authentication might be used:
o 認証のないBaseline Withdrawalは使用されるかもしれません:
- if a previous IOTP transaction, for example a Baseline Deposit
or a Baseline Authentication, authenticated the consumer, and a
secure channel has been maintained, therefore the authenticity
of the consumer is known
- 前のIOTPトランザクション(例えば、Baseline DepositかBaseline Authentication)が消費者を認証して、安全なチャンネルが維持されて、したがって、消費者の信憑性が知られているなら
- if authentication is achieved as part of a proprietary payment
protocol and is therefore included in the Payment Document
Exchange
- 認証が独占支払いプロトコルの一部として達成されて、したがって、Payment Document Exchangeに含まれているなら
- if authentication of the consumer has been achieved by some
other means, for example, by using a pass phrase, or a
proprietary banking software solution.
- 例えば、消費者の認証がパス句、または独占銀行業ソフトウェアソリューションを使用することによってある他の手段で達成されたなら。
9.1.11 Baseline Value Exchange IOTP Transaction
9.1.11 基礎値交換IOTPトランザクション
The Baseline Value Exchange Transaction uses Payment Document Exchanges to support the exchange of value in one currency obtained using one payment method with value in the same or another currency using the same or another payment method. Examples of its use include:
Baseline Value Exchange Transactionは、1の価値の交換が同じくらいの値か別の通貨が同じくらい使用している1つの支払い方法を使用することで入手された通貨か別の支払い方法であるとサポートするのにPayment Document Exchangesを使用します。 使用に関する例は:
o electronic cash advance on a credit card. For example the first
payment could be a "dollar SET Payment" using a credit card with
the second payment being a download of Visa Cash e-cash in
dollars.
o クレジットカードにおける電子現金進歩。 例えば、最初の支払いはドルで、Visa Cash電子通貨のダウンロードである2番目の支払いと共にクレジットカードを使用する「ドルセット支払い」であるかもしれません。
o foreign exchange using the same payment method. For example the
payment could be an upload of Mondex value in British Pounds and
the second a download of Mondex value in Euros
o 同じ支払い方法を使用する外為。 例えば、支払いは英国ポンドで、モンデックス価値のアップロードであるかもしれなく、2番目はユーロがモンデックス価値のダウンロードです。
Burdett Informational [Page 226] RFC 2801 IOTP/1.0 April 2000
バーデット[226ページ]情報のRFC2801IOTP/2000年4月1日
o foreign exchange using different payment methods. For example the
first payment could be a SET payment in Canadian Dollars followed
a download of GeldKarte in Deutchmarks.
o 異なった支払い方法を使用する外為。 例えば、最初の支払いはカナダドルにおけるSET支払いがDeutchmarksのGeldKarteのダウンロードに続いたということであるかもしれません。
The Baseline Value Exchange uses the following Document Exchanges:
Baseline Value Exchangeは以下のDocument Exchangesを使用します:
o an optional Authentication Document Exchange (see section 9.1.1)
o 任意のAuthentication Document Exchange(セクション9.1.1を見ます)
o an Offer Document Exchange (see section 9.1.2), which provides
details of what values and currencies will be exchanged, and
o そしてどんな値と通貨を交換するかに関する詳細を明らかにするOffer Document Exchange(セクション9.1.2を見る)。
o two Payment Document Exchanges (see section 9.1.3) which carry out
the two payments involved.
o かかわった2つの支払いを行う2Payment Document Exchanges(セクション9.1.3を見ます)。
The way in which these Document Exchanges may be combined together is illustrated by the diagram below.
これらのDocument Exchangesが一緒に結合されるかもしれない方法は以下のダイヤグラムで例証されます。
Burdett Informational [Page 227] RFC 2801 IOTP/1.0 April 2000
バーデット[227ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- |
| | |
| -------------- | -------------
v v v v
------------------- -----------------
| BRAND INDEPENDENT | | BRAND DEPENDENT |
| OFFER | | OFFER |
------------------- -----------------
| |
| |
| |
| -------------------
v v
--------- --------------
| PAYMENT | | PAYMENT WITH |
| (first) | | DELIVERY |
--------- --------------
|
----
v
---------- ---------
| DELIVERY | | PAYMENT |
| | | {second)|
---------- ---------
|
-----------------------------> STOP
始め----------------------------------------------------- | v| ---------------- | | 認証| | ---------------- -------------------------------------- | | | | | -------------- | ------------- v対vに------------------- ----------------- | ブランド独立者| | ブランド扶養家族| | 申し出| | 申し出| ------------------- ----------------- | | | | | | | ------------------- vに対して--------- -------------- | 支払い| | 支払い| | (最初に) | | 配送| --------- -------------- | ---- v---------- --------- | 配送| | 支払い| | | | {second)| ---------- --------- | -----------------------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 29 Baseline Value Exchange IOTP Transaction
図29 基礎値交換IOTPトランザクション
Burdett Informational [Page 228] RFC 2801 IOTP/1.0 April 2000
バーデット[228ページ]情報のRFC2801IOTP/2000年4月1日
The Baseline Value Exchange IOTP Transaction occurs in two basic forms:
Baseline Value Exchange IOTP Transactionは2つの基本的なフォームに起こります:
o Brand Dependent Value Exchange. Where the content of the offer,
for example the rate at which one form of value is exchanged for
another, is dependent on the payment brands and protocols selected
by the consumer, and
o 依存する値に交換と商標を付けてください。 そして申し出の内容(例えば、価値形態が別のものと交換されるレート)が消費者によって選択された支払いブランドとプロトコルに依存しているところ。
o Brand Independent Value Exchange. Where the content of the offer
is not dependent on the payment brands and protocols selected.
o 独立している値に交換と商標を付けてください。 申し出の内容がブランドとプロトコルが選択した支払いに依存していないところ。
Note: In the above the role is a Merchant even though the Organisation carrying out the Value Exchange may be a Bank or some other Financial Institution. This is because the Bank is acting as a merchant in that they are making an offer which the Consumer can either accept or decline.
以下に注意してください。 上記では、Value Exchangeを行うOrganisationはBankかある他のFinancial Institutionであるかもしれませんが、役割はマーチャントです。 これは彼らがConsumerがそうすることができる申し出が受け入れるか、またはお断りするのをさせているのでBankが商人として務めているからです。
The TPO Block and Offer Response Block may only be combined into the same IOTP Message if the content of the Offer Response Block does not change as a result of selecting the payment brands and payment protocols to be used in the Value Exchange.
支払いブランドと支払いプロトコルがValue Exchangeで使用されるのを選択することの結果、Offer Response Blockの内容が変化しない場合にだけ、TPO BlockとOffer Response Blockは同じIOTP Messageに結合されるかもしれません。
BASELINE VALUE EXCHANGE SIGNATURES
基礎値交換署名
The use of signatures to ensure the integrity of a Baseline Value Exchange is illustrated by the diagram below.
Baseline Value Exchangeの保全を確実にする署名の使用は以下のダイヤグラムで例証されます。
Burdett Informational [Page 229] RFC 2801 IOTP/1.0 April 2000
バーデット[229ページ]情報のRFC2801IOTP/2000年4月1日
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Signature generated IotpMsg (TPO)
by Merchant ensures - Trans Ref Block
integrity of the Offer --------> - - Signature Block
| - TPO Block MERCHANT
| - Offer Response Block
|
Signature generated by |
the Payment Handler of | IotpMsg (Pay Resp 1)
the first payment binds | - Trans Ref Block PAYMENT
Pay Receipt for the first -----> -> - Signature Block ----- HANDLER
payment to the Offer - Pay Response Block 1 | 1
|
Signature generated by |
the Payment Handler of IotpMsg (Pay Resp 2) | PAYMENT
the second payment binds - Trans Ref Block | HANDLER
the second payment to the -----> - Signature Block <------ 2
first payment and therefore - Pay Response Block 2
to the Offer
マーチャントによる発生しているIotpMsg(TPO)が確実にする署名--Offerの移-Ref Block保全-------->----署名欄| - TPOブロックの商人| - 申し出応答ブロック| 生成された署名| 支払い操作者| 最初の支払いが縛るIotpMsg(Resp1を支払います)| - 1番目のための移-Ref Block PAYMENT Pay Receipt----->->--署名欄----- OfferへのHANDLER支払い--Response Block1を支払ってください。| 1 | 生成された署名| IotpMsg(Resp2を支払う)の支払い操作者| 2番目の支払いが縛るPAYMENT--移-Ref Block| HANDLER、支払いを配置替えします。----->--署名欄<。------ 2、最初の支払い、したがって、Response Block2をOfferに支払ってください。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 30 Baseline Value Exchange Signatures
図30 基礎値交換署名
9.1.12 Valid Combinations of Document Exchanges
9.1.12 ドキュメント交換の有効な組み合わせ
The following diagram illustrates the data conditions in the various IOTP messages which can be used by a Consumer Trading Role to determine whether the combination of Document Exchanges are valid.
以下のダイヤグラムはConsumer Trading RoleがDocument Exchangesの組み合わせが有効であるかどうか決定するのに使用できる様々なIOTPメッセージのデータ状態を例証します。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
START
|
v
Auth Request Block in =TRUE
first IOTP Message ? ---------------------------------------
| = FALSE |
v v
Offer Response Block in ----------------
first IOTP Message ? | AUTHENTICATION |
|=TRUE |=FALSE ----------------
| | |
| | v
始め| =TRUE最初のIOTP MessageのAuth Request Blockに対して? --------------------------------------- | = 誤る| 中のv Offer Response Blockに対して---------------- 最初に、IOTP Message? | 認証| |=本当|=誤る---------------- | | | | | v
Burdett Informational [Page 230] RFC 2801 IOTP/1.0 April 2000
バーデット[230ページ]情報のRFC2801IOTP/2000年4月1日
| ---------------------- TPO & Offer Response
------------- | Blocks in last IOTP Msg
| | |=TRUE |=FALSE
| | | v
| ------------- | ---- TPO Block only if
| | | last IOTP Message
| | | of Authentication
| | | |=TRUE |=FALSE
v v v v |
------------------- ----------------- |
| BRAND INDEPENDENT | | BRAND DEPENDENT | |
| OFFER | | OFFER | |
------------------- ----------------- |
| | |
v v |
Offer Response Block contains |
Delivery Component ? |
|=FALSE |=TRUE |
--- v |
| Value of DelivAndPayResp |
| attribute of Delivery Component ? |
| |=FALSE |=TRUE |
| | | |
v v v |
--------- -------------- |
| PAYMENT | | PAYMENT WITH | |
| (first) | | DELIVERY | |
--------- -------------- |
| | |
v | |
Offer and Response Block contains -------------->|
Delivery Component ? |
|=TRUE |=FALSE |
| v |
| Two Payment Components |
| present in Offer Response Block? |
| |=TRUE |=FALSE |
v v | |
---------- --------- | |
| DELIVERY | | PAYMENT | | |
| | | {second)| | |
---------- --------- | |
| | | v
----------------------------------------------> STOP
| ---------------------- TPOと申し出応答------------- | 最後のIOTPエムエスジーにおけるブロック| | |=本当|=誤る| | | v| ------------- | ---- TPO Block専用| | | 最後のIOTP Message| | | 認証について| | | |=本当|=FALSE v対v v| ------------------- ----------------- | | ブランド独立者| | ブランド扶養家族| | | 申し出| | 申し出| | ------------------- ----------------- | | | | vに対して| Response Blockが含む申し出| 配送コンポーネント? | |=誤る|=本当| --- v| | DelivAndPayRespの値| | Delivery Componentの属性? | | |=誤る|=本当| | | | | v vに対して| --------- -------------- | | 支払い| | 支払い| | | (最初に) | | 配送| | --------- -------------- | | | | v| | 申し出とResponse Blockは含んでいます。-------------->| 配送コンポーネント? | |=本当|=誤る| | v| | 2つの支払いコンポーネント| | Offer Response Blockでは、存在していますか? | | |=本当|=誤る| vに対して| | ---------- --------- | | | 配送| | 支払い| | | | | | {second)| | | ---------- --------- | | | | | v ----------------------------------------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 31 Valid Combinations of Document Exchanges
図31 ドキュメント交換の有効な組み合わせ
Burdett Informational [Page 231] RFC 2801 IOTP/1.0 April 2000
バーデット[231ページ]情報のRFC2801IOTP/2000年4月1日
1) If first IOTP Message of an IOTP Transaction contains an
Authentication Request then:
1) 最初に、IOTP TransactionのIOTP Messageがその時Authentication Requestを含むなら:
a) IOTP Transaction includes an Authentication Document Exchange
(see section 9.1.1). (Note 1)
a) IOTP TransactionはAuthentication Document Exchangeを含んでいます(セクション9.1.1を見てください)。 (注意1)
b) If the last IOTP Message of the Authentication Document
Exchange includes a TPO Block and an Offer Response Block then:
b) Authentication Document Exchangeの最後のIOTP Messageがその時TPO BlockとOffer Response Blockを含んでいるなら:
i) IOTP Transaction includes a Brand Independent Offer Document
Exchange (see section 9.1.2.2). (Note 2)
i) セクション9.1を見てください。IOTP TransactionがBrand無党派Offer Document Exchangeを含んでいる、(.2 .2)。 (注意2)
c) Otherwise, if the last IOTP Message of the Authentication
Exchange includes a TPO Block but NO Offer Response Block,
then:
c) TPO Blockを含んでいますが、次に、Authentication Exchangeの最後のIOTP Messageが別の方法でどんなOffer Response Blockも含んでいないなら:
i) IOTP Transaction includes a Brand Dependent Offer Document
Exchange (see section 9.1.2.1). (Note 2)
i) セクション9.1を見てください。IOTP TransactionがBrand Dependent Offer Document Exchangeを含んでいる、(.2 .1)。 (注意2)
d) Otherwise (Authentication Status IOTP Message of the
Authentication Document Exchange contains neither a TPO Block
but nor an Offer Response Block)
d) そうではありませんまたは、しかし、(Authentication Document Exchangeの認証Status IOTP MessageがどちらもTPO Blockを含んでいない、Offer Response Block)
i) IOTP Transaction consists of just an Authentication Document
Exchange. (Note 3)
i) IOTP TransactionはまさしくAuthentication Document Exchangeから成ります。 (注意3)
2) Otherwise (no Authentication Request in first IOTP Message):
2) そうでなければ、(最初に、IOTP MessageでAuthentication Requestがありません):
e) IOTP Transaction does not include an Authentication Document
Exchange (Note 2)
e) IOTP TransactionはAuthentication Document Exchangeを含んでいません。(注意2)
f) If first IOTP Message contains an Offer Response Block, then:
f) 次に、最初に、IOTP MessageがOffer Response Blockを含んでいるなら:
i) the IOTP Transaction contains a Brand Independent Offer
Document Exchange (Note 2)
i) IOTP TransactionはBrand無党派Offer Document Exchangeを含んでいます。(注意2)
g) Otherwise (no Offer Response Block in first IOTP Message):
g) そうでなければ、(最初に、IOTP MessageでOffer Response Blockがありません):
i) the IOTP Transaction includes a Brand Dependent Offer
Document Exchange (Note 2)
i) IOTP TransactionはBrand Dependent Offer Document Exchangeを含んでいます。(注意2)
3) If an Offer Response Block exists in any IOTP message then:
3) Offer Response Blockがその時どんなIOTPメッセージにも存在するなら:
h) If the Offer Response Block contains a Delivery Component then:
h) Offer Response Blockがその時Delivery Componentを含むなら:
i) If the DelivAndPayResp attribute of the Delivery Component
is set to True, then:
i) 次に、Delivery ComponentのDelivAndPayResp属性がTrueに設定されるなら:
Burdett Informational [Page 232] RFC 2801 IOTP/1.0 April 2000
バーデット[232ページ]情報のRFC2801IOTP/2000年4月1日
(1) the IOTP Transaction consists of a Payment And Delivery
Document Exchange (see section 9.1.5) (Note 4)
(1) IOTP TransactionはPayment And Delivery Document Exchangeから成ります(セクション9.1.5を見てください)。(注意4)
ii) otherwise (the DelivAndPayResp attribute of the Delivery
Component is set to False)
ii) そうでなければ(Delivery ComponentのDelivAndPayResp属性はFalseに設定されます)
(1) the IOTP Transaction consists of a Payment Document
Exchange (see section 9.1.3) followed by a Delivery
Document Exchange (see section 9.1.4) (Note 4)
(1) IOTP TransactionはDelivery Document Exchangeによって続かれたPayment Document Exchange(セクション9.1.3を見る)から成ります(セクション9.1.4を見てください)。(注意4)
i) otherwise (the Offer Response Block does not contain a Delivery
Component)
i) そうでなければ(Offer Response BlockはDelivery Componentを含んでいません)
i) if the Offer Response Block contains just one Payment
Component, then:
次に、i)はOffer Response Blockであるならちょうど1Payment Componentを含んでいます:
(1) the IOTP Transaction contains just one Payment Document
Exchange (Note 5)
(1) IOTP Transactionはちょうど1Payment Document Exchangeを含んでいます。(注意5)
ii) if the Offer Response Block contains two Payment Components,
then:
次に、ii)はOffer Response Blockであるなら2Payment Componentsを含んでいます:
(1) the IOTP Transaction contains two Payment Document
Exchanges. The StartAfter attribute of the Payment
Components is used to indicate which payment occurs
first (Note 6)
(1) IOTP Transactionは2Payment Document Exchangesを含んでいます。 Payment ComponentsのStartAfter属性は、どの支払いが最初に起こるかを示すのに使用されます。(注意6)
iii) if the Offer Response Block contains no or more than two
Payment Components, then there is an error
iii) Offer Response Blockがいいえか2Payment Componentsを含んでいるなら、誤りがあります。
4) Otherwise (no Offer Response Block) there is an error.
4) さもなければ(Offer Response Blockがない)、誤りがあります。
The following table indicates the types of IOTP Transactions which can validly have the conditions indicated above.
以下のテーブルは確実に上で示された状態を持つことができるIOTP Transactionsのタイプを示します。
Note IOTP Transaction Validity
注意IOTPトランザクションの正当性
1. Any Payment and Authentication IOTP Transaction
1. どんな支払いと認証IOTPトランザクション
2. Any Payment and Authentication IOTP Transaction except Baseline
Authentication
2. どんな支払いと基線認証以外の認証IOTPトランザクション
3. Either Baseline Authentication, or a Baseline Purchase, Refund,
Deposit, Withdrawal or Value Exchange with a failed Authentication
3. 失敗したAuthenticationとBaseline Authentication Baseline Purchase、Refund、Deposit、WithdrawalまたはValue Exchangeのどちらか
4. Baseline Purchase only
4. 基線Purchase専用
5. Baseline Purchase, Refund, Deposit or Withdrawal
5. 基線購買、還付、預金または退出
Burdett Informational [Page 233] RFC 2801 IOTP/1.0 April 2000
バーデット[233ページ]情報のRFC2801IOTP/2000年4月1日
6. Baseline Value Exchange only
6. 基線Value Exchange専用
9.1.13 Combining Authentication Transactions with other Transactions
9.1.13 他のTransactionsにAuthentication Transactionsを結合すること。
In the previous sections an Authentication Document Exchange is shown preceding an Offer Document Exchange as part of a single IOTP Transaction with the same IOTP Transaction Id.
前項で、Authentication Document Exchangeは同じIOTP Transactionアイダホ州と共に独身のIOTP Transactionの一部としてOffer Document Exchangeに先行するのが示されます。
It is also possible to run a separate Authentication Transaction at any point, even in parallel with another IOTP Transaction. Typically this will be used:
また、任意な点で別のIOTP Transactionと平行してさえ別々のAuthentication Transactionを実行するのも可能です。 通常、これは使用されるでしょう:
o by a Consumer to authenticate a Merchant, Payment Handler or a
Delivery Handler, or
o またはマーチャント、Payment HandlerまたはDelivery Handlerを認証するConsumerで。
o by a Payment Handler or Delivery Handler to authenticate a
Consumer.
o Consumerを認証するPayment HandlerかDelivery Handler。
In outline the basic process consists of:
アウトラインでは、塩基性製鋼法は以下から成ります。
o the Trading Role that decides it wants to carry out an
authentication of another role suspends the current IOTP
transaction being carried out
o 別の役割の認証を行いたがっていると決めるTrading Roleは行われる現在のIOTPトランザクションを中断させます。
o a stand-alone Authentication transaction is then carried out. This
may, at implementer's option, be linked to the original IOTP
Transaction using a Related To Component (see section 3.3.3) in
the Transaction Reference Block.
o そして、スタンドアロンのAuthenticationトランザクションが行われます。 implementerの選択では、これは、オリジナルのIOTP TransactionにTransaction Reference Blockで関連To Component(セクション3.3.3を見る)を使用することでリンクされるかもしれません。
o if the Authentication transaction is successful, then the original
IOTP Transaction is restarted
o Authenticationトランザクションがうまくいくなら、オリジナルのIOTP Transactionは再開されます。
o if the Authentication fails then the original IOTP Transaction is
cancelled.
o Authenticationが失敗するなら、オリジナルのIOTP Transactionは取り消されます。
For example, a Consumer could:
例えば、Consumerはそうすることができました:
o authenticate the Payment Handler for a Payment between receiving
an Offer Response from a Merchant and before sending the Payment
Request to that Payment Handler
o マーチャントからOffer Responseを受けることの間とそのPayment HandlerにPayment Requestを送る前に、PaymentのためにPayment Handlerを認証してください。
o authenticate a Delivery Handler for a Delivery between receiving
the Payment Response from a Payment Handler and before sending the
Delivery Request
o Payment HandlerからPayment Responseを受けることの間とDelivery Requestを送る前に、DeliveryのためにDelivery Handlerを認証してください。
A Payment Handler could authenticate a Consumer after receiving the Payment Request and before sending the next Payment related message.
Payment Requestを受けた後と次のPaymentの関連するメッセージを送る前に、Payment HandlerはConsumerを認証できました。
Burdett Informational [Page 234] RFC 2801 IOTP/1.0 April 2000
バーデット[234ページ]情報のRFC2801IOTP/2000年4月1日
A Delivery Handler could authenticate a Consumer after receiving the Delivery Request and before sending the Delivery Response.
Delivery Requestを受けた後とDelivery Responseを送る前に、Delivery HandlerはConsumerを認証できました。
Note: Some Payment Methods may carry out an authentication within the Payment Exchange. In this case the information required to carry out the authentication will be included in Payment Scheme Components.
以下に注意してください。 いくつかのPayment MethodsがPayment Exchangeの中で認証を行うかもしれません。 この場合、認証を行うのに必要である情報はPayment Scheme Componentsに含まれるでしょう。
In this instance IOTP aware application will not be aware that an authentication has occurred since the Payment Scheme Components that contain authentication request information will be indistinguishable from other Payment Scheme Components.
この場合アプリケーションが認証を含むPayment Scheme Componentsが情報を要求するので認証が起こったのを意識しないのを意識しているIOTPは他のPayment Scheme Componentsから区別がつかなくなるでしょう。
9.2 Infrastructure Transactions
9.2 インフラストラクチャトランザクション
Infrastructure Transactions are designed to support inquiries about whether or not a transaction has succeeded or a Trading Role's servers are operating correctly. There are two types of transaction:
インフラストラクチャTransactionsは、トランザクションが成功したか、またはTrading Roleのサーバが正しく作動するかどうかに関する問い合せをサポートするように設計されています。 トランザクションの2つのタイプがあります:
o a Transaction Status Inquiry Transaction which provides
information on the status of an existing or complete IOTP
transaction, and
o そして存在か完全なIOTPトランザクションの状態の情報を提供するTransaction Status Inquiry Transaction。
o Ping Transaction that enables one IOTP aware application to
determine if the IOTP aware application at another Trading Role is
operating and verify whether or not signatures can be handled.
o 1つのIOTPの意識しているアプリケーションが、別のTrading RoleのIOTPの意識しているアプリケーションが作動しているかどうか決定するのを可能にするTransactionを確認してください、そして、署名を扱うことができるかどうか確かめてください。
Each of these is described below
それぞれのこれらは以下で説明されます。
9.2.1 Baseline Transaction Status Inquiry IOTP Transaction
9.2.1 基線トランザクション資産調査IOTPトランザクション
The Baseline IOTP Transaction Status Inquiry provides information on the status of an existing or complete IOTP transaction.
Baseline IOTP Transaction Status Inquiryは存在か完全なIOTPトランザクションの状態の情報を提供します。
The Trading Blocks used by the Baseline Transaction Status Inquiry Transaction are:
Baseline Transaction Status Inquiry Transactionによって使用されたTrading Blocksは以下の通りです。
o an Inquiry Request Trading Block (see section 8.12),
o Inquiry Request Trading Block(セクション8.12を見ます)
o an Inquiry Response Trading Block (see section 8.13)
o 問い合せ応答通商圏(セクション8.13を見ます)
o an optional Signature Block (see section 8.16).
o 任意のSignature Block(セクション8.16を見ます)。
The Inquiry IOTP Transaction can be used for a variety of reasons. For example:
さまざまな理由にInquiry IOTP Transactionを使用できます。 例えば:
o to help in resuming a suspended transaction to determine the
current state of processing of one of the other roles,
o 吊したトランザクションを再開する際に他の役割の1つの処理の現状を決定するのを助けるために
Burdett Informational [Page 235] RFC 2801 IOTP/1.0 April 2000
バーデット[235ページ]情報のRFC2801IOTP/2000年4月1日
o for a merchant to determine if a payment, delivery, etc., was
completed. For example, a Consumer might claim that payment was
made but no signed IOTP payment receipt was available to prove it.
If the Merchant makes an inquiry of the Payment Handler then the
Merchant can determine whether or not payment was made.
o 商人が確認するように、支払い、配送などは完成しました。 例えば、Consumerは、支払いが済んだと主張するかもしれませんが、どんな署名しているIOTP支払い領収書も、それを立証するために利用可能ではありませんでした。 マーチャントがPayment Handlerへの問い合せをするなら、マーチャントは、支払いが済んだかどうかと決心できます。
Note: Inquiries on Baseline Ping IOTP Transactions (see section 9.2.2) are ignored.
以下に注意してください。 Baseline Ping IOTP Transactions(セクション9.2.2を見る)における問い合せは無視されます。
MAKING INQUIRIES OF ANOTHER TRADING ROLE
別の取り引き役割について問い合わせること。
One Trading Role may make an inquiry of any other Trading Role at any point in time.
1Trading Roleが時間内に、任意な点でいかなる他のTrading Roleへの問い合せもするかもしれません。
IOTP aware software that supports the Consumer Trading Role may not:
Consumer Trading RoleをサポートするIOTPの意識しているソフトウェアはそうしないかもしれません:
o digitally sign a response if requested, since it may not have the
capability, or
o または要求されるならそれには能力がないかもしれないので応答にデジタルに署名してください。
o respond to an Inquiry Request at all since it may not be on-line,
or may consider that the request is not reasonable since, for
example, the Request was not digitally signed.
o 例えば、Requestがデジタルに署名されなかったので要求が合理的でないことがオンラインでないかもしれない、または考えるかもしれないので、全くInquiry Requestに応じてください。
As a guideline:
ガイドラインとして:
o the Consumer should send a Transaction Status Inquiry Block to a
Trading Role only after the following events have occurred:
o 以下のイベントが起こった後にだけConsumerはTransaction Status Inquiry BlockをTrading Roleに送るはずです:
- to the Merchant, after sending a TPO Selection Block,
- TPO Selection Blockを送った後のマーチャントに
- to the Payment Handler, after sending a Payment Request Block,
- Payment Request Blockを送った後のPayment Handlerに
- to the Delivery Handler, after sending a Delivery Request Block,
- Delivery Request Blockを送った後のDelivery Handlerに
o other Trading Roles should send a Transaction Status Inquiry Block
to the Consumer only after receiving a message from the Consumer
and before sending the final "Response" message to the Consumer
o 他のTrading Rolesは、Consumerと最終的な「応答」メッセージをConsumerに送る前にメッセージを受け取りながら、ConsumerへのTransaction Status Inquiry Blockについて伝言を伝えるだけであるはずです。
一覧
スポンサーリンク
