Network Working Group D. Burdett
Request for Comments: 2801 Commerce One
Category: Informational April 2000
Internet Open Trading Protocol - IOTP
Version 1.0
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
インターネットオープン取引プロトコル（IOTP）インターネット商取引のための相互運用可能なフレームワークを提供します。これは、独立した決済システムであり、そのようなSET等のセキュリティで保護されたチャネルクレジット/デビット、モンデックス、サイバーコイン、ゲルトカルテ、と決済システムをカプセル化IOTPは、ショッピングサイト、支払ハンドラの配達ハンドラなどの商人の役割ケースを処理することができます商品やサービス、および顧客サポートの提供は、異なる当事者によってまたは一方の当事者によって実行されています。
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
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
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
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
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
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
IDの図1 IOTPトレーディングロール16図2オファー取引19図3支払い取引22図4配信所25、図5の認証交換27図6 IOTPメッセージ構造33図7アンIOTPトランザクション34図8使用例46の図9要素参照属性10署名が12 87図13は、配信ハンドラを確認支払いハンドラが支払いを行うことができるチェックベースライン購入81図のための署名の79、図11の例の使用を消化48図は、配達90、図14トレーディング・コンポーネント94、図15ブランドのリスト要素を実行することができ関係113図16のトレーディングブロック164、図17のお支払いと認証メッセージフローの組み合わせ187、図18の認証文書の交換190図19ブランド依存オファー文書交換196図20ブランドの独立オファー取引所198図21支払いドキュメント取引所204、図22の配信文書交換210図23支払いと配達ドキュメント取引所214、図24のベースラインAuthenticaンIOTPトランザクション217、図25のベースラインデポジットがIOTPトランザクション219、図26のベースライン購入IOTPトランザクション221、図27のベースライン払い戻しIOTPトランザクション223、図28のベースライン離脱IOTPトランザクション225、図29のベースライン値のExchange IOTPトランザクション228、図30のベースライン値のExchange署名230、図31の有効文書交換の組み合わせ231、図32のベースラインの取引状況照会238の図33のベースラインpingメッセージ242
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.
インターネットオープン取引プロトコル（IOTP）インターネット商取引のための相互運用可能なフレームワークを提供します。これは、独立した決済システムであり、そのようななどSET、モンデックス、サイバーキャッシュ、デジキャッシュ、ゲルトカルテ、などの決済システムIOTPは、ショッピングサイト、支払ハンドラ、商品またはサービスの配達ハンドラなどの商人の役割ケースを処理することができますをカプセル化し、および顧客サポートの提供は、異なる当事者によってまたは一方の当事者によって実行されています。
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が開発された理由の背景を提供します。仕様自体は、次の章で開始します。
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.
インターネットの成長と電子商取引の出現は、社会、政治、政府内で、世界中の巨大な変化をもたらす、ビジネスでされています。取引パートナーが支配され、商取引を行い、通信する方法が充実し、永遠に変更されました。
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が関係しているかについて非常に根本的な変化の一つは、消費者や商人の貿易の方法で行われています。著しく変化している取引の特徴は次のとおりです。
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認証：個人的な存在の重要な部分は、彼らがあると主張する者であることを確認するためにおなじみのオブジェクトとの対話を使用するために、当事者の能力です。売り手は、購入の支払い部分に広く使われているクレジットカードやデビット楽器を受け入れるために彼の能力を諳誦する一つまたはいくつかのよく知られた金融のロゴが表示されます。買い手は、彼女が支払われる販売者を確保し、政府や金融機関の識別をもたらします。人々は、認証の正式な手段を強化するために、このような個人的な外観や行動、店の場所、商品のブランドと見かけの品質と親しみやすさ、そして目で良いクリアな表情などの無形資産を使用しています。
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配信：配信の新モードは、このような直接的な電子配信として対応しなければなりません。領収書が確認される手段と、商品やサービスが極端に低い配信コストを持っていますが、実際には非常に高い値を有することができる劇的に支払い変更の実行。または、多分値は高くありませんが、配達が発生すると値が、支払いが確定し、返金不可でなければならないので、取り返しのつかないほど配信されますが、配信はそれにもかかわらず、まだ入金する前に確認する必要があります。そのようなリスニングや時間の表示や再生時間などの増分配信は、仮想世界で多少異なる動作する他のモデルです。
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.
電子商取引ソフトウェアベンダーは、彼らが他のベンダーのソフトウェアと相互運用されますように、より魅力的であるEコマース製品を開発することができるようになります。 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:
商人のためのいくつかの利点があります。
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:
銀行および金融機関のためのいくつかの利点もあります。
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
- 新しい支払いと預金を処理することから手数料 - 商人のための顧客ケアを提供
o they have an opportunity to build relationships with new types of merchants
O彼らは商人の新しいタイプとの関係を構築する機会を持っています
CUSTOMERS
顧客
For Customers there are several benefits:
お客様のためにいくつかの利点があります。
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例えば、使用することができ、そのトランザクションの記録は、会計システムに供給したり、潜在的に、税務当局に提示することがあります
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.
この仕様は、ベースラインIOTPです。それは例の購入と払い戻しのために、最も一般的なインターネット上の取引を行うための方法を含んでいることでベースラインです。
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.
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.
この期間中には、問題が検出された修正に限定されるものでは変更のみで、この仕様の範囲には変更がないことが予想されます。ソフトウェアソリューションは、（例えば、バージョンのバージョン1.0の0.9初期の1998年に出版され、それ以前のリビジョンが1999年に発行）IOTPが動作することを証明したこの仕様の以前のバージョンに基づいて開発されています。
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.
このドキュメントの目的は、インターネットのオープン・トレーディング・プロトコルを使用して、インターネット上の電子取引をサポートするシステムを設計し、実装するために使用することができ、インターネットのオープン・トレーディングプロトコルのバージョン1.0の仕様を提供することです。
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電流または開発支払制度のいずれか、今では商人の顧客ベースで使用または検討されています
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.
それは受取人への支払人からの電子バリューの動きが取引を完了するために、関与している可能性がある多くの唯一の、しかし重要なステップである完全な購入プロセスを対象とするので、プロトコルは任意の電子決済スキームに適用できるように設計されています。
Payment Scheme which IOTP could support include MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton, etc.
IOTPがサポートできる支払制度等MasterCardのクレジットカード、ビザクレジット、モンデックス現金、ビザ現金、ゲルトカルテ、eCashの、サイバーコイン、ミリセント、プロトンを含み、
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.
この文書はまた、プロトコルまたはそれらを使用する情報システムの実現を取り巻くあらゆる法的または規制上の問題に対処しません。
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が提供するメリットについての簡単な背景を提供します。
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 - はじめに：このセクションでは、さまざまな取引の交流を説明し、これらの取引交換はIOTPトランザクションを構築するために使用されている方法を示しています。このセクションでは、電子取引に参加する様々な取引の役割を説明します。
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取引のための基本的なビルディング・ブロックであること貿易ブロックと取引コンポーネントを使用して構築されている方法をまとめたものです。すべての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は、デジタル署名を使用する方法の概要を提供します。どのように署名をチェックするためには、正しく計算されており、必要なときにどのように取引に参加し、様々な取引の役割は、署名を確認する必要があります。
o Section 7 - Trading Components: This section defines the XML elements required by Trading Components.
Oセクション7 - 取引コンポーネント：このセクションでは、取引コンポーネントで必要とされるXML要素を定義します。
o Section 8 - Trading Blocks: This section describes how Trading Blocks are constructed from Trading Components.
Oセクション8 - 貿易ブロック：このセクションでは、貿易ブロックが取引のコンポーネントから構成されている方法を説明します。
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ベースラインの取引について説明します。それは貿易ブロックと取引コンポーネントと署名を指します。このセクションでは、直接プロトコル交換時のエラー処理をリンクしない、読者は、このセクションを読む前のセクションで定義されたエラー処理を理解することをお勧めします。
o Section 10 - Retrieving Logos: This section describes how IOTP specific logos can be retrieved.
Oセクション10 - 取得ロゴス：このセクションでは、IOTP特定のロゴを取得できる方法を説明します。
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 - ブランド：このセクションでは、用意されています。消費者は商人によって提供されたリストからブランドを選択する方法について説明ブランドの定義やブランド選択の概要;同様にブランドのリストのいくつかの例として。
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データ型の定義が含まれています。
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 - 完全な著作権声明
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.
ソフトウェアとハードウェアの開発者。開発アナリスト。ビジネスおよび技術プランナー。業界アナリスト、商人;銀行や他の支払ハンドラ。支払プロトコルの所有者、カストディアン、およびユーザー。
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の原則を理解したい人を対象としたシーケンスで構成されています。しかし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のエラー処理
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
The Internet Open Trading Protocols (IOTP) define a number of different types of IOTP Transactions:
インターネットのオープン・トレーディング・プロトコル（IOTP）IOTP取引の異なる種類の数を定義します。
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払い戻し。これは、一般的に、以前の購入の結果として、支払いの払い戻しをサポートしています
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取引の状況に関する問い合わせをサポートしています
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平。これは、他の場所で実行している別のIOTPアプリケーションが動作しているかどうかを判断するために1つの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取引は、「ベースライン」取引です。 IOTPの以降のバージョンでは、トランザクションの追加の種類を含むことができます。
Each of the IOTP Transactions above involve:
上記IOTP取引のそれぞれが関与します：
o a number of organisations playing a Trading Role, and
O取引役割を果たしている組織の数、および
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 Roles, Trading Exchanges and Trading Components are described below.
貿易の役割、取引の取引所と取引コンポーネントは、以下に記載されています。
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.
取引の役割は、組織が貿易に取ることができます異なる部分を識別します。 IOTP内で使用される5つの貿易の役割は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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 |
----------
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 1 IOTP Trading Roles
図1 IOTP取引の役割
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支払いハンドラ。物理的に加盟店に代わって消費者からの支払いを受け取るエンティティ
o Delivery Handler. The entity that physically delivers the goods or services to the Consumer on behalf of the Merchant.
配達ハンドラO。物理的に加盟店に代わって消費者に商品やサービスを提供するエンティティ。
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
最も単純なケース1つの物理的な組織内のoは（例えば、商人）、支払いを受け入れる、購入を扱う商品をお届けし、加盟店の顧客ケアを提供することができ
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時間365日サービスを提供する組織に連絡することができます。
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.
言葉消費者、商人、支払いハンドラ、配達ハンドラや顧客ケアプロバイダが使用された場合、反対の記述がない限り、なお、本明細書では、彼らは貿易の役割ではなく、実際の組織を参照してください。
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.
個々の組織は、複数のロールがかかる場合があります。同社は、商品やサービスそのものを購入された場合、商品またはサービスと消費者の役割を販売する際に例えば、インターネット上で商品やサービスを販売している会社が商人の役割を取ることができます。
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.
役割が異なる場所で発生するとの貿易に関わる組織は、データを交換する取引を完了できるように、すなわち、取引交換を行うために必要とされています。
The Internet Open Trading Protocols identify four Trading Exchanges which involve the exchange of data between the Trading Roles. The Trading Exchanges are:
インターネットオープン取引プロトコルは取引の役割との間でデータの交換を伴う4つの取引取引所を特定します。貿易取引所は、次のとおりです。
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オファー。貿易が行われている理由を消費者に提供する商人でオファーの交換の結果。貿易が継続している場合には消費者がオファーを受け入れなければならないので、それはオファーと呼ばれています
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支払い。消費者と支払ハンドラの間にいくつかの種類の支払いで決済取引結果。これは、どちらの方向に発生する可能性があります
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配信。配達取引所は、消費者へのオンライン商品、または配達ハンドラからの物理的な商品についての配信情報のいずれかを送信し、
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。認証取引所は、彼らがように見える人であることを確認するために、別の取引の役割を認証するために任意の取引の役割で使用することができます。
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取引は、これらのトレーディング取引所の様々な組み合わせで構成されています。例えば、IOTP購入取引はオファー、お支払い、配送トレーディング取引所が含まれています。別の例として、IOTPバリューExchangeトランザクションがオファー取引所と2つの支払取引の取引所で構成されています。
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.
貿易取引所は、様々な取引の役割との間で送信されている取引のコンポーネントで構成されています。可能であれば、IOTPトランザクションにおける往復遅延の数は、組み合わせIOTPメッセージにいくつかの貿易取引所からコンポーネントを梱包することによって最小化されます。例えば、IOTP購入トランザクションは、余分な消費者の要求と応答を避けるために、オファーレスポンスコンポーネントで配達組織コンポーネントを組み合わせています。
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トレーディング取引所のそれぞれについて、以下に詳細に説明します。彼らは、スタンドアロンの操作であるかのような説明を明確にするために、これらは、取引の交換について説明します。パフォーマンス上の理由から、取引の取引所は、実際のIOTPトランザクションの定義に混在しています。
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.
オファー取引所の目標は、消費者が取引を継続するかどうかを決定できるように、取引に関する情報を消費者に提供するために、商人のためです。これは、以下の図に示します。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Consumer | Merchant STEP | | 1. Consumer decides to trade and sends information about the transaction (requests an offer) to the Merchant e.g., using HTML.
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費者|マーチャントSTEP | | 1.消費者が取引することを決定し、HTMLを使用して、例えば、取引先の取引（募集を要求）についての情報を送信します。
C --> M Data: Information on what is being purchased (Offer Request)
- outside scope of IOTP
2. Merchant checks the information provided by the Consumer, creates an Offer optionally signs it and sends it to the Consumer.
2.マーチャントは、消費者によって提供される情報をチェックし必要に応じてオファーを作成し、それに署名し、消費者に送信します。
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
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:
オファーの交換は、消費者と商人の間で渡され、次の取引のコンポーネントを使用しています。
o the Status component is used to indicate to other parties that a valid Offer Response has been generated
Oステータスコンポーネントは、有効なオファーレスポンスが生成されている他の関係者に示すために使用されます
o the Organisation Component contains information which describes the Organisations which are taking a role in the trade:
O組織コンポーネントは、貿易の役割を取っている組織を説明する情報が含まれています。
- 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
- 消費者が商品やサービスが配信されている場合、消費者が商品やサービスはに配信される場所、で、誰についての情報を提供し、
- 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
- 商人は商人、支払いハンドラ、顧客ケアプロバイダと、商品またはサービスが配信されている場合は、配達ハンドラに関する情報を提供することによって、この情報を強化
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次成分は、消費者が提供して同意すれば、貿易からなり、商品やサービスの説明が含まれています。この情報は、それを確認する必要があり、消費者に商人によって送られます
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、通貨及び決済方向は、例えば消費者が返金を求めことができ支払うどのくらいの詳細が含まれています。貿易に複数の支払いがあるかもしれないことに注意してください
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、使用されています。これは、配達はポストまたは電子メールを使用することにより、たとえば、発生する方法に関する情報が含まれています
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取引ロールデータコンポーネントは、このような支払ハンドラまたは配達ハンドラとして商人が他の取引の役割に転送したいデータが含まれています
o the "Offer Response" Signature Component, if present, digitally signs all of the above components to ensure their integrity.
O「オファーレスポンス」署名コンポーネントは、存在する場合、デジタルでその整合性を確保するために、上記のすべてのコンポーネントに署名します。
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トランザクションの種類によって異なります。例えば：
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.
消費者の「ショッピング体験」の一環として、[HTML]ページを使用して、O。
o Using the Open Profiling Standard [OPS] which has recently been proposed,
提案されているオープンスタンダードプロファイリング[OPS]を用いて、O、
o in the form of Organisation Components associated with an authentication of a Consumer by a Merchant
商人によって消費者の認証に関連した組織構成要素の形でO
o as Order Components in a later version of IOTP.
IOTPの以降のバージョンで注文するコンポーネントとして、O。
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.
支払取引所の目標は、消費者が選択した支払いブランド、支払いプロトコルを使用して支払ハンドラまたはその逆に消費者からなされるべき支払いのためです。二次の目標は、オファーの取引所で説明したように、支払いのための理由に支払いをリンクするために使用することができ、デジタル署名された支払領収書を消費者に提供するために、オプションです。
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.
支払取引所は、さまざまな方法で作業することができます。貿易が使用ペイメントブランドとプロトコルに依存している最も一般的な場合は、以下の図に示されています。シンプルな支払いの交換が可能です。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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.
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *コンシューマー有料ハンドラ|マーチャント| STEP | | | 1.消費者が取引することを決定し、HTMLを使用して、例えば、取引先の取引（募集を要求）についての情報を送信します。
C --> M Information on what is being paid for (outside
scope of 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.加盟店は、ブランドのリストコンポーネントで、その後の支払いブランド、提供する決済プロトコルおよび通貨/金額、場所を決定し、消費者に送信します
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.消費者は、支払いブランド、プロトコル、使用する通貨/金額を選択ブランドの選択コンポーネントを作成し、商人に送信します
C --> M Component: Brand List Selection
C - > Mコンポーネント：ブランドリストセレクション
4. Merchant checks Brand Selection, creates a Payment Amount information, optionally signs it to authorise payment and sends it to the Consumer
4.マーチャントチェックブランドの選択、それは支払いを承認する支払額情報、必要に応じてサインを作成し、消費者に送信します
C <-- M Component: Payment; Organisation(s) (Merchant and
Payment Handler); Optional Offer Response Signature
that signs other components
5. Consumer checks the Payment Amount information and if OK requests that the payment starts by sending information to the Payment Handler
5.消費者は、支払金額情報をチェックし、支払いが支払いハンドラに情報を送信することにより開始しOK要求した場合
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
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.お支払いハンドラは、オプションの署名などの情報を確認し、[OK]を選択した支払いブランド、支払いプロトコルのために支払うスキームのデータ・コンポーネントを交換し始めた場合
C <-------> P PAYMENT EXCHANGE. Component: Pay Scheme Data
7. Eventually payment protocol messages finish so Payment Handler sends Pay Receipt and optional signature to the Consumer as proof of payment
7.支払ハンドラが支払いの証拠として消費者に有料領収書とオプションの署名を送信しますので、最終的に支払いプロトコルメッセージを終えます
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
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:
支払取引所は、消費者、商人や支払ハンドラの間で受け渡され、次の取引のコンポーネントを使用しています。
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 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.
クレジットカードまたはデビットカードでの支払いのために使用される名前 - ブランドリストコンポーネントは、ペイメントブランド（例えば、マスターカード、ビザ、モンデックス、ゲルトカルテ）、支払プロトコル（例えばSETバージョン1.0、セキュアチャネルクレジットデビット（SCCDのリストが含まれていますoをアカウント情報への不正アクセスは、セキュアなSSL / TLSなどのチャネル・トランスポート・メカニズム）と同様に適用する通貨/量の使用によって阻止されるところ。商人は、消費者にブランドのリストを送信します。消費者が支払いブランド、プロトコル、および通貨を比較します/消費者がサポートすると選択を行うものと提供に達します。
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ブランドの選択コンポーネントは、消費者の選択が含まれています。お支払いブランド、プロトコル、通貨/量と、おそらくプロトコル固有の情報は、マーチャントに送り返されます。この情報は、オファーの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状況コンポーネントは、支払取引の完了ステータスを示すために、以前の交換は（例えば、オファー取引所）が正常に完了した支払いハンドラへと支払いハンドラによって示すために使用されます。
o The Organisation Components are generated by the Merchant. They contain details of the Merchant and Payment Handler Roles:
組織コンポーネントoを商人によって生成されます。彼らは、マーチャントとペイメントハンドラの役割の詳細が含まれています。
- 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
- お支払いハンドラが支払いを開始した商人識別できるように商人の役割が必要です。一般的に、商人に代わって支払いハンドラ受諾（または作成する）の結果支払いは支払ハンドラが保持している商人のアカウントにクレジットカードやデビット取引となります。これらの取引は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
- お支払いハンドラは、それが支払いに使用する正しい支払ハンドラであることを確認することができるように支払いハンドラの役割が必要です
o The Payment Component contains details of how much to pay, the currency and the payment direction
○お支払コンポーネントは、通貨および支払い方向を支払うためにどのくらいの詳細が含まれています
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「オファーレスポンス」署名コンポーネントは、存在する場合、デジタルでその整合性を確保するために、上記のすべてのコンポーネントに署名します。支払い情報が作成されるまでブランド一覧やブランドセレクションコンポーネントが署名されていないことに注意してください（図中のステップ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こと
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をスキームコンポーネントが展覧会で使用される支払プロトコルからのメッセージが含まれています。例えば、それらは、SETメッセージ、モンデックスメッセージ、ゲルトカルテメッセージやIOTPでサポートされている他の支払方法の一つである可能性があります。支払の内容
Scheme Component is defined in the supplements that describe how IOTP works with various payment protocols.
スキームコンポーネントはIOTPは、様々な決済プロトコルでどのように機能するかを説明サプリメントで定義されています。
o The Payment Receipt Component contains a record of the payment. The content depends upon the payment protocol used.
○お支払領収書のコンポーネントは、支払いの記録が含まれています。コンテンツが使用され、支払いプロトコルに依存します。
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「支払領収書」署名コンポーネントは、デジタル支払領収書のコンポーネントおよびオファーレスポンス署名の両方に署名することによって、支払いの証拠を提供します。提供する上での署名はデジタルオファーに含まれる注文、組織と配信コンポーネントに署名します。このシグネチャは、効果的に提供への支払いをバインドします。
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).
上記の支払取引所の例は、最も一般的な場合です。シンプルな例も可能です。例えば、支払った金額は、ステップ3で生成された支払い情報を選択したペイメントブランドとプロトコルに依存しない場合がステップ1で生成されたブランドリストコンポーネントと同時に消費者に送信することができ、これらおよび他のバリエーションですベースラインの購入IOTPトランザクションに記述（セクション9.1.8を参照してください）。
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.
配信取引所の目標は、購入した商品がオンラインまたは物理的な配信のいずれかを介して消費者に配信させることです。第二の目標は、出荷追跡番号などの配信に関する詳細を、提供し、消費者に「納品書」を提供することです。それは物理的送達に伴う問題の場合には顧客ケアのために使用することができるように、送達の結果はまた、署名することができます。メッセージ・フローは、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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.
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費者DELIVERY | HANDLER |マーチャント| STEP | | | 1.消費者が取引することを決定し、HTMLを使用して、マーチャント例えばに、配達を取ることが何であるかを提供するために、誰の情報を送信します。
C --> M Information on what is being delivered (outside
scope of 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.商人は、消費者によって提供される情報をチェックする配信は、配信に関係機関の情報を発生する方法に関する情報を追加し、必要に応じてそれを歌い、消費者に送信します
C <-- M Components: Delivery; Organisations (Delivery
Handler, Deliver To); Order, Optional Offer
Response Signature
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です支払いを行うことにより、例えば、配信のための認可を取得し、配信ハンドラに配信情報を送ります
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)
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.配達ハンドラは、情報および承認をチェックします。開始またはスケジュール配信および作成し、必要に応じて署名することができる消費者がTOTない配信を送ります。
C <-------- D DELIVERY RESPONSE. Components: Status; Delivery
Note, Trading Role Data (optional); Optional
Delivery Response Signature
5. Consumer checks delivery note is OK and accepts or waits for delivery as described in the the Delivery Note.
5.消費チェックの納品書は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:
配達所は消費者、商人や配達ハンドラ間で受け渡され、次の取引のコンポーネントを使用しています。
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状況コンポーネントは、以前の交換（例えば、オファーExchangeまたは支払取引）が正常に完了したことを配信ハンドラに指示するために使用され、配信ハンドラによる送達交換の完了ステータスを示すために。
o The Organisation Component(s) contain details of the Deliver To, Delivery Handler and Merchant Roles:
O組織コンポーネント（複数可）提供するために、配達ハンドラと商人の役割の詳細が含まれています。
- the Deliver To role indicates where the goods or services are to be delivered to
- 商品やサービスはに配信される場所役割への配信を示しています
- the Delivery Handler role is required so that the Delivery Handler can check that she is the correct Delivery Handler to do the delivery
- 配信ハンドラは、彼女が配信を行うには、正しい配達ハンドラであることを確認することができるように配達ハンドラの役割が必要です
- the Merchant role is required so that the Delivery Handler can identify which Merchant initiated the delivery
- 配信ハンドラが配信を開始した商人識別できるように商人の役割が必要です
o The Order Component, contains information about the goods or services to be delivered
次成分O、配信される商品やサービスに関する情報が含まれています
o The Delivery Component contains information about how delivery will occur, for example by post or using e-mail.
O配信コンポーネントは、配達はポストまたは電子メールを使用することにより、たとえば、発生する方法に関する情報が含まれています。
o The "Offer Response" Signature Component, if present, digitally signs all of the above components to ensure their integrity.
O「オファーレスポンス」署名コンポーネントは、存在する場合、デジタルでその整合性を確保するために、上記のすべてのコンポーネントに署名します。
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「支払領収書」署名コンポーネントは、デジタル支払領収書のコンポーネントとオファー署名を署名することによって、支払いの証拠を提供します。これは、配信が許可されていることを確認するために配達ハンドラで使用されています
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納品書のコンポーネントは、物理的な引渡し、あるいは実際の「電子製品」に関連した顧客ケア情報が含まれています。消費者は、この配信は、トランザクション・リストから、関係する取引を選択した場合、消費者のソフトウェアは、後に物理的な配達についての情報を解釈することはありませんが、情報を表示する機能を持っている必要があり、両方の配達時と
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「配信応答」シグネチャー成分は、存在する場合、デジタル納品書と配信ハンドラが受信したオファーレスポンスまたは支払い応答署名を署名による送達の結果の証拠を提供します。
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.
認証取引所の目標は、1機関、例えば金融機関は、他の組織は、例えば消費者が、彼らはのように見える人であることを確認することができるようにすることです。
An Authentication Exchange involves:
認証交換が含まれます。
o an Authenticator - the Organisation which is requesting the authentication, and
O認証 - 認証を要求している組織、および
o an Authenticatee - the Organisation being authenticated.
O被認証者 - 組織が認証されています。
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
+ * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *機関1（被認証者）|組織2 | （認証）STEP | | 1.最初の組織は、例えば、消費者は、組織が認証されている必要があります（HTMLページ上のボタンを押すことにより）行動をとります
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と第二の組織は、認証要求を生成し、および/または組織情報の要求は、第1の組織に送ります
1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication
Request, Trading Role Information Request
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
前記第1の組織は、必要に応じて認証要求に関連付けられた任意の署名は、要求された任意の組織情報の詳細と一緒に第二組織に返送される認証応答を生成するために、指定された認証アルゴリズムを使用して確認し
1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication
Response, Organisation(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.認証応答は、最初の組織は、彼らが、その後、戻って最初の組織に送られる状況コンポーネントに記録されている結果に見える人であることを確認するために、チャレンジデータと照合されます。
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.
前記第1の組織は、その後、必要に応じてステータスによって示される結果と関連する署名を検査し、適切なアクションまたは停止を要します。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 5 Authentication Exchange
図5の認証交換
An Authentication Exchange uses the following Trading Components that are passed between the two Organisations:
認証交換には、2つの組織間渡され、次の取引のコンポーネントを使用しています。
o the Authentication Request Component that requests an Authentication and indicates the authentication algorithm and optional challenge data to be used.
認証を要求し、使用される認証アルゴリズムと任意チャレンジデータを示す認証要求コンポーネントO。
o A Trading Role Information Request Component that requests information about an Organisation, for example a ship to address.
組織に関する情報を要求した取引ロール情報要求コンポーネントO、例えば船が対処します。
o The Authentication Response Component which contains the challenge response generated by the recipient of the Authentication Request Component.
認証要求コンポーネントの受信者によって生成されたチャレンジレスポンスが含まれている認証応答コンポーネントO。
o Organisation Components that contain the result of the Trading Role Information Request
取引ロール情報要求の結果が含まれているO組織コンポーネント
o the Status Component which contains the results of the second party's verification of the Authentication Response.
認証応答の第二党の検証の結果が含まれている状況コンポーネントO。
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."
この仕様は、ベースラインIOTPを構成するIOTP取引について説明します。序文で述べたように、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.1貿易の役割でより詳細に記載されています。商人、消費者、支払ハンドラ、配達ハンドラおよびカスタマーケアプロバイダー：役割がある要約します。
Payment Handlers who can be of three types:
三種類のものとすることができる支払ハンドラ：
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取引と貿易ブロックを定義します。
Merchants
商人
ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler
ECashのECashストアバリューバリュー消費者の支払配達発行者買ハンドラハンドラ
TRANSACTIONS
取引
Purchase Must Must
購入する必要があります必要があります
Merchants
商人
ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler
ECashのECashストアバリューバリュー消費者の支払配達発行者買ハンドラハンドラ
Refund Must b) Depends
払い戻し）依存bでなければなりません
Authentication May Must May b) Depends
認証月マスト月b）は異なります
Value Exchange May Must
バリュー交換してもよいの必要があります
Withdrawal Must b) Depends
脱退は）依存bでなければなりません
Deposit Must b) Depends
デポジットは）依存bでなければなりません
Inquiry Must Must Must May Must Must
お問い合わせは、必要がありますする必要があります月にする必要がありますする必要がありますする必要があります
Ping Must Must Must May Must Must
pingが必要がありますする必要があります月の必要がありますする必要がありますする必要があります
TRADING BLOCKS
TRADINGブロック
TPO Must Must Must Must
TPOは必要がありますする必要がありますする必要がありますする必要があります
TPO Selection Must Must Must Must
TPO選択する必要がありますしなければならない必要がありますする必要があります
Auth-Request a) a) a) Depends Depends Depends
認証リクエストは、A）a）のA）に依存は依存依存します
Auth-Reply a) a) a) Depends Depends Depends
AUTH-返信A）a）のA）に依存Dependsとは異なり
Offer Response Must Must Must Must
オファーレスポンスは、必要があります必要があります必要がありますする必要があります
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
ECashのECashストアバリューバリュー消費者の支払配達発行者買ハンドラハンドラ
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要求は、必要がありますする必要がありますしなければならない必要がありますする必要があります必要があります
Ping Response Must Must Must Must Must Must
pingの応答する必要がありますする必要がありますする必要があります必要があります必要がありますする必要があります
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貿易の役割は、取引や貿易ブロックをサポートしなければならないことを意味し、「しなければなりません」。
o "May" means that an implementation may support the Transaction or Trading Block at the option of the developer.
O実装は、開発者の選択で取引または取引ブロックをサポートすることを意味し、「あります」。
o "Depends" means implementation of the Transaction or Trading Block depends on one of the following conditions:
O「依存」トランザクションの実装を意味または取引ブロックは、次のいずれかの条件によって異なります。
- if Baseline Authentication IOTP Transaction is supported;
- ベースラインの認証IOTPトランザクションがサポートされている場合は、
- if required by a Payment Method as defined in its IOTP Supplement document.
- 支払方法により、必要に応じてそのIOTP補足文書で定義されています。
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「リミテッド」のトレーディングブロックが理解されなければならないし、その内容はなく、あらゆる点で操作を意味します。具体的には、署名ブロックに、消費者は、デジタル署名を検証できるようにする必要はありません。
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".
IOTP溶液は、その溶液のために、上記の表に記載されているように「IOTPを支持する」と記載される少なくとも一つのロール（カラム）によって必要とされる全てのIOTPトランザクションと取引ブロックをサポートしなければなりません。
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トレーディング役割：消費者、商人、支払いハンドラ、配達ハンドラおよび顧客ケアプロバイダ、および
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。
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取引コンポーネントは、トレーディング・ブロックと物理的に異なる取引の役割との間の[XML]文書の形式で送信されたIOTPメッセージに構成されている方法、
o how IOTP Messages are exchanged between Trading Roles to create an IOTP Transaction
O取引の役割との間でやりとりされているかIOTPメッセージIOTPトランザクションを作成します
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
その中IOTPトランザクションとIOTPメッセージを識別するXML要素 - トランザクション参照ブロックを含むIOTPメッセージのXML定義O
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
IOTPメッセージを識別するために使用されるXMLのID属性の定義O、トレーディングブロックと取引コンポーネントおよび方法は、これらは、他のXML要素から要素参照を使用して参照されています
o how extra XML Elements and new user defined values for existing IOTP codes can be used when Extending IOTP,
Oどのように余分なXML要素とIOTPを拡張する際に、既存のIOTPコードの新しいユーザー定義された値を使用することができ、
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メッセージ内の詳細な順序の定義などのデータを埋め込むためにパッケージ化されたコンテンツ要素をどのように使用しますか
o how IOTP Identifies Languages so that different languages can be used within IOTP Messages
OどのようにIOTP識別言語、異なる言語がIOTPメッセージ内で使用できるように、
o how IOTP handles both Secure and Insecure Net Locations when sending messages
メッセージを送信するとき、O IOTPは、両方の安全で安全でないネットの場所をどのように処理しますか
o how an IOTP Transaction can be cancelled.
OどのようにIOTPトランザクションをキャンセルすることができます。
The structure of an IOTP Message and its relationship with Trading Blocks and Trading Components is illustrated in the diagram below.
IOTPメッセージおよび取引ブロックと取引コンポーネントとの関係の構造は以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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.
*-*-*-*-*-*--*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ーー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
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 the globally unique identifier in the Transaction Reference Block is sufficient to uniquely identify any Trading Block or Trading Component.
図はまた、取引のリファレンスブロックの概念を導入しています。このブロックは、とりわけ、IOTPトランザクションのグローバル一意識別子が含まれています。また、各ブロック、コンポーネントはIOTPトランザクション内で一意のID属性（セクション3.4を参照）が与えられます。したがって、トランザクション・リファレンスブロック内のID属性とグローバル一意識別子の組み合わせは一意に任意の貿易ブロックや取引コンポーネントを識別するのに十分です。
A predefined set of IOTP Messages exchanged between the Trading Roles constitute an IOTP Transaction. This is illustrated in the diagram below.
IOTPメッセージの所定のセットは、IOTPトランザクションを構成する取引の役割との間で交換しました。これは、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー
Figure 7 An IOTP Transaction
図7アンIOTPトランザクション
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メッセージは、トランスポート機構のさまざまな方法を使って輸送することができます。
The IOTP Transactions (see section 9) in this version of IOTP are specifically:
IOTPのこのバージョンでIOTPトランザクション（セクション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払い戻し。これは、一般的に、以前の購入の結果として、支払いの払い戻しをサポートしています
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。これは、認証アルゴリズムのさまざまな方法を使って、別の取引の役割によって、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取引の状況に関する問い合わせをサポートしています
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のPingは、これは他の場所で実行している別のIOTPアプリケーションが動作しているかどうかを判断するために1つの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メッセージは、物理的に取引に参加している別の取引の役割との間で送信されている[XML]ドキュメントです。
The XML definition of an IOTP Message is as follows.
次のようにIOTPメッセージのXML定義があります。
<!ELEMENT IotpMessage ( TransRefBlk, SigBlk?, ErrorBlk?, ( 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'
<！ELEMENT IotpMessage（TransRefBlk、SigBlk？ErrorBlk ?,（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'
Content:
コンテンツ：
TransRefBlk This contains information which describes an IOTP Message within an IOTP Transaction (see section 3.3 immediately below)
TransRefBlkこれは（すぐ下の3.3節を参照）IOTPトランザクション内IOTPメッセージを記述する情報が含まれてい
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は、これらの取引をブロックしています。 AuthRespBlk、DeliveryReqBlk、IOTPメッセージ内に存在する貿易・ブロック、DeliveryRespBlkと貿易ブロック自体の内容が行われ、InquiryReqBlkいるIOTPトランザクションの種類に依存しているErrorBlk - 各InquiryRespBlkの定義を参照してください、セクション9インターネットオープン中のトランザクション取引OfferRespBlk、プロトコル取引。 PayExchBlk、PayReqBlk、各取引ブロックの完全な定義は、セクション8 PingReqBlk、PingRespBlk、SigBlk、TpoBlk、TpoSelectionBlkに記載PayRespBlkあります
Attributes:
属性：
xmlns The [XML Namespace] definition for IOTP messages.
IOTPメッセージの[XML名前空間]定義のxmlns。
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メッセージは、XML文書のルート要素です。したがって、適切なXMLドキュメントのプロローグに先行する必要があります。例えば：
<?XML Version='1.0'?> <!DOCTYPE IotpMessage > <IotpMessage> ... </IotpMessage>
<？XMLバージョン= '1.0'？> <！DOCTYPE IotpMessage> <IotpMessage> ... </ IotpMessage>
A Transaction Reference Block contains information which identifies the IOTP Transaction and IOTP Message. The Transaction Reference Block contains:
トランザクション参照ブロックがIOTPトランザクションとIOTPメッセージを識別する情報が含まれています。トランザクション参照ブロックが含まれています。
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,
グローバルに一意IOTPトランザクションを識別するトランザクションIDコンポーネントO。トランザクションIDコンポーネントは、単一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
IOTPメッセージに関する制御情報を提供するだけでなく、一意IOTPトランザクション内IOTPメッセージを識別するメッセージIDコンポーネント、O、及び
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の取引またはこれらのイベントの識別子を使用して他のイベントのいずれかに、このIOTPトランザクションをリンクするコンポーネントにより関連。
The definition of a Transaction Reference Block is as follows:
次のようにトランザクションリファレンスブロックの定義は次のとおりです。
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) > <!ATTLIST TransRefBlk ID ID #REQUIRED >
<！ELEMENT TransRefBlk（TRANSID、のMsgId、のRelatedTo *）> <！ATTLIST TransRefBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Transaction Reference Block within the IOTP Transaction (see section 3.4 ID Attributes).
ID一意IOTPトランザクション内のトランザクション参照ブロックを識別する識別子（セクション3.4 ID属性を参照します）。
Content:
コンテンツ：
TransId See 3.3.1 Transaction Id Component immediately below.
すぐ下の3.3.1トランザクションIDコンポーネントを参照してくださいTRANSID。
MsgId See 3.3.2 Message Id Component immediately below.
すぐ下の3.3.2メッセージIDのコンポーネントを参照してくださいMSGID。
RelatedTo See 3.3.3 Related To Component immediately below.
RelatedToのすぐ下のコンポーネントに関連3.3.3を参照してください。
This contains information which globally uniquely identifies the IOTP Transaction. Its definition is as follows:
これは、グローバル一意IOTPトランザクションを識別する情報が含まれています。次のようにその定義は次のとおりです。
<!ELEMENT TransId EMPTY > <!ATTLIST TransId ID ID #REQUIRED Version NMTOKEN #FIXED '1.0' IotpTransId CDATA #REQUIRED IotpTransType CDATA #REQUIRED TransTimeStamp CDATA #REQUIRED >
<！ELEMENT TRANSID EMPTY> <！ATTLIST TRANSID ID ID #REQUIREDバージョンNMTOKEN #FIXED '1.0' IotpTransId CDATA #REQUIRED IotpTransType CDATA #REQUIRED TransTimeStamp CDATA #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Transaction Id Component within the IOTP Transaction.
ID一意IOTPトランザクション内のトランザクションIDコンポーネントを識別する識別子。
Version This identifies the version of IOTP, and therefore the structure of the IOTP Messages, which the IOTP Transaction is using.
バージョンこれはIOTPトランザクションが使用しているIOTPメッセージのIOTPのバージョン、したがって構造を識別する。
IotpTransId Contains data which uniquely identifies the IOTP Transaction. It must conform to the rules for Message Ids in [RFC 822].
IotpTransIdは一意IOTPトランザクションを識別するデータが含まれています。これは、[RFC 822]にメッセージIDの規則に準拠する必要があります。
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これが行われているIOTPトランザクションのタイプです。ベースラインIOTPにとっては、「標準」IOTPトランザクションを識別し、シーケンスを意味し、IOTPメッセージの内容は、取引の役割間で交換しました。ベースライン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.
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トランザクションのさまざまなタイプをサポートするように拡張されます。また、トランザクション内の一連のステップは、非標準であることを示しているタイプのダイナミックをサポートする可能性があります。
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.
IOTPトランザクションを開始するシステムは内部クロックを持っているTransTimeStampは、それがIOTPトランザクションは、[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」の値が含まれている必要があります。
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.
メッセージIDコンポーネントを一意IOTPトランザクション内IOTPメッセージを識別するだけでなく、IOTPメッセージに関する制御情報を提供します。次のようにその定義があります。
<!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タイムスタンプ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トランザクション内IOTPメッセージを識別するID識別子（セクション3.4 ID属性を参照）。 IOTPメッセージが再送されている場合、この属性の値は同じままであることに注意してください。
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 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.
RespIotpMsgこれは、このIOTPメッセージが応答されているIOTPメッセージのメッセージIDコンポーネントのID属性が含まれています。このように、IOTPトランザクション内のすべてのIOTPメッセージは明確に一緒にリンクされています。このフィールドはIOTPトランザクションにおける最初のIOTPメッセージを除くすべてのIOTPメッセージに必要とされます。
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メッセージを生成した取引の役割のSenderTradingRoleRefザ要素リファレンス（セクション3.5を参照）。これは、ネットの場所を識別するために使用される取引のブロックのいずれかに問題が技術的なエラーが（セクション4.1を参照）に報告すべき取引の役割の（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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
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]言語の識別に準拠言語コードのLangPrefListオプションリスト。応答を生成する際に、優先順序で、理想的には、メッセージの受信側が使用する言語を示すために送信側によって使用されます。示されている言語のいずれかを使用しますが、言語の一つが向上したユーザーエクスペリエンスを提供する可能性がある使用して対応する受信機上の義務はありません。
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オプションリスト。示すために送信側によって使用される優先順序で、文字が応答を生成する際に、メッセージの受信側は、理想的に使用するよう設定されています。そこ示される文字セットのいずれかを使用して対応する受信機上の義務はありませんが、文字セットのいずれかを使用すると、改善されたユーザ体験を提供する可能性があります。
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: 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
SoftwareIdこれはIOTPメッセージを生成したソフトウェアを特定する情報が含まれています。その目的は、異なるソフトウェアによって生成されたメッセージの間の非互換性の結果として発生する可能性のある相互運用性の問題を解決することです。 LANG：これは、XMLで定義された言語での単一のテキスト文字列です。ソフトウェアのバージョンOソフトウェアの名称Oソフトウェアの製造元の名前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.
メッセージを送信するデバイスが内部クロックを有するタイムスタンプは、それがIOTPメッセージは[UTC]形式で作成された時刻に設定されています。
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.
コンポーネントに関連するが、それらのイベントの識別子を使用して他のIOTPの取引やその他のイベントのいずれかにIOTP取引をリンクします。次のようにその定義があります。
<!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関係CDATA #REQUIRED RelnKeyWords NMTOKENS #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Related To Component within the IOTP Transaction.
ID一意IOTPトランザクション内のコンポーネントに関連を識別する識別子。
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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
RelationshipType Defines the type of the relationship. Valid values are:
RelationshipTypeは、関係のタイプを定義します。有効な値は以下のとおりです。
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.
Values of RelationshipType are controlled under the procedures defined in section 12 IANA Considerations which also allows user defined values to be defined.
RelationshipTypeの値は、ユーザ定義の値が定義されることを可能にする12のIANA問題セクションで定義された手順の下で制御されています。
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.
LANGこのコンポーネントと他のIOTPトランザクションまたはその他のイベントが含まれているIOTPトランザクション間の関係の性質を説明します関係リレーション属性は、XMLで定義された言語でのフレーズが含まれています。使用する正確な言葉はIOTPソフトウェアの実装者に委ねられています。
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.
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".
ケアは、関係属性にに使用されている単語が正しく関係の「向き」を示すように注意しなければなりません。たとえば：1つのトランザクションは、別の以前のトランザクションの払い戻しかもしれません。この場合は返金での取引は、むしろ「への返金」または単に「返金」より「の払い戻し」として関係属性語に含まれている必要があります。
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この属性は、例えば、すべての払い戻しを同様の関係を識別するために使用できるキーワードが含まれています。お勧めのキーワードは、実際の使用状況の調査を通じて開発されることが予想されます。仕様のこのバージョンでは具体的な提言や使用されるキーワードはありません実装の裁量です。
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（3.7節を参照）に関連するトランザクションを識別するデータが含まれています。そのフォーマットは、RelationshipTypeの値に依存して変化します。
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.
IOTPメッセージ、ブロック（すなわちトランザクション参考ブロックと貿易ブロック）は、取引（トランザクションIDコンポーネントと署名コンポーネントを含む）、コンポーネントとその子要素のいくつかは、それぞれのインスタンスを識別するために使用されるXML「ID」属性を与えられていますこれらのXML要素。一つの要素が他から参照できるように、これらの識別子が使用されています。すべてのこれらの属性は、属性名IDを与えられています。
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属性の値はすなわち、同じグローバルに一意のトランザクションIDコンポーネントを持っているIOTPメッセージのセットIOTPトランザクション内で一意です。要素の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).
結果として、を参照し、要素参照（セクション3.5を参照）を使用して同じIOTPトランザクション内の他のIOTPメッセージ、ブロックまたはコンポーネントから任意IOTPメッセージ、ブロックまたはコンポーネントのコンテンツを見つけるために、これらのIDを使用することが可能です。
This section defines the rules for setting the values for the ID attributes of IOTP Messages, Blocks and Components.
このセクションでは、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メッセージのメッセージIDコンポーネントのID属性は、IOTPトランザクション内で一意でなければなりません。次のようにそれの定義は次のとおりです。
IotpMsgId_value ::= IotpMsgIdPrefix IotpMsgIdSuffix
IotpMsgIdPrefix ::= NameChar (NameChar)*
IotpMsgIdSuffix ::= Digit (Digit)*
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：問い合わせ要求貿易ブロック、問い合わせ応答貿易ブロック、Ping要求貿易ブロックやPingの応答貿易ブロック。その後、同じ接頭辞は次のように商人や消費者ロールによって送信されたすべてのメッセージのために使用されます。
o "M" - Merchant
o "C" - Consumer
For messages which contain an Inquiry Request Trading Block or a Ping Request Trading Block, the prefix is set to "I" for Inquiry.
問い合わせ要求取引をブロックまたはping要求取引のブロックが含まれているメッセージの場合、接頭辞は、お問い合わせについては「I」に設定されています。
For messages which contain an Inquiry Response Trading Block or a Ping Response Trading Block, the prefix is set to "Q".
問い合わせレスポンス貿易ブロックやPingの応答取引のブロックが含まれているメッセージの場合、接頭辞は「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:
貿易の他の役割のための接頭辞は、役割のための組織コンポーネント内に含まれ、一般的に商人によって設定されています。以下は、ガイドラインとして推奨され、頼りにされてはなりません。
o "P" - First (only) Payment Handler o "R" - Second Payment Handler o "D" - Delivery Handler o "C" - Deliver To
O "P" - "R" Oファースト（のみ）支払いハンドラ - "C" O配信ハンドラ - - "D" ○第2の支払ハンドラに配信
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サフィックスは1つの以上の数字で構成されています。サフィックスはIOTPトランザクション内貿易の役割内で一意でなければなりません。以下は、ガイドラインとして推奨され、頼りにされてはなりません。
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
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.
消費者によって送信された最初のIOTPメッセージのメッセージIDコンポーネント等、「C1」、第二の「C2」、第三の「C3」のID属性を持つことになり、より簡単に言えば
Digit has the same definition as the [XML] definition of Digit.
桁が桁の[XML]定義と同義です。
The ID Attribute of Blocks and Components must also be unique within an IOTP Transaction. Their definition is as follows:
ブロックとコンポーネントのID属性もIOTPトランザクション内で一意でなければなりません。次のように彼らの定義は次のとおりです。
BlkOrCompId_value ::= IotpMsgId_value "." IdSuffix
IdSuffix ::= Digit (Digit)*
IotpMsgId_value The ID attribute of the Message ID Component of the IOTP Message where the Block or Component is first used.
ブロックまたはコンポーネントが最初に使用されているIOTPメッセージのメッセージID構成要素のID属性IotpMsgId_value。
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.
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サフィックスは1つの以上の数字で構成されています。接尾辞は、IDコンポーネントID属性を生成するために使用されるメッセージの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
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.
もっと簡単に言えば、最初の新しいブロックまたはコンポーネントが送信された第2 IOTPメッセージに追加、例えば、消費者が「C2.1」のID属性を、第二の「C2.2」、第三の「C2を有するであろう。 3" など
Digit has the same definition as the [XML] definition of Digit.
桁が桁の[XML]定義と同義です。
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 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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー
Figure 8 Example use of ID attributes
ID属性の図8の例の使用
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:
取引コンポーネントまたはその子XML要素の一つは、他のブロック（すなわち、トランザクション参照ブロックまたは取引ブロック）または（トランザクションIDと署名コンポーネントを含む）取引成分を意味するXML属性を含んでいてもよいです。これらの要素の参照は、多くの目的のために使用されている、いくつかの例は次のとおりです。
o identifying an XML element whose Digest is included in a Signature Component,
そのダイジェストの署名要素に含まれているXML要素を識別するO、
o referring to the Payment Handler Organisation Component which is used when making a Payment
○お支払の際に使用されているお支払いハンドラ組織コンポーネントを参照
An Element Reference always contains the value of an ID attribute of a Block or 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:
要素のリファレンスによって参照されたIOTPメッセージ、貿易ブロックや取引コンポーネントの識別、そのXML要素を見つける含まれます。
o belongs to the same IOTP Transaction (i.e. the Transaction Id Components of the IOTP Messages match), and
O（すなわちトランザクションIOTPメッセージのIDコンポーネントが一致）同じIOTPトランザクションに属し、そして
o where the value of the ID attribute of the element matches the value of the Element Reference.
O要素のID属性の値は、要素のリファレンスの値と一致しています。
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.
「マッチング」要素についての例を以下の例に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
1st IOTP MESSAGE 2nd IOTP MESSAGE
(e.g., from Merchant to (e.g., from Consumer to
Consumer Payment Handler)
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー*ー
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.
注意：要素のリファレンス属性は、むしろ「IDREF」よりも「NMTOKEN」（[XML]を参照）のように定義されています。 IDREFは、XML要素は、同じXMLドキュメントであると呼ぶことを必要とするからです。 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: o extra XML elements, and
ベースラインIOTPはIOTPをサポートするシステムが受け入れることができなければならない最低限のプロトコルを定義しています。 IOTPの新しいバージョンが開発されると、IOTP取引の追加的なタイプが定義されます。これに加えて、ベースラインとIOTPの将来のバージョンでは、二つの機構を通じてIOTPへのユーザーの拡張機能をサポートします：余分なXML要素O、および
o new values for existing IOTP codes.
既存のIOTPコードの新しい値O。
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].
XML要素とIOTP内で使用される名前をxmlns属性によって識別される[XML名前空間]を構成するIotpMessage要素の属性。これはIOTPは[XML名前空間]の使用を通じてIOTPメッセージ内の追加のXML要素の包含をサポートすることを可能にします。
Using XML Namespaces, extra XML elements may be included at any level within an IOTP message including:
XML名前空間を使用して、余分なXML要素にはIOTPメッセージ内の任意のレベルで含まれていてもよいです。
o new Trading Blocks
新しい取引ブロックO
o new Trading Components
O新たな取引コンポーネント
o new XML elements within a Trading Component.
取引コンポーネント内の新しいXML要素O。
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貿易ブロックまたは取引コンポーネントのどちらかである新しい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.
クリティカル、TrueまたはFalseの値を取り、IOTPメッセージに追加し、余分な要素に表示される場合があります余分なXML要素を適切に処理できることを確認するために、IOTPは特別な属性、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.
余分なXML要素は「IOTP：クリティカル」している場合はO「真」とIOTP対応アプリケーションの値を持つ属性が要素とその子要素を処理する方法を知りません、そして、IOTPトランザクションは、技術的なエラーがあります（セクションを参照してください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:
余分なXML要素は「IOTP：クリティカル」があればO「偽」の値を持つ属性をIOTP対応アプリケーションがそれを処理する方法を知らないならば、IOTPトランザクションが継続してもよいです。この場合：
- 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
- IOTP XML要素が使用されるか、またはIOTPによってコピーされるたびにIOTP名前空間内で定義されたXML要素内に含まれる余分なXML要素は、その要素に含まれなければなりません
- 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"
余分なXML要素が何も持っていない場合はO「真」の値を持つ属性「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
XML要素は、「IOTP：クリティカル」が含まれている場合、Oの属性を、その属性の値は、その要素内のすべての子要素に適用すると想定されます
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：クリティカル（TRUE | FALSE） '真'
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が不透明埋め込まれたデータを使用して拡張する場合は、パッケージ化されたコンテンツ要素は、（セクション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:
パッケージ化されたコンテンツ要素は、システムを輸送することによって誤解に対してそれを保護し、XMLとの互換性を確保するために、両方に変換し、埋め込まれたデータストリームの概念をサポートしています。 IOTPでの使用の例としては、次のとおりです。
o to encapsulate payment scheme messages, such as SET messages,
このようSETメッセージなどの決済スキームのメッセージをカプセル化するために、O、
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つの標準化された属性を持っています。次のようにその定義があります。
<!ELEMENT PackagedContent (#PCDATA) > <!ATTLIST PackagedContent Name CDATA #IMPLIED Content NMTOKEN "PCDATA" Transform (NONE|BASE64) "NONE" >
<！ELEMENT PackagedContent（#PCDATA）> <！ATTLIST PackagedContent名CDATA #IMPLIEDコンテンツNMTOKEN "PCDATA" 変換（NONE | BASE64） "NONE">
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の同じポイントでパッケージ化されたコンテンツ要素の複数の出現を区別します。例えば：<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.
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.
コンテンツは、これがパッケージ化されたコンテンツ要素の内容に含まれているデータの種類を識別します。次のようにコンテンツの属性の有効な値は次のとおりです。PCDATA oを。パッケージ化されたコンテンツ要素の内容は、さらなる処理でPCDATAとして扱うことができます。 MIME O。パッケージ化されたコンテンツ要素の内容は、完全なMIMEアイテムです。処理は、パッケージ化されたコンテンツ要素内にMIMEヘッダを探して含める必要があります。 MIME O：MIMEタイプ。パッケージ化されたコンテンツ要素の内容は、次のヘッダー「：MIMEタイプのContent-Type」で、MIMEコンテンツです。それはMIME持つことが可能ですが：NONEに設定する変換属性とMIMEタイプを、それがBASE64に属性セットを変換するために持ってはるかに可能性があります。トランスフォームは、NONEが使用されていない場合は、その後、全体の内容はまだPCDATAに適合しなければならないことに注意してください。一部の文字は、XMLのデフォルトのエンティティとして、または数値文字エンティティのいずれかとしてエンコードする必要があります。
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.
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.
コンテンツ属性の値は、ユーザ定義の値が定義されることを可能にする12のIANA問題セクションで定義された手順の下で制御されています。
Transform This identifies the transformation that has been done to the data before it was placed in the content. Valid values are:
これは、それがコンテンツに置かれた前のデータに行われた変換を識別する変換。有効な値は以下のとおりです。
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.
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は、これが埋め込まれている実際のデータです。データとそれをデコードする方法についての規則の形式は、コンテンツに含まれると属性を変換しています
Note that any special details, especially custom attributes, must be represented at a higher level.
特別な詳細、特にカスタム属性は、より高いレベルで表現されなければならないことに注意してください。
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
パッケージ化されているデータの受信者の理解が同じ親要素内に含まれる他のパッケージ化された要素を参照する必要があります影響を与えることができ、そのような音やWebページなどの任意の文書、画像または他のもの、例えば、オーダ説明への言及O
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、その後、他のすべてのパッケージ化された要素への参照を決定することができ、そこからトップレベルのパッケージ化されたコンテンツのName属性は、メインの値を持つ必要があります
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相対参照は、同じレベルに別のパッケージングされたコンテンツ要素の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]は、各パッケージ要素内のデータをカプセル化するために使用されます。これは、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
注意：実装のガイドラインとしてパッケージ化されたコンテンツの要素に割り当てられた名前の属性の値は、それが可能ディレクトリに各パッケージ化されたコンテンツを抽出して、直接HTMLを表示するために行う必要があります
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を表示する必要がある場合、消費者のための説明の内容を表示するには、たとえば、その実装は、World Wide Web Consortiumの最新の勧告に従うべきです。
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
http://www.w3.org/TR/WD-xslで「拡張スタイルシート言語（XSL）仕様の」o、および
o "Associating stylesheets with XML documents" at http://www.w3.org/TR/xml-stylesheet.
O http://www.w3.org/TR/xml-stylesheetで「XML文書とスタイルシートの関連付け」。
Once these standards become W3C "Recommendations", then it is anticipated that this specification will be amended if practical.
これらの規格は、W3C「勧告」になったら、実用的な場合には、この仕様が改正されることが予想されます。
IOTP uses [XML] Language Identification to specify which languages are used within the content and attributes of IOTP Messages.
IOTPはIOTPメッセージの内容と属性内で使用される言語を指定する[XML]言語識別を使用します。
The following principles have been used in order to determine which XML elements contain an xml:lang Attributes:
以下の原則は、XML要素は、XMLを含むかを決定するために使用されてきた：langの属性：
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属性は、特定の言語で表示または印刷する必要があるかもしれない属性またはコンテンツを含むすべての取引コンポーネントに含まれています
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属性は、これらの取引コンポーネントの子要素に含まれています。この場合、XMLの値：langは、存在する場合、取引コンポーネントの値を上書きします。
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で定義された自分の子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.
メッセージの送信者は、典型的には、消費者は、メッセージIDコンポーネントに好ましい言語/文字セット（セクション3.3.2を参照）のリストを指定することにより設定された言語の優先、および文字を示すことができます。彼らはそれを行うことができるようにする技術を持っていない可能性として記載されている言語/文字セットのいずれかを使用して対応するため、このようなメッセージの受信者には何の義務がないことに注意してください。また、これらのリストを処理する能力がこの仕様への適合性のための要件ではないことを意味します。しかし述べた言語/文字セットのいずれかを使用して、たとえば、対応する能力は、より優れたユーザーエクスペリエンスを提供する可能性があります。
IOTP contains several "Net Locations" which identify places where, typically, IOTP Messages may be sent. Net Locations come in two types:
IOTPは一般的に、IOTPメッセージを送信することができる、場所を特定し、いくつかの「ネット場所」を含んでいます。ネットの場所は、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]などの暗号化方式を、「セキュア」と
o "Insecure" Net Locations where privacy of data is not assured.
O「安全でない」データのプライバシーが保証されていないネットの場所。
Note that either a Secure Net Location or an Insecure Net Location or both must be present.
セキュアネット場所や安全でないネット場所のいずれか、または両方が存在しなければならないことに注意してください。
If only one of the two Net Locations is present, then the one present must be used.
2つのネット場所の一つだけが存在する場合、1つの存在を使用する必要があります。
Where both types of net location are present then either may be used depending on the preference of the sender of the message.
ネット場所の両方のタイプが存在する場合、その後のいずれかは、メッセージの送信者の好みに応じて使用することができます。
Any Trading Role involved in an IOTP transaction may cancel that transaction at any time.
IOTPトランザクションに関与どれ貿易の役割は、任意の時点でそのトランザクションを取り消すことができます。
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取引はちょうど貿易取引に関与する他の取引の役割に適した状況コンポーネントでブロックをキャンセル含む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メッセージを非同期的に送信することができます。具体的には、送信する前に、または他のトレーディングの役割からIOTPメッセージを受信した後、いずれかの送信することができます
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.
IOTPトランザクションが（「要求」ブロックを送信し、マッチング「応答」ブロックを受信間隔IE）取引交換中にキャンセルされた場合、ブロックは、取引所の次IOTPメッセージと同じ場所に送信されるキャンセル希望送られました。
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.
取引所は（すなわち取引所のための「レスポンス」ブロックが受信されている）が完了しましたが、IOTPトランザクションが完了する前に、そして消費者がネットに適切な状況コンポーネントでブロックをキャンセルを送信した後、消費者は、取引をキャンセルした場合トランザクションのTPOブロックに含まれるプロトコルオプション成分に含まSenderNetLocn又はSecureSenderNetLocnによって識別された位置（セクション7.1を参照）（セクション8.1参照）。これは通常、マーチャントトレーディングの役割です。
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.
IOTPトランザクションが完了した後に消費者はキャンセルブロックを送るべきではありません。完全なトランザクションをキャンセルすると、技術的なエラーとして扱われるべきです。
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トランザクションをキャンセルした後、消費者はキャンセルブロック送信された組織のための取引role要素に含まれるCancelNetLocn属性で指定されたネットの場所に行く必要があります。
A non-Consumer Trading Role should only cancel a transaction:
非消費者取引の役割は、トランザクションを取り消す必要があります。
o after a request block has been received and o before the response block has been sent
O要求ブロックが受信され、応答ブロックの前にOが送信された後
If a non-Consumer Trading Role cancels a transaction at any other time it should be treated by the recipient as an error.
非消費者取引の役割は、他のどの時点で取引をキャンセルした場合、エラーとして受信者によって扱われるべきです。
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.
キャンセルが許可されている場合、キャンセルはブロックがIOTPトランザクションでの時点で消費者によって受信された場合には、消費者は、取引を停止する必要があります。
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.
ブロックが非消費者の役割によって受信されたキャンセル場合は、取引の役割は、消費者が取引の役割のための取引role要素に含まれるCancelNetLocn属性で指定された場所に行くことを予想しなければなりません。
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は、各メッセージが取引コンポーネントの数を含む取引ブロック数で構成されている要求/応答プロトコルとして設計されています。エラー処理、再送信、重複、などのいくつかの相互に考慮事項があります。これらの要因は、メッセージを管理しなければならないIOTP対応アプリケーションは、単純な要求/応答モデルよりも複雑な流れを意味します。また、エラーの多種多様なメッセージにだけでなく、トランスポートレベルでまたは取引ブロックまたはコンポーネントで発生する可能性があります。
This section describes at a high level how IOTP handles errors, retries and idempotency. It covers:
このセクションでは、IOTPがエラー、再試行して冪等をどのように処理するかをハイレベルで説明します。これは、説明します。
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メッセージの目的とは無関係である「技術的なエラー」、
- "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どのように異なるの取引の役割は、彼らが受け取ることができる異なるタイプのメッセージを処理する必要があります。
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:
技術的なエラーメッセージの意味とは独立しているものです。これは、彼らが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メッセージにエラーを検出しパーティによって送信されたエラー誤差ブロックにおける成分（セクション7.21を参照）（セクション8.17を参照）によって示され。
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.
技術的なエラーに関連付けられたエラーコードを設定することができ、すべての異なる技術的なエラーを示していますエラーコンポーネントに記録されています。
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メッセージは「技術的には」正しい時にビジネス・エラーが発生することがあります。これらは、特定のプロセスと各プロセスが可能ビジネス・エラーの異なるセットを有する、例えば、申し出、支払い、送達または認証を、接続されています。
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.
たとえば、「不足資金は、」合理的な決済エラーですが、「戻る命じた」合理的な配信エラーが、支払いにはあまり意味がありませんしながら、配信のためには意味がありません。ビジネス・エラーは、例えば、適切なタイプの「応答ブロック」の状況コンポーネント（セクション7.16を参照）、支払い応答ブロックまたは配達応答ブロックに示されています。これは、追加の応答に関連する情報がエラー表示に同行するために必要とされるものは何でもできます。
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 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.
彼らが次に何をすべきかを決めることができるようにビジネスのエラーは通常、ユーザに提示する必要があります。エラーがブランドの独立したオファーで資金不足（セクション9.1.2.2を参照）である場合、例えば、ユーザーは、同じブランドまたは別のブランドまたは支払いシステムのさまざまな決済手段/アカウントを選択したい場合があります。 IOTPベースの実装がそれを可能にし、それがその楽器のために理にかなっている場合は別の方法として、使用者は、機器/口座により多くの資金を入れて、もう一度しようとする場合があります。
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つのレベルがトランスポートレベル、メッセージレベル、およびブロックレベルです。それぞれについて、以下に説明されます。
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から、または全く応答が要求に受信されなかったタイムアウトによって「Noルート先に」エラーとして、明示的なトランスポートレベルのエラー表示によって示されています。
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交通サプリメントのドキュメントは、エラーと適切な行動のために相談する必要があります。
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.
リクエストが支払い情報をカプセル化する場合に使用するために、適切なタイムアウトが使用されているトランスポートの両方のと決済システムの機能です。輸送および決済システム固有のドキュメントには、タイムアウトと自動再試行パラメータのために相談する必要があります。頻繁に直接トランスポートレベルのエラーの相手方に通知する方法はありませんが、彼らは一般的にログに記録されなければならないし、自動回復が失敗し、人間のユーザが存在する場合、ユーザーに通知する必要があります。
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は「整形」ではない、またはメッセージは受信機が処理するには大きすぎるか、トランザクションリファレンスブロックにエラーがある（セクション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 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.
すべてのメッセージ・レベルのエラーは、技術的なエラーであり、相手に送信誤差成分（セクション7.21を参照）で示されています。エラーコンポーネントは、エラーが警告であると、再試行が問題か、トランザクションが失敗しなければならない場合にはHardErrorを解決することができることを示しているTransientErrorを無視することができるかどうかを示す重要度属性を含んでいます。
The Technical Errors (see section 7.21.2 Error Codes) that are Message Level errors are:
メッセージレベルのエラーがある技術的なエラー（セクション7.21.2エラーコードを参照）は、次のとおりです。
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ブロックレベルの技術的なエラーが（セクション4.3.3を参照）のみ署名ブロック（セクション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.
署名ブロックのチェックが各署名要素が正しく計算されていることを、可能な場合、確認が含まれることに留意されたいです。署名が誤って計算されている場合は、署名でカバーされているはずのデータが信頼できないため、誤ったものとして扱われなければなりません。正確に計算された署名をチェックする方法については、セクション6.2に含まれています。
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.
ブロックレベルエラーは、（離れトランザクションリファレンスまたは署名ブロックから）IOTPメッセージ内のブロックまたはそのコンポーネントの1つに問題があることを示しています。メッセージが適切に搬送されてきた、全体的なメッセージ構造およびトランザクションリファレンスおよび署名ブロックを含むブロック/成分（単数または複数）は意味があるが、他のブロックのいずれかに関連するいくつかのエラーがあります。
Block level errors can be either:
ブロックレベルのエラーは、いずれかになります。
o technical errors, or
O技術的なエラー、または
o business errors
O事業エラー
Technical Errors are further divided into:
技術的なエラーは、さらにに分かれています。
o Block Level Attribute and Element Checks, and
Oブロックレベルの属性と要素をチェックし、
o Block and Component Consistency Checks
Oブロックとコンポーネントの整合性をチェックします
o Transient Technical Errors
O一時技術的なエラー
If a technical error occurs related to a block or component, then an Error Component is generated for return.
技術的なエラーがブロックまたはコンポーネントに関連し発生した場合、エラーコンポーネントは、リターンのために生成されます。
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.
ブロックレベルの属性と要素のチェックは、同じブロック内でのみ発生します。他のブロックに対するクロスチェックを伴うかどうかをチェックはブロックとコンポーネントの一貫性チェックによって覆われています。
The Block Level Attribute & Element checks are:
ブロックレベルの属性と要素のチェックは、次のとおりです。
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.
前のチェックがOKであれば、O、属性値と同じブロック内の他の構成要素内の他の属性値や要素内容に対して要素コンテンツの整合性をチェックします。
Block and Component Consistency Checks consist of:
ブロックとコンポーネントの一貫性チェックがで構成されています。
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
ブロックおよび/またはIOTPメッセージ中に存在する成分の組み合わせは、このIOTP仕様内のルールと一致含まれていることを確認O
o checking for consistency between attributes and element content within the blocks within the same IOTP message.
同じIOTPメッセージ内のブロック内の属性や要素内容との整合性をチェックO。
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
このIOTPメッセージとブロックで、ブロック内の属性と要素間の整合性をチェックするoを同じ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のアプリケーションによって、または、おそらく、このような決済サーバなどの一部の「バックエンド」システムのいずれかによって処理されます。
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
ブロックの処理中にそれを発生することがあり、いくつかの一時的な障害は、潜在的に、いくつかの少し後の時点で、他の取引役割を再送信することで、彼らが送られた元のメッセージを復元することができます。この場合、他の役割は、過渡が通知されます
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).
彼らに重大属性TransientErrorに設定し、MinRetrySecsが使用されているトランスポートメカニズムおよび/または支払プロトコルに適したいくつかの値に設定する属性を持つエラーコンポーネント（セクション7.21を参照）を送信することにより、エラー（適切な輸送と支払いプロトコルサプリメントを参照してください）。
Note that transient technical errors can be generated by any of the Trading Roles involved in transaction.
過渡的技術的なエラーがトランザクションに関与取引の役割のいずれかによって生成することができることに注意してください。
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.
ビジネス誤差は、このような支払いや配達などのプロセスで発生した場合、レスポンスブロックの適切なタイプは、問題の性質を示す失敗に設定ProcessState属性とCompletionCodeで（セクション7.16を参照してください）状況コンポーネントを含む返されます。
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.
いくつかのビジネスの誤差は消費者の役割が回復し、他のいくつかの方法でトランザクションを完了することがあり得ることで、「一過性」であってもよいです。たとえば、提供、消費者が購入のための十分な資金を持っていたクレジットカードは、その後、消費者は、別のクレジットカードを使用することによって回復することができる場合。
Recovery from "transient" business errors is dependent on the CompletionCode. See the definition of the Status Component for what is possible.
「一過性」のビジネス・エラーからの回復はCompletionCodeに依存しています。何が可能であるかのステータスコンポーネントの定義を参照してください。
Note that no Error Component or Error Block is generated for business errors.
何のエラーコンポーネントまたはエラーブロックは、ビジネス・エラーのために生成されていないことに注意してください。
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.
3.1.1 IOTPメッセージ構造で説明したようにIOTPメッセージは、実際にブロックおよび構成要素の組み合わせです。特にIOTPの将来の拡張では、このようなブロックおよび構成要素の組み合わせの豊富なが発生する可能性があります。状態を変更するアクションのために「同じ」要求の複数の送信/受信が複数回発生し、そのアクションを生じさせないことが重要です。これは冪等と呼ばれています。例えば、順番にお金を払う顧客は一度だけ全額を支払うしたいと思います。ほとんどのネットワーク・トランスポート・メカニズムは、おそらく再送信を必要とする、すべてで複数回かメッセージを配信するいくつかの可能性を持っています。一方、ステータス要求が合理的に繰り返すことができ、それが受信されるたびに新たに処理されなければなりません。
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の正しい実装は、特定の処理順序によってモデル化することができます。当事者間で送信されるメッセージに区別できない任意の他の方法も同様に許容可能です。
"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:
「サーバーの役割は、」消費者の役割ではない任意の取引の役割です。彼らは通常、彼らがサービスを提供し、応答を生成しなければならない要求を受け取るため、彼らは、「サーバーの役割」です。しかし、サーバーの役割も、トランザクションを開始することができます。具体的にはサーバーの役割のことができるようにする必要があります。
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
- 入力メッセージを処理するサーバーがそれを処理するにはあまりにも忙しい場合は一時的なエラーが発生
- 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を参照）メッセージを再送信します。
Server Roles may initiate a variety of different types of transaction. Specifically:
サーバーの役割は、取引の様々な異なるタイプのを開始することができます。具体的に：
o an Inquiry Transaction (see section 9.2.1)
お問い合わせトランザクションO（セクション9.2.1を参照してください）
o a Ping Transaction (see section 9.2.2)
PINGトランザクションO（セクション9.2.2を参照してください）
o an Authentication Transaction (see section 9.1.6)
認証トランザクションO（セクション9.1.6を参照）
o a Payment Related Transaction such as:
○お支払関連取引など：
- 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を参照してください）
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.
これらのそれぞれは、以下でより詳細に議論されています。
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メッセージ内のトランザクションID（TRANSIDコンポーネント上IotpTransId属性）が正常に識別できることを確認することが重要です。
If the input message is not well formed then generate an Error Component with a Severity of HardError and ErrorCode of XmlNotWellFrmd.
入力メッセージが十分に形成されていない場合、HardErrorとXmlNotWellFrmdののErrorCodeの重症度とエラーコンポーネントを生成します。
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 a PackagedContent containing "IotpTransId" - the missing attribute.
O HardErrorの重症度および「IotpTransId」を含むPackagedContent O AttMissingののErrorCode、 - 行方不明の属性を。
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のコンポーネントでエラーブロックの内部エラーコンポーネントを挿入し、元のメッセージの送信者にそれを返します。
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]
注：同じメッセージをチェックするのをお勧めの方法は、自分の[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.
処理が完了していない場合は、処理されている一時的なエラーの重大度とメッセージを示すためにMsgBeingProcのエラーコードとエラーコンポーネントを生成し、元のメッセージが適切なの後に再送することを要求する入力メッセージの送信者に戻ってそれを送信期間。
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.
メッセージが重複していない場合、それは処理されるべきです。
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
o checking the Transaction is Not Already in error or cancelled
トランザクションの確認oをエラーになっていないか、またはキャンセル
o validating the input message. This includes:
入力されたメッセージを検証O。これも：
- checking for message level errors
- メッセージ・レベルのエラーをチェック
- checking for block level errors
- ブロック・レベルのエラーをチェック
- 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ハードエラーも一時的なエラーでもない、入力メッセージの送信者への復帰のために必要であれば、その後、メッセージを処理し、出力メッセージを生成する結果とならば
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.
注意：絶対に「同一」メッセージを受信した場合、重複入力メッセージ手段の取り扱いに対するこのアプローチは、その後、絶対に「同一」のメッセージが返されます。現実には、取引やサーバの処理能力の状態が変更された可能性があるとき、これはまた、問い合わせや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.
サーバーがビジー状態である場合、それは一時的なエラーの重大度を持つエラーコンポーネントとSystemBusyのエラーコードを生成する必要がありますし、元のメッセージが適切な期間の後に再送することを要求する入力メッセージの送信者に戻ってそれを送信します。
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
TRANSACTIONをチェックすると、ERRORになっていないか、またはキャンセル
Check that:
それを確認します：
o previous messages received or sent did not contain or result in Hard Errors, and
O以前のメッセージが含まれているか、ハードエラーにはなりませんでした受信または送信され、
o the Transaction has not been cancelled by either the Consumer or the Server Trading Role
Oトランザクションは、消費者やサーバーの貿易の役割のいずれかによってキャンセルされていません
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
XMLをチェックすることは有効であるO
o checking that the elements, attributes and content of the Transaction Reference Block are without error and conform to this specification
要素、属性、およびトランザクションのリファレンスブロックの内容がエラーなしであり、この仕様に準拠していることを確認するO
o checking the digital signature which involves:
O含むデジタル署名を確認します。
- checking that the Signature value is correctly calculated, and
- 署名値が正しく計算されていることを確認し、
- 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：
- 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属性の値は、要素と要素の内容が以前のメッセージ送信または受信のいずれかで入力メッセージ内のブロックとブロックの間に一貫していることを確認。これは、ブロックの存在は、特定のトランザクションタイプに対して有効であることを確認含み
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.
メッセージは、任意のカプセル化されたデータが含まれている場合は、可能な場合は、適切な場合には、データをチェックするために追加のソフトウェアを使用してエラーのためにカプセル化されたデータを確認してください。
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 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 ...
注：簡略化の理由から、ブロックシーケンスでエラーをチェックする方法の以下の説明では、フレーズは、トランスのRefブロックが参照するIotpTransIdが含まれているIOTPメッセージに含まれている」と解釈され、「IOTPトランザクションを指し、」 」。そのため、たとえば、「エラー場合、またはブロックを解除することは...その後、認識されないIOTPトランザクションを指し、」エラーまたはブロックをキャンセルは、TransのRefブロックが含まれているIOTPメッセージに含まれている場合」として解釈されるべきですその後、認識されないIOTPトランザクションを指しIotpTransId ...
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エラーやブロックを解除してください。エラーまたはキャンセルブロックが認識されないIOTPトランザクションを参照する場合、それはハードエラーです。エラーまたはキャンセルブロックはループを回避するために、前にIOTPトランザクションのために受信された場合、エラーを返しません。
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問い合わせ要求と応答をブロックします。問い合わせ要求や問い合わせ応答ブロックが認識されないIOTPトランザクションを参照する場合、それはハードエラーであります
o Authentication Request Block. If an Authentication Request Block refers to an IOTP transaction that is recognised it is a Hard Error
O認証は、ブロックを要求します。認証要求ブロックが認識されているIOTPトランザクションを参照する場合、それはハードエラーであります
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
- 認証応答ブロックは、それ以外の場合はハードエラーで認識されているIOTPトランザクションを参照していない場合
- if the Authentication Response Block doesn't refer to an Authentication Request that had been previously sent then it is a Hard Error, otherwise
- 認証応答ブロックは、以前に送られた認証要求を参照していないならば、それはそれ以外の場合は、ハードエラーであります
- 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トランザクションの認証応答が以前に受信され、認証が成功した場合、それはハードエラーです。
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
- 認証ステータスブロックは、それ以外の場合はハードエラーで認識されているIOTPトランザクションを参照していない場合
- if the Authentication Status Block doesn't refer to an Authentication Response that had been previously sent then it is a Hard Error, otherwise
- 認証ステータスブロックが以前に送られた認証応答を参照していないならば、それはそれ以外の場合は、ハードエラーであります
- if an Authentication Status for the same IOTP transaction has been received before then it is a Warning Error
- 同じIOTPトランザクションの認証ステータスが以前に受信されている場合、それは警告エラーです
o TPO Selection Block (Merchant only). Check as follows:
O TPOセレクションブロック（マーチャントのみ）。次のように確認してください：
- if the TPO Selection Block doesn't refer to an IOTP Transaction that is recognised then it is a Hard Error, otherwise
- TPO選択ブロックが認識されているIOTPトランザクションを参照していないならば、それはそれ以外の場合は、ハードエラーであります
- 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選択ブロックはTPOブロックとオファーレスポンス（一つのメッセージで）以前に、次に送られていたIOTPトランザクションを参照している場合、それはそうでない場合、ハードエラーであります
- 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選択ブロックはTPOブロックのみ（すなわち、オファーレスポンスなし）以前に、次に送られていたIOTPトランザクションを参照していない場合には、そうでない場合、ハードエラーであります
- if a TPO Selection Block for the same TPO Block has been received before then it is a Hard Error
- 同じTPOブロックのためのTPOの選択ブロックが以前に受信されている場合、それはハードエラーであります
o Payment Request Block (Payment Handler only). Check as follows:
○お支払要求ブロック（支払ハンドラのみ）。次のように確認してください：
- if the Payment Request Block refers to an IOTP Transaction that is not recognised then its OK, otherwise
- 支払要求ブロックがそうでなければ、そのOKを認識されないIOTPトランザクションを参照する場合
- if the Payment Request Block refers to IOTP Transaction that was not for a Payment then it is a Hard Error, otherwise
- 支払要求ブロックが支払いのためではなかったIOTPトランザクションを参照している場合、それはそうでない場合は、ハードエラーであります
- if there was a previous payment that failed with a non-recoverable Completion Code then it is a Hard Error, otherwise
- 回復不能完了コードで失敗した前回の支払いがあった場合、それはそうでない場合は、ハードエラーであります
- if a previous payment is still in progress then it is a Hard Error
- 前回のお支払いがまだ進行中であるならば、それはハードエラーであります
o Payment Exchange Block (Payment Handler only). Check as follows:
○お支払為替ブロック（支払ハンドラのみ）。次のように確認してください：
- if the Payment Exchange Block doesn't refer to an IOTP Transaction that is recognised then it is a Hard Error, otherwise
- お支払い交換ブロックが認識されているIOTPトランザクションを参照していないならば、それはそれ以外の場合は、ハードエラーであります
- if the Payment Exchange doesn't refer to an IOTP Transaction where a Payment Exchange had previously been sent then it a Hard Error
- 支払取引所は、支払取引所は、以前にそれをその後、ハードエラーを送られたIOTPトランザクションを参照していない場合
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配信要求（配信ハンドラのみ）。配信要求ブロックは、サーバーによって認識されたIOTPトランザクションを参照する場合、それはハードエラーであります
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.
任意の誤差成分は、入力メッセージの送信者に送信するための誤りブロックにそれらを収集し、その後、生成されている場合。 1が指定されている場合はエラーブロックは、送信者の取引の役割のために、メッセージの送信者にと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:
注：認証応答および支払請求の順序で上記のチェックは、例えば、前回の1が失敗したため、消費者の再提出リピートアクション要求をサポートしています。
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
ERROR FREE INPUTメッセージを処理
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の取引上のお問合せ要求は無視されるべきです
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、その後、前のメッセージを再送信し、その後、必要な時間を待ちます
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
入力メッセージはHardErrorまたはキャンセルブロックとエラーコンポーネントを含む場合、O、トランザクションのすべてのさらなる処理を停止します。これは、現在生成されているすべてのメッセージの送信または受信された新しい非重複メッセージへの応答を抑制することが含ま
o processing of encapsulated messages (e.g., Payment Protocol Messages) may result in additional transient errors
Oカプセル化メッセージ（例えば、支払プロトコルメッセージ）の処理は、追加の一時的なエラーをもたらす可能性
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.
出力メッセージは、生成された場合、それは、それが同一の入力メッセージが再度受信した場合、必要に応じて再送信することができるように保存されるべきです。入力メッセージが再度受信されたとき、彼らは新たに処理できるように一時的なエラーが含まれている出力メッセージが保存されません注意してください。
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サーバ上で実行中のトランザクションをキャンセルするために使用されます。これは、同じ取引の役割によって運営されている別のシステムまたはサーバからの外部要求の結果として、いくつかの他のプロセスによって開始されます。次のように必要な処理は次のようになります。
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
IotpTransIdはPINGトランザクションを参照している場合、O、次にそれ以外の場合は、要求を失敗さ
o determine which Document Exchange to cancel and generate a Cancel Block and send it to the other party
OドキュメントExchangeがキャンセルするかを決定し、生成ブロックをキャンセルし、相手にそれを送信
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サーバにビジネスの意思決定をしたプロセス/サーバーからメッセージを送信する必要があります。
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搬送機構が使用されています。
o the time required to process encapsulated messages (e.g., Payment messages) and
カプセル化されたメッセージ（例えば、支払メッセージ）を処理するのに必要な時間Oと
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.
何のメッセージが受信されなかった場合は、元のメッセージを再送する必要があります。これは、使用されているトランスポートメカニズムの信頼性に依存する最大回数まで行うべきです。
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:
応答が必要な時間の後に受信されない場合、トランザクションは「タイムアウトした」でなければなりません。この場合には、失敗したトランザクションの処理状態、及びいずれかの完了コードを設定します。
o TimedOutRcvr if the transaction can potentially recovered later, or
トランザクションは、潜在的に後から回復できるかどうTimedOutRcvr O、または
o TimedOutNoRcvr if the transaction is non-recoverable
トランザクションが回復不能である場合TimedOutNoRcvr O
The "Client role" in IOTP is the Consumer Trading Role.
IOTPにおける「クライアントの役割は、」消費者取引の役割です。
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.
注意：購入を行うか、ダウンロードまたは電子現金を引き出す際に商人である会社や組織を、例えば、消費者の取引の役割をとることができます。
More specifically the Consumer Role must be able to:
具体的には消費者の役割のことができるようにする必要があります。
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
- 入力メッセージを処理するサーバーがそれを処理するにはあまりにも忙しい場合は一時的なエラーが発生
- 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、現在のトランザクションをキャンセルする（セクション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を参照）メッセージを再送信します。
The Consumer Role may initiate a number of different types of transaction. Specifically:
消費者の役割は、トランザクションの異なるタイプの数を開始することができます。具体的に：
o an Inquiry Transaction (see section 9.2.1)
お問い合わせトランザクションO（セクション9.2.1を参照してください）
o a Ping Transaction (see section 9.2.2)
PINGトランザクションO（セクション9.2.2を参照してください）
o an Authentication Transaction (see section 9.1.6)
認証トランザクションO（セクション9.1.6を参照）
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サーバ（セクション4.5.2を参照）（IOTP Serverのセクション4.5.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サーバの処理の説明は、入力メッセージと要求のマルチタスクのマルチスレッドの考慮を含みます。特にPCなどのスタンドアロンシステム上で実行されている場合 - - 消費者の役割のためにマルチスレッドを使用することは、消費者の役割IOTPソリューションの実装の決定です。
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サーバーの役割のために置換されていることを除いて（セクション4.5.2.4を参照）IOTPサーバの場合と同じです。
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:
消費者の役割を受け取る可能性があります他のブロックについて、ブロックが到着順に潜在的なエラーがブロックに依存します。シーケンスのチェックが必要とされたブロックは、以下のとおりです。
o TPO Block. Check as follows:
TPOブロックO。次のように確認してください：
- if the input message also contains an Authentication Request block and an Offer Response Block then there is a Hard Error, otherwise
- 入力メッセージも認証要求のブロックとオファー応答ブロックが含まれているならば、そうでない場合は、ハード誤りがあります
- if the input message also contains an Authentication Request block and Authentication Status block then there is Hard Error otherwise,
- 入力メッセージも認証要求のブロックと認証ステータスブロックが含まれている場合、ハードエラーは、そうでない場合があります
- 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
- 入力メッセージも認証要求のブロックが含まれているとIOTPトランザクションは、消費者の役割のシステムによって認識された場合、それ以外の場合は、ハード誤りがあります
- 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
- 入力メッセージも認証ステータスブロックが含まれているとIOTPトランザクションは、消費者の役割のシステムによって認識されないならば、そうでない場合は、ハード誤りがあります
- 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
- 入力メッセージも認証ステータスブロックと認証ステータスが含まれている場合、ブロックは、以前の認証応答メッセージの後に送信されていない、ハードエラーが発生しています
- 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
- 入力メッセージも応答ブロックとIOTPトランザクションは、消費者の役割のシステムによって認識されたオファーが含まれているならば、そうでない場合は、ハード誤りがあります
- 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ブロックが独自に発生し、IOTPトランザクションは、消費者の役割のシステムによって認識されるならば、ハードエラーがあります
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
- オファー応答ブロックは、ブランドの独立したオファーの取引の一部である場合はそう、それは最初のメッセージの一部を受信するようチェック何シーケンスはありません（セクション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
- オファー応答ブロックは、消費者の役割が認識されたIOTPトランザクションの一部でないならば、そうでない場合は、ハード誤りがあります
- 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
- オファー応答ブロックは、TPO選択ブロックは、ハードエラーがある送信された最後のメッセージだったIOTPトランザクションを参照していない場合
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
- お支払いは、Exchangeブロックは、消費者の役割のシステムによって認識されたIOTPトランザクションを参照していないならば、そうでない場合は、ハード誤りがあります
- 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
- 支払Exchangeは支払請求または支払交換ブロックのいずれかが最後に送られたIOTPトランザクションを参照していないならば、ハードエラーがあります
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
- お支払いは、応答ブロックは、消費者の役割のシステムによって認識されたIOTPトランザクションを参照していないならば、そうでない場合は、ハード誤りがあります
- 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
- お支払い応答が支払いの要求または支払交換ブロックのいずれかが最後に送られたiotopのトランザクションを参照していないならば、ハードエラーがあります
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
- 配達が応答ブロックは、消費者の役割のシステムによって認識されたIOTPトランザクションを参照していないならば、そうでない場合は、ハード誤りがあります
- 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
- 配信レスポンスが支払いの要求または支払交換ブロックのいずれかが最後に送られたIOTPトランザクションを参照していない場合は、ハードエラーがあります
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).
このプロセスは、ユーザー、または消費者の役割では、別のシステムまたはサーバからの外部要求の結果として、消費者の役割のシステム上の現在のトランザクションをキャンセルします。処理はIOTPサーバ（セクション4.5.3を参照）と同じです。
The process of retransmitting messages is the same as for an IOTP Server (see section 4.5.4).
メッセージを再送信するプロセスは、IOTPサーバ（セクション4.5.4を参照）と同じです。
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.
このセクションでは、IOTPは、セキュリティをどのように対処するかIETFの観点から、と考えています。次のセクション（see節6.デジタル署名とIOTP）は、これらが必要な場合IOTPは、デジタル署名を使用する方法について説明します。
This section covers:
このセクションでは、説明します。
o determining whether to use digital signatures
デジタル署名を使用するかどうかを決定O
o data privacy, and
Oデータのプライバシー、および
o payment protocol security.
○お支払プロトコルのセキュリティ。
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 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:
最終的にはそれがIOTPメッセージが署名を含め、消費者は署名せずに取引を行うことは許容できるリスクであるかどうかを決定するためになるかどうかを決定するために、マーチャント、または他の取引役割までです。商人は、署名のない取引が受け入れされていないことが判明した場合、彼らはどちらかでしょう：
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マーチャント（または他の取引役割は）彼らが信頼できることを証明したいと考えています。消費者に知られている信頼できるサードパーティからの証明書を使用して（セクション7.19.2を参照してください）例えば、商人はオファーレスポンス署名を生成し、場合、消費者は、署名と証明書を確認することができますので、より合理的に提供に依存しています商人があることを主張する実際の組織からです。この場合、非対称暗号を使用して署名が必要とされる可能性があります
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、特定の目的に適合しているトランザクションのレコードを生成します。例えば、適切な信頼階層で、デジタル署名を決定するために消費者によって確認することができます：
- 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、要求が変更されていないと承認されていることを知っている必要があります。例えば、IOTPに、どのくらい支払うの詳細は、オファーレスポンスで消費者に送信され、その後、支払い要求でのお支払いハンドラに転送されます。リクエストが署名されていない場合、消費者は、数字を取り除く、例えば、原因によって量を変更することができます。支払ハンドラはオファーレスポンスの元の支払い情報へのアクセスを持っていない場合は、その後の署名なしで、支払ハンドラは、データが改ざんされていないことを確認することはできません。支払い情報がデジタル署名されていない場合は同様に、支払ハンドラは支払いを要求している商人が誰であるかを確認することはできません
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, 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.
○お支払ハンドラまたは配達ハンドラは、支払いや配達の完了状況の非反駁記録を提供したいと考えています。支払い応答や配信応答が署名されている場合、消費者は、後でそれが発生したことを証明するために支払いや配達の記録を使用することができます。これは、例えば、顧客ケアの目的のために、使用することができます。
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つの取引役割が決定できるようにということです。取引の役割が必要なデータへのアクセス権を持っている場合しかし、例えば、オファーレスポンスでのお支払い情報とお支払い要求でのお支払い情報を比較することが可能かもしれません。必要なデータへのアクセスをすることによって実現することができ、例えば、マーチャントと支払いハンドラの役割は、同じシステム上で同じ組織によって行われ、または販売及び支払いハンドラの役割は、異なるシステム上で実行されているが、システムはで通信することができますいくつかの方法。 （このタイプの通信注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暗号の処理コストが高すぎます。支払いがわずか数セントで作られている場合たとえば、デジタル署名を生成し、チェックに関連付けられているすべての暗号化を実施するコストは、トランザクション全体が不経済になるかもしれません。取引の役割を同じ場所に配置、この問題を回避するに役立つ可能性があります。
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で対称鍵を使用することの利点は、公開鍵インフラストラクチャを設定する必要はなく、ただ商人、支払いハンドラと配信ハンドラが使用する共有秘密に同意する必要があるということです。
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.
しかし、対称暗号の欠点は、消費者が簡単に彼らが扱っている商人、支払いハンドラなどの資格情報を確認することができないということです。これは、多少、消費者が取引を行う必要があります信頼を削減する可能性があります。
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.
しかし、例えば、オファーレスポンスの署名をチェックする支払ハンドラがにコピーし、非対称暗号化が使用されている場合でも、トランザクションの整合性がで決定されるよう、消費者がどのデジタル証明書を提供する必要はないことに留意すべきです支払い要求。
Note that symmetric, asymmetric or both types of cryptography may be used in a single transaction.
、対称、非対称、または暗号化の両方のタイプは、単一のトランザクションで使用されてもよいことに留意されたいです。
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]などのセキュアなチャネルを使用して、様々な取引ロール間IOTPメッセージを送信することによって提供されます。 IOTP内のセキュアなチャネルの使用はオプションです。
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は互いに結合することができます：オファー、支払いと配達を。
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.セキュリティについての考慮事項を参照してください。
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
IOTPは、デジタル署名を使用する方法の概要O
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.
○お支払ハンドラと配信ハンドラをチェックどのように彼らは商人に代わって支払いや配送を行うことができます。
In general, signatures when used with IOTP:
IOTPと共に使用される場合、一般的に、シグネチャ。
o are always treated as IOTP Components (see section 7)
O常にIOTP成分として扱われる（セクション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同じIOTPトランザクション内の任意IOTPメッセージに、おそらく他の署名コンポーネントを含む1つまたは複数のIOTPコンポーネントまたは取引ブロックのダイジェストを含みます
o identify:
O識別します。
- which Organisation signed (originated) the signature, and
- 組織が署名された署名を（発信）、および
- which Organisation(s) should process the signature in order to check that the Action the Organisation should take can occur.
- その機構（複数可）組織が取るべきアクションが起こり得ることを確認するために、署名を処理しなければなりません。
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.
非対称暗号が使用されている場合、デジタル証明書は、デジタル署名に関連付けられてもよいです。対称暗号が使用されている場合は、その後、デジタル証明書を使用する秘密鍵のいくつかの識別子によって置き換えられます。
The way in which Signatures Components digest one or more elements is illustrated in the figure below.
署名コンポーネントは、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
Elements that are digested can be in any IOTP Message within the same IOTP Transaction *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
消化されている要素は同じIOTPトランザクション内の任意のIOTPメッセージにすることができ* - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - *
Figure 10 Signature Digests
図10署名ダイジェスト
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つのシグネチャの古典的な例は、です "支払領収書」の署名。このように、IOTPトランザクションでのお支払いは、マーチャントの申し出にバインドされています。
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.
1マニフェストは、各値の要素は、おそらく同じ（または異なる）署名アルゴリズムを使用して、異なる証明書または共有秘密鍵を使用して、同じマニフェスト上のデジタル署名を含む複数の署名「値」要素に関連してもよいことに留意されたいです。具体的には、商人が彼らの支払ハンドラと配信ハンドラと異なる共有秘密キーに同意することができます。
The detailed definitions of a Signature component are contained in section 7.19.
署名要素の詳細な定義は、セクション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署名コンポーネント内OriginatorInfoとのRecipientInfo要素が署名に関連付けられている組織を同定するために使用される方法
o how IOTP uses signatures to prove actions complete successfully
O 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).
署名が使用されている方法の例は、ベースライン購買における様々な構成要素及び構成要素が互いにどのように関係するかを示した以下の図に示されています。署名が支払いを確認するために使用されるか、または送達が起こることができる方法の以降の説明ではこの例を参照してください（セクション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.
注：ベースラインの購入取引は、説明の目的のために使用されてきました。要素と属性の使用は、IOTP取引のすべてのタイプのために同じです。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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
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).
署名コンポーネントマニフェスト要素は、ダイジェスト含ま：トランス文献ブロック（図示せず）。トランザクションIDコンポーネント（図示せず）。組織コンポーネント（マーチャント、支払いハンドラ、配達ハンドラ）。ブランドリストコンポーネント。次成分、支払コンポーネント配信コンポーネントとブランドの選択コンポーネント（ブランド依存購入した場合）。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 11 Example use of Signatures for Baseline Purchase
ベースラインの購入のための署名の図11に使用例
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.
署名コンポーネントでOriginatorInfo要素のOriginatorRef属性は、署名を生成した組織の組織構成要素を指す要素リファレンス（セクション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署名タイプに設定Type属性を持つAttribute要素のコンテンツの価値は、それに署名した組織の取引の役割と一致しなければならないことに注意してください。そうでないなら、それは誤りです。有効な組み合わせを以下の表に示されています。
IOTP Signature Type Valid Trading Role
IOTPシグニチャタイプ有効な取引の役割
OfferResponse Merchant
マーチャントOfferResponse
PaymentResponse PaymentHandler
PaymentResponse PaymentHandler
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:
署名コンポーネントでのRecipientInfo要素のRecipientRefs属性はそれを検証するために署名を使用するべき組織の組織構成要素に要素参照が含まれています。
o they have a pre-existing relationship with the Organisation that generated the signature,
O彼らは、署名を生成した組織と既存の関係を持っています
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と価値要素が署名コンポーネント内に可能性があることに留意されたいです。
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属性は、複数の組織コンポーネントを参照することができます。
Proving an action completed successfully, is achieved by signing data on Response messages. Specifically:
正常に完了したアクションを証明する、応答メッセージ上のデータに署名することによって達成されます。具体的に：
o on the Offer Response, when a Merchant is making an Offer to the Consumer which can then be sent to either:
商人は、その後のいずれかに送信することができ、消費者にオファーをしているオファーレスポンス、上のO：
- a Payment Handler to prove that the Merchant authorises Payment, or
- 商人が支払いを承認するか、ということを証明するための支払ハンドラ
- a Delivery Handler to prove that Merchant authorises Delivery, provided other necessary authorisations are complete (see below)
- 配達ハンドラ商人が配信を許可することを証明するために、他の必要な権限を与え完了している（下記参照）
o on the Payment Response, when a Payment Handler is generating a Payment Receipt which can be sent to either:
支払ハンドラは、どちらかに送信することができます支払いの領収書を生成している支払レスポンス、上のO：
- a Delivery Handler, in a Delivery Request Block to authorise Delivery together with the Offer Response signature, or
- 配達オファーレスポンス署名と一緒に配達を許可する配信要求ブロックでハンドラ、または
- another Payment Handler, in a second Payment Request, to authorise the second payment in a Value Exchange IOTP Transaction
- 別のお支払いハンドラは、第二支払い要求に、バリュー交換IOTPトランザクションにおける第二の支払いを承認します
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配信レスポンス、配達ハンドラは、納品書を生成しているとき。これは、配達ハンドラは、彼らがやると言ったものをイベント後に証明するために使用することができます
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。貿易に他の当事者を認証する一つの方法は、デジタル署名を認証用に使用することを指定する認証要求を送信することです
o Transaction Status Inquiry. The Inquiry Response Block may be digitally signed to attest to the authenticity of the response
Oトランザクションステータス照会。問い合わせ応答ブロックは、デジタル応答の真正性を証明するために署名することができます
o Ping. The Ping Response may be digitally signed so that checks can be made that the signature can be understood.
O平。チェックが署名が理解できると判断することができるように、Pingの応答がデジタル署名されてもよいです。
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トランザクションが発生したイベントの後に証明するために使用することができます。顧客ケアプロバイダにたとえば。
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.
正確に計算された署名をチェックすると、メッセージ・レベルのエラー（セクション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:
取引の役割は、署名を確認することができます前に、それをチェックする必要が潜在的に複数の署名要素のかを特定しなければなりません。次のように必要な手順は以下のとおりです。
o check that a Signature Block is present and it contains one or more Signature Components
O署名ブロックが存在し、それが一つ以上の署名コンポーネントが含まれていることを確認してください
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署名チェックを行っている組織のためのORGID属性を含む組織のコンポーネントを識別します。なしまたは複数の組織コンポーネントが、その後発見された場合にはエラーであります
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その組織成分を意味するRecipientRefs属性が含まれているのRecipientInfo要素を見つけるために、組織コンポーネントのID属性を使用します。検証する一切の署名がない場合があります
o check the Signature Component that contains the identified RecipientInfo element as follows:
O次のように識別されるのRecipientInfo要素が含まれている署名コンポーネントを確認してください。
- 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
次に、チェックされる署名と署名を検証するために使用される署名アルゴリズムを記載している署名アルゴリズム要素を含むValue要素を： - SignatureValueRefを使用しSignatureAlgorithmRefは、それぞれ識別するための属性
- 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
- 署名アルゴリズム素子が非対称暗号が使用されていることを示す場合、署名アルゴリズムによって使用される証明書を特定するためにSignatureCertRefを使用
- 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
- 署名アルゴリズム要素は、対称暗号化は、その後使用されていることを示す場合のRecipientInfo元素の含有量は、使用する正しい共有秘密鍵を識別するために使用され
- use the specified signature algorithm to check that the Value Element correctly signs the 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.
- ダイジェストで参照されるコンポーネントまたはブロックは署名をチェックする機関が受信されているところManifest要素でのダイジェスト要素が正しく計算されていることを確認してください。
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.
このセクションでは、支払いや配送が発生する可能性があることを確認するために支払いハンドラや配達ハンドラのために必要なプロセスを説明します。これは、これは商人によって指定された場合、署名をチェックが含まれます。
In outline the steps are:
アウトラインでは手順は次のとおりです。
o check that the Payment Request or Delivery Request has been sent to the correct 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または配信要求ブロック（セクション8.7を参照してください）（セクション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「の応答ブロックが」支払い応答ブロックのいずれかを参照するために使用されているか、配達応答ブロック（セクション8.9を参照してください）（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「アクション」要求ブロックの受信時に発生するアクションを参照するために使用されます。アクションは、お支払いや配達のいずれかになります
o an "Action Organisation", is used to refer to the Payment Handler or Delivery Handler that carries out an Action
「アクション組織」O、アクションを実行する支払ハンドラまたは配達ハンドラを参照するために使用されます
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、全体的または部分的のいずれかで、アクションを許可するアクションに関するデータを署名する組織を指すために使用されます
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、彼らはアクションを実行するために許可されているかどうかを判断するために、データを検証する組織を参照するために使用されます
o an ActionOrgRef attribute contains Element References which can be used to identify the "Action Organisation" that should carry out an Action
O ActionOrgRef属性は、アクションを実行する必要があり、「アクション組織」を識別するために使用することができる要素参照が含まれています
Checking the Request Block was sent to the correct Organisation varies depending on whether the request refers to a Payment or a Delivery.
ブロックが正しい組織に送られたリクエストをチェックすると、要求が支払いや配達を参照するかどうかによって異なります。
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.
アウトラインでのお支払いハンドラをチェックし、それがその後、組織を識別するために、ブランドの一覧やブランドセレクションコンポーネントを通じて追跡するために、支払コンポーネントのIDを使用して、それが受信した支払要求ブロックでのお支払いのコンポーネントを識別することによって支払を受け入れるか、作ることができるかどうか消費者が選択した後、この組織が自身であることを確認します。
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)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 12 Checking a Payment Handler can carry out a Payment
支払ハンドラを確認する。図12は、支払いを行うことが可能
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受信した支払要求ブロックに（セクション7.9を参照）支払コンポーネントを識別。
o Identify the Brand List and Brand Selection Components for the Payment Component. This involves:
○お支払コンポーネントのブランド一覧やブランドの選択コンポーネントを識別します。これには、次
- 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属性の値が支払コンポーネントのBrandListRef属性にマッチするブランドリストコンポーネントを（セクション7.7を参照）を特定します。何か複数のブランドリストコンポーネントが見つからない場合はエラーがあります。
- 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属性の値が支払コンポーネントのBrandListRefと一致するブランドセレクションコンポーネント（セクション7.8を参照）を特定します。何か複数の一致ブランドセレクションコンポーネントが見つからない場合はエラーがあります。
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ブランド、議定書の金額、次のように消費者によって選択されたブランド一覧以内にお支払いプロトコルおよび通貨額の要素を識別します。
- 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.
- ブランド要素（セクション7.7.1を参照）を選択し、そのid属性の値は、ブランド選択におけるBrandRef属性の値と一致する要素です。何か複数の一致ブランド要素が見つからない場合は、エラーがあります。
- 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
- 選択されたプロトコル量要素（セクション7.7.3を参照）、そのid属性の値は、ブランド選択コンポーネントでProtocolAmountRef属性の値と一致する要素です。プロトコル金額要素に一致するか2つ以上が見つからない場合はエラーがあります
- 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
- 選択された支払プロトコル要素（セクション7.7.5を参照）、そのid属性の値が特定プロトコル量要素内PayProtocolRef属性の値と一致する要素です。何か複数の一致ペイプロトコル要素が見つからない場合はエラーがあります
- 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
- 選択した通貨額要素（セクション7.7.4を参照）、そのid属性の値は、ブランド選択コンポーネントでCurrencyAmountRef属性の値と一致する要素です。何か複数の一致通貨額の要素が見つかった場合、エラーはありません
o Check the consistency of the references in the Brand List and Brand Selection Components:
Oブランド一覧やブランドセレクションコンポーネント内の参照の整合性を確認します。
- 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
- 要素のリファレンスが特定のプロトコル金額要素のid属性に一致する識別ブランド要素のProtocolAmountRefs属性に存在することを確認してください。要素のリファレンスに一致するか2つ以上が見つからない場合はエラーがあります
- 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.
- 識別プロトコル金額要素のCurrencyAmountRefs属性が特定の通貨金額要素のid属性に一致する要素の参照が含まれていることを確認してください。何か複数の一致要素のリファレンスが見つからない場合はエラーがあります。
- 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.
- ブランドリスト内の要素の整合性をチェック。具体的には、選択したブランド、議定書の金額、支払プロトコルおよび通貨金額の要素が特定ブランドリストコンポーネントのすべての子要素です。そうでない場合はエラーがあります。
o Check that the Payment Handler that received the Payment Request Block is the Payment Handler selected by the Consumer. This involves:
○お支払要求ブロックを受け取った支払ハンドラは、消費者が選択した支払ハンドラであることを確認してください。これには、次
- 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
- お支払いハンドラのための組織コンポーネントを特定します。これは、そのID属性が識別ペイプロトコル要素でActionOrgRef属性にマッチする組織コンポーネントです。組織コンポーネントが一致するか2つ以上が見つからない場合はエラーがあります
- checking the Organisation Component has a Trading Role Element with a Role attribute of PaymentHandler. If not there is an error
- 組織コンポーネントをチェックするPaymentHandlerの役割属性を持つ取引Role要素を持っています。ない場合はエラーがあります
- finally, if the identified Organisation Component is not the same as the Organisation that received the Payment Request Block, then there is an error.
- 識別された組織コンポーネントが支払要求ブロックを受けた組織と同じではない場合、最終的には、エラーがあります。
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.
データは、それが送達を行うことができることを確認するために、配信ハンドラによってアクセスされる方法は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Start | v Delivery Component | |ActionOrgRef | v Organisation Component | -Trading Role Element (Delivery Handler)
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *スタート| V配信コンポーネント| | ActionOrgRef | V機構部品| -Trading Role要素（配達ハンドラ）
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 13 Checking a Delivery Handler can carry out a Delivery
配信ハンドラの確認図13は、配信を行うことが可能
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配信要求ブロックで配信コンポーネントを識別します。なしまたは複数の一致配信コンポーネントがある場合はエラーがあります
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配信ハンドラの組織コンポーネントを識別するために、出荷コンポーネントのActionOrgRef属性を使用します。組織コンポーネント一致するか、複数存在しない場合はエラーが発生します
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
配達ハンドラのための組織コンポーネントがDeliveryHandlerの役割属性を持つ取引Role要素を持っていない場合はOエラーが発生しました
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最後に、ブロック配信ハンドラとして自身のために組織のコンポーネントを識別しない配信要求を受信した機関は、エラーがある場合。
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).
正しいコンポーネントが支払要求ブロックに存在する（8.7節を参照）、または配信要求ブロック（セクション8.10を参照）であることを確認してください。
If components are missing, there is an error.
コンポーネントが含まれていない場合、エラーがあります。
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.
前の手順は、アクション組織を特定し、必要なすべてのコンポーネントが存在していること。このステップでは、アクション機関がアクションを実行するために許可されていることを確認します。
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.
アクション機関がマーチャントを識別しますアウトラインでは、それはそれはアクションを実行することができますし、その合意により暗示いかなる制約が守られていること、そして、署名が必要な場合は、そのチェック商人との既存の契約を締結していることを確認彼らは正しいデータに署名すること。
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要素で組織コンポーネントです。何かつ以上の取引Role要素が見つからない場合は、エラーがあります
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商人とアクション組織の合意を確認してくださいアクションを行うことができるようになります。これを行うにはアクションの組織はそれを確認する必要があります。
- the Merchant is known and a pre-existing agreement exists for the Action Organisation to be their agent for the payment or delivery
- 商人が知られており、既存の契約は、支払いや配送のために彼らの物質であることが行動の組織のために存在しています
- 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トランザクションの種類に参加することを許可されています。例えば支払ハンドラは、ベースライン購入の一部として支払いを受け入れることに合意したことはなく、ベースライン払い戻しの一部として支払いを行います
- any constraints in their agreement with the Merchant are being followed, for example, whether or not an Offer Response signature is required
- マーチャントとの契約における任意の制約は、オファーレスポンスの署名が必要であるか否か、例えば、守られています
o Check the signatures are correct. If signatures are required then they need to be checked. This involves:
O署名が正しいことを確認してください。署名が必要とされている場合、それらをチェックする必要があります。これには、次
- 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
- チェックするために、正しい署名を特定します。これは、アクション機構（6.3.1を参照）への参照を含む署名コンポーネントを特定するアクション機構を必要とします。行われIOTPトランザクションに応じて、1つのまたは2つのシグネチャを識別することができる（セクション9を参照）
- 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).
- 署名コンポーネントが正しいことを確認します。これは、ダイジェスト要素が必要な取引の構成要素を指すマニフェスト要素内に存在することをチェックすることを含む（セクション6.3.3.1を参照）。
All Signature Components contained within IOTP Messages must include Digest elements that refer to:
IOTPメッセージ内に含まれるすべての署名コンポーネントを参照するダイジェスト要素を含める必要があります。
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
トランザクションIDコンポーネントO（セクション3.3.1を参照）署名要素を含んIOTPメッセージ。これはIOTPトランザクションを構成する他のコンポーネントにグローバルにユニークな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).
署名を含んでいた最初のIOTPメッセージのトランザクション参照ブロックO（3.3節を参照）。これは、メッセージIDコンポーネント内に含まれているIOTPメッセージ（セクション3.3.2を参照）に関する情報をIotpTransIdをバインドします。
Check that each Signature Component contains Digest elements that refer to the correct data required.
各署名コンポーネントが必要な正しいデータを参照するダイジェスト要素が含まれていることを確認してください。
The Digest elements that need to be present depend on the Trading Role of the Organisation which generated (signed) the signature:
本（符号付き）が発生機関の取引の役割に依存する必要がダイジェスト要素署名：
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
- ダイジェスト要素はオプションであるブランドの選択コンポーネントから離れ要求ブロック内のすべてのコンポーネントのために存在しなければなりません
o if the signer of the signature is a Payment Handler then Digest elements must be present for:
署名の署名者が支払いハンドラである場合にO次いでダイジェスト要素はのために存在しなければなりません。
- the Signature Component signed by the Merchant, and optionally
- 署名コンポーネントは、マーチャントによって署名され、そして必要に応じて
- one or more Signature Components signed by the previous Payment Handler(s) in the Transaction.
- トランザクションの前の支払いハンドラ（S）によって署名された一つ以上の署名コンポーネント。
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内で使用される取引のコンポーネントについて説明します。取引コンポーネントは、次の図に示すように、貿易ブロックの直下に発生した子XML要素です。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 14 Trading Components
図14のトレーディングコンポーネント
The Trading Components described in this section are listed below in approximately the sequence they are likely to be used:
このセクションで説明する取引コンポーネントは、それらが使用される可能性が高い約順に次のとおりです。
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 Payment Scheme Component
○お支払スキームコンポーネント
o Payment Receipt Component
○お支払領収書のコンポーネント
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トランザクションIDコンポーネント（セクション3.3.1を参照してください）
o Message Id Component (see section 3.3.2)
メッセージIDコンポーネント（セクション3.3.2を参照）O
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トランザクションに適用されるオプションです。基本的に、それは全体の取引と消費者の役割は、IOTPトランザクションが成功した場合に分岐するネット場所の短い説明を提供します。
The definition of a Protocol Options Component is as follows.
次のようにプロトコル・オプション・コンポーネントの定義があります。
<!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.
ID一意IOTPトランザクション内プロトコルオプションコンポーネントを識別する識別子。
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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
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.
LANG：shortDesc属性これはXMLで定義された言語でIOTPトランザクションの簡単な説明が含まれています。その目的は、当事者間で行われているIOTPトランザクションの種類の説明を提供することです。
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.
SenderNetLocn This contains the non secured net location of the sender of the TPO Block in which the Protocol Options Component is contained.
SenderNetLocnこれはプロトコル・オプションのコンポーネントが含まれているTPOブロックの送信者の不安全なネットの場所が含まれています。
It is the net location to which the recipient of
the TPO block should send a TPO Selection Block
if required.
The content of this attribute is dependent on the Transport Mechanism see the 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これはプロトコル・オプションのコンポーネントが含まれているTPOブロックの送信者の安全なネットロケーションが含まれています。
The content of this attribute is dependent on
the Transport Mechanism see the Transport
Mechanism Supplement.
SuccessNetLocn This contains the net location that should be displayed after the IOTP Transaction has successfully completed.
SuccessNetLocnこれはIOTPトランザクションが正常に完了した後に表示されなければならないネットの場所が含まれています。
The content of this attribute is dependent on
the Transport Mechanism see the Transport
Mechanism Supplement.
Either SenderNetLocn, SecureSenderNetLocn or both must be present.
SenderNetLocn、SecureSenderNetLocnのいずれか、または両方が存在しなければなりません。
This Trading Component contains parameter data that is used in an Authentication of one Trading Role by another. Its definition is as follows.
この取引コンポーネントは別で1つの取引の役割の認証に使用されているパラメータデータが含まれています。次のようにその定義があります。
<!ELEMENT AuthReq (Algorithm, PackagedContent*)> <!ATTLIST AuthReq ID ID #REQUIRED AuthenticationId CDATA #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT AUTHREQ（アルゴリズム、PackagedContent *）> <！ATTLIST AUTHREQ ID ID #REQUIRED AuthenticationId CDATA #REQUIRED ContentSoftwareId CDATA #IMPLIED>
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.
必要に応じてアルゴリズムは、その計算に認証要求コンポーネント内にパッケージ化されたコンテンツの要素に含まれる、チャレンジデータを使用することができます。パッケージ化されたコンテンツのフォーマットは、アルゴリズムに依存しています。
Attributes:
属性：
ID An identifier which uniquely identifies the Authentication Request Component within the IOTP Transaction.
ID一意IOTPトランザクション内の認証要求コンポーネントを識別する識別子。
AuthenticationId An identifier specified by the Authenticator which, if returned by the Organisation that receives the Authentication Request, will enable the Authenticator to identify which Authentication is being referred to.
認証要求を受信する組織によって戻される場合は、認証が参照されている識別するための認証を可能にする認証システムによって指定された識別子をAuthenticationId。
ContentSoftwareId See section 14.Glossary
セクション14.Glossaryを参照してくださいContentSoftwareId
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これは、アルゴリズムの要素によって定義されたアルゴリズムを使用して対応すること（セクション3.7を参照）は、1つまたは複数のパッケージ化されたコンテンツとしてのチャレンジデータが含まれています。
Algorithm This contains information which describes the Algorithm (see 7.19 Signature Components) that must be used to generate the Authentication Response.
アルゴリズムこれは、認証応答を生成するために使用されなければならないアルゴリズムを記述する情報（7.19署名コンポーネントを参照）を含みます。
The Algorithms that may be used are identified by
the Name attribute of the Algorithm element. For
valid values see section 12. IANA Considerations.
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).
認証応答コンポーネントは、認証要求の結果が含まれています。それが認証要求ブロックから選択した認証要求コンポーネント（セクション7.2を参照）に含まれているアルゴリズムを使用して（セクション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.
選択されたアルゴリズムに応じて、アルゴリズムを適用した結果は、署名コンポーネント符号が認証応答、潜在的に他のデータの両方に、または認証応答コンポーネント内にパッケージングされたコンテンツ要素に含まれることになるのいずれか。次のようにその定義があります。
<!ELEMENT AuthResp (PackagedContent*) > <!ATTLIST AuthResp ID ID #REQUIRED AuthenticationId CDATA #REQUIRED SelectedAlgorithmRef NMTOKEN #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT AuthResp（PackagedContent *）> <！ATTLIST AuthResp ID ID #REQUIRED AuthenticationId CDATA #REQUIRED SelectedAlgorithmRef NMTOKEN #REQUIRED ContentSoftwareId CDATA #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Authentication Response Component within the IOTP Transaction.
ID一意IOTPトランザクション内で認証応答コンポーネントを識別する識別子。
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.
認証要求コンポーネントに含まれた認証で指定された認証識別子をAuthenticationId（セクション7.2を参照）。これは、参照されている認証を識別するための認証を可能にします。
SelectedAlgorithmRef An Element Reference that identifies the Algorithm element used to generate the Authentication Response.
認証応答を生成するために使用されるアルゴリズムの要素を識別しSelectedAlgorithmRefアン要素のリファレンス。
ContentSoftwareId See section 14.Glossary.
セクション14.Glossaryを参照してくださいContentSoftwareId。
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これは、コンポーネントは、セクション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.
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.
この取引コンポーネントは、情報が要求されているかについての取引の役割（セクション2.1を参照）のリストが含まれています。トレーディング役割要求の結果は、要求された取引の役割のそれぞれを記述する組織コンポーネントのセット（セクション7.6を参照）です。
Example usage includes:
使用例が含まれています：
o a Merchant requesting that a Consumer provides Organisation Components for the Consumer and DelivTo Trading Roles
消費者は、消費者とDelivTo取引の役割の組織コンポーネントを提供することを要求している商人O
o a Consumer requesting from a Merchant, information about the Payment Handlers and Delivery Handlers that the Merchant uses.
マーチャントからの要求の消費者O、商人が使用する支払ハンドラと配信ハンドラに関する情報。
Its definition is as follows.
次のようにその定義があります。
<!ELEMENT TradingRoleInfoReq EMPTY> <!ATTLIST TradingRoleInfoReq ID ID #REQUIRED TradingRoleList NMTOKENS #REQUIRED >
<！ELEMENT TradingRoleInfoReq EMPTY> <！ATTLIST TradingRoleInfoReq ID ID #REQUIRED TradingRoleList NMTOKENS #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Trading Role Information Request Component within the IOTP Transaction.
ID一意IOTPトランザクション内の取引ロール情報要求コンポーネントを識別する識別子。
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.
情報が要求されている - TradingRoleListは、一つ以上の取引の役割（セクション7.6.2取引Role要素のTradingRole属性を参照）のリストが含まれています。
An Order Component contains information about an order. Its definition is as follows.
注文コンポーネントは、順序に関する情報が含まれています。次のようにその定義があります。
<!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注文（PackagedContent *）> <ATTLIST注文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.
ID一意IOTPトランザクション内の次成分を識別する識別子。
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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
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これは、オーダーの作成者が順序を識別するために使用することができるコード、参照番号又は他の識別子です。それはIOTPトランザクション内で一意でなければなりません。それはこのように使用されている場合、それは参照として受注要素の任意のコンテンツを指定する必要を削除することがあり、データベース内の必要な情報を検索するために使用することができます。
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 orders, for example from a database of orders which has been stored by a Consumer, Merchant, etc.
XMLで定義された言語のための短い説明をshortDesc属性：langの。消費者、販売者、等によって記憶された注文のデータベースから、例えば、注文のリストから個々の注文を選択容易にするために使用されます
OkFrom The date and time in [UTC] format after which the offer made by the Merchant lapses.
OkFromオファーが商人の経過によってなされた後、[UTC]の形式で日付と時刻。
OkTo The date and time in [UTC] format before which a Value Acquirer may accept the offer made by the Merchant is not valid.
バリュー買が商人によって行われた提案を受け入れる可能性がある前に、[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.
LANG問題や紛争を解決に適用される管轄の州や国を記述する：XMLで定義された言語でのフレーズをApplicableLaw。
ContentSoftwareId See section 14.Glossary.
セクション14.Glossaryを参照してくださいContentSoftwareId。
Content:
コンテンツ：
PackagedContent An optional description of the order information as one or more Packaged Contents (see section 3.7).
一つ以上のパッケージコンテンツ（セクション3.7を参照）などの注文情報の説明（オプション）をPackagedContent。
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.
パッケージ化されたコンテンツ要素は、通常、購入に関する十分な情報がshortDesc属性属性で提供することができる場所が、それは省略することができ、必要になります。フルオーダ説明がそれを必要とする場合、いくつかのパッケージ化されたコンテンツ要素を使用することができます。
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.
量および通貨がオーダ説明のパッケージ化されたコンテンツに表示される可能性があるものの、それは権威である支払関連取引コンポーネント（ブランド一覧、ブランド選択とお支払い）に含まれる量および通貨です。 （支払関連取引コンポーネントに含まれる）実際に支払われる金額が目立つように消費者に表示されることが重要であることを意味します。
For interoperability, implementations must support Plain Text, HTML and XML as a minimum so that it can be easily displayed.
それは簡単に表示できるように相互運用性のため、実装が最小とプレーンテキスト、HTMLやXMLをサポートしている必要があります。
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
この注文に関連付けられている（セクション7.9を参照）OkFrom日が支払コンポーネントの後OkFrom日付よりもよい、O、及び
o similarly, the OkTo date may be earlier that the OkTo date on the Payment Component (see section 7.9).
O同様に、OkTo日は（セクション7.9を参照）支払コンポーネント上OkTo日付それ以前であってもよいです。
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
OkFromとOkToタイムスタンプoをオファーの有効性を指定
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日付はオーダ説明のパッケージ化されたコンテンツに表示される可能性があるが、それは権威のある次成分に含まれる日付であることに注意してください。 OkFromとOkToが実際に使用されている日付が目立つように消費者に表示されることが重要であることを意味します。
The Organisation Component provides information about an individual or an Organisation. This can be used for a variety of purposes. For example:
組織コンポーネントは、個人または組織に関する情報を提供します。これは、様々な目的のために使用することができます。例えば：
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は支払ハンドラになります誰が説明します。
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メッセージ中に存在しなければならない組織のコンポーネントが実行されている特定のトランザクションに依存していることに留意されたいです。詳細については、セクション9インターネットオープン取引議定書の取引を参照してください。
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 >
<！ELEMENT組織（TradingRole +、のContactInfo？PersonNameの?,のPostalAddress？）> <ATTLIST組織ID ID #REQUIREDのXML：LANG NMTOKEN #REQUIRED ORGID CDATA #REQUIRED氏名権CDATA #IMPLIED shortDesc属性CDATA #IMPLIED LogoNetLocn CDATA #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Organisation Component within the IOTP Transaction.
ID一意IOTPトランザクション内組織成分を識別する識別子。
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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
OrgId A code which identifies the Organisation described by the Organisation Component. See 7.6.1 Organisation IDs, below.
組織コンポーネントによって記述さ組織を識別するコードをORGID。以下、7.6.1組織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.
LANG：これはXMLで定義された言語での正式名称である企業組織のために氏名権。これは、消費者やDelivTo以外の取引の役割を持っている組織のために必要とされます。
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で定義された言語での組織の短い説明をshortDesc属性：langの。それは、典型的には、組織が一般的に知られている名前です。例えば、正式名称は「ブルー・メドウズ・ファイナンシャル・サービス株式会社」だった場合。そして、その短い名前はおそらく、「ブルー・メドウズ」になります。
It is used to facilitate selecting an individual
Organisation from a list of Organisations, for
example from a database of Organisations involved in IOTP Transactions which has been stored by a
consumer.
LogoNetLocn The net location which can be used to download the logo for the Organisation.
組織のロゴをダウンロードするために使用することができ、ネット場所をLogoNetLocn。
See section 10 Retrieving Logos.
セクション10は、ロゴの取得を参照してください。
The content of this attribute must conform to [RFC1738].
この属性の内容は、[RFC1738]に準拠する必要があります。
Content:
コンテンツ：
TradingRole See 7.6.2 Trading Role Element below.
TradingRoleは、以下の7.6.2取引Role要素を参照してください。
ContactInfo See 7.6.3 Contact Information Element below.
ContactInfoは、以下の7.6.3連絡先情報要素を参照してください。
PersonName See 7.6.4 Person Name below.
PersonNameのは、以下の7.6.4人名を参照してください。
PostalAddress See 7.6.5 Postal Address below.
PostalAddressは、以下の7.6.5住所を参照してください。
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は別のものを識別するために、1つのIOTP貿易の役割で使用されています。混乱を避けるために、これは、これらの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組織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,
消費者取引の役割のための組織IDは、IOTPトランザクション内の他の取引の役割の一つによって割り当てられ、その他のロール組織IDとそれを連結することで独自の作られて、O
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一度消費者は、同じ組織IDがその消費者を識別するために、そのIOTPトランザクション内の他のすべての取引の役割で使用されているIOTPトランザクション内組織IDを割り当てられています。
Specifically, the content of the Organisation ID is defined as follows:
次のように具体的には、組織IDの内容が定義されています。
OrgId ::= NonConsumerOrgId | ConsumerOrgId
NonConsumerOrgId ::= DomainName
ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId
ConsumerOrgIdPrefix ::= "Consumer:"
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
ConsumerOrgId消費者のための組織IDの構成は次のとおりです。続い組織IDが消費者のためのものであることを識別するための標準の接頭辞、O、
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.
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、これは組織コンポーネントによって記述されている非消費者団体の正規名が含まれています。 NonConsumerOrgIdを一意にするために、必要に応じて、[DNS]オプションで追加の文字が続くを参照してください。
Note that a NonConsumerOrgId may not start with
the ConsumerOrgIdPrefix.
Use of upper and lower case is not significant.
大文字と小文字の使用は重要ではありません。
Examples of Organisation Ids follow:
組織IDの例としては、次のとおりです。
o newjerseybooks.com - a merchant Organisation id
O newjerseybooks.com - 商人の組織ID
o westernbank.co.uk - a Payment Handler Organisation id
westernbank.co.uk O - 支払いハンドラ組織ID
o consumer:1000247ABH/newjerseybooks.com - a consumer Organisation id allocated by a merchant
Oコンシューマ：1000247ABH / newjerseybooks.com - 商人によって割り当てられた消費者団体のID
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トランザクションにおける個人または組織の取引役割を識別します。注意、組織は、複数の取引の役割を有することができ、いくつかの役割は、1つの組織要素中に存在することができます。次のようにその定義は次のとおりです。
<!ELEMENT TradingRole EMPTY > <!ATTLIST TradingRole ID ID #REQUIRED TradingRole NMTOKEN #REQUIRED IotpMsgIdPrefix NMTOKEN #REQUIRED CancelNetLocn CDATA #IMPLIED ErrorNetLocn CDATA #IMPLIED
<！ELEMENT TradingRole EMPTY> <！ATTLIST TradingRole ID ID #REQUIRED TradingRole NMTOKEN #REQUIRED IotpMsgIdPrefix NMTOKEN #REQUIRED CancelNetLocn CDATA #IMPLIED ErrorNetLocn CDATA #IMPLIED
ErrorLogNetLocn CDATA #IMPLIED >
ErrorLogNetLocn CDATA #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Trading Role Element within the IOTP Transaction.
ID一意IOTPトランザクション内トレーディングRole要素を識別する識別子。
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。有効な値は以下のとおりです。Oの消費者。 IOTP取引における消費者の役割で行動している個人または組織。 Oの商人。 IOTPトランザクションにおける商人の役割で行動している個人または組織。 PaymentHandler O。 DeliveryHandler O IOTPトランザクションの支払ハンドラである金融機関やその他の組織。 DelivTo O IOTPトランザクションのための商品やサービスを提供している個人または組織。 CustCare O IOTPトランザクションで商品やサービスの提供を受けている人や組織。 IOTPトランザクションのための顧客ケアを提供します組織および/または個々の。
Values of TradingRole are controlled under the
procedures defined in section 12 IANA
Considerations which also allows user defined
values to be defined.
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は、このIOTPトランザクションにおける貿易の役割によって送信されたすべてのIOTPメッセージに使用しなければならない接頭辞が含まれています。使用する値は、3.4.1 IOTPメッセージID属性定義で定義されています。
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.
CancelNetLocnこれは、消費者は、消費者が何らかの理由で取引をキャンセルした場合に行くべき場所のネットの場所が含まれています。特定の取引の状況に、より適合した応答を提供するために、取引の役割で使用することができます。
This attribute:
o must not be present when TradingRole is set to
Consumer role or DelivTo,
o must be present when TradingRole is set to Merchant, PaymentHandler or DeliveryHandler.
TradingRoleは商人、PaymentHandlerまたはDeliveryHandlerに設定されている場合oが存在している必要があります。
The content of this attribute is dependent on the Transport Mechanism see the 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.
消費者はを続行しないことを決定した警告が、O HardError、O：ErrorNetLocnこれは、消費者が受け取ったかのいずれかに設定重大度属性を持つエラーコンポーネントを含むエラーブロックを生成したか、後に消費者によって表示されるべきであるネットの場所が含まれていますTransientErrorとトランザクションOトランザクションは、その後タイムアウトしました。
See section 7.21.1 Error Processing Guidelines for
more details.
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.
この属性：TradingRoleは商人、PaymentHandlerまたはDeliveryHandlerに設定されている場合TradingRoleは、消費者やDelivToに設定されている場合oは存在してはならない、oが存在しなければなりません。
The content of this attribute is dependent on the Transport Mechanism see the 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オプション。 HardError O、警告が、消費者がTransientError Oトランザクションを続行しないことを決定し、トランザクションがその後、時限あり○：これは、消費者はのいずれかに設定する重大度属性を持つエラーコンポーネントでエラーブロックが含まれているIOTPメッセージを送信する必要があり、ネットの場所が含まれていますでる。
This attribute:
o must not be present when TradingRole is set to
Consumer role,
o must be present when TradingRole is set to Merchant, PaymentHandler or DeliveryHandler.
TradingRoleは商人、PaymentHandlerまたはDeliveryHandlerに設定されている場合oが存在している必要があります。
The content of this attribute is dependent on the Transport Mechanism see the 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.
ErrorLogNetLocnは、ソフトウェア会社または着信メッセージを送っソフトウェアにおける問題を解決する責任いくつかの他の組織にエラーメッセージを送信するために使用することができます。詳細については、セクション7.21.1エラー処理のガイドラインを参照してください。
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.
これは、組織または個人への連絡に使用できる情報が含まれています。すべての属性は、しかし、連絡先情報の少なくとも1つのアイテムが存在しなければならないオプションです。次のようにその定義があります。
<!ELEMENT ContactInfo EMPTY > <!ATTLIST ContactInfo xml:lang NMTOKEN #IMPLIED Tel CDATA #IMPLIED Fax CDATA #IMPLIED Email CDATA #IMPLIED NetLocn CDATA #IMPLIED >
<！ELEMENTのContactInfo EMPTY> <！ATTLISTのContactInfoのxml：langのNMTOKEN #IMPLIED電話CDATA #IMPLIEDファックスCDATA #IMPLIEDメールCDATA #IMPLIED NetLocn CDATA #IMPLIED>
Attributes:
属性：
xml:lang Defines the language used by attributes within this element. See section 3.8 Identifying Languages.
XML：langは、この要素内の属性で使用される言語を定義します。セクション3.8は、言語の識別を参照してください。
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.
TEL組織を接触させることができるそれによって電話番号。これはテキストフィールドで、何の検証がそれに行われないことに注意してください。
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.
組織が連絡されるかもしれないファックス番号をファックス。これはテキストフィールドで、何の検証がそれに行われないことに注意してください。
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].
組織が連絡されるかもしれないメールアドレスにメールで知らせます。このフィールドは、[RFC822]に含まれるアドレスの仕様のための規則に準拠する必要があることに注意してください。
NetLocn A location on the Internet by which information about the Organisation may be obtained that can be displayed using a web browser.
ウェブブラウザを用いて表示することができる組織に関する情報を得ることができることにより、インターネット上の場所NetLocn。
The content of this attribute must conform to
[RFC1738].
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タイトルCDATA #IMPLIED GIVENNAME CDATA #IMPLIEDイニシャル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は、この要素内の属性で使用される言語を定義します。セクション3.8は、言語の識別を参照してください。
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)
タイトル独特の名前。遺伝性かどうか個人的な名称、事務所（例えば、裁判官、市長）や貴族示すまたは暗示する（例えば、公爵、公爵夫人を、伯爵）、またはアドレッシングや人（例えば、ミスター、ミセス、ミス）を参照して使用
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。それ以外の場合は最初の名前やキリスト教の名前として知られています。
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.
人は自分の家族、友人や知人によって間知られている、または識別されることにより、（指定された名前以外の）二名の最初の文字を頭文字。
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で。それは、典型的には、子供たちに親によって渡される個人の名前の一部です。
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住所1 CDATA #IMPLIED住所2 CDATA #IMPLIED CityOrTown CDATA #IMPLIED StateOrRegion CDATA #IMPLIED郵便番号CDATA #IMPLIED国CDATA #IMPLIED LegalLocation（TRUE | FALSE） '偽'>
Attributes:
属性：
xml:lang Defines the language used by attributes within this element. See section 3.8 Identifying Languages.
XML：langは、この要素内の属性で使用される言語を定義します。セクション3.8は、言語の識別を参照してください。
AddressLine1 The first line of a postal address. e.g., "The Meadows"
住所1住所の最初の行。例えば、「メドウズ」
AddressLine2 The second line of a postal address. e.g., "Sandy Lane"
住所2住所の2行目。例えば、「サンディレイン」
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"
例えば郵便番号または郵便番号、として知られているコードを郵便番号、それは、典型的には、効率的なシーケンスに郵便配達を整理する郵便組織によって使用されます。例えば、 "KT22 1AA"
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これは、アドレスが組織のために登録されたアドレスであるかどうかを識別する。取引の役割は消費者やDeliverToのいずれかでなければ、組織のための少なくとも1つのアドレスがTrueに設定された値を持っている必要があります。
Brand List Components are contained within the Trading Protocol Options Block (see section 8.1) of the IOTP Transaction. They contains lists of:
ブランド一覧コンポーネントはIOTPトランザクションの取引プロトコル・オプションブロック（セクション8.1を参照）の中に含まれています。彼らはのリストが含まれています。
o payment Brands (see also section 11.1 Brand Definitions and Brand Selection),
○お支払ブランド（また、セクション11.1ブランドの定義とブランドの選択を参照）、
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、および
o the net locations of the Payment Handlers which accept payment for a payment protocol
支払プロトコルのための支払を受け入れる支払ハンドラのネットの位置O
The definition of a Brand List Component is as follows.
次のようにブランドリストコンポーネントの定義があります。
<!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.
ID一意IOTPトランザクション内ブランドリストコンポーネントを識別する識別子。
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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
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属性：ラングはブランド一覧の目的の詳細を与えます。この情報は、選択を行うことを支援するために、ブランドのリストの受信機に表示されなければなりません。それはIOTPトランザクションが複数の支払いを伴う場合の消費者がブランド一覧の目的を区別することが可能で、特に有益です。
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はブランドが選択されているために支払いが行われるべき方向を示しています。その値は次のようになります。デビット○お支払要求ブロックの送信者（例えば、消費者）にこのブランドのリストが支払ハンドラへの支払い、またはOクレジット支払要求ブロックの送信者を行います関係するこのブランド一覧支払ハンドラからの支払いを受け取ることになりますに関するものです。
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.
ブランドこれは、ブランドを説明しています。ブランドリスト内のブランド要素（セクション7.7.1を参照）の配列は、任意の優先度を示すものではありません。このブランドのリストを処理するソフトウェアは、ブランドのリストの受信機が好む順序でブランドを提示することをお勧めします。
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これは、特定のブランドにリンクします。o通貨やブランドで使用することができますCurrencyAmount要素に金額、及び支払プロトコルと支払いハンドラ、それらの通貨と量で使用することができ、かつ特定のブランドO
CurrencyAmount This contains a currency code and an amount.
これは、通貨コードと金額が含まれていCurrencyAmount。
PayProtocol This contains information about a Payment Protocol and the Payment Handler which may be used with a particular Brand.
PayProtocolこれは、支払プロトコルと特定のブランドと一緒に使用することができる支払ハンドラに関する情報が含まれています。
The relationships between the elements which make up the content of the Brand List is illustrated in the diagram below.
ブランドリストの内容を構成する要素間の関係は、次の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
Brand List Component
ブランドリストコンポーネント
| ProtocolAmountRefs
|-Brand Element-----------------------------
| | |
| - Protocol Brand Element-------- |
| | |
| ProtocolId| |
| | |
|-Protocol Amount Element<----------+-------
| | | |
| | | |
| |CurrencyAmountRefs |Pay |
| | |Protocol |
| v |Ref |
|-Currency Amount Element | |
| Element | |
| | |
-PayProtocolElement<------<--------
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 15 Brand List Element Relationships
図15ブランドのリスト要素の関係
Examples of complete Brand Lists are contained in section 11.2 Brand List Examples.
完全なブランドのリストの例は、セクション11.2ブランド一覧例に含まれています。
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.
ブランド要素は、支払いを行うために使用することができるブランドを説明しています。これらの要素の1つ以上はデビットに設定PayDirection属性を持つ各ブランドの一覧コンポーネントで運ばれます。正確に一つのブランド要素は、クレジットに設定PayDirection属性を持つブランド一覧コンポーネントで行うことができます。
<!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ブランド（ProtocolBrand *、PackagedContent *）> <ATTLISTブランドID ID #REQUIREDのXML：LANG NMTOKEN #IMPLIED BrandId CDATA #REQUIRED新しい名称CDATA #REQUIRED BrandLogoNetLocn CDATA #REQUIRED BrandNarrative CDATA #IMPLIED ProtocolAmountRefs IDREFS #REQUIRED ContentSoftwareId CDATA #IMPLIED >
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.
潜在的ブランド選択コンポーネントで参照IDエレメントIDは、後支払要求メッセージに含まれる一意IOTPトランザクション内ブランド要素を識別する。
xml:lang Defines the language used by attributes and content of this element. See section 3.8 Identifying Languages.
XML：langは属性と、この要素のコンテンツで使用される言語を定義します。セクション3.8は、言語の識別を参照してください。
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これは、ブランド（またはプロモーションブランド）の一意の識別子が含まれています。消費者は、消費者がブランドを使用して支払うことができるかどうかを判断するために保持している決済手段のリストと照合するために使用されます。
Values of BrandId are managed under the procedure
described in section 12 IANA Considerations.
As values of BrandId are controlled under the procedures defined in section 12 IANA Considerations user defined values may be defined.
BrandIdの値は、セクション12 IANA問題ユーザ定義された値で定義された手順の下で制御されるように定義されてもよいです。
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.
新しい名称は、これは、例えばマスターカードクレジットのために、ブランドの名前が含まれています。 LANG：これは、XMLで定義された消費者の言語で消費者に表示されているブランドの説明です。例えば、それは、「アメリカン航空メリットビザ」であるかもしれません。この属性は、消費者が保有する決済手段に対して照合に使用されていないことに注意してください。
BrandLogoNetLocn The net location which can be used to download the logo for the Organisation. See section Retrieving Logos (see section 10).
組織のロゴをダウンロードするために使用することができ、ネット場所をBrandLogoNetLocn。セクションの取得ロゴを（セクション10を参照）を参照してください。
The content of this attribute must conform to
[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.
BrandNarrativeこのオプション属性は、消費者がそのブランドを選択した場合に適用されるいくつかの特別な条件や利点を示すために商人によって使用されるように設計されています。たとえばなど「5％割引」、「送料無料とハンドリング」、「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がこのブランドで使用できるプロトコルと関連する通貨や金額を指定します。議定書金額要素のIDのリストとして指定されたブランドのリスト内に含まれる（セクション7.7.3を参照してください）。
ContentSoftwareId See section 14.Glossary.
セクション14.Glossaryを参照してくださいContentSoftwareId。
Content:
コンテンツ：
ProtocolBrand Protocol Brand elements contain brand information to be used with a specific payment protocol (see section 7.7.2)
ProtocolBrandプロトコルブランド要素がブランド情報が含まれていますが、特定の支払プロトコルで使用される（セクション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オプションパッケージ化されたコンテンツ（セクション3.7を参照してください）支払プロトコルによって使用することができるブランドについての情報を含む要素。この情報の内容は、支払プロトコルはIOTPでどのように機能するかを説明し、支払プロトコルのためのサプリメントで定義されています。
Example Brand Elements are contained in section 11.2 Brand List Examples.
例ブランド要素は、セクション11.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.
議定ブランド要素はブランドと、特定のプロトコルの使用に固有の情報が含まれています。次のようにその定義があります。
<!ELEMENT ProtocolBrand (PackagedContent*) > <!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #REQUIRED >
<！ELEMENT ProtocolBrand（PackagedContent *）> <！ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #REQUIRED>
Attributes:
属性：
ProtocolId This must match the value of a ProtocolId attribute in a Pay Protocol Element (see section 7.7.5).
ProtocolIdこれは（セクション7.7.5を参照）を支払うプロトコル要素でProtocolId属性の値と一致する必要があります。
The values of ProtocolId should be unique within a
Brand Element otherwise there is an error.
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これは、特定の支払プロトコルで使用するための支払いブランドIDです。例えば、SETとEMVは、ブランド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.
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オプションパッケージ化されたコンテンツ（セクション3.7を参照してください）支払プロトコルによって使用されるプロトコル/ブランドについての情報を含む要素。この情報の内容は、支払プロトコルはIOTPでどのように機能するかを説明し、支払プロトコルのためのサプリメントで定義されています。
The Protocol Amount element links a Brand to:
プロトコル金額要素がにブランドをリンクします。
o the currencies and amounts in Currency Amount Elements (see section 7.7.4) that can be used with the Brand, and
ブランドで使用できる通貨金額の要素（セクション7.7.4を参照）での通貨や金額O、および
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をこれらの通貨と量で使用することができ、（セクション7.7.5を参照してください）。
Its definition is as follows:
次のようにその定義は次のとおりです。
<!ELEMENT ProtocolAmount (PackagedContent*) > <!ATTLIST ProtocolAmount ID ID #REQUIRED PayProtocolRef IDREF #REQUIRED CurrencyAmountRefs IDREFS #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT ProtocolAmount（PackagedContent *）> <！ATTLIST ProtocolAmount ID ID #REQUIRED PayProtocolRef IDREF #REQUIRED CurrencyAmountRefs IDREFS #REQUIRED ContentSoftwareId CDATA #IMPLIED>
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.
潜在的ブランド要素で参照IDエレメントID、。またはブランドの選択コンポーネントで一意IOTPトランザクション内プロトコル金額要素を識別する後支払要求メッセージに含まれています。
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はブランドで使用できる支払プロトコルと支払いハンドラが含まれていペイ議定書の要素を参照する要素のリファレンスを（セクション3.5を参照してください）（セクション7.7.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.
CurrencyAmountRefsはブランドで使用できる通貨と金額を説明通貨金額要素（セクション7.7.4を参照）を参照してください要素参照（セクション3.5を参照）のリストが含まれています。
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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オプションのパッケージングされたコンテンツ（セクション3.7を参照）支払プロトコルによって使用され得るプロトコル量に関する情報を含む要素。この情報の内容は、支払プロトコルはIOTPでどのように機能するかを説明し、支払プロトコルのためのサプリメントで定義されています。
Examples of Protocol Amount Elements are contained in section 11.2 Brand List Examples.
議定書金額要素の例は、セクション11.2ブランド一覧例に含まれています。
A Currency Amount element contains:
通貨額の要素が含まれています。
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つ以上は、各ブランドのリストコンポーネントで運ばれます。次のようにその定義は次のとおりです。
<!ELEMENT CurrencyAmount EMPTY > <!ATTLIST CurrencyAmount ID ID #REQUIRED Amount CDATA #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED >
<！ELEMENT CurrencyAmount EMPTY> <！ATTLIST CurrencyAmount ID ID #REQUIRED額CDATA #REQUIRED CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED>
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 Currency Amount Element within the IOTP Transaction.
潜在的ブランド要素で参照IDエレメントID、。またはブランドの選択コンポーネントで一意にIOTPトランザクション内通貨金額の要素を識別し、後に支払要求メッセージに含まれています。
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".
金額は、通貨の全体と小数単位で支払われる金額を示します。たとえば、$ 245.35は「245.35」を表現することでしょう。最小の金種よりも小さいが許可された値に注意してください。例えば、セントの10分の1は「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はCurrCodeのドメインを示します。この属性は、通貨コードは、などマイレージポイント、トレーディングスタンプ、などの非標準の「通貨」をサポートすることができるように、その値がかもしれ含まれています：ISO4217-A（デフォルト）O通貨コードを示します3文字のアルファベットでありますIOTP O [ISO 4217]に準拠した通貨コードがCurrCodeの値がセクション12のIANAの考慮事項に記載された手順の下で管理されていることを示しています
CurrCode A code which identifies the currency to be used in the payment. The domain of valid currency codes is defined by CurrCodeType
支払いに使用する通貨を識別するコードをCurrCode。有効な通貨コードのドメインはCurrCodeTypeによって定義されます
As values of CurrCodeType are managed under the
procedure described in section 12 IANA
Considerations user defined values of CurrCodeType
may be defined.
Examples of Currency Amount Elements are contained in section 11.2 Brand List Examples.
通貨金額要素の例は、セクション11.2ブランド一覧例に含まれています。
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.
ペイプロトコル要素は、支払プロトコルとブランドを使用することができます支払ハンドラの詳細を指定します。これらの要素の1つ以上は、各ブランドの一覧に運ばれます。
<!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
PayReqNetLocn CDATA #IMPLIED SecPayReqNetLocn CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED >
PayReqNetLocn CDATA #IMPLIED SecPayReqNetLocn CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED>
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.
潜在的ブランド要素で参照IDエレメントID、。またはブランドの選択コンポーネントで一意にIOTPトランザクション内ペイプロトコル要素を識別し、後に支払要求メッセージに含まれています。
xml:lang Defines the language used by attributes and content of this element. See section 3.8 Identifying Languages.
XML：langは属性と、この要素のコンテンツで使用される言語を定義します。セクション3.8は、言語の識別を参照してください。
ProtocolId Consists of a protocol name and version. For example "SETv1.0".
ProtocolIdはプロトコル名とバージョンで構成されています。例えば「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.
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：langの。たとえば、「電子取引のバージョン1.0を固定します」。その目的は、問題が発生した場合に使用されている支払プロトコルに関する情報を提供できるようにすることです。
ActionOrgRef An Element Reference (see section 3.5) to the Organisation Component for the Payment Handler for the Payment Protocol.
支払プロトコルの支払ハンドラのための組織構成要素にActionOrgRefアン要素のリファレンス（セクション3.5を参照してください）。
PayReqNetLocn The Net Location indicating where an unsecured Payment Request message should be sent if this protocol choice is used.
このプロトコルの選択が使用されている場合は、無担保支払要求メッセージを送信すべき場所を示すネット場所をPayReqNetLocn。
The content of this attribute is dependent on the
Transport Mechanism (such must conform to
[RFC1738].
SecPayReqNetLocn The Net Location indicating where a secured Payment Request message should be sent if this protocol choice is used.
このプロトコルの選択が使用されている場合は安全な支払要求メッセージを送信すべき場所を示すネット場所をSecPayReqNetLocn。
A secured payment involves the use of a secure
channel such as [SSL/TLS] in order to communicate
with the Payment Handler.
The content of this attribute must conform to [RFC1738]. See also See section 3.9 Secure and Insecure Net Locations.
この属性の内容は、[RFC1738]に準拠する必要があります。 3.9節安全で安全でないネットの場所を参照してくださいも参照してください。
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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オプションパッケージ化されたコンテンツ要素（3.7節を参照してください）。この情報の内容は、支払プロトコルはIOTPでどのように機能するかを説明し、支払プロトコルのためのサプリメントで定義されています。その使用の例は、支払いプロトコルメッセージを含めることである可能性があります。
Examples of Pay Protocol Elements are contained in section 11.2 Brand List Examples.
ペイプロトコル要素の例は、セクション11.2ブランド一覧例に含まれています。
A Brand Selection Component identifies the choice of payment brand, payment protocol and the Payment Handler. This element is used:
ブランド選択コンポーネントは、ペイメントブランド、支払いプロトコルおよび支払ハンドラの選択肢を識別します。この要素が使用されます。
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
支払いのためのブランド、プロトコルおよび支払いハンドラを識別するために、ベースラインの購入とベースライン値取引IOTP取引以内にご入金のリクエストメッセージ、O、または
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.
ベースラインIOTPでは、ブランドの選択コンポーネントの整合性は保証されません。支払プロトコル自体はメッセージの修正、複製、およびスワップの攻撃に対して安全である場合は、ブランドの選択コンポーネントの変更はサービス拒否を引き起こす可能性があります。
The definition of a Brand Selection Component is as follows.
次のようにブランドの選択コンポーネントの定義があります。
<!ELEMENT BrandSelection (BrandSelBrandInfo?, BrandSelProtocolAmountInfo?, BrandSelCurrencyAmountInfo?) > <!ATTLIST BrandSelection
<！ELEMENT BrandSelection（BrandSelBrandInfo ?, BrandSelProtocolAmountInfo ?, BrandSelCurrencyAmountInfo？）> <！ATTLISTのBrandSelection
ID ID #REQUIRED BrandListRef NMTOKEN #REQUIRED BrandRef NMTOKEN #REQUIRED ProtocolAmountRef NMTOKEN #REQUIRED CurrencyAmountRef NMTOKEN #REQUIRED >
ID ID #REQUIRED BrandListRef NMTOKEN #REQUIRED BrandRef NMTOKEN #REQUIRED ProtocolAmountRef NMTOKEN #REQUIRED CurrencyAmountRef NMTOKEN #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Brand Selection Component within the IOTP Transaction.
ID一意IOTPトランザクション内ブランドの選択コンポーネントを識別する識別子。
BrandListRef The Element Reference (see section 3.5) of the Brand List Component from which a Brand is being selected
ブランドが選択されているから、ブランドのリストコンポーネントのBrandListRefザ要素リファレンス（セクション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.
支払いに使用することを選択されているブランドリストコンポーネント内のブランド要素のBrandRefザ・要素のリファレンス。
ProtocolAmountRef The Element Reference of a Protocol Amount element within the Brand List Component which is to be used when making the payment.
支払いを行うときに使用するブランドリストコンポーネント内のプロトコル量要素のProtocolAmountRefザ・要素のリファレンス。
CurrencyAmountRef The Element Reference of a Currency Amount element within the Brand List Component which is to be used when making the payment.
支払いを行うときに使用するブランドリストコンポーネント内の通貨量要素の要素のリファレンスCurrencyAmountRef。
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は、これは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トランザクションにブランドリストコンポーネントの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取引プロトコル・オプションブロック（セクション8.1を参照）内のすべてのブランドリストコンポーネントは1で参照されると、唯一のブランドセレクションコンポーネントする必要があります
o the BrandRef must refer to the ID of a Brand contained within the Brand List Component referred to by BrandListRef
O BrandRefブランドリストコンポーネント内に含まれるブランドのIDを参照する必要がBrandListRefによって参照しました
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で識別されるブランド要素のProtocolAmountRefs属性に列挙された要素のIDのいずれかを参照する必要があります
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で識別されるプロトコル額要素のCurrencyAmountRefs属性に列挙された要素のIDのいずれかを参照する必要があります。
An example of a Brand Selection Component is included in 11.2 Brand List Examples.
ブランドの選択コンポーネントの例は、11.2ブランド一覧例に含まれています。
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.
ブランドセレクションブランド情報要素は、特定のペイメントブランドによって必要とされる任意の追加データが含まれています。それは使用方法と時期についての説明のためのIOTP支払い方法の補足を参照してください。
<!ELEMENT BrandSelBrandInfo (PackagedContent+) > <!ATTLIST BrandSelBrandInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT BrandSelBrandInfo（PackagedContent +）> <！ATTLIST BrandSelBrandInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED>
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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パッケージ化されたコンテンツの要素（3.7節を参照してください）。これがどのように使われるかに関する規則のためのIOTPの支払い方法の補足を参照してください。
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.
ブランドの選択議定書金額情報要素は、特定のペイメントブランドまたは支払プロトコルによって必要とされる支払いプロトコル固有の追加データが含まれています。それは使用方法と時期についての説明のためのIOTP支払い方法の補足を参照してください。
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) > <!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT BrandSelProtocolAmountInfo（PackagedContent +）> <！ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED>
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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パッケージ化されたコンテンツ要素（3.7節を参照してください）。これがどのように使われるかに関する規則のためのIOTPの支払い方法の補足を参照してください。
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.
ブランドセレクション通貨金額情報要素は、特定のペイメントブランドによって必要とされるペイメントブランドと通貨固有の追加データが含まれています。それは使用方法と時期についての説明のためのIOTP支払い方法の補足を参照してください。
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) > <!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT BrandSelCurrencyAmountInfo（PackagedContent +）> <！ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED>
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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パッケージ化されたコンテンツ要素（3.7節を参照してください）。これがどのように使われるかに関する規則のためのIOTPの支払い方法の補足を参照してください。
A Payment Component contains information used to control how a payment is carried out. Its provides information on:
支払コンポーネントは、支払いが行われる方法を制御するために使用される情報が含まれています。 ITSは上の情報を提供しています。
o the times within which a Payment with a Payment Handler may be started
支払ハンドラでのお支払いが開始されることができる以内回O
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
支払いを行うために使用することができますブランド、プロトコル、通貨および金額を特定ブランド一覧（セクション7.7を参照）への参照O
o whether or not a payment receipt will be provided o whether another payment precedes this payment.
領収書は、別のお支払いは、この支払いの前にいるかどうかoを提供するかどうか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 >
<！ELEMENT支払いEMPTY> <！ATTLIST支払ID ID #REQUIRED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED BrandListRef NMTOKEN #REQUIRED SignedPayReceipt（TRUE | FALSE）#REQUIRED StartAfterRefs NMTOKENS #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Component within the IOTP Transaction.
ID一意IOTPトランザクション内支払コンポーネントを識別する識別子。
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.
OkFrom [UTC]形式の日付と時刻は、その後支払いハンドラが支払成分を含む（セクション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.
OkTo支払いハンドラが支払成分を含む支払い要求ブロックを処理するために受け入れることができる前に、[UTC]形式の日付と時刻。
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トランザクションのためのTPO貿易ブロック内のブランドリストコンポーネントのBrandListRefアン要素のリファレンス（セクション3.5を参照してください）（セクション7.7を参照してください）。ブランド一覧お支払いを行うことが可能な代替方法を特定します。
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は、支払いのための支払ハンドラによって生成された決済応答ブロックは、（セクション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
StartAfterは、この支払いを開始する前に完了していなければならないの支払いを説明し、他の支払コンポーネントの要素参照（セクション3.5を参照）が含まれています。何StartAfter属性が存在しない場合、依存関係はありませんし、支払いはすぐに始めることができます
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.
支払いスキームコンポーネントは、例えば[SET]メッセージに対する支払いに関与する当事者間で転送される特定の支払い方式の支払プロトコル情報を含みます。次のようにその定義があります。
<!ELEMENT PaySchemeData (PackagedContent+) > <!ATTLIST PaySchemeData ID ID #REQUIRED PaymentRef NMTOKEN #IMPLIED ConsumerPaymentId CDATA #IMPLIED PaymentHandlerPayId CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT PaySchemeData（PackagedContent +）> <！ATTLIST PaySchemeData ID ID #REQUIRED PaymentRef NMTOKEN #IMPLIED ConsumerPaymentId CDATA #IMPLIED PaymentHandlerPayId CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Scheme Component within the IOTP Transaction.
ID一意IOTPトランザクション内の決済スキームのコンポーネントを識別する識別子。
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).
PaymentRefアン要素のリファレンスは支払コンポーネントに（セクション3.5を参照）、この支払スキームコンポーネントが関係する（セクション7.9を参照してください）。お支払いスキームコンポーネントがトランザクション問い合わせステータストランザクションの一部でない限り、それが必要とされる（セクション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。
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。これは、支払要求ブロックに含まれる1つから離れて、すべての支払いスキームコンポーネントに必要とされます。
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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.
PackagedContentは、パッケージ化されたコンテンツの要素（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
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.
支払領収書は支払わまたは受信されているどのくらいのお金を示して支払いの記録です。それが購入されたもののレコードが含まれていないという点で、購入時の領収書とは区別されます。
Typically the content of a Payment Receipt Component will contain data which describes:
：通常、お支払いの領収書の成分の含有量は、記述したデータが含まれています
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.
使用されているお支払い方法は、施設を提供していた場合、お支払いの領収書のコンポーネントは、支払いが発生したことを証明メッセージへの支払いプロトコルメッセージ、または参照を、含まれている必要があります。
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.
コンテンツの正確な定義は依存支払い方法です。適用される規則を決定するために使用されている支払方法のためのサプリメントを参照してください。
Information contained in the Payment Receipt Component should be displayed or otherwise made available to the Consumer.
支払領収書のコンポーネントに含まれる情報は、表示されるか、そうでなければ、消費者に利用できるようにすべきです。
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
注意：お支払いの領収書のコンポーネントは、支払プロトコルメッセージが含まれている場合、メッセージは消費者が理解できる形式に変換する決済方法ソフトウェアで処理する必要があります。
The definition of a Payment Receipt Component is as follows.
次のように支払領収書のコンポーネントの定義があります。
<!ELEMENT PayReceipt (PackagedContent*) > <!ATTLIST PayReceipt ID ID #REQUIRED PaymentRef NMTOKEN #REQUIRED PayReceiptNameRefs NMTOKENS #IMPLIED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT PayReceipt（PackagedContent *）> <！ATTLIST PayReceipt ID ID #REQUIRED PaymentRef NMTOKEN #REQUIRED PayReceiptNameRefs NMTOKENS #IMPLIED ContentSoftwareId CDATA #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Receipt Component within the IOTP Transaction.
ID一意IOTPトランザクション内支払受領コンポーネントを識別する識別子。
PaymentRef Contains an Element Reference (see section 3.5) to the Payment Component (see section 7.9) to which this payment receipt applies
PaymentRefは、この領収書が適用される支払コンポーネントへの要素の参照を（セクション3.5を参照してください）（セクション7.9を参照）を含みます
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は、必要に応じて一緒に領収書を構成するパッケージ化されたコンテンツ要素のName属性の値のリストが含まれています。パッケージングされたコンテンツ要素は、内のいずれかに含まれる：支払スキームデータ成分O及び/又は支払い受領コンポーネント自体O、支払い時に支払いハンドラと消費者の役割との間で交換。なお：各支払い方式はその補足この属性（もしあれば）に記載されている必要がありパッケージ化されたコンテンツ要素の名前で定義しますoを。支払いスキームコンポーネントPayReceiptNameRefs内の名前と一致する名前を持つパッケージングされたコンテンツ要素を含む場合、O、それらの支払いスキームのコンポーネントは、（署名が使用されている場合）支払レスポンス署名コンポーネントで消化によって参照されなければなりません
The client software should save all the
components referenced so that the payment receipt
can be reconstructed when required.
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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オプションでは、パッケージ化されたコンテンツの要素（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
Note that either the PayReceiptNameRefs attribute, the PackagedContent element, or both must be present.
PayReceiptNameRefs属性、PackagedContent要素、あるいはその両方が存在しなければならないことに注意してください。
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.
支払注意コンポーネントは関連する追加、非支払い、支払いハンドラが消費者に提供したい情報が含まれています。撤退やデポジットが行われていた場合、転送が完了した後に例えば、それはアカウントの残高に関する情報を含めることができます。情報には、お支払いの領収書のコンポーネント内に含まれる情報を複製する必要があります。
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.
支払注意コンポーネントに含まれる情報は、表示されるか、そうでなければ、消費者に利用できるようにすべきです。相互運用性のため、お支払い（注）コンポーネントは、最低限として、「プレーンテキスト」、HTMLやXMLのコンテンツタイプをサポートする必要があります。次のようにその定義があります。
<!ELEMENT PaymentNote (PackagedContent+) > <!ATTLIST PaymentNote ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT PaymentNote（PackagedContent +）> <！ATTLIST PaymentNote ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Receipt Component within the IOTP Transaction.
ID一意IOTPトランザクション内支払受領コンポーネントを識別する識別子。
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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は関連する追加、非支払い、支払いハンドラは、1つまたは複数のパッケージ化されたコンテンツ要素（3.7節を参照）として消費者に提供したい情報が含まれています。
The Delivery Element contains information required to deliver goods or services. Its definition is as follows.
配達要素は、商品やサービスを提供するために必要な情報が含まれています。次のようにその定義があります。
<!ELEMENT Delivery (DeliveryData?, PackagedContent*) > <!ATTLIST Delivery ID ID #REQUIRED xml:lang NMTOKEN #REQUIRED DelivExch (True | False) #REQUIRED DelivAndPayResp (True | False) #REQUIRED ActionOrgRef NMTOKEN #IMPLIED >
<！ELEMENT配達（DeliveryData ?, PackagedContent *）> <ATTLIST配達ID ID #REQUIREDのXML：LANG NMTOKEN #REQUIRED DelivExch（TRUE | FALSE）#REQUIRED DelivAndPayResp（TRUE | FALSE）#REQUIRED ActionOrgRef NMTOKEN #IMPLIED！>
Attributes:
属性：
ID An identifier which uniquely identifies the Delivery Component within the IOTP Transaction.
ID一意IOTPトランザクション内送達構成要素を識別する識別子。
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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
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トランザクションが配信取引に関連するメッセージが含まれている場合DelivExchを示します。有効な値は以下のとおりです。TRUEが示すoをそれが偽の配信所が含まれていないことを示してoを配信取引所もありません
If set to true then a DeliveryData element must
be present. If set to false it may be absent.
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が配信応答ブロックかどうかを示し1つのIOTPメッセージに結合されている（セクション8.9を参照）、支払い応答ブロック（8.11節を参照してください）。有効な値は以下のとおりです。TRUEは、両方のブロックが同じIOTPメッセージであろう示しO、及び
o False indicates each block will be in a
different IOTP Message
DelivAndPayResp should not be true if DelivExch is False.
DelivExchがFalseの場合DelivAndPayRespは真実ではありません。
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
彼らは何を知っているように、お支払いハンドラoを注文コンポーネント情報へのアクセス権を持っている必要があります。配達応答ブロックを組み合わせて実際にしてお支払い応答ブロックが商人ならば実用的であることが唯一の可能性があるため、支払ハンドラと配信ハンドラは、同じ組織です提供する、および支払ハンドラoを配信を行うことができなければなりません
ActionOrgRef An Element Reference to the Organisation Component of the Delivery Handler for this delivery.
この配信の配信ハンドラの組織コンポーネントにActionOrgRefアン要素参照。
Content:
コンテンツ：
DeliveryData Contains details about how the delivery will be carried out. See 7.13.1 Delivery Data Element below.
DeliveryDataは配信が行われる方法の詳細が含まれています。下記の7.13.1配信データ要素を参照してください。
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.
PackagedContentは、一つ以上のパッケージ化されたコンテンツElementsはセクション3.7を参照してくださいとして配信ハンドラによって要求された商人のために定義された「ユーザー」のデータが含まれています。
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>
Attributes:
属性：
xml:lang Defines the language used by attributes within this component. See section 3.8 Identifying Languages.
XML：langは、このコンポーネント内の属性で使用される言語を定義します。セクション3.8は、言語の識別を参照してください。
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配信ハンドラが配信要求ブロックを処理するために受け入れることができるし、[UTC]形式の日付と時刻（セクション8.10を参照）。
OkTo The date and time in [UTC] format before which the Delivery Handler may accept for processing a Delivery Request Block.
OkTo配信ハンドラが配信要求ブロックを処理するために受け入れることができる前に、[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は、商品やサービスを提供することのできる方法を示します。有効な値は以下のとおりです。ポスト○商品は、商品が商品が電子メールによって電子的に配信されますメールoを納品書のコンポーネントに電子的に配信されますウェブoを郵便または宅配便でお届けいたします
Values of DelivMethod are managed under the
procedure described in section 12 IANA
Considerations which allows user defined codes to
be defined.
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トランザクション内で組織コンポーネントのDelivToRefザ・要素のリファレンス（セクション3.4を参照してください）。このブロックの情報は、配信が行われるべき場所を決定するために使用されます。それはDelivMethodと互換性がなければなりません。 DelivMethodがある。具体的場合：ポストO、その後、郵便配達のための十分な情報を含む住所要素がなければならない、ウェブO、その後、特別な要件はありません。情報は、有効な電子メールアドレスと連絡先情報の要素がなければならない、バック消費者0メールへのWebページに送信されます
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これは、配信コンポーネントを送信する必要があります含まれている無担保配信要求ブロック（セクション8.10を参照）へのネットの場所が含まれています。
The content of this attribute is dependent on the
Transport Mechanism and must conform to
[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た配信コンポーネントが含まれているセキュアな配信要求ブロックは、（セクション8.10を参照）を送信する必要があります。
A secured delivery request involves the use of a
secure channel such as [SSL/TLS] in order to
communicate with the Payment Handler.
The content of this attribute is dependent on the Transport Mechanism must conform to [RFC1738].
この属性の内容は、[RFC1738]に準拠しなければならないトランスポートメカニズムに依存しています。
See also Section 3.9 Secure and Insecure Net Locations.
また、3.9節安全で安全でないネット場所を参照してください。
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
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.
商人によって配信ハンドラに提供される一つまたは複数のパッケージ化されたコンテンツ要素（3.7節を参照）としての送達に関するPackagedContent追加情報。
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.
消費者の配信データコンポーネントは、配信を識別するために消費者によって使用可能な識別子を指定するために消費者によって使用されます。
Its definition is as follows:
次のようにその定義は次のとおりです。
<!ELEMENT ConsumerDeliveryData EMPTY > <!ATTLIST ConsumerDeliveryData ID ID #REQUIRED ConsumerDeliveryId CDATA #REQUIRED>
<！ELEMENT ConsumerDeliveryData EMPTY> <！ATTLIST ConsumerDeliveryData ID ID #REQUIRED ConsumerDeliveryId CDATA #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Consumer Delivery Data Component within the IOTP Transaction.
ID一意IOTPトランザクション内の消費者の配信データコンポーネントを識別する識別子。
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。
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.
納品書は、商品またはサービスの提供または潜在的に実際の配達情報自体についての配送指示が含まれています。それは、人や組織が、配信が発生した場合に使用することができ納品書を受けた情報です。
For interoperability, the Delivery Note Component Packaged Content should support both Plain Text, HTML and XML.
相互運用性のため、納品書コンポーネントパッケージ化されたコンテンツは、プレーンテキスト、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.
ID一意IOTPトランザクション内納品書コンポーネントを識別する識別子。
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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
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。これは、配信要求ブロックに含まれる1つから離れて、すべての配信コンポーネントに必要とされます。
An example use of this attribute is to contain a
delivery tracking number.
ContentSoftwareId See section 14. Glossary.
セクション14.用語集を参照してくださいContentSoftwareId。
Content:
コンテンツ：
PackagedContent Contains actual delivery note information as one or more Packaged Content elements (see section 3.7).
PackagedContentは、一つ以上のパッケージ化されたコンテンツの要素（3.7節を参照）として、実際の納品書情報が含まれています。
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.
注：配信メッセージの内容は、MIMEメッセージである場合、納品書は、実際の配信が発生する原因となるアプリケーションをトリガすることができます。
A Status Component contains status information about the business success or failure (see section 4.2) of a process.
状況コンポーネントは、ビジネスの成功または失敗に関するステータス情報が含まれているプロセスの（セクション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ステータスEMPTY> <！ATTLISTステータス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.
ID一意IOTPトランザクション内状況コンポーネントを識別する識別子。
xml:lang Defines the language used by attributes within this component. See section 3.8 Identifying Languages.
XML：langは、このコンポーネント内の属性で使用される言語を定義します。セクション3.8は、言語の識別を参照してください。
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.
StatusTypeはステータスに報告された文書交換のタイプを示します。これは、オファー、お支払い、配達、認証または未定義のいずれかに設定することができます。
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.
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のユーザ定義された値が定義されることを可能にするセクション12 IANAの考慮事項に記載された手順の下で管理されています。
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.
StatusTypeが未定義に設定されていない場合ElRefはその後ElRefはステータスが記述されるコンポーネントに（セクション3.5を参照）要素のリファレンスが含まれています。これは、どちらかを参照する必要があります：オーダーコンポーネントoをStatusTypeがオファーであればStatusTypeが支払い、またはOA送達コンポーネントである場合StatusType場合、（セクション7.13を参照）、（セクション7.9を参照）、OA支払コンポーネント（7.5節を参照してください） StatusTypeが認証された場合に認証要求コンポーネントO送達である（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が行われているプロセスの現在の状態を表す状態コードが含まれています。 ProcessStateの有効な値は以下のとおりです。NotYetStarted oを。要求ブロックが受信されているが、プロセスはまだのInProgress oを開始していません。要求ブロックの処理が開始されたが、それはまだCompletedOk O完了していません。失敗したoを要求ブロックの処理がエラーなしで正常に完了しました。要求ブロックの処理がProcessError O（セクション4.2を参照）ので、ビジネスのエラーで失敗しました。状況コンポーネントは、問い合わせ要求取引ブロック（セクション8.12を参照）に関連して使用されている場合、この値はのみ使用されます。これは、処理されている要求ブロックまたは一部の内部処理エラーに（セクション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.
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は、プロセスが完了したかを示します。 CompletionCodeの有効な値は、一緒に障害からの回復が可能な場合に、それが存在していなければならない条件と指摘して以下に与えられています。
A CompletionCode is a maximum of 14 characters
long.
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このオプション属性は、ステータスが報告されているプロセスのための参照を保持しています。それは次の値を保持することがあります。StatusTypeを提供するように設定されている場合StatusTypeが支払いに設定されている場合、それは注文成分OからOrderIdentifierが含まれている必要がありO、それは支払いスキームデータ成分OからPaymentHandlerPayIdが含まれている必要がありStatusTypeが配達に設定されている場合StatusTypeが認証に設定されている場合、それは、認証要求ComponentからAuthenticationIdが含まれている必要があり、納品書の成分OからDelivHandlerDelivIdが含まれている必要があり
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.
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.
この属性は、以前に利用できなかったトランザクションの参照番号を与えること（セクション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.
例えば、パッケージ追跡番号は、配達応答が受信された時点で割り当てられないかもしれません。消費者は、後にベースラインの取引状況照会を発行した場合は、配達ハンドラは、問い合わせ応答メッセージに、この属性にパッケージの追跡番号を置くことができ、バック消費者に送信します。
StatusDesc An optional textual description of the current status of the process in the language identified by xml:lang.
XMLで識別される言語でのプロセスの現在の状態のStatusDescオプションのテキスト説明：LANG。
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属性が設定されている場合、完了コードにのみ必要です。次の表を使用することができるCompletionCodeの有効な値が含まれており、回復は可能かもしれないかどうかを示します。 StatusDesc属性が適切な場合にはさらなる説明を提供するために使用されることをお勧めします。
Value Description
値説明
AuthError Authentication Error. The check of the Authentication Response which was carried out has failed.
AuthError認証エラー。実施した認証レスポンスのチェックが失敗しました。
Recovery may be possible by the Consumer re-
submitting a new Authentication Response Block with
corrected information.
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消費者がキャンセル。消費者は、何らかの理由でトランザクションを中止することを決定します。このコードは、キャンセルをブロックまたは照会応答ブロックに含まれている状況コンポーネントでのみ有効です。
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オファーはキャンセル。商人は、何らかの理由でプランを生成するために低下し、トランザクションをキャンセルします。このコードは、キャンセルをブロックまたは照会応答ブロックに含まれている状況コンポーネントでのみ有効です。
No recovery possible.
可能ませ回復ません。
Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes.
詳細不明の不明なエラー。他のCompletionCodesのいずれかに該当していないいくつかの未知の問題やエラーがあります。
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回復タイムアウト。メッセージは再送信されましたが、応答が受け取りませんでした。文書交換は、したがって、「タイムアウト」しています。このコードは、トランザクション問合せでのみ有効です。
Recovery is possible if the last message from the
other Trading Role is received again.
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非回復タイムアウト。メッセージは再送信されましたが、応答が受け取りませんでした。文書交換は、したがって、「タイムアウト」しています。このコードは、トランザクション問合せでのみ有効です。
No recovery possible.
可能ませ回復ません。
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属性が設定されている場合CompletionCodeにのみ必要です。以下の表は、使用して回復が可能かもしれない場所を示すこともCompletionCodeの有効な値が含まれています。 StatusDesc属性が適切な場合にはさらなる説明を提供するために、個々の決済スキームによって使用されることをお勧めします。
Value Description
値説明
BrandNotSupp Brand not supported. The payment brand is not supported by the Payment Handler.
BrandNotSuppブランドがサポートされていません。ペイメントブランドは支払いハンドラによってサポートされていません。
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通貨はサポートされていません。支払いが行われるべきで通貨が支払手段または支払ハンドラのいずれかによってサポートされていません。
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.
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消費者がキャンセル。消費者は、何らかの理由で支払いを中止することを決定します。このコードは、キャンセルをブロックまたは照会応答ブロックに含まれている状況コンポーネントでのみ有効です。
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お支払いはキャンセル。お支払いハンドラは、何らかの理由で支払いを完了するために低下し、トランザクションをキャンセルします。このコードは、キャンセルをブロックまたは照会応答ブロックに含まれている状況コンポーネントでのみ有効です。
See below for recovery options.
リカバリオプションについては、以下を参照してください。
AuthError Authentication Error. The Payment Scheme specific authentication check which was carried out has failed.
AuthError認証エラー。行った支払スキーム、特定の認証チェックに失敗しました。
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。なされるべき支払いのために利用できる十分な資金があります。
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.
InstBrandInvalid支払手段ブランドには有効ではありません。支払機器は、選択されたブランドに対応していないが使用されています。マスターカードは、ブランドとして選ばれたとき、例えば、ビザのクレジットカードが使用されています。
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支払機器貿易のための有効ではありません。支払手段は、何らかの理由で、貿易の提案タイプに使用することはできません。
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。支払いのために使用することができないことを意味使用されている支払手段に問題があります。
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.
詳細不明の不明なエラー。他のCompletionCodesのいずれかに該当していないいくつかの未知の問題やエラーがあります。 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回復タイムアウト。メッセージは再送信されましたが、応答が受け取りませんでした。文書交換は、したがって、「タイムアウト」しています。このコードは、トランザクション問合せでのみ有効です。
Recovery is possible if the last message from the
other Trading Role is received again.
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非回復タイムアウト。メッセージは再送信されましたが、応答が受け取りませんでした。文書交換は、したがって、「タイムアウト」しています。このコードは、トランザクション問合せでのみ有効です。
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.
お支払いはブランドの独立であれば、回復は異なるペイメントブランドや同じブランドの異なる決済手段のいずれかを選択する消費者により、完了コードのいくつかの値のために可能かもしれません。これは別の支払ハンドラを伴う可能性があることに注意してください。これが適用されるコードは次のとおりです。BrandNotSupp、PaymtCancelled、InsuffFunds、InstBrandInvalid、InstNotValid、BadInstrumentおよび未指定。
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.
消費者への商人によって送られたブランドの選択コンポーネントが変更されない場合はブランド依存の購入に関連した支払いからの回復は、のみ可能です。実際には、これは同じブランド、議定書の金額とPayProtocol要素を使用しなければならないことを意味しています。変更可能なのは支払手段です。その他の変更は、オファーレスポンスが無効になり、変更選択として商人のオファーが無効になります。
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.
次の表は、配信のための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が失敗した場合にのみ有効です。
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ある場合にのみ有効です。
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消費者がキャンセル。消費者は、何らかの理由で配信を中止することを決定します。このコードは、キャンセルをブロックまたは照会応答ブロックに含まれている状況コンポーネントでのみ有効です。
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配信はキャンセル。配達ハンドラは、何らかの理由で配達を完了するのに低下し、トランザクションをキャンセルします。このコードは、キャンセルをブロックまたは照会応答ブロックに含まれている状況コンポーネントでのみ有効です。
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.
詳細不明の不明なエラー。他のCompletionCodesのいずれかに該当していないいくつかの未知の問題やエラーがあります。 StatusDesc属性は、原因の説明を提供する必要があります。
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回復タイムアウト。メッセージは再送信されましたが、応答が受け取りませんでした。文書交換は、したがって、「タイムアウト」しています。このコードは、トランザクション問合せでのみ有効です。
Recovery is possible if the last message from the
other Trading Role is received again.
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非回復タイムアウト。メッセージは再送信されましたが、応答が受け取りませんでした。文書交換は、したがって、「タイムアウト」しています。このコードは、トランザクション問合せでのみ有効です。
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.
注意：失敗した、または部分的に完了した配達からの回復は不可能です。消費者は、現在の状態に最新に情報を決定するために（セクション9.2.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. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
失敗にProcessState属性が設定されている場合、完了コードにのみ必要です。次の表を使用することができる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被認証者がキャンセルします。組織が何らかの理由で認証することを拒否し、認証されています。認証要求の署名が無効であったか、オーセンティケータが認証者に知られているか、または許容されるなかったため、これは、例えば、とすることができます。
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認証をキャンセルします。認証応答を検証するための認証の下落を要求する組織が何らかの理由で受信し、トランザクションをキャンセルします。
Recovery is not possible.
回復は不可能です。
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認証が利用できない要求します。被認証者は、彼らが正常に認証することができるように提供されなければならないデータを持っていません。パスワードを忘れてしまったかもしれない例えば、被認証者は、まだメンバーになっていない、またはスマートカードトークンが存在しません。
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認証に失敗しました。認証は、認証応答を確認したが、認証が何らかの理由で失敗しました。たとえば、パスワードが間違っている可能性があります。
Recovery may be possible by the Authenticatee re-
sending a revised Authentication Response with
corrected data.
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トレーディング役割。取引ロール情報要求コンポーネントのTradingRoleList属性内に含まれる取引の役割は、（セクション7.4を参照）認証者がIOTPトランザクションを取り込むか、取ることができるです取引の役割と矛盾しています。矛盾の例としては、マーチャント情報についての消費者を求めてoをDeliveryHandler情報についてPaymentHandlerを尋ねるO
Recovery may be possible by the Authenticator re-
sending a revised Authentication Request Block with
corrected information.
Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes.
詳細不明の不明なエラー。他のCompletionCodesのいずれかに該当していないいくつかの未知の問題やエラーがあります。
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回復タイムアウト。メッセージは再送信されましたが、応答が受け取りませんでした。文書交換は、したがって、「タイムアウト」しています。このコードは、トランザクション問合せでのみ有効です。
Recovery is possible if the last message from the
other Trading Role is received again.
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非回復タイムアウト。メッセージは再送信されましたが、応答が受け取りませんでした。文書交換は、したがって、「タイムアウト」しています。このコードは、トランザクション問合せでのみ有効です。
No recovery possible.
可能ませ回復ません。
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属性が設定されている場合、完了コードにのみ必要です。次の表を使用することができる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入力メッセージハードエラーが発生しました。要求ブロックの種類は特定さや矛盾したことができませんでした。したがって、単一のドキュメント交換を識別することはできませんでした。これは、トランザクション内でハードエラーが発生します
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属性が設定されている場合、完了コードにのみ必要です。次の表を使用することができるCompletionCodeの有効な値が含まれています。 StatusDesc属性が適切な場合にはさらなる説明を提供するために使用されることをお勧めします。
Value Description
値説明
UnAuthReq Unauthorised Request. The recipient of the Transaction Status Request declines to respond to the request.
UnAuthReq不正なリクエスト。トランザクションステータス要求の受信者が要求に応答して低下します。
The Trading Role Data Component contains opaque data which needs to be communicated between the Trading Roles involved in an IOTP Transaction.
取引の役割データコンポーネントはIOTPトランザクションに関与取引の役割との間で通信する必要が不透明なデータが含まれています。
Trading Role Components identify:
取引役割のコンポーネントを識別します：
o the Organisation that generated the component, and
成分を生成組織O、及び
o the Organisation that is to receive it.
それを受信する組織O。
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.
彼らは、最初に生成され、「レスポンス」ブロックに含まれ、その後、適切な「要求」ブロックにコピーされます。例えば支払ハンドラは、クレジットカードでの支払いが承認さが、キャプチャされませんされていた配信ハンドラーを通知する必要がある場合があります。また、フォーマットが個人的に通信する必要が配信ハンドラで合意した場合支払ハンドラーが生成されたことを、他の情報があるかもしれません。別の例では商人は、消費者が支払いをダブルロイヤリティポイントを獲得することができるように消費者に関するいくつかの具体的な情報をお支払いハンドラを提供する必要があるかもしれません。
Its definition is as follows.
次のようにその定義があります。
<!ELEMENT TradingRoleData (PackagedContent+) > <!ATTLIST TradingRoleData ID ID #REQUIRED OriginatorElRef NMTOKEN #REQUIRED DestinationElRefs NMTOKENS #REQUIRED >
<！ELEMENT TradingRoleData（PackagedContent +）> <！ATTLIST TradingRoleData ID ID #REQUIRED OriginatorElRef NMTOKEN #REQUIRED DestinationElRefs NMTOKENS #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Trading Role Data Component within the IOTP Transaction.
ID一意IOTPトランザクション内トレーディング役割データ・コンポーネントを識別する識別子。
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は、取引の役割データコンポーネントを作成し、「レスポンス」ブロック（例えば、オファーレスポンスや支払応答ブロック）でそれを含め組織の組織構成要素に要素参照が含まれています。
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).
DestinationElRefsは、「要求」ブロック（例えば、支払いの要求または配信要求ブロックのいずれか）での取引の役割データコンポーネントを受け取るためにある組織の組織構成要素に要素参照が含まれています。
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これは、1つのまたは複数のPackagedContent要素はセクション3.7を参照のような様々なトレーディング・ロールの間で送信されるべきデータを含みます。
The rules for deciding what to do with Trading Role Data Components are described below.
取引の役割データコンポーネントをどのように処理するかを決定するためのルールは、以下に記載されています。
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貿易の役割データコンポーネントは、「レスポンス」ブロックで受信されるたびにDestinationElRefs属性によって識別されるようにそれを受け取るためにある組織の組織構成要素を識別します。
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たび、「要求は、」ブロックは、それがDestinationElRefs属性によって識別される組織のいずれかに送られているかどうかをチェックし、送信されています。それはその後、「要求」ブロックに含まれている場合：
- the Trading Role Data Component as well as,
- 取引の役割データコンポーネントと同様に、
- the Organisation Component of the Organisation identified by the OriginatorElRef attribute (if not already present)
- OriginatorElRef属性によって識別された組織の組織成分（既に存在しない場合）
The Inquiry Type Component contains the information which indicates the type of process that is being inquired upon. Its definition is as follows.
問い合わせの種類コンポーネントは上に問い合わせされているプロセスの種類を示す情報を含みます。次のようにその定義があります。
<!ELEMENT InquiryType EMPTY > <!ATTLIST InquiryType ID ID #REQUIRED Type NMTOKEN #REQUIRED ElRef NMTOKEN #IMPLIED ProcessReference CDATA #IMPLIED >
<！ELEMENT InquiryType EMPTY> <！ATTLIST InquiryType ID ID #REQUIREDタイプNMTOKEN #REQUIRED ElRef NMTOKEN #IMPLIED ProcessReference CDATA #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Inquiry Type Component within the IOTP Transaction.
ID一意IOTPトランザクション内の問い合わせの種類コンポーネントを識別する識別子。
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.
種類は、お問い合わせの種類が含まれています。タイプの有効な値は以下のとおりです。Oオファー。お問い合わせは、オファーの状況についてですマーチャントにアドレス指定されています。 O支払い。お問い合わせは、支払いの状況についてですと支払いハンドラにアドレス指定されています。 O配信。お問い合わせは、配達の状況についてですと配達ハンドラ宛。
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 o Payment Component when Type is Payment o Delivery Component when Type is Delivery
ElRefは、このお問い合わせタイプコンポーネントが適用されるコンポーネントに（セクション3.5を参照）要素の参照が含まれています。タイプが配達されたときにタイプの種類が配達コンポーネント○お支払の場合に支払コンポーネントoをオファーされた場合にはTPOブロックO、です
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必要に応じて上に照会されるプロセスへの参照を含みます。情報が利用可能な場合には設定する必要があります。それは含まれていてもよい値の定義については、状況コンポーネントのProcessReference属性が（セクション7.16を参照）を参照してください。
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構造の定義は、この文書と同時に発表されケントダビッドソンと義明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.
各署名要素は、デジタル署名他の成分を含む一つ以上のブロックまたはコンポーネントを署名します。
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トランザクション内の1つ以上のIOTPメッセージ内の1つまたは複数のブロックまたはコンポーネントのダイジェストを含んでおり、ダイジェスト要素に結果を配置します
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他の署名の種類に関する情報、発信者及び潜在署名の受信者と使用される署名アルゴリズムの詳細は、これらのダイジェスト要素を連結し、マニフェスト要素に配置し、そして
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は、署名コンポーネント内の値要素に結果を配置する署名ブロック内の証明書の要素で識別された任意の証明書を使用して、マニフェスト要素に署名します
Note that there may be multiple Value elements that contain signatures of a Manifest Element.
Manifest要素のシグネチャを含む複数値の要素が存在し得ることに留意されたいです。
A Signature Component can be one of four types either:
署名要素は、4つのタイプのいずれか一方であることができます。
o an Offer Response Signature,
Oオファーレスポンス署名、
o a Payment Response Signature, o a Delivery Response Signature, or
○お支払レスポンス署名、O配達応答署名、または
o an Authentication Response Signature.
認証応答標示O。
For a general explanation of signatures see section 6 Digital Signatures.
署名の一般的な説明についてはセクション6デジタル署名を参照してください。
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
Signature要素
The ID attribute is mandatory.
ID属性は必須です。
MANIFEST ELEMENT
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属性は、マニフェスト内のすべてのダイジェスト要素の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
アルゴリズムとPARAMETER ELEMENTS
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.
アルゴリズムの要素は、署名を生成する際に使用されるアルゴリズムを識別する。アルゴリズムの種類は、それがダイジェストアルゴリズム、署名アルゴリズム又は鍵共有アルゴリズムとして使用するかどうかを示すType属性の値によって定義されます。
The following Digest algorithms must be implemented:
以下のダイジェストアルゴリズムを実装する必要があります。
o a [DOM-HASH] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:ibm:dom-hash"
[DOM-HASH]アルゴリズムO。これは、アルゴリズム要素のName属性を設定することによって識別され、「URN：IBM：DOM-ハッシュ」
o a [SHA1] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:fips:sha1", and
[SHA1]アルゴリズムO。 「：FIPS：URN SHA1」これは、アルゴリズムの要素へのName属性を設定することにより識別され、
o a [MD5] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:rsa:md5"
[MD5]アルゴリズムO。これは「：RSA：MD5壷」にアルゴリズム要素のName属性を設定することによって識別されます
o The following Signature algorithms must be implemented:
O次の署名アルゴリズムを実装する必要があります。
o a [DSA] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:us.gov:dsa"
[DSA]アルゴリズムO。これは、アルゴリズム要素のname属性を設定することによって識別されると、「URN：us.gov：DSA」
o a [HMAC] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:ibm:hmac"
[HMAC]アルゴリズムO。これは、アルゴリズム要素のName属性を設定することによって識別され、「URN：IBM：HMAC」
It is recommended that the following Signature algorithm is also implemented:
以下の署名アルゴリズムも実装されていることをお勧めします。
o a [RSA] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:rsa:rsa"
[RSA]アルゴリズムO。これは、アルゴリズム要素のName属性を設定することによって識別され、「URN：RSA：RSA」
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.
加えて、他の支払い方式特定のアルゴリズムを使用することができます。この場合、使用するname属性の値は、そのアルゴリズムの決済スキームサプリメントで指定されています。
One algorithm may make use of other algorithms by use of the Parameter element, for example:
一のアルゴリズムは、例えば、パラメータ要素の使用により、他のアルゴリズムを利用してもよいです。
<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>
<アルゴリズムID = A1タイプは= "ダイジェスト" 名前= "壷：IBM：DOM-ハッシュ"> <パラメータタイプ= 'AlgorithmRef'> A2 </パラメータ> </アルゴリズム> <アルゴリズムID = A2タイプ= "ダイジェスト" 名= "URN：FIPS：SHA1"> </アルゴリズム> <アルゴリズムID = A3タイプ= "署名" NAME = "URN：IBM：HMAC"> <パラメータ・タイプ= 'AlgorithmRef'> A1 </パラメータ> </アルゴリズム>
DIGEST ELEMENT
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:
トランザクションIDコンポーネントのIotpTransId属性の値O、続い：
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.
ダイジェストの主題であるIOTPトランザクション内の要素に（セクション3.5を参照）要素リファレンスO。
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属性の構造を分析する前に、それは（すぐ上記参照）マニフェスト要素のLocatorHrefBase属性の値と連結されなければなりません。
ATTRIBUTE ELEMENT
attribute要素
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署名型の値を持つとのいずれかにコンテンツが設定されたType属性が含まれ、唯一の属性の要素がなければなりません：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要素の含有量の値は、ユーザ定義の値が定義されることを可能にする12のIANA問題セクションで定義された手順の下で制御されています。
The Critical attribute must be set to true.
重要な属性をtrueに設定する必要があります。
ORIGINATORINFO ELEMENT
ORIGINATORINFO ELEMENT
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属性が常に存在し、署名コンポーネントを生成した組織の組織成分に対する要素リファレンス（セクション3.5を参照）を含んでいなければなりません。
RECIPIENTINFO ELEMENT
RecipientInfo ELEMENT
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属性は、署名を検証する必要があるかもしれません団体に、その点を要素参照（セクション3.5を参照）のリストが含まれています。詳細については以下を参照してください。
The Manifest Element of a signature which has a type of OfferResponse should contain Digest elements for the following Components:
OfferResponseの型を持つ署名のマニフェスト要素は、以下のコンポーネントのダイジェスト要素を含むべきです。
o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Offer Response Signature
オファーレスポンス署名を含むIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照）O
o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Offer Response Signature
オファーレスポンスの署名が含まれているIOTPメッセージのトランザクション・リファレンスブロック（セクション3.3を参照してください）O
o from the TPO Block:
TPOブロックからO：
- the Protocol Options Component
- プロトコル・オプションコンポーネント
- each of the Organisation Components
- 組織の各コンポーネント
- each of the Brand List Components
- ブランドリストコンポーネントの各
o optionally, all the Brand Selection Components if they were sent to the Merchant in a TPO Selection Block
O、必要に応じて、すべてのブランドの選択コンポーネントを、彼らはTPO選択ブロック内の商人に送られた場合
o from the Offer Response Block:
オファー応答ブロックからO：
- the Order Component
- 次成分
- each of the Payment Components
- 支払コンポーネントの各
- the Delivery Component
- 配信コンポーネント
- each of the Authentication Request Components
- 認証要求コンポーネントの各々
- any 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:
オファーレスポンス署名も又は署名を検証する必要があるかもしれ組織のそれぞれを記述するコンポーネントのダイジェスト要素を含むべきです。これには、次
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.
商人は、ブランドの選択コンポーネントを含むTPO選択ブロックを受信した場合には、O、そしてブランドの選択コンポーネントおよび配信コンポーネントで識別配達ハンドラによって識別される支払ハンドラのダイジェスト要素を生成します。ブロックは、これを行う方法の詳細については、正しい組織に送られたセクション6.3.1チェック要求を参照してください。
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選択ブロックを受け取り配達ハンドラーと関わっているすべての支払ハンドラのダイジェスト要素を生成するために期待されていない場合。
The Manifest Element of the Payment Receipt Signature Component should contain Digest Elements for the following Components:
支払領収書の署名コンポーネントのマニフェスト要素は、以下のコンポーネントのダイジェストの要素が含まれている必要があります。
o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Payment Receipt Signature
支払レシート署名を含むIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照）O
o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Payment Receipt Signature
支払領収書の署名が含まれているIOTPメッセージのトランザクション・リファレンスブロック（セクション3.3を参照してください）O
o the Offer Response Signature Component
オファーレスポンス署名コンポーネントO
o the Payment Receipt Component
支払領収書のコンポーネントO
o the Payment Note Component
支払注意コンポーネントO
o the Status Component o the Brand Selection Component.
ブランドセレクションコンポーネントのステータスコンポーネントO。
o any Trading Role Data Components
任意の取引の役割データコンポーネントO
The Manifest Element of the Delivery Response Signature Component should contain Digest Elements for the following Components:
配信レスポンス署名コンポーネントのマニフェスト要素は、以下のコンポーネントのダイジェストの要素が含まれている必要があります。
o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Delivery Response Signature
配信レスポンス署名が含まれているIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照してください）O
o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Delivery Response Signature
配信レスポンス署名が含まれているIOTPメッセージのトランザクション・リファレンスブロック（セクション3.3を参照してください）O
o the Consumer Delivery Data component contained in the preceding Delivery Request (if any)
（もしあれば）先行配信要求に含まれている消費者配信データコンポーネントO
o the Signature Components contained in the preceding Delivery Request (if any)
（もしあれば）先行配信要求に含まれる署名コンポーネントO
o the Status Component
状況コンポーネントO
o the Delivery Note Component
納品書コンポーネントO
The Manifest Element of the Authentication Request Signature Component should contain Digest Elements for the following Components:
認証要求署名コンポーネントのマニフェスト要素は、以下のコンポーネントのダイジェストの要素が含まれている必要があります。
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
IOTPメッセージとIOTPトランザクションを記述する情報が含まれているIOTPメッセージのトランザクション参照ブロック（セクション3.3を参照）O
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
Oグローバル一意IOTPトランザクションを識別するトランザクションIDコンポーネント（セクション3.3.1を参照）
o the following components of the TPO Block :
TPOブロックの次のコンポーネントO：
- the Protocol Options Component
- プロトコル・オプションコンポーネント
- the Organisation Component
- 組織コンポーネント
o the following components of the Authentication Request Block:
認証要求ブロックの次のコンポーネント（O）
- the Authentication Request Component(s) (if present)
- 認証要求コンポーネント（単数または複数）（存在する場合）
- the Trading Role Information Request Component (if present)
- 取引のロール情報の要求コンポーネント（存在する場合）
The Manifest Element of the Authentication Response Signature Component should contain Digest Elements for the following Components:
認証応答署名コンポーネントのマニフェスト要素は、以下のコンポーネントのダイジェストの要素が含まれている必要があります。
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
IOTPメッセージとIOTPトランザクションを記述する情報が含まれているIOTPメッセージのトランザクション参照ブロック（セクション3.3を参照）O
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
Oグローバル一意IOTPトランザクションを識別するトランザクションIDコンポーネント（セクション3.3.1を参照）
o the following components of the Authentication Request Block:
認証要求ブロックの次のコンポーネント（O）
- the Authentication Request Component that was used in the Authentication (if present)
- 認証に用いた認証要求コンポーネント（存在する場合）
- the Trading Role Information Request Component (if present)
- 取引のロール情報の要求コンポーネント（存在する場合）
o the Organisation Components contained in the Authentication Response Block
O組織コンポーネントは、認証応答ブロックに含まれます
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.
問い合わせ要求が署名されている場合問い合わせ要求署名コンポーネントのマニフェスト要素は、問い合わせの種類コンポーネントのダイジェスト要素を含み、存在する場合、支払スキームコンポーネントべきである（セクション9.2.1を参照）。
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.
問い合わせ応答が署名されている場合問い合わせ応答署名コンポーネントのマニフェスト要素は、取引応答ブロックおよびステータスコンポーネントのダイジェスト要素を含むべきである（セクション9.2.1を参照）。
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要求は、（セクション9.2.2を参照）調印されている場合は、ping要求の署名要素のマニフェスト要素は、すべての組織コンポーネントのダイジェスト要素を含むべきです。
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の応答は（セクション9.2.2を参照）が調印されている場合は、Pingの応答署名コンポーネントのマニフェスト要素は、すべての組織コンポーネントモミダイジェスト要素が含まれている必要があります。
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.19署名コンポーネントの開始時に注意を参照してください。
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.
証明書のコンポーネントは、デジタル証明書が含まれています。必要な場合にのみ非対称暗号化が使用されており、チェックする必要がある署名の受信者は、すでに公開鍵を受信していないとき、彼らは、例えば、使用されています。
The structure of a Certificate Component is defined in [IOTPDSIG].
証明書のコンポーネントの構造は、[IOTPDSIG]で定義されています。
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
証明書のCOMPONENT
The ID attribute is mandatory.
ID属性は必須です。
VALUE ELEMENT
VALUE ELEMENT
The ID attribute is mandatory.
ID属性は必須です。
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.
エラーコンポーネントは、貿易に関わる取引の役割の一つによって受信されたIOTPメッセージで（セクション4.1を参照）技術的なエラーに関する情報が含まれています。
For clarity two phrases are defined which are used in the description of an Error Component:
明確にするために2つの句は、エラーコンポーネントの説明に使用される定義されます。
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 Component that describes the error found in a message in error.
Oメッセージは、エラーを報告します。エラーメッセージ内で見つかったエラーを説明するエラーコンポーネントが含まれているIOTPメッセージ。
The definition of the Error Component is as follows.
次のようにエラーコンポーネントの定義があります。
<!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重大度（警告| TransientError | HardError）#REQUIRED MinRetrySecs CDATA #IMPLIED SwVendorErrorRef CDATAの＃黙示>
Attributes:
属性：
ID An identifier which uniquely identifies the Error Component within the IOTP Transaction.
ID一意IOTPトランザクション内のエラーコンポーネントを識別する識別子。
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は、このコンポーネント内の属性または子要素で使用する言語を定義します：langは、子要素の属性。セクション3.8は、言語の識別を参照してください。
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エラーでメッセージにエラーの内容を示すエラーコードを含みます。 ErrorCodeの有効な値は、セクション7.21.2エラーコードに与えられています。
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
LANG：ErrorDescは、XMLで定義された言語でのエラーの物語の記述が含まれています。この属性の内容は、エラーコンポーネントを生成したソフトウェアのベンダー/開発者によって定義されます
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
重大度は、エラーの重大度を示します。有効な値は以下のとおりです。o警告。これはエラーでメッセージがあるものの、IOTPトランザクションがまだ継続できることを示しています。 TransientError O。 ErrorLocation要素によって参照されるエラーにメッセージが再送信される場合、これはエラーでメッセージでエラーを回復することができることを示しています
o HardError. This indicates that there is an
unrecoverable error in the message in error and
the IOTP Transaction must stop.
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.
重大度がTransientErrorに設定されている場合MinRetrySecsは、この属性は存在しなければなりません。これは、全体の秒数の最小値であるErrorLocation要素によって識別されるエラーでメッセージを再送信する前に待機しなければならないエラーを報告するメッセージを受け取ったIOTP対応アプリケーション。
If Severity is not set to TransientError then the
value of this attribute is ignored.
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この属性は、値がエラーコンポーネントを生成したソフトウェアのベンダー/開発者によって設定された基準です。それは彼らのソフトウェアの正確な位置及びソフトウェアがエラーを報告するメッセージを発生させる状況のセットを識別するためにベンダーを可能にするデータを含むべきです。また、トランザクションのリファレンスブロック（セクション3.3）でのメッセージ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これはエラーでメッセージと、可能なエラー成分が生成される原因となったエラーでメッセージ内の要素と属性のIOTPトランザクション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.
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これは、エラーを理解するために使用できる追加データが含まれています。その内容は、エラーの性質に応じて適宜変化させる（セクション7.21.2エラーコードを参照）、IOTP対応アプリケーションのベンダー/開発者の裁量でもよいです。 PackagedContentの定義については3.7節を参照してください。
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.
エラーを報告するメッセージに複数のエラーコンポーネントがある場合は、重大度が最も高いとエラーコンポーネントのための適切なアクションを実行します。この文脈において、HardErrorは警告よりも高い重大度を有するTransientError、より高い重大度を有しています。
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対応アプリケーションは、重大度属性が警告に設定されているエラーコンポーネントとのエラーを報告するメッセージを生成している場合は、エラーを報告するメッセージが高い警告よりも重大度別のエラーコンポーネントが含まれていない場合は、IOTPメッセージも必要エラーは表示されませんされていた場合は含まれていたであろう貿易ブロックと取引コンポーネントが含まれます。
If a message reporting the error is received with an Error Component where Severity is set to Warning, then:
エラーを報告するメッセージは、重大度を警告に設定されているエラーコンポーネントを受信した場合：
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:
IOTP対応アプリケーションの実装は、どちらかでなければなりませんO、自分またはユーザーの裁量で：
- 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).
- HardError（セクション7.21.1.3を参照）に設定重大度を持つエラーコンポーネントとのエラーを報告するメッセージを生成することによって、IOTPトランザクションを失敗。
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取引を継続する場合には、継続するトランザクションの正常な処理に必要な貿易ブロックと取引コンポーネントが存在していることを確認してください。そうでない場合は、HardErrorに重要度が設定されたエラーコンポーネントでエラーを報告するメッセージを生成します。
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対応アプリケーションは、重大度属性がTransientErrorに設定されているエラーコンポーネントとのエラーを報告するメッセージを生成している場合は、エラーを報告するメッセージで唯一のエラーコンポーネントがあるはずです。また、MinRetrySecs属性が存在しなければなりません。
If a message reporting the error is received with an Error Component where Severity is set to TransientError then:
エラーを報告するメッセージは、重大度は、その後TransientErrorに設定されているエラーコンポーネントを受信した場合：
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
- 警告の重大度を持つエラーコンポーネントを含むエラーを報告するメッセージを生成し、無効なMinRetrySecsでエラーを報告するメッセージを送った取引の役割に送信される次のIOTPメッセージ（もしあれば）、上でそれを送信し、
- use a value for MinRetrySecs which is set by the vendor/developer of the IOTP Aware Application.
- IOTP対応アプリケーションのベンダー/開発者によって設定された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つのみErrorLocation要素がエラーコンポーネント内に含まれていることを確認し、それがTransientErrorの重症度とエラーコンポーネントの受信者によって送信されたIOTPメッセージを参照すること。複数のErrorLocationが存在する場合、HardErrorの重大度を持つエラーを報告するメッセージを生成します。
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対応アプリケーションは、重大度属性がHardErrorに設定エラーコンポーネントとのエラーを報告するメッセージを生成している場合は、エラーを報告するメッセージで唯一のエラーコンポーネントがあるはずです。
If a message reporting the error is received with an Error Component where Severity is set to HardError then terminate the IOTP Transaction.
エラーを報告するメッセージが重大度がHardErrorに設定されているエラーコンポーネントを受信した場合は、IOTPトランザクションを終了します。
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.
次の表は、エラーコンポーネントののErrorCode属性の有効な値が含まれています。説明の最初の文が表示されたときにエラーを記述するために使用されるか、そうでない場合に報告しなければならないテキストが含まれています。個々の実装は、その裁量で代替言語にこれを翻訳することができます。
An Error Code must not be more that 14 characters long.
エラーコードは、よりその14文字の長であってはなりません。
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).
予約予約。このエラーは、ソフトウェアのベンダー/開発者によって予約されています。トランザクションのリファレンスブロック（セクション3.3）でのメッセージID要素のSoftwareId属性を参照してください詳細については、ソフトウェアのベンダー/開発者にお問い合わせください。
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が整形されていない場合でも、まだ適切に形成されてエラー応答を生成することができるように、トランザクション・リファレンスブロックを見つけるためにスキャンする必要があります。
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]を参照してください。具体的に：XML文書は（セクション13、インターネットのオープン・トレーディング・プロトコル・データ型定義を参照）IOTP文書型宣言（DTD）で定義された制約に準拠していないO、およびXML文書が文書で定義された制約に準拠していないO宣言されているすべての追加[XML名前空間]の型宣言。
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.
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予期しない要素。 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要素がサポートされていません。 oは、本明細書に含まれている規則と制約と一致しているが、OはIOTPメッセージを処理しているIOTP対応のアプリケーションによってサポートされていません。文書が十分に形成され、有効であるが、要素が存在すること。
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要素が欠落しています。文書がうまく形成されており、有効ですが、要素は、この仕様書に含まれているルールと制約に従っている場合はそれが存在しているはずがありません。
In this case set the PackagedContent of the Error
Component to the type of the missing element.
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要素内容違法。文書が整形して有効であるが、要素の内容は、この仕様書に含まれているルールや制約に準拠していない値が含まれています。
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カプセル化されたプロトコル・エラー。文書が十分に形成され、有効であるが、素子の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。 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はサポートされていない属性。 XML文書が十分に形成され、有効な、及び要素内の属性の存在がルール及び本明細書に含まれる制約と一致しているが、それはIOTPメッセージを処理しているIOTP対応のアプリケーションによってサポートされていません。
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。文書がうまく形成されており、有効ですが、属性は、この仕様書に含まれているルールと制約に従っている場合はそれが存在しているはずがありません。
In this case set the PackagedContent of the Error
Component to the type of the missing attribute.
AttValIllegal Attribute value illegal. The attribute contains a value which does not conform to the rules and constraints contained in this specification.
違法AttValIllegal属性値。属性は、この仕様書に含まれているルールや制約に適合しない値が含まれています。
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のアプリケーションが認識できなかったエラーを報告するメッセージを生成する値が含まれています。
MsgTooLarge Message too large. The message is too large to be processed by the IOTP Aware Application.
MsgTooLargeメッセージが大きすぎます。メッセージはIOTP対応のアプリケーションによって処理するには大きすぎます。
ElTooLarge Element too large. The element is too large to be processed by the IOTP Aware Application
ElTooLarge要素が大きすぎます。要素はIOTP対応のアプリケーションによって処理するには大きすぎます
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値が小さすぎるか早いです。要素や属性の内容の全部または一部の値が、有効なものの、小さすぎます。
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値が大きすぎるか、将来インチ要素や属性の内容の全部または一部の値が、有効なものの、大きすぎます。
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、または属性の値が値と矛盾はO一つ以上の他の属性の。
In this case create ErrorLocation elements which
identify all the attributes or elements which are
inconsistent.
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トランスポートエラーが発生しました。このエラーコードは、受信されるメッセージを防止されるトランスポート機構に問題があることを示すために使用されます。これは、通常、一時的なエラーに関連付けられています。トランスポートエラーの説明ErrorDesc属性内に含まれています。 TransportErrorとErrorDesc内で使用できる値は、トランスポート機構のための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メッセージが処理されています。このエラーコードは、のみ一時的なエラーの重大度で使用されます。応答が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 the time indicated by the MinRetrySecs attribute, then the original message should be resent.
SystemBusyシステムビジー。このエラーコードは、のみ一時的なエラーの重大度で使用されます。これは、メッセージを受信したサーバがメッセージを処理するために、現在ビジー状態であることを示しています。応答が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.
注：トランスポート機構を（例えば、HTTP）処理サーバ/システムがビジーである場合、トランスポート固有のエラーメッセージではなくIOTPエラーメッセージを使用すべきです。このコードは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.
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.
エラーロケーション要素は、要素及び任意のエラーに関連付けられているエラーでメッセージ内の属性を識別する。それは誤りであるIOTPメッセージ、貿易ブロック、取引コンポーネント、要素や属性への参照が含まれています。
<!ELEMENT ErrorLocation EMPTY > <!ATTLIST ErrorLocation ElementType NMTOKEN #REQUIRED IotpMsgRef NMTOKEN #IMPLIED BlkRef NMTOKEN #IMPLIED CompRef NMTOKEN #IMPLIED ElementRef NMTOKEN #IMPLIED AttName NMTOKEN #IMPLIED >
<！ELEMENT ErrorLocation EMPTY> <！ATTLIST ErrorLocationのElementType NMTOKEN #REQUIRED IotpMsgRef NMTOKEN #IMPLIED BlkRef NMTOKEN #IMPLIED CompRef NMTOKEN #IMPLIED ElementRef NMTOKEN #IMPLIED AttName NMTOKEN #IMPLIED>
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。要素は、<！ELEMENT組織として宣言された場合、たとえば...その名は「組織」です。
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これは、このエラーコンポーネントが適用されるエラーでメッセージの（セクション3.3.2を参照）メッセージIDコンポーネントのIDの属性の値です。
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、これはエラーが配置されている取引のブロックの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エラーは、特定の取引コンポーネントに関連付けられている場合、これはエラーが配置されている取引コンポーネントの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エラーが取引コンポーネント内の特定の要素に関連付けられている場合は要素が「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、これはその属性の名前です。この場合、エラーコンポーネントの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.
できるだけ属性だけ多くが含まれなければならないことに注意してください。取引コンポーネントの子要素内の属性が不正な値が含まれている場合たとえば、その後、ErrorLocationのすべての属性が存在しなければなりません。
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.
取引ブロックは直接取引に参加している別の取引の役割間でドキュメント[XML]の形式で送信されているトップレベルのIOTPメッセージの子要素です。
Each Trading Blocks consist of one or more Trading Components (see section 7). This is illustrated in the diagram below.
各取引ブロックは、一つ以上の取引コンポーネント（セクション7を参照）で構成されています。これは、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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.
|
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 16 Trading Blocks
図16のトレーディングブロック
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:
取引ブロックはIOTPメッセージの定義の一部として定義される（セクション3.1.1を参照）。 IOTPメッセージ要素の定義は、ここでは繰り返されます。
<!ELEMENT IotpMessage ( TransRefBlk, SigBlk?, ErrorBlk?, ( AuthReqBlk | AuthRespBlk | AuthStatusBlk | CancelBlk | DeliveryReqBlk | DeliveryRespBlk | InquiryReqBlk | InquiryRespBlk | OfferRespBlk | PayExchBlk | PayReqBlk | PayRespBlk | PingReqBlk | PingRespBlk | TpoBlk | TpoSelectionBlk )* ) >
<！ELEMENT 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のこのバージョンで取引ブロックを定義します。彼らです：
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 Offer Response Block
オファー応答ブロックO問い合わせ応答ブロックO
o Payment Exchange Block
○お支払為替ブロック
o Payment Request Block
○お支払要求ブロック
o Payment Response Block
○お支払応答ブロック
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.
トランザクションのリファレンスブロックは、セクション3.3に記載されています。
The TPO Trading Block contains options which apply to the IOTP Transaction. The definition of a TPO Trading Block is as follows.
TPO貿易ブロックがIOTPトランザクションに適用されるオプションが含まれています。次のようにTPO貿易ブロックの定義があります。
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) > <!ATTLIST TpoBlk ID ID #REQUIRED >
<！ELEMENT TpoBlk（ProtocolOptions、BrandList *、組織*）> <！ATTLIST TpoBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Trading Protocol Options Block within the IOTP Transaction (see section 3.4 ID Attributes).
ID一意IOTPトランザクション内トレーディング・プロトコル・オプションブロックを識別する識別子（セクション3.4 ID属性を参照します）。
Content:
コンテンツ：
ProtocolOptions The Protocol Options Component (see section 7.1)defines the options which apply to the whole IOTP Transaction (see section 9).
ProtocolOptionsプロトコルオプションコンポーネント（セクション7.1を参照）（セクション9を参照）全体IOTPトランザクションに適用されるオプションを定義します。
BrandList This Brand List Component contains one or more payment brands and protocols which may be selected (see section 7.7).
BrandListこのブランドのリストコンポーネントは、（セクション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ザ機関コンポーネント（セクション7.6を参照）IOTPトランザクションに組織とその役割を同定します。存在していなければならない役割や組織はIOTPトランザクションの特定の種類に依存します。セクション9.インターネットオープン取引議定取引における各トランザクションの定義を参照してください。
The TPO Block should contain:
TPOブロックが含まれている必要があります。
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の取引役割で、配達はIOTPトランザクションに含ま
o Brand List Components for each payment in the IOTP Transaction
IOTPトランザクション内の各支払いのブランド一覧コンポーネントO
o Organisation Components for all the Payment Handlers involved
関係するすべての支払ハンドラの組織コンポーネントO
o optionally, Organisation Components for the Delivery Handler (if any) for the transaction
O、必要に応じて、取引のための配達ハンドラのための機関コンポーネント（もしあれば）
o additional Organisation Components that the Merchant may want to include. For example
商人は含めることができ、追加の組織コンポーネントO。例えば
- a Customer Care Provider
- 顧客ケアプロバイダ
- an Certificate Authority that offers Merchant "Credentials" or some other warranty on the goods or services being offered.
- 商人「資格情報」や提供される商品やサービスの他のいくつかの保証を提供しています認証局。
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選択ブロックトレーディングプロトコル・オプションブロック（セクション8.1を参照）に含まれているオプションから作られた選択の結果が含まれている次のようにTPO選択ブロックの【選択定義があります。
<!ELEMENT TpoSelectionBlk (BrandSelection+) > <!ATTLIST TpoSelectionBlk ID ID #REQUIRED >
<！ELEMENT TpoSelectionBlk（BrandSelection +）> <！ATTLIST TpoSelectionBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the TPO Selection Block within the IOTP Transaction.
ID一意IOTPトランザクション内TPO選択ブロックを識別する識別子。
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これはIOTPトランザクション内でのお支払いに使用する支払いブランド、支払いプロトコルの選択を識別します。各支払いがIOTPトランザクションで作られるため1つのブランドセレクション成分（セクション7.8を参照）があります。
The TPO Selection Block should contain one Brand Selection Component for each Brand List in the TPO Block.
TPO選択ブロックは、TPOブロック内の各ブランドの一覧用の1つのブランド選択のコンポーネントが含まれている必要があります。
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.
オファー応答ブロックは場所を取るためにある商品、サービス、金額、配達指示や金融取引の詳細が含まれています。次のようにその定義があります。
<!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*) > <!ATTLIST OfferRespBlk ID ID #REQUIRED >
<！ELEMENT OfferRespBlk（ステータス、注文?,支払*、配達?, TradingRoleData *）> <！ATTLIST OfferRespBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Offer Response Block within the IOTP Transaction.
ID一意IOTPトランザクション内オファー応答ブロックを識別する識別子。
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.
ステータスは、オファーの世代のビジネスの成功（セクション4.2を参照）、または失敗に関するステータス情報が含まれています。オファー応答ブロックで、NotYetStartedかのInProgressのProcessStateが不正な値であることに注意してください。
Order The Order Component contains details about the goods, services or financial transaction which is taking place see section 7.5.
行われている商品、サービス、または金融取引に関する次成分が含まれている注文の詳細は、セクション7.5を参照してください。
The Order Component must be present unless the
ProcessState attribute of the Status Component is
set to Failed.
Payment The Payment Components contain information about the payments which are to be made see section 7.9.
お支払いお支払いコンポーネント参照セクション7.9なされるべき支払いに関する情報が含まれています。
Delivery The Delivery Component contains details of the delivery to be made (see section 7.13).
配達ザ・配達成分（セクション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ザ・貿易の役割データコンポーネントはIOTPトランザクション（セクション7.17を参照）に関わる取引の役割との間で通信する必要がある不透明なデータが含まれています。
The Offer Response Block should contain: o the Order Component for the IOTP Transaction
応答ブロックが含まれている必要があります提供：次成分O IOTPトランザクションについて
o Payment Components for each Payment in the IOTP Transaction
IOTPトランザクション内の各お支払いのためのO支払いコンポーネント
o the Delivery Component the IOTP Transaction requires (if any).
配達コンポーネントoをIOTPトランザクションは、（もしあれば）が必要です。
The Authentication Request Block contains the data which is used by one Trading Role to obtain information about and optionally authenticate another Trading Role.
認証要求ブロックは、情報を取得し、必要に応じて別の取引の役割を認証するために、1つの取引の役割で使用されるデータを含みます。
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組織に関する追加情報の要求が認証されています。
Its definition is as follows.
次のようにその定義があります。
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) > <!ATTLIST AuthReqBlk ID ID #REQUIRED >
<！ELEMENT AuthReqBlk（AUTHREQ * TradingRoleInfoReq？）> <！ATTLIST ID AuthReqBlk ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Authentication Request Block within the IOTP Transaction.
ID一意IOTPトランザクション内の認証要求ブロックを識別する識別子。
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各認証リクエスト（セクション7.2を参照）コンポーネントは、認証要求の受信者が認証応答コンポーネント（セクション7.3を参照）を生成することによって自分自身を認証することができる代替方法を記載しています。
If one Authentication Request Component is
present then that Authentication Request
Component should be used.
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.
複数の認証要求コンポーネントが存在する場合、受信者は、受信者またはそのソフトウェアの個人的な好みに基づいたコンポーネントのいずれかを選択しなければなりません。
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.
何の認証要求コンポーネントが存在しない場合には、取引の役割情報要求コンポーネントで指定された認証要求ブロックは、組織コンポーネントのリターンを要求していることを意味します。
TradingRoleInfoReq The Trading Role Information Request Component (see section 7.4) contains a list of Trading Roles about which information is being requested
取引役割情報要求コンポーネントをTradingRoleInfoReq情報が要求されているかについての取引の役割のリストが含まれています（セクション7.4を参照してください）
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.
それ以外の場合はエラーである認証ブロック内の少なくとも1つのコンポーネント（認証要求や取引の役割の情報要求のいずれか）が存在する必要があります。
The Authentication Response Block contains the response which results from processing the Authentication Request Block. Its definition is as follows.
認証応答ブロックは、認証要求のブロックを処理した結果、応答が含まれています。次のようにその定義があります。
<!ELEMENT AuthRespBlk (AuthResp?, Org*) > <!ATTLIST AuthRespBlk ID ID #REQUIRED >
<！ELEMENT AuthRespBlk（AuthResp？、組織*）> <！ATTLIST ID AuthRespBlk ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Authentication Response Block within the IOTP Transaction.
ID一意IOTPトランザクション内で認証応答ブロックを識別する識別子。
Content:
コンテンツ：
AuthResp The optional Authentication Response Component which contains the results of processing the Authentication Request Component - see section 7.3.
認証要求コンポーネントを処理した結果が含まれていAuthRespオプションの認証応答成分 - セクション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.
取引役割情報要求コンポーネントのTradingRoleList属性によって要求された取引の役割に対応する情報が含まれている組織のオプション組織のコンポーネント。
The components present in the Authentication Response Block must match the requirement of the corresponding Authentication Request Block otherwise it is an error.
認証応答ブロック中に存在する成分は、そうでなければ、それはエラーである対応する認証要求ブロックの要件と一致しなければなりません。
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.
認証ステータスブロックは、認証による認証応答ブロックの検証の成功または失敗を示します。次のようにその定義があります。
<!ELEMENT AuthStatusBlk (Status) > <!ATTLIST AuthStatusBlk ID ID #REQUIRED >
<！ELEMENT AuthStatusBlk（ステータス）> <！ATTLIST AuthStatusBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Authentication Status Block within the IOTP Transaction.
ID一意IOTPトランザクション内の認証ステータスブロックを識別する識別子。
Content:
コンテンツ：
Status Contains status information about the business success (see section 4.2) or failure of the authentication
ステータスは、ビジネスの成功（セクション4.2を参照）、または認証の失敗に関するステータス情報が含まれています
The Payment Request Block contains information which requests that a payment is started. Its definition is as follows.
支払要求ブロックは、支払いが開始されていることを要求した情報が含まれています。次のようにその定義があります。
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection, Payment, PaySchemeData?, Org*, TradingRoleData*) > <!ATTLIST PayReqBlk ID ID #REQUIRED >
<！ELEMENT PayReqBlk（ステータス+、BrandList、BrandSelection、支払い、PaySchemeData ?,組織*、TradingRoleData *）> <！ATTLIST PayReqBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Request Block within the IOTP Transaction.
ID一意IOTPトランザクション内支払要求ブロックを識別する識別子。
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 step depends. It is used to indicate the success or failure of those steps. Payment should only occur if the previous steps were successful.
ステータスは、このステップが依存するステップの応答の状況コンポーネント（セクション7.13を参照）（例えば、オファーレスポンスおよび/または支払Response）を含みます。これらのステップの成功または失敗を示すために使用されます。前の手順が成功した場合のお支払いにのみ発生する必要があります。
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ザ・ブランドリストコンポーネントを選択することができ、一つ以上のペイメントブランドとプロトコル（セクション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これは支払いブランド、支払いプロトコルとIOTPトランザクション内でのお支払いに使用する支払いハンドラの選択肢を識別します。各支払いがIOTPトランザクションで作られるため1つのブランドセレクション成分（セクション7.8を参照）があります。
Payment The Payment Components contain information about the payment which is being made see section 7.9.
お支払いお支払いコンポーネント参照セクション7.9行われている支払いに関する情報が含まれています。
PaySchemeData The Payment Scheme Component contains payment scheme specific data see section 7.10.
PaySchemeDataお支払いは、スキームコンポーネントは、特定のデータは、セクション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.
組織ザ・組織コンポーネントが支払いに関わる組織の詳細が含まれています（セクション7.6を参照してください）。本組織はIOTPトランザクションと署名されるべきデータに依存しています。詳細については、セクション6デジタル署名を参照してください。
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ザ・貿易の役割データコンポーネントはIOTPトランザクション（セクション7.17を参照）に関わる取引の役割との間で通信する必要がある不透明なデータが含まれています。
The Payment Request Block should contain:
支払要求ブロックが含まれている必要があります：
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 the Organisation Component (if any) for the Organisation which carried out the previous step, for example another Payment Handler
例えば、別の支払いハンドラの前工程を行う機関のための組織成分（もしあれば）O支払いの支払いハンドラの組織コンポーネントO
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あれば、次のステップを実行するために組織のための組織の成分です。これは、例えば、配信ハンドラまたは支払ハンドラのいずれであってもよいです。
o the Organisation Components for any additional Organisations that the Merchant has included in the Offer Response Block
商人は、オファーレスポンスブロックに含まれている任意の追加の組織のための組織コンポーネントO
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サプリメントで定義されています
o any Trading Role Data Components that may be required (see section 7.17.1).
必要とされるすべての取引の役割のデータコンポーネントO（セクション7.17.1を参照してください）。
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.
支払取引ブロックは、貿易の役割のうちの2つの間で交換される決済スキーム固有のデータが含まれています。次のようにその定義があります。
<!ELEMENT PayExchBlk (PaySchemeData+) > <!ATTLIST PayExchBlk ID ID #REQUIRED >
<！ELEMENT PayExchBlk（PaySchemeData +）> <！ATTLIST PayExchBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Exchange Block within the IOTP Transaction.
ID一意IOTPトランザクション内の支払取引のブロックを識別する識別子。
Content:
コンテンツ：
PaySchemeData This Trading Component contains payment scheme specific data see section 7.10 Payment Scheme Component.
PaySchemeDataこの取引コンポーネントは、特定のデータは、セクション7.10決済スキームのコンポーネントを参照の支払い方式を採用しています。
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.
このお支払い応答ブロックは、支払い状況、オプションの支払領収書、およびオプションの支払いプロトコルメッセージに関する情報が含まれています。次のようにその定義があります。
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?, PaymentNote?, TradingRoleData*) > <!ATTLIST PayRespBlk ID ID #REQUIRED >
<！ELEMENT PayRespBlk（ステータス、PayReceipt？、？、PaySchemeData PaymentNote ?, TradingRoleData *）> <！ATTLIST PayRespBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Response Block within the IOTP Transaction.
ID一意IOTPトランザクション内の支払応答ブロックを識別する識別子。
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を参照）、または失敗に関するステータス情報が含まれています。ペイ応答ブロックで、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が発生し、支払いを確認するために使用することができ、支払いスキーム固有のデータが含まれています。セクション7.11支払領収書のコンポーネントを参照してください。状況コンポーネントのProcessState属性がCompletedOkに設定されている場合、それが存在しなければなりません。 PayReceiptは、適切な支払スキームサプリメントによって指定されたその他の値はオプションです。
PaySchemeData Contains payment scheme specific data see section, for example a payment protocol message. See 7.10 Payment Scheme Component.
PaySchemeDataは、特定のデータは、例えばセクション、支払いプロトコルメッセージを参照支払い方式を採用しています。 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.
PaymentNoteは関連する追加、非支払い、支払いハンドラが消費者に提供したい情報が含まれています。撤退やデポジットが行われていた場合、転送が完了した後に例えば、それはアカウントの残高に関する情報を含めることができます。セクション7.12支払注意コンポーネントを参照してください。
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ザ・貿易の役割データコンポーネントはIOTPトランザクション（セクション7.17を参照）に関わる取引の役割との間で通信する必要がある不透明なデータが含まれています。
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.
配信要求ブロックは、配信が許可されていることを確認するために使用することができ、署名と一緒に配信される商品やサービスの詳細が含まれています。次のようにその定義があります。
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery, ConsumerDeliveryData?, TradingRoleData*) > <!ATTLIST DeliveryReqBlk ID ID #REQUIRED >
<！ELEMENT DeliveryReqBlk（ステータス+、注文、組織*、配達、ConsumerDeliveryData ?, TradingRoleData *）> <！ATTLIST DeliveryReqBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Delivery Request Block within the IOTP Transaction.
ID一意IOTPトランザクション内の配信要求ブロックを識別する識別子。
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.
ステータスは、このステップが依存するステップの応答の状況コンポーネント（セクション7.13を参照）（例えば、支払Response）を含みます。これらのステップの成功または失敗を示すために使用されます。前の手順が成功した場合は配達にのみ発生する必要があります。
Order The Order Component contains details about the goods, services or financial transaction which is taking place see section 7.5.
行われている商品、サービス、または金融取引に関する次成分が含まれている注文の詳細は、セクション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.
組織コンポーネント（セクション7.6を参照）組織と組織IOTPトランザクションにおけるそれらの役割を識別する。存在していなければならない役割や組織はIOTPトランザクションの特定の種類に依存します。セクション9.インターネットオープン取引議定取引における各トランザクションの定義を参照してください。
Delivery The Delivery Component contains details of the delivery to be made (see section 7.13).
配達ザ・配達成分（セクション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オプション。配達ハンドラによって返された場合、消費者により指定された識別子が参照されている納入識別するために、消費者が有効になりますが含まれています。
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ザ・貿易の役割データコンポーネントはIOTPトランザクション（セクション7.17を参照）に関わる取引の役割との間で通信する必要がある不透明なデータが含まれています。
The Delivery Request Block contains:
配信要求ブロックが含まれています。
o the Organisation Component with a Trading Role of Merchant
商人の取引の役割と組織コンポーネントO
o the Organisation Component for the Consumer and DeliverTo Trading Roles
消費者のための組織コンポーネントとDeliverTo取引の役割O
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。具体的に組織コンポーネントが配信コンポーネントにActionOrgRef属性によって識別されます
o the Organisation Component (if any) for the Organisation which carried out the previous step, for example a Payment Handler
前のステップを行う機関のための組織成分（もしあれば）、例えば支払いハンドラO
o the Organisation Components for any additional Organisations that the Merchant has included in the Offer Response Block
商人は、オファーレスポンスブロックに含まれている任意の追加の組織のための組織コンポーネントO
o any Trading Role Data Components that may be required (see section 7.17.1).
必要とされるすべての取引の役割のデータコンポーネントO（セクション7.17.1を参照してください）。
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.
配達応答ブロックは、商品が配送される方法の詳細を含む納品書が含まれています。次のようにその定義があります。配達応答ブロックにNotYetStartedかのInProgressのDeliveryStatusCodeで配信ステータス要素が無効であることに注意してください。
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) > <!ATTLIST DeliveryRespBlk ID ID #REQUIRED >
<！ELEMENT DeliveryRespBlk（ステータス、DeliveryNote）> <！ATTLIST DeliveryRespBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Delivery Response Block within the IOTP Transaction.
ID一意IOTPトランザクション内の配達応答ブロックを識別する識別子。
Content:
コンテンツ：
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を参照）、または失敗に関するステータス情報が含まれています。配達応答ブロックで、NotYetStartedかのInProgressのProcessStateが不正な値であることに注意してください。
DeliveryNote The Delivery Note Component contains details about how the goods or services will be delivered (see section 7.15).
配信は納品書のコンポーネントは、（セクション7.15を参照）を商品やサービスをお届けいたします方法についての詳細が含まれています。
The Inquiry Request Trading Block contains an Inquiry Type Component and an optional Payment Scheme Component to contain payment scheme specific inquiry messages.
問い合わせ要求取引ブロックは、支払スキーム、特定の照会メッセージを含むように照会タイプコンポーネントとオプションの決済スキームのコンポーネントが含まれています。
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) > <!ATTLIST InquiryReqBlk ID ID #REQUIRED >
<！ELEMENT InquiryReqBlk（InquiryType、PaySchemeData？）> <！ATTLIST InquiryReqBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Inquiry Request Trading Block within the IOTP Transaction.
ID一意IOTPトランザクション内の問い合わせ要求取引ブロックを識別する識別子。
Content:
コンテンツ：
InquiryType Inquiry Type Component (see section 7.18) that contains the type of inquiry.
お問い合わせの種類が含まれていInquiryType問い合わせタイプコンポーネント（セクション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決済スキームのコンポーネント（セクション7.10を参照してください）。問い合わせタイプコンポーネントのType属性がお支払いの場合にこれが存在しています。
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.
問い合わせレスポンス貿易ブロックは、状況コンポーネントおよび支払制度、特定の照会メッセージを格納するためのオプションの決済スキームのコンポーネントが含まれています。その目的は、サーバーでIOTPトランザクションの現在のステータスに問い合わせることです。
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) > <!ATTLIST InquiryRespBlk ID ID #REQUIRED LastReceivedIotpMsgRef NMTOKEN #IMPLIED LastSentIotpMsgRef NMTOKEN #IMPLIED >
<！ELEMENT InquiryRespBlk（ステータス、PaySchemeData？）> <！ATTLIST InquiryRespBlk ID ID #REQUIRED LastReceivedIotpMsgRef NMTOKEN #IMPLIED LastSentIotpMsgRef NMTOKEN #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Inquiry Response Trading Block within the IOTP Transaction.
ID一意IOTPトランザクション内問い合わせレスポンス貿易ブロックを識別する識別子。
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は、このサーバが消費者から受け取った最後のメッセージのメッセージIDコンポーネントへの要素の参照を（セクション3.5を参照してください）（セクション3.3.2を参照）が含まれています。何の以前の関連取引における消費者からのメッセージが受信されない場合は、この属性は、値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は、このサーバが消費者に送信された最後のメッセージのメッセージIDコンポーネントへの要素の参照を（セクション3.5を参照してください）（セクション3.3.2を参照）が含まれています。何も以前に適切なトランザクションで消費者にメッセージが送信されない場合は、この属性は、値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).
ステータスは、特定の取引所（すなわち、オファー、お支払い、または配達）のビジネスの成功（セクション4.2を参照）、または失敗に関するステータス情報が含まれています。
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決済スキームのコンポーネント（セクション7.10を参照してください）。状況コンポーネントのStatusType属性のType属性が支払いに設定されているときにこれが存在しています。
The Ping Request Block is used to determine if a Server is operating and whether or not cryptography is compatible.
Ping要求のブロックは、サーバーが動作しているかどうかを判断するために使用されているかどうかにかかわらない暗号は互換性があります。
The definition of a Ping Request Block is as follows.
次のようにping要求ブロックの定義があります。
<!ELEMENT PingReqBlk (Org*)> <!ATTLIST PingReqBlk ID ID #REQUIRED>
<！ELEMENT PingReqBlk（組織*）> <！ATTLIST PingReqBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Ping Request Trading Block within the IOTP Transaction.
ID一意IOTPトランザクション内ping要求取引ブロックを識別する識別子。
Content:
コンテンツ：
Org Optional Organisation Components (see section 7.6).
組織オプションの組織コンポーネント（7.6節を参照してください）。
If no Organisation Component is present then the
Ping Request is anonymous and simply determines if
the server is operating.
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.
組織コンポーネントが存在している場合しかし、それはping要求の送信者がデジタル署名を処理できることを確認したいことを示しています。
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自体が取引の役割（複数可）は、メッセージの意図された受信者を特定の組織コンポーネントO IOTPトランザクション（マーチャント、支払いハンドラなど）に取って指定識別する：送信者が含まれ、この場合には。
These are then used to generate a signature over the Ping Response Block.
次いで、これらは、Pingの応答ブロックを超える署名を生成するために使用されています。
The Ping Response Trading Block provides the result of a Ping Request.
Pingの応答貿易ブロックは、ping要求の結果を提供します。
It contains an Organisation Component that identifies the sender of the Ping Response.
これは、Pingの応答の送信者を特定する組織コンポーネントが含まれています。
If the Ping Request to which this block is a response contained Organisation Components, then it also contains those Organisation Components.
Ping要求は、このブロックは、組織コンポーネントに含まれる応答であるならば、それはまた、これらの組織コンポーネントが含まれています。
<!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（組織+）> <！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.
ID一意IOTPトランザクション内ping要求取引ブロックを識別する識別子。
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.
PingStatusCodeはIOTPメッセージを処理し、送信者のソフトウェアの状態を示したコードが含まれています。有効な値は次のとおりです。[OK]を、O。サービスとすべてが署名検証を含め、正常に動作しています。忙しいO。物事は正常に動作しているが、いくつかの遅延が発生することがあります。ダウンO。サーバーが完全に機能していないが、それでも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は、署名検証のステータスを示すコードが含まれています。これは、Ping要求ブロックを含むメッセージは、署名ブロックを含む場合にのみ存在します。有効な値は次のとおりです。[OK]を、O。署名は正常に確認し、互換性のある証明されています。 Oブロックは、署名の検証をサポートしていません。このping要求の受信機をはNotSupported。 O失敗。署名の検証に失敗しました。
Xml:lang Defines the language used in PingStatusDesc. This is present when PingStatusDesc is present.
XML：langはPingStatusDescで使用される言語を定義します。 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 attribute to send more refined status information than PingStatusCode which can be used for debugging purposes, for example.
PingStatusDescは、このpingの応答ブロックを送信し、サーバーの状態の簡単な説明が含まれています。サーバは、その設計者が望む場合、例えば、デバッグ目的のために使用することができますPingStatusCodeより洗練されたステータス情報を送信するには、この属性を使用することができます。
Content:
コンテンツ：
Org These are Organisation Components (see section 7.6).
ORGこれらは、組織コンポーネント（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.
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.
注意：Ping要求メッセージを受信したソフトウェアがまったく機能していないとき、何のPing応答メッセージが戻って送信されません、ので、Pingのステータスコードの値は、そのような失敗としての価値が含まれていません。
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.
（必要な場合）、署名ブロックは、符号データはIOTPトランザクションに関連付けられた1つ以上の署名コンポーネントと関連する証明書を含みます。 IOTPが署名を使用する方法の一般的な議論や概要については、第6章デジタル署名を参照してください。署名コンポーネントと証明書の定義は、紙に含まれている「インターネットオープン取引議定書のデジタル署名」、[IOTPDSIG]を参照してください。これらはIOTPで使用されているかの説明は、セクション7.19と7.20に含まれています。
The definition of a Signature Block is as follows:
次のように署名ブロックの定義は次のとおりです。
<!ELEMENT IotpSignatures (Signature+, Certificate*) > <!ATTLIST IotpSignatures ID ID #IMPLIED >
<！ELEMENT IOTP署名（署名、証明書*）> <！ATTLIST IOTP署名ID ID #IMPLIED>
Attributes:
属性：
ID An identifier which uniquely identifies the Signature Block within the IOTP Transaction.
ID一意IOTPトランザクション内の署名ブロックを識別する識別子。
Content:
コンテンツ：
Signature A Signature Component. See section 7.19.
署名署名コンポーネント。セクション7.19を参照してください。
Certificate A Certificate Component. See section 7.20.
証明書Aの証明書コンポーネント。セクション7.20を参照してください。
The contents of a Signature Block depends on the Trading Block that is contained in the same IOTP Message as the Signature Block.
署名ブロックの内容は、署名ブロックと同じIOTPメッセージに含まれているトレーディングブロックに依存します。
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).
オファー応答ブロックと同じメッセージである署名ブロックだけオファーレスポンス署名要素（セクション7.19.2を参照）を含みます。
A Signature Block which is in the same message as a Payment Request Block contains:
支払要求ブロックが含まれているものと同じメッセージ内で署名ブロック：
o an Offer Response Signature Component (see section 7.19.2), and
オファーレスポンス署名コンポーネントO（セクション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
支払（決済コンポーネントのStartAfter属性によって示されるように）前のステップに依存している場合、O、次いで支払いレシート署名コンポーネントは、前のステップによって生成された（セクション7.19.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.
A Signature Block which is in the same message as a Delivery
Request Block contains:
o an Offer Response Signature Component (see section 7.19.2), and
オファーレスポンス署名コンポーネントO（セクション7.19.2を参照）、および
o the Payment Receipt Signature Component (see section 7.19.3) generated by the previous step.
O前のステップによって生成された支払レシート署名コンポーネント（セクション7.19.3を参照）。
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.
配信応答ブロックと同じメッセージである署名ブロックはステップによって生成されただけ配信応答標示成分（セクション7.19.4を参照）を含みます。
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.
エラー貿易ブロックは、貿易に関わる取引の役割の一つによって受信されたIOTPメッセージにおける技術的なエラー（セクション4.1を参照）に関する情報を含む1つ以上の誤差成分（セクション7.21を参照）が含まれています。
For clarity two phrases are defined which are used in the description of an Error Trading Block:
明確にするために2つの句は、エラー・トレーディングブロックの説明で使用される定義されています。
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メッセージは、エラーを報告します。エラーメッセージ内で見つかったエラーを説明するエラートレーディングブロックが含まれている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.
エラー貿易ブロックがエラーを報告する任意のメッセージに含まれていてもよいです。その後、次のアクションは、エラーの重大度に依存します。重症度の異なる種類、その後発生する可能性がありますアクションの説明については、エラーコンポーネントの定義を参照してください。
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.
立方インチ注：エラー貿易ブロックは、複数の誤差成分を使用して、複数の異なるエラーを報告することができ、が、そうするためのIOTP認識アプリケーションの開発者の義務はありません。
The structure of an Error Trading Block is as follows.
以下のようにエラー・トレーディングブロックの構造があります。
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) > <!ATTLIST ErrorBlk ID ID #REQUIRED >
<！ELEMENT ErrorBlk（ErrorComp +、PaySchemeData *）> <！ATTLIST ErrorBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Error Trading Block within the IOTP Transaction.
ID一意IOTPトランザクション内のエラー貿易ブロックを識別する識別子。
Content:
コンテンツ：
ErrorComp An Error Components (see section 7.21) that contains information about an individual Technical Error.
個々の技術的なエラーに関する情報が含まれてErrorComp誤差成分（セクション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 determine whether or not this component needs to be present and for the definition of what it must contain.
支払スキームのメッセージが含まれていPaySchemeDataするオプションの決済スキームのコンポーネント（セクション7.10を参照してください）。このコンポーネントが存在し、それが含まれている必要がありますものの定義にする必要があるかどうかを判断するために、適切な支払スキームの補足を参照してください。
The Cancel Block is used by one Trading Role to inform any other that a transaction has been cancelled. Example usage includes:
キャンセルブロックは、取引がキャンセルされたことを他に知らせるために1つの取引の役割で使用されています。使用例が含まれています：
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それはもはや取引を継続する予定で非消費者の役割を知らせる消費者の役割。これが発生すると、タイムアウトを待たずに整然と取引を閉鎖するサーバーをできるようになります
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非消費者の役割は、取引が停止されている消費者の役割を通知します。この場合、消費者は、元が受信されなかったという誤った理解に送信された再送信前のメッセージに、その後はほとんどありません。
Its definition is as follows.
次のようにその定義があります。
<!ELEMENT CancelBlk (Status) > <!ATTLIST CancelBlk ID ID #REQUIRED >
<！ELEMENT CancelBlk（ステータス）> <！ATTLIST CancelBlk ID ID #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Cancel Block within the IOTP Transaction.
ID一意IOTPトランザクション内キャンセルブロックを識別する識別子。
Content:
コンテンツ：
Status Contains status information indicating that the IOTP transaction has been cancelled.
ステータスはIOTPトランザクションがキャンセルされたことを示すステータス情報が含まれています。
The Baseline Internet Open Trading Protocol supports three types of transactions for different purposes. These are
ベースラインのインターネットオープン取引議定書は、異なる目的のための取引の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
別によって貿易の一方の当事者の認証をサポートおよび/または他の取引の役割についての情報を要求し、認証IOTPトランザクションO
o IOTP Transactions that involve one or more payments. Specifically:
一つ以上の支払いを伴うIOTP取引O。具体的に：
- Deposit
- 保証金
- Purchase
- 購入
- Refund
- 払い戻し
- Withdrawal, and
- 撤退し、
- Value Exchange
- 価値交換
o IOTP Transactions designed to check the correct function of the IOTP infrastructure. Specifically:
IOTPインフラストラクチャの正しい機能をチェックするために設計されたIOTP取引O。具体的に：
- Transaction Status Inquiry, and
- トランザクション状態の問い合わせ、および
- Ping
- 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:
認証IOTPトランザクションが独自に動作することができますが、認証が必要に応じて、「支払い」取引のいずれかを先行することができます。したがって、このセクションの残りの部分を覆う2つの部分に分割されます。
o Authentication and Payment transactions (Authentication, Deposit, Purchase, Refund, Withdrawal and Value Exchange)
O認証と決済取引（認証、預金、購入、返金、撤退と価値交換）
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インフラ取引（トランザクションステータスの照会とPing）、および
The Authentication and Payment related IOTP Transactions consist
of six Document Exchanges which are then combined in sequence to
implement a specific transaction.
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.
一般的に、そこに近いですが、正確ではありません、ドキュメント取引所と取引所との対応。主な違いは、いくつかの文書交換が同時にインターネット経由で送信する必要があり、実際のIOTPメッセージの数を最小限にするために、一部または2つの取引の取引所のすべてを実装することです。
The six Document Exchanges are:
6ドキュメント交換は以下のとおりです。
o Authentication. This is a direct implementation of the Authentication Trading Exchange
認証O。これは、認証取引所の直接の実装です
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ブランド依存オファー。これは、支払取引所のブランド選択部と組み合わせたオファー取引所です。その目的は、オファーレスポンスの内容はそれに応じて適合させることができるように選択されたブランドの情報と販売を提供することです
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の種類Independentオファー。これはまた、オファー取引所です。しかし、この例では、オファーレスポンスの内容は、選択したブランドに依存しません。
o Payment. This is a direct implementation of the Payment part of a Payment Trading Exchange
O支払い。これは、支払取引所の決済一部の直接の実装です
o Delivery. This is a direct implementation of the Delivery Exchange
O配信。これは、配達所の直接の実装です
o Delivery with Payment. This is an implementation of combined Payment and Delivery Trading Exchanges
お支払いとO配信。これは、組み合わせたお支払いと配達貿易取引所の実装です
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.
これらの文書交換は、各IOTPトランザクションを実装するために異なる順序で一緒に結合されています。これらは組み合わせ可能な方法は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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
図17支払いと認証メッセージフローの組み合わせ
The combinations of Document Exchanges that are valid depend on the particular IOTP transaction.
有効な文書交換の組み合わせは、特定のIOTPトランザクションに依存します。
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、および
o descriptions of how each IOTP Transaction uses the Document Exchanges to effect the desired result.
各IOTPトランザクションは、望ましい結果をもたらすために文書交換をどのように使用するかのOの説明。
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.
注：さまざまなビジネスのエラーが（セクション4.2を参照）する方法を説明し従うドキュメント交換の説明が処理されます。これらのメッセージが送信されるコンテキストに関係なく同じように処理されるので、何の言及は技術的なエラーの取り扱いがなされていないメッセージのいずれかに（セクション4.1を参照）。詳細については、セクション4を参照してください。
The Authentication Document Exchange is a direct implementation of the Authentication Trading Exchange (see section 2.2.4). It involves:
認証文書の交換は、認証取引所（セクション2.2.4を参照）の直接の実装です。これは、含まれます。
o an Authenticator - the Organisation which is requesting the authentication, and
O認証 - 認証を要求している組織、および
o an Authenticatee - the Organisation being authenticated.
O被認証者 - 組織が認証されています。
The authentication consists of:
認証の構成は次のとおりです。
o an Authentication Request being sent by the Authenticator to the Authenticatee,
被認証に認証することによって送信される認証要求O、
o an Authentication Response being sent in return by the Authenticatee to the Authenticator which is then checked, and
次にチェックされるオーセンティケータに被認証によってリターンに送信される認証応答O、及び
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認証ステータスは、認証の成功または失敗の表示を提供するために、被認証者にAuthenticatorが送信されています。
An Authentication Document Exchange also:
また、認証文書の交換：
o provides an Authenticatee with an Organisation Component which describes the Authenticator, and
O認証を記述する組織コンポーネントと被認証を提供し、そして
o optionally provides the Authenticator with Organisation Components which describe the Authenticatee.
O必要に応じて被認証を記述する組織コンポーネントとの認証を提供します。
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.
関与しているIOTPメッセージは、以下の図によって示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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 | （認証）STEP | | 1.最初の組織は、組織が認証されている必要があります（HTMLページ上のボタンを押すことにより）行動をとります
1 --> 2 Authentication Need (outside scope of IOTP)
1 - > 2認証の必要性（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.第二の組織は、生成：1つ以上の認証要求構成要素及び/又はトレーディングロール情報要求コンポーネントを含む認証要求ブロックを、最初の組織に送信します
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対応アプリケーションが起動しました。署名ブロックが存在する場合、第一の組織は、第二の組織の資格を確認するためにこれを使用することができます。資格情報がOKであれば、最初の組織は（存在する場合と、複数）を使用する認証要求を選択し、認証応答ブロックを生成するために選択された認証アルゴリズムを使用します。存在する場合、取引役割情報要求コンポーネントは、組織のコンポーネントを生成するために使用されます。必要であれば、最終的に署名コンポーネントが作成され、すべてのコンポーネントは、次に、検証のために第二の組織に送り返されます。
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.第二機関は、最初の組織は、彼らがように見える人であることを確認するために、認証要求ブロック内のデータに対する認証応答を確認し、その後、停止した結果を示すために、最初の組織への認証ステータスブロックを送信します。
1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block;
Signature Block (optional); Auth Response Block
5. The first Organisation checks the authentication Status Block and optionally keeps information on the IOTP transaction for record keeping purposes and stops.
5.最初の機関は、認証ステータスブロックをチェックし、必要に応じて記録保持のためにIOTPトランザクションに関する情報を保持して停止します。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 18 Authentication Document Exchange
図18の認証文書交換
On receiving a TPO & Authentication Request IOTP Message (see below), an Authenticatee may either:
TPO＆認証要求IOTPメッセージを受信する（下記参照）、被認証のいずれかの可能性があります。
o generate and send an Authentication Response IOTP Message back to the Authenticator, or
O生成し、認証に戻って認証応答IOTPメッセージを送ったり、
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.
AutEeCancel、NoAuthReq、TradRolesIncon：Oバック認証のStatusType失敗のProcessStateとCompletionCode有する状況コンポーネントを含む認証にキャンセルブロックを送信することによって認証要求を遵守する失敗は（セクション7.16.4を参照）のいずれかに設定示しますまたは指定されていません。
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:
認証応答IOTPメッセージ（下記参照）を受信すると、オーセンティケータはStatusTypeが認証に設定されている状況コンポーネントを有する状態ブロックを含む（下記参照）、リターンに認証ステータスIOTPメッセージを送信し、必要があります。
o the ProcessState attribute of the Status Component is set to CompletedOk which indicates a successful completion, or
正常に完了したことを示し、またはCompletedOkに設定されている状況コンポーネントのProcessState属性O
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 ProcessState属性が失敗に設定され、CompletionCode属性に設定されるか：失敗した認証を示しAutOrCancel、AuthFailedまたは未指定、
On receiving an Authentication Status IOTP Message (see below), the Authenticatee should check the Status Component in the Status Block. If this indicates:
認証ステータスIOTPメッセージ（下記参照）を受信すると、被認証者は、ステータスブロックで状況コンポーネントを確認してください。これが示している場合：
o a successful authentication, then the Authenticatee should either:
oは認証が成功し、被認証者のいずれかすべきです：
- continue with the next step in the IOTP Transaction of which the Authentication Document Exchange is part (if any), or
- 認証文書Exchangeが部分（もしあれば）となっているIOTPトランザクションの次のステップに進み、又は
- 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.
- ブロックは認証、失敗のProcessStateとCompletionCodeのStatusTypeで状況コンポーネントを含むキャンセル認証に戻って送信することにより、IOTPトランザクションの残りの部分を続行するために失敗したことを示すAutEeCancelに設定（セクション7.16.4を参照してください） 。
o a failed authentication, then the failure should be reported to the Authenticatee and any further processing stopped.
認証失敗O、その後、障害が認証者に報告されるべきであり、任意のさらなる処理が停止しました。
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.
オーセンティケータは、消費者からのブロックをキャンセル含むIOTPメッセージを受信した場合には、被認証者が取引プロトコル・オプションのブロックに含まれる認証のための組織コンポーネントで取引Role要素で指定CancelNetLocnに行くことがあります。
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
別にトランザクションの参照ブロックから、このメッセージがで構成され（セクション3.3を参照）。
o a Trading Protocol Options Block (see section 8.1)
取引プロトコル・オプションブロック（セクション8.1を参照してください）O
o an Authentication Request Block (see section 8.4), and
認証要求ブロックO（セクション8.4を参照）、および
o an optional Signature Block (see section 8.16).
オプションの署名ブロックO（セクション8.16を参照）。
Each of these are described below.
これらのそれぞれは、以下に記載されています。
TRADING PROTOCOL OPTIONS BLOCK
TRADINGプロトコルオプションのBLOCK
The Trading Protocol Options Block (see section 8.1) must contain the following Trading Components:
取引プロトコル・オプションブロック（セクション8.1を参照）、次の取引のコンポーネントが含まれている必要があります。
o one Protocol Options Component (see Section 7.1) which defines the options which apply to the whole Authentication Document Exchange.
全体の認証文書Exchangeに適用されるオプションを定義し、O 1プロトコル・オプションコンポーネント（7.1節を参照してください）。
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ある組織成分（セクション7.6を参照）。組織コンポーネント上の取引の役割は、オーセンティケータは、例えば、展覧会に加盟店や消費者を取っている役割を示すべきです。
AUTHENTICATION REQUEST BLOCK
認証要求BLOCK
The Authentication Request Block (see section 8.4) must contain the following Trading Components:
認証要求ブロックは、次の取引のコンポーネントが含まれている必要があります（セクション8.4を参照してください）：
o one Authentication Request Component (see section 7.2), and
つの認証要求コンポーネントO（7.2節を参照）、および
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:
認証要求がデジタル署名されている場合、署名ブロックが含まれていなければなりません。これは、次のXML要素のダイジェストが含まれています。
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
IOTPメッセージとIOTPトランザクションを記述する情報が含まれているIOTPメッセージのトランザクション参照ブロック（セクション3.3を参照）O
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
Oグローバル一意IOTPトランザクションを識別するトランザクションIDコンポーネント（セクション3.3.1を参照）
o the following components of the TPO Block :
TPOブロックの次のコンポーネントO：
- the Protocol Options Component
- プロトコル・オプションコンポーネント
- the Organisation Component
- 組織コンポーネント
o the following components of the Authentication Request Block:
認証要求ブロックの次のコンポーネント（O）
- the Authentication Request Component
- 認証要求コンポーネント
- the Trading Role Information Request Component
- 取引のロール情報要求コンポーネント
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
別にトランザクションの参照ブロックから、このメッセージがで構成され（セクション3.3を参照）。
o an Authentication Response Block (see section 8.5), and
認証応答ブロックO（セクション8.5を参照）、および
o an optional Signature Block (see section 8.16).
オプションの署名ブロックO（セクション8.16を参照）。
Each of these are described below.
これらのそれぞれは、以下に記載されています。
AUTHENTICATION RESPONSE BLOCK
認証応答BLOCK
The Authentication Response Block must contain the following Trading Component:
認証応答ブロックは、次の取引のコンポーネントが含まれている必要があります。
o one Authentication Response Component (see section 7.3)
O 1の認証応答コンポーネント（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.
認証要求ブロックに含まれる取引ロール情報要求コンポーネントのTradingRoleList属性で特定され、すべての取引の役割のための1つの組織コンポーネントO。
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:
認証要求ブロックに含まれる認証要求コンポーネント内のアルゴリズム要素（セクション12 IANAの考慮事項を参照）は、認証応答は、署名ブロックは認証を含む同じIOTPメッセージに含まれていなければならないデジタル署名で構成すべきであることを示す場合応答ブロック。署名コンポーネントは、次のXML要素のダイジェスト要素が含まれています。
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
IOTPメッセージとIOTPトランザクションを記述する情報が含まれているIOTPメッセージのトランザクション参照ブロック（セクション3.3を参照）O
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
Oグローバル一意IOTPトランザクションを識別するトランザクションIDコンポーネント（セクション3.3.1を参照）
o the following components of the Authentication Request Block:
認証要求ブロックの次のコンポーネント（O）
- the Authentication Request Component
- 認証要求コンポーネント
- the Trading Role Information Request Component
- 取引のロール情報要求コンポーネント
o the Organisation Components contained in the Authentication Response Block
O組織コンポーネントは、認証応答ブロックに含まれます
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.
注意：すべての取引の役割は、データの署名をサポートできることを前提とすべきではありません。特に消費者は、データの署名をサポートすることを想定すべきではありません。
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
別にトランザクションの参照ブロックから、このメッセージがで構成され（セクション3.3を参照）。
o an Authentication Status Block (see section 8.5), and
認証ステータスブロックO（セクション8.5を参照）、および
o an optional Signature Block (see section 8.16).
オプションの署名ブロックO（セクション8.16を参照）。
Each of these are described below.
これらのそれぞれは、以下に記載されています。
AUTHENTICATION STATUS BLOCK
認証状態BLOCK
The Authentication Status Block (see section 8.6) must contain the following Trading Components:
認証ステータスブロック（セクション8.6を参照）、次の取引のコンポーネントが含まれている必要があります。
o one Status Component (see section 7.16) with a ProcessState attribute set to CompletedOk.
O 1つのステータスコンポーネント（セクション7.16を参照）CompletedOkに設定ProcessState属性を持ちます。
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:
認証ステータスブロックがデジタル署名されている場合は、署名ブロックは、次のXML要素のためのダイジェスト要素と署名コンポーネントが含まれている含まれている必要があります。
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
IOTPメッセージとIOTPトランザクションを記述する情報が含まれているIOTPメッセージのトランザクション参照ブロック（セクション3.3を参照）O
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
Oグローバル一意IOTPトランザクションを識別するトランザクションIDコンポーネント（セクション3.3.1を参照）
o the following components of the Authentication Status Block:
認証ステータスブロックの次のコンポーネントO：
- the Status Component (see section 7.16).
- 状況コンポーネント（セクション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:
注：認証ドキュメントエクスチェンジをオファードキュメント交換（セクション9.1.2を参照）、次に認証ステータスブロックおよび署名ブロック（認証ステータス）のいずれかと組み合わせることができるが続く場合：
o a TPO IOTP Message (see section 9.1.2.3), or
TPO IOTPメッセージO（セクション9.1.2.3を参照）、又は
o a TPO and Offer Response IOTP Message (see section 9.1.2.6)
TPO Oおよび応答IOTPメッセージを提供します（セクション9.1.2.6を参照してください）
The Offer Document Exchange occurs in two basic forms:
オファー文書交換は、2つの基本的な形で発生します。
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ブランド依存オファー交換。オファー、例えば、注文の詳細、量、配達詳細、等の含有量は、消費者によって選択された支払ブランドとプロトコルに依存している場合、及び
o Brand Independent Offer Exchange. Where the content of the offer is not dependent on the payment brand and protocol selected.
Oブランドの独立したオファー交換。オファーの内容は、選択したペイメントブランドとプロトコルに依存しない場合。
Each of these types of Offer Document Exchange may be preceded by an Authentication Document Exchange (see section 9.1.1).
オファードキュメントエクスチェンジこれらのタイプのそれぞれは、認証文書交換（セクション9.1.1を参照）が先行してもよいです。
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.:
o the Brand List Component is sent to the Consumer in a TPO Block,
Oブランドリストコンポーネントは、TPOブロックで消費者に送られます
o the Consumer selects a Payment Brand, Payment Protocol and optionally a Currency and amount from the Brand List Component
O消費者はブランドリストコンポーネントからの支払いブランド、支払いプロトコルおよび必要に応じて通貨と金額を選択し、
o the Consumer sends the selected brand, protocol and currency/amount back to the Merchant in a TPO Selection Block, and
Oの消費者は、ブランド、プロトコルおよびバックTPO選択ブロック内の商人に通貨量/選択を送信し、
o the Merchant uses the information received to define the content of and then send the Offer Response Block to the Consumer.
O商人はの内容を定義し、消費者にオファー応答ブロックを送信するために、受信した情報を使用しています。
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,
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費者|マーチャントSTEP | | 1.消費者は、取引を決定し、オファーを作成するために商人を可能マーチャント情報（例えば、HTMLを使用して）に送信します
C --> M Offer information - outside scope of IOTP
C - > Mオファー情報 - 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.加盟店は、TPOブロック内部のブランドリストコンポーネントで、その後、ブランドプロトコル、通貨や金額が適用される支払場所を決定し、消費者に送信します
C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block
C < - M TPO。 IotpMsg：トランス参考ブロック。 TPOブロック
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対応アプリケーションが起動しました。消費者が使用する支払いブランド、支払いプロトコルおよび通貨/金額を選択します。ブランドセレクションコンポーネントのレコードの選択およびマーチャントに送り返します。
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.商人はオプションで、それに署名し、消費者に送信するなど、応答ブロックは、価格を含むIOTPトランザクションに関する詳細を含むオファーを作成するには、選択した支払いブランド、支払いプロトコル、通貨/量と提供情報を使用しています
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.消費者は、その後、TPOブロック、TPOの選択ブロックとの取引については、次のIOTPメッセージを作成するためのオファー応答ブロックから部品を組み合わせて、存在する場合に必要な取引の役割に署名ブロックと一緒に送信し、オファーがOKでチェック
CONTINUED ...
CONTINUED ...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 19 Brand Dependent Offer Document Exchange
図19ブランド依存オファーの文書交換
Note, a Consumer identifies a Brand Dependent Offer Document Exchange, by the absence of an Offer Response Block in the first IOTP Message.
消費者は、最初のIOTPメッセージでオファー応答ブロックの不在により、ブランド依存オファー文書交換を識別し、注意してください。
MESSAGE PROCESSING GUIDELINES
メッセージ処理ガイドライン
On receiving a TPO IOTP Message (see below), the Consumer may either:
TPO IOTPメッセージ（下記参照）を受信すると、消費者はどちらかの可能性があります。
o generate and send a TPO Selection IOTP Message back to the Merchant, or
O生成し、商人に戻っTPO選択IOTPメッセージを送ったり、
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.
ConsCancelledまたは未指定：OオファーのStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む商人に戻ってブロックをキャンセル送信することにより、IOTPトランザクションを続行するには失敗したことを示すのいずれかに設定（セクション7.16.4を参照してください）。
On receiving a TPO Selection IOTP Message (see below) the Merchant may either:
TPO選択IOTPメッセージを受信すると商人は、どちらかは、（下記参照）：
o generate and send an Offer Response IOTP Message back to the Consumer, or
O生成し、消費者に戻っオファーレスポンスIOTPメッセージを送ったり、
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.
MerchCancelledまたは未指定：OオファーのStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む消費者に戻ってブロックをキャンセル送信することにより、IOTPトランザクションを続行するには失敗したことを示すのいずれかに設定（セクション7.16.4を参照してください）。
On receiving an Offer Response IOTP Message (see below) the Consumer may either:
オファーレスポンスIOTPメッセージを受信する消費者がどちらかは、（下記参照）：
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メッセージを送信し、必要な取引の役割に送信します。これはIOTPトランザクションに依存している、または
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.
ConsCancelledまたは未指定：OオファーのStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む商人に戻ってブロックをキャンセル送信することにより、IOTPトランザクションを続行するには失敗したことを示すのいずれかに設定（セクション7.16.4を参照してください）。
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メッセージを受信した場合、その後、消費者は商人のための組織コンポーネントで取引Role要素で指定CancelNetLocnに行く可能性があります。
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.
消費者がキャンセルブロックを含むIOTPメッセージを受信した場合、その後、IOTPメッセージに含まれる情報は、消費者に報告しなければならないが、それ以上のアクションは取られません。
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.
ブランド独立オファードキュメント交換でTPOブロックとオファー応答ブロックは、消費者に商人によって一緒に送られ、すなわちTPOブロック、およびオファー応答ブロックの両方が含まれている1つのIOTPメッセージがあります。
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,
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費者|マーチャントSTEP | | 1.消費者は、取引を決定し、オファーを作成するために商人を可能マーチャント情報（例えば、HTMLを使用して）に送信します
C --> M Offer information - outside scope of IOTP
C - > Mオファー情報 - 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.商人はTPOブロック内部のブランドリストコンポーネントには、その後の場所、ブランドのプロトコル、通貨や金額が適用されるの支払いを決定するなど、価格を含むIOTPトランザクションに関する詳細を含むオファーレスポンスを作成し、必要に応じてそれに署名し、消費者に送信します
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対応アプリケーションが起動しました。消費者が使用する支払いブランド、支払いプロトコルおよび通貨/金額を選択します。ブランドセレクションコンポーネントのレコードの選択、チェックが提供するには、OKであるTPOブロックからの情報でブランドの選択コンポーネントを組み合わせて、トランザクションのために次のIOTPメッセージを作成するために、応答ブロックを提供し、存在する場合、必要に署名ブロックと一緒に送信します取引役割。
CONTINUED ...
CONTINUED ...
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 20 Brand Independent Offer Exchange
図20ブランドの独立したオファーの交換
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.
唯一のペイメントブランド、プロトコルおよび通貨/量は、商人によって消費者に提供されているときにブランドの独立オファードキュメントExchangeが常に発生することに注意してください。また、する可能性があるが、必ずしも、複数のブランドが提供されている際に、お支払いハンドラが同じで、かつすべてのブランドは、プロトコルの同じセットを使用して発生しません。
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.
TPOブロックことに注意してくださいとオファー応答ブロックが変化していない場合でもオファー応答ブロックは、（ブランド依存オファー文書交換を参照）別のIOTPメッセージで送信することができます。しかし、これは、トランザクション内のメッセージ数を増加させ、したがって、トランザクション応答時間を増加させる可能性が高いです。
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対応のアプリケーションは、オファードキュメントExchangeがブランドに依存しているか否かを判断するために最初のIOTPメッセージでオファー応答ブロックが存在するかどうかを確認しなければなりません。
MESSAGE PROCESSING GUIDELINES
メッセージ処理ガイドライン
On receiving a TPO and Offer Response IOTP Message (see below), the Consumer may either:
TPOを受信し、応答IOTPメッセージ（下記参照）を提供する上で、消費者のいずれでもよいです。
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メッセージを送信し、必要な取引の役割に送信します。これはIOTPトランザクションに依存している、または
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.
ConsCancelledまたは未指定：OオファーのStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む商人に戻ってブロックをキャンセル送信することにより、IOTPトランザクションを続行するには失敗したことを示すのいずれかに設定（セクション7.16.1を参照してください）。
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メッセージを受信した場合、その後、消費者は商人のための組織コンポーネントで取引Role要素で指定CancelNetLocnに行く可能性があります。
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メッセージが唯一のブランド依存オファードキュメント取引所で使用されます。別にトランザクション参照ブロック（セクション3.3を参照）から、このメッセージは、以下に記載されているだけトレーディング・プロトコル・オプションブロック（セクション8.1を参照）で構成されています。
TPO (TRADING PROTOCOL OPTIONS) BLOCK
TPO（TRADINGプロトコルオプション）BLOCK
The Trading Protocol Options Block (see section 8.1) must contain the following Trading Components:
取引プロトコル・オプションブロック（セクション8.1を参照）、次の取引のコンポーネントが含まれている必要があります。
o one Protocol Options Component which defines the options which apply to the whole IOTP Transaction. See Section 7.1.
全体IOTPトランザクションに適用されるオプションを定義する1プロトコル・オプションコンポーネントO。 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
各支払いに使用するために選択され得る1つまたは複数のペイメントブランドとプロトコルが含まれているIOTPトランザクション内の各お支払いのためのO 1つのブランドリストコンポーネント（セクション7.7を参照してください）
o Organisation Components (see section 7.6) with the following roles:
以下の役割を持つO機関コンポーネント（セクション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（複数可）。支払ハンドラ組織コンポーネントの「ID」は支払コンポーネントのPhOrgRef属性内に含まれています
If the IOTP Transaction includes a Delivery then the TPO Block must also contain:
IOTPトランザクションは配達が含まれている場合、TPOブロックも含まれている必要があります：
o Organisation Components with the following roles:
以下の役割を持つ組織コンポーネント○：
- DeliveryHandler who will be delivering the goods or services
- 商品やサービスを提供しますDeliveryHandler
- DelivTo i.e. the person or Organisation which is to take delivery
- 配達を取ることであるDelivToすなわち個人または組織
AUTHENTICATION STATUS AND SIGNATURE BLOCKS
認証ステータスと署名BLOCKS
If the Offer Document Exchange was preceded by an Authentication Document Exchange, then the TPO IOTP Message may also contain:
オファードキュメントExchangeは、認証文書の交換によって先行された場合には、TPO IOTPメッセージも含まれる場合があります。
o an Authentication Status Block (see section 8.6), and
認証ステータスブロックO（セクション8.6を参照）、および
o an optional Signature Block (Authentication Status) Signature Block
Oオプションの署名ブロック（認証ステータス）署名ブロック
See section 9.1.1.4 Authentication Status IOTP Message for more details.
詳細については、セクション9.1.1.4認証ステータス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選択IOTPメッセージは、唯一のブランド依存オファードキュメント取引所で使用されます。別にトランザクション参照ブロック（セクション3.3を参照）から、このメッセージは、以下に記載されているだけTPO選択ブロック（セクション8.1を参照）で構成されています。
TPO SELECTION BLOCK
TPO選択ブロック
The TPO Selection Block (see section 8.2) contains:
TPOセレクションブロック（セクション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後の支払取引所での使用のための1つのブランドの選択コンポーネント（セクション7.8を参照してください）。これは、ブランドのリストコンポーネントで提供されたリストからお支払いブランド、支払いプロトコルおよび通貨/金額を選択する消費者の結果が含まれています。
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:
オファーレスポンスIOTPメッセージが唯一のブランド依存オファードキュメント取引所で使用されます。別にトランザクションの参照ブロックから、このメッセージがで構成され（セクション3.3を参照）。
o an Offer Response Block (see section 8.1) and
オファー応答ブロックO（セクション8.1を参照）
o an optional Signature Block (see section 8.16).
オプションの署名ブロックO（セクション8.16を参照）。
OFFER RESPONSE BLOCK
オファーレスポンスBLOCK
The Offer Response Block (see section 8.3) contains the following components:
オファー応答ブロックは、（セクション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 1件の状況コンポーネント（セクション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
購入された商品やサービスの詳細や場所を取っている金融取引が含まれている1次成分（セクション7.5を参照してください）O
o one or more Payment Component(s) (see section 7.9) for each payment which is to be made
一つ以上の支払コンポーネント（S）Oなされるべき各支払（セクション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
IOTPトランザクションが送達を含む場合、O 0または1つの配信コンポーネント（セクション7.13を参照）を行うことが配達の詳細を含みます
o zero or more Trading Role Data Components (see section 7.17) if required by the Merchant.
ゼロまたはそれ以上の取引の役割データコンポーネントO（セクション7.17を参照）販売者が必要な場合。
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:
認証ステータスブロックは、デジタル署名されている場合、署名ブロックは、次のXML要素のダイジェスト要素を有する署名要素（セクション7.19を参照）が含まれている含まれていなければなりません。
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:
オファーレスポンスは、デジタル署名されている場合、署名ブロックは、次のXML要素のダイジェスト要素を有する署名要素（セクション7.19を参照）が含まれている含まれていなければなりません。
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
IOTPメッセージとIOTPトランザクションを記述する情報が含まれているIOTPメッセージのトランザクション参照ブロック（セクション3.3を参照）O
o the Transaction Id Component (see section 3.3.1) which globally uniquely identifies the IOTP Transaction
Oグローバル一意IOTPトランザクションを識別するトランザクションIDコンポーネント（セクション3.3.1を参照）
o the following components of the TPO Block :
TPOブロックの次のコンポーネントO：
- the Protocol Options Component, and
- プロトコル・オプションコンポーネント、および
- the Brand List Component
- ブランドリストコンポーネント
- all the Organisation Components present
- すべての組織コンポーネントが存在
o the following components of the Offer Response Block:
オファー応答ブロックの次のコンポーネントO：
- the Order Component
- 次成分
- all the Payment Components present
- 現在、すべてのお支払いのコンポーネント
- the Delivery Component if present
- 配達コンポーネント存在する場合
- any Trading Role Data Components present
- 任意の取引の役割データコンポーネントの存在
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とレスポンスIOTPメッセージをオファーは唯一のブランド独立オファードキュメント取引所で使用されます。別にトランザクションの参照ブロックから、このメッセージがで構成され（セクション3.3を参照）。
o a Trading Protocol Options Block (see section 8.1)
取引プロトコル・オプションブロック（セクション8.1を参照してください）O
o an Offer Response Block (see section 8.1) and
オファー応答ブロックO（セクション8.1を参照）
o an optional Signature Block (see section 8.16).
オプションの署名ブロックO（セクション8.16を参照）。
TPO (TRADING PROTOCOL OPTIONS) BLOCK
TPO（TRADINGプロトコルオプション）BLOCK
This is the same as the Trading Protocol Options Block described in TPO IOTP Message (see section 9.1.2.3).
これは、TPO IOTPメッセージ（セクション9.1.2.3を参照）で説明した取引プロトコル・オプションブロックと同じです。
OFFER RESPONSE BLOCK
オファーレスポンスBLOCK
This the same as the Offer Response Block in the Offer Response IOTP Message (see section 9.1.2.5).
このオファーレスポンスIOTPメッセージ（セクション9.1.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).
オファードキュメントExchangeは、認証文書の交換によって先行された場合は、TPOおよびオファーレスポンスIOTPメッセージも認証ステータスのブロックを（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:
このことは、加えて（セクション9.1.2.5を参照）を提供応答IOTPメッセージに署名ブロックと同じです。
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
オファードキュメントExchangeがブランド依存している場合は、O、署名ブロックに署名コンポーネントは、さらにTPO選択ブロックに含まれているブランドの選択コンポーネントのダイジェスト要素が含まれています
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、署名ブロックに署名コンポーネントは、さらに、認証ステータスブロックのダイジェスト元素を含みます。
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:
ブランドは、消費者が選択した後に支払文書交換は（セクション2.2.2を参照してください）支払取引所の最後の部分の直接の実装です。支払取引所の構成は次のとおりです。
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
消費者が支払いトランザクション内の前のIOTPメッセージからの情報を使用して、その後、支払いハンドラに送信する支払要求IOTPメッセージを生成することによって、開始することを要求O
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を最終的に支払いが完了するまで支払いプロトコルメッセージをカプセル化する支払取引IOTPメッセージを交換し、
o the Payment Handler sending a Payment Response IOTP Message to the Consumer containing a receipt for the payment.
○お支払ハンドラは、支払いの領収書を含む消費者への支払い応答IOTPメッセージを送信します。
The IOTP Messages which are involved are illustrated by the diagram below.
関与しているIOTPメッセージは、以下の図によって示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費者|お支払い|ハンドラSTEP | | 1.消費者は、必要に応じて支払いプロトコルメッセージをカプセル化する有料要求ブロックを生成し、存在する場合署名ブロックで支払いハンドラに送信します
C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
Block (optional); Pay Request Block
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.お支払いハンドラプロセスは要求ブロックを払って、オプションの署名をチェックし、消費者との交流ペイブロックにカプセル化支払プロトコルメッセージを、交換を開始
C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
Block
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.消費者と支払いハンドラは、最終的に支払いプロトコルメッセージは、その支払ハンドラが支払う応答ブロック内の有料領収書のコンポーネントを作成し、署名ブロック内のオプション署名コンポーネントは、消費者に送信して停止し終えるまで、支払取引所のブロックを交換し続けます。
C <-- P PAYMENT RESPONSE. IotpMsg: Trans Ref Block; Signature
Block (optional); Pay Response Block
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.消費者小切手の支払い応答はOKです。必要に応じて記録保持のためにIOTPトランザクションに関する情報を保持し、いずれかが存在する場合、必要な取引の役割に、停止したり、トランザクションのための次のIOTPメッセージを作成し、署名ブロックと一緒に送信します
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 21 Payment Document Exchange
図21支払文書交換
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:
支払い要求IOTPメッセージを受信すると、支払ハンドラは、それらが（セクション6デジタル署名を参照してください）お支払いを実行するために許可されていることを確認する必要があります。そして、彼らはどちらかの可能性があります。
o generate and send a Payment Exchange IOTP Message back to the Consumer, if more payment protocol messages need to be exchanged, or
O生成し、より多くの支払いプロトコルメッセージを交換する必要がある場合は、消費者に戻って支払取引IOTPメッセージを送ったり、
o generate and send a Payment Response IOTP Message if the exchange of payment protocol messages is complete, or
O生成し、支払いプロトコルメッセージの交換が完了している場合は決済応答IOTPメッセージを送ったり、
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.
BrandNotSupp、CurrNotSupp、PaymtCancelled：Oバック支払いのStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む消費者へのブロックをキャンセル送信することにより、支払いを継続するために失敗したことを示すのいずれかに設定（セクション7.16.4を参照してください） 、AuthError、InsuffFunds、InstBrandInvalid、InstNotValid、BadInstrumentまたは未指定。
On receiving a Payment Exchange IOTP Message, the Consumer may either:
支払取引IOTPメッセージを受信すると、消費者はどちらかの可能性があります。
o generate and send a Payment Exchange Message back to the Payment Handler or
O生成し、支払いハンドラに戻って支払い交換メッセージを送信したり、
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.
ConsCancelledまたは未指定：Oバック支払いのStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む支払ハンドラのブロックをキャンセル送信することにより、支払いを継続するために失敗したことを示すのいずれかに設定（セクション7.16.2を参照してください）。
On receiving a Payment Exchange IOTP Message, the Payment Handler may either:
支払取引IOTPメッセージを受信すると、支払ハンドラは、どちらかの可能性があります。
o generate and send a Payment Exchange IOTP Message back to the Consumer, if more payment protocol messages need to be exchanged, or
O生成し、より多くの支払いプロトコルメッセージを交換する必要がある場合は、消費者に戻って支払取引IOTPメッセージを送ったり、
o generate and send a Payment Response IOTP Message if the exchange of payment protocol messages is complete, or
O生成し、支払いプロトコルメッセージの交換が完了している場合は決済応答IOTPメッセージを送ったり、
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.
PaymtCancelledまたは未指定：○お支払のStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む消費者に戻ってブロックをキャンセル送信することにより、支払いを継続するために失敗したことを示すのいずれかに設定（セクション7.16.2を参照してください）。
On receiving a Payment Response IOTP Message, the Consumer may either:
お支払いレスポンスIOTPメッセージを受信すると、消費者はどちらかの可能性があります。
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メッセージを送信し、必要な取引の役割に送信します。これは、IOTPトランザクションに依存しています
o stop, since the IOTP Transaction has ended, or
O IOTPトランザクションが終了しているため、停止、または
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.
ConsCancelledまたは未指定：○お支払のStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む商人に戻ってブロックをキャンセル送信することにより、IOTPトランザクションを続行するには失敗したことを示すのいずれかに設定（セクション7.16.1を参照してください）。
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.
消費者がキャンセルブロックを含むIOTPメッセージを受信した場合、その後、IOTPメッセージに含まれる情報は、消費者に報告しなければならないが、それ以上のアクションは取られません。
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.
支払ハンドラは、ブロックをキャンセル含むIOTPメッセージを受信した場合、その後、消費者はそれ以上のアクションが起こり得る、そこから支払ハンドラのための組織コンポーネントで取引Role要素で指定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メッセージを受信した場合、その後、消費者が支払いを完了したが、何らかの理由でトランザクションを続行していないはずです。この場合、消費者はそれ以上のアクションが起こり得る、そこから商人のための組織コンポーネントで取引Role要素で指定CancelNetLocnに行く可能性があります。
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
別にトランザクションの参照ブロックから、このメッセージがで構成され（セクション3.3を参照）。
o a Payment Request Block, and
○お支払要求ブロック、および
o an optional Signature Block
オプションの署名ブロックO
PAYMENT REQUEST BLOCK
支払要求BLOCK
The Payment Request Block (see section 8.7) contains:
支払要求ブロックが含まれています（セクション8.7を参照してください）：
o the following components copied from the Offer Response Block from the preceding Offer Document Exchange:
直前のオファードキュメント取引所からのオファー応答ブロックからコピーされた次のコンポーネントO：
- the Status Component
- 状況コンポーネント
- the Payment Component for the payment which is being carried out
- 実行されている支払の支払コンポーネント
o the following components from the TPO Block:
TPOブロックから次のコンポーネント○：
- the Organisation Components with the roles of Merchant and for the PaymentHandler that is being sent the Payment Request Block
- 商人の役割を持つと支払いの要求ブロックを送信されているPaymentHandlerための機構部品
- the Brand List Component for the payment, i.e. the Brand List referred to by the BrandListRef attribute on the Payment Component
- 支払のためのブランドのリストコンポーネント、すなわちブランドの一覧には、お支払いのコンポーネントにBrandListRef属性によって参照されます
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 1つのブランドブランド一覧の選択コンポーネント、BrandListRefはブランド一覧へのポイントの属性、すなわちブランドの選択コンポーネント。このコンポーネントは、いずれかになります。
- 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
- 支払いがブランド依存オファー文書交換により先行された場合（セクション9.1.2.1を参照）TPO選択ブロックからコピー、または
- 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)
- 支払いがブランドの独立オファードキュメント取引所が先行していた場合、支払いブランド、支払いプロトコルとブランドの一覧から選択した通貨/量を含む、消費者により作成された（セクション9.1.2.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オプションの決済スキームのコンポーネントは、（セクション7.10を参照）を使用し、支払方法によって要求された場合（これが必要かどうかを決定するためにお支払い方法の補足を参照してください）。
o zero or more Trading Role Data Components (see section 7.17).
O、ゼロまたはそれ以上の取引の役割データコンポーネント（セクション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、2番目の支払いはStartAfter属性が含まれているオファー応答ブロック内の一つです（セクション7.9を参照）最初の支払いのための支払コンポーネントを識別する
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
○お支払ハンドラは、ブランドの選択コンポーネントで識別されるための金銭のために（セクション7.8を参照してください）。また、セクション6.3.1チェック要求ブロックは、支払ハンドラが識別されている方法についての説明は正しい組織を送っ見ます
o the Brand List Component to include is the one identified by the BrandListRef attribute of the Payment Component for the identified payment
インクルードするブランドリストコンポーネントoを特定し、支払いのための支払コンポーネントのBrandListRef属性によって識別される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を応答ブロックは、第二の支払いのためにブランドリストコンポーネントを識別し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
いずれかの先行オファードキュメント交換オファーレスポンス署名が含まれている場合（セクション9.1.2.5オファーレスポンスIOTPメッセージを参照）、又は先行支払取引は決済応答標示を含ま
(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.
その後、彼らは両方の支払い要求IOTPメッセージでの署名ブロックにコピーする必要があります（セクション9.1.3.4支払い応答IOTPメッセージを参照してください）。
Apart from a Transaction Reference Block (see section 3.3), this message consists of just a Payment Exchange Block.
別にトランザクションリファレンスブロック（セクション3.3を参照）から、このメッセージは、単に支払い取引所のブロックで構成されています。
PAYMENT EXCHANGE BLOCK
PAYMENTの交換BLOCK
The Payment Exchange Block (see section 8.8) contains:
支払取引ブロックは（セクション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 1つの支払の支払方法の特定のデータが含まれているスキームのコンポーネント（セクション7.10を参照してください）。これが含まれている必要がありますかを決定するために使用されている支払方法についてお支払い方法の補足を参照してください。
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
別にトランザクションの参照ブロックから、このメッセージがで構成され（セクション3.3を参照）。
o a Payment Response Block, and
○お支払応答ブロック、および
o an optional Signature Block
オプションの署名ブロックO
PAYMENT RESPONSE BLOCK
PAYMENT応答ブロック
The Payment Response Block (see section 8.9) contains:
支払応答ブロックが含まれています（セクション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 1回の支払領収書のコンポーネントは、支払いが発生し検証するために使用することができるスキーム固有のデータが含まれています（セクション7.11を参照してください）
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 1支払いスキームのコンポーネントは、支払方法の特定のデータが含まれている（セクション7.10を参照してください）。これが含まれている必要がありますかを決定するために使用されている支払方法についてお支払い方法の補足を参照してください。
o an optional Payment Note Component (see section 7.12)
オプションの支払い注コンポーネントO（セクション7.12を参照）
o zero or more Trading Role Data Components (see section 7.17).
O、ゼロまたはそれ以上の取引の役割データコンポーネント（セクション7.17を参照してください）。
SIGNATURE BLOCK (PAYMENT RESPONSE)
署名ブロック（PAYMENT応答）
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に設定されている支払コンポーネントのSignedPayReceipt属性によって示され、その後、署名ブロックは、次のダイジェストの要素が含まれている署名コンポーネントが含まれている必要があります。
o the Transaction Reference Block (see section 3.3) for the IOTP Message which contains the first usage of the Payment Response Block,
お支払い応答ブロックの最初の使用が含まれているIOTPメッセージのトランザクション・リファレンスブロック（セクション3.3を参照）、O
o the Transaction Id Component (see section 3.3.1) within the Transaction Reference Block that globally uniquely identifies the IOTP Transaction,
グローバルに一意IOTPトランザクションを識別するトランザクション参照ブロック内のトランザクションIDコンポーネント（セクション3.3.1を参照）、O
o the Payment Receipt Component from the Payment Response Block,
○お支払応答ブロックからの支払領収書のコンポーネント、
o the Payment Note Component from the Payment Response Block,
○お支払応答ブロックからの支払い（注）コンポーネント、
o the other Components referenced by the PayReceiptNameRefs attribute (if present) of the Payment Receipt Component,
支払受領コンポーネントのPayReceiptNameRefs属性によって参照される他の成分（存在する場合）、O、
o the Status Component from the Payment Response Block,
○お支払応答ブロックから状況コンポーネント、
o any Trading Role Data Components in the Payment Response Block, and
お支払い応答ブロック内のすべての取引の役割データコンポーネントO、および
o all the Signature Components contained in the Payment Request Block if present.
存在する場合支払要求ブロックに含まれるすべての署名コンポーネントO。
The Delivery Document Exchange is a direct implementation of a Delivery Trading Exchange (see section 2.2.3). It consists of:
出荷文書交換は配達取引所（セクション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
消費者は、トランザクション内の前のIOTPメッセージからの情報を利用して配信要求IOTPメッセージを生成して配信を要求してから配達ハンドラに送信するO
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配達ハンドラは、オプションの署名とともに要求に対するハンドラの応答の詳細を含む消費者に配信レスポンスIOTPメッセージを送信します。
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
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費者|配達|ハンドラSTEP | | 1.消費者は、配信要求ブロックを生成し、署名ブロック存在する場合に配信ハンドラに送信します
C --> D DELIVERY REQUEST. IotpMsg: Trans Ref Block; Signature
Block; Delivery Request Block
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.配達ハンドラは、配信要求とオプションの署名でのステータスと注文コンポーネントをチェック配達応答ブロックを作成し、消費者に送信すると停止します。
C <-- D DELIVERY RESPONSE. IotpMsg: Trans Ref Block; Signature
Block; Delivery Response Block
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.消費者のチェック配達応答ブロックとオプションの署名ブロックはOKです。必要に応じて記録保持のためにIOTPトランザクションに関する情報を保持して停止します。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 22 Delivery Document Exchange
図22配信文書交換
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:
配信要求IOTPメッセージを受信すると、配信ハンドラは、彼らが（セクション6人のデジタル署名を参照してください）配信を行うために許可されていることを確認する必要があります。そして、彼らはどちらかの可能性があります。
o generate and send a Delivery Response IOTP Message to the Consumer, or
O生成し、消費者に配信レスポンスIOTPメッセージを送ったり、
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.
DelivCanceled、または未指定：O配達のStatusType、失敗のProcessStateとCompletionCodeで状況コンポーネントを含む消費者に戻ってブロックをキャンセル送信することにより、配信を続行するには失敗したことを示すのいずれかに設定（セクション7.16.4を参照してください）。
On receiving a Delivery Response IOTP Message, the Consumer should just stop since the IOTP Transaction is complete.
IOTPトランザクションが完了したので、配達応答IOTPメッセージを受信すると、消費者は、単に停止する必要があります。
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.
消費者がキャンセルブロックを含むIOTPメッセージを受信した場合、その後、IOTPメッセージに含まれる情報は、消費者に報告しなければならないが、それ以上のアクションは取られません。
The Delivery Request IOTP Message consists of:
配信要求IOTPメッセージで構成されています。
o a Delivery Request Block, and
O配信要求ブロック、および
o an optional Signature Block
オプションの署名ブロックO
DELIVERY REQUEST BLOCK
配送依頼BLOCK
The Delivery Request Block (see section 8.10) contains:
配信要求ブロックが含まれています（セクション8.10を参照してください）：
o the following components copied from the Offer Response Block:
オファー応答ブロックからコピーされた次のコンポーネントO：
- 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
マーチャント、DeliveryHandlerとDeliverTo： - の役割を持つ組織成分（セクション7.6を参照）
- the Delivery Component (see section 7.13)
- 配信コンポーネント（セクション7.13を参照してください）
o the following Component from the Payment Response Block:
お支払い応答ブロックから次のコンポーネント○：
- the Status Component (see section 7.16).
- 状況コンポーネント（セクション7.16を参照してください）。
o zero or more Trading Role Data Components (see section 7.17).
O、ゼロまたはそれ以上の取引の役割データコンポーネント（セクション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.
直前のオファー文書交換は、オファーレスポンス署名または支払い文書交換を含めた場合は支払レスポンス署名が含まれ、それらは、両方の署名ブロックにコピーする必要があります。
The Delivery Response IOTP Message contains a Delivery Response Block and an optional Signature Block.
配達応答IOTPメッセージは配信応答ブロックとオプションの署名ブロックが含まれています。
DELIVERY RESPONSE BLOCK
DELIVERY応答ブロック
The Delivery Response Block contains:
配達応答ブロックが含まれています。
o one Delivery Note Component (see section 7.15) which contains delivery instructions about the delivery of goods or services
商品やサービスの配送について配送指示が含まれているO 1つの納品書コンポーネント（セクション7.15を参照してください）
in3 SIGNATURE BLOCK (DELIVERY RESPONSE)
立方インチ署名ブロック（DELIVERY応答）
The Signature Block should contain one Signature Component that contains Digest elements that refer to
署名ブロックはを参照してダイジェスト要素が含まれている1つの署名コンポーネントが含まれている必要があります
o the Transaction Id Component (see section 3.3.1) of the IOTP message that contains the Delivery Response Signature
配信レスポンス署名が含まれているIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照してください）O
o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Delivery Response Signature
配信レスポンス署名が含まれているIOTPメッセージのトランザクション・リファレンスブロック（セクション3.3を参照してください）O
o the Consumer Delivery Data component contained in the Delivery Request Block (if any)
配信要求ブロックに含まれる消費者配信データコンポーネント（もしあれば）O
o the Signature Components contained in the Delivery Request Block (if any)
配信要求ブロックに含まれる署名コンポーネント（存在する場合）O
o the Status Component
状況コンポーネントO
o the Delivery Note Component
納品書コンポーネントO
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:
お支払いと配達ドキュメント取引所は、支払取引所（セクション2.2.2を参照）、配達取引所（セクション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
消費者が支払いトランザクション内の前のIOTPメッセージからの情報を使用して、その後、支払いハンドラに送信する支払要求IOTPメッセージを生成することによって、開始することを要求O
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を最終的に支払いが完了するまで支払いプロトコルメッセージをカプセル化する支払取引IOTPメッセージを交換し、
o the Payment Handler sending to the Consumer in one IOTP Message:
○お支払ハンドラは1つのIOTPメッセージに消費者への送信します：
- a Payment Response Block containing a receipt for the payment, and
- 支払いの領収書を含む、および支払応答ブロック
- a Delivery Response Block containing details of the goods or services to be delivered
- 配信される商品やサービスの詳細を含む配達応答ブロック
The IOTP Messages which are involved are illustrated by the diagram below.
関与しているIOTPメッセージは、以下の図によって示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *消費者|お支払い|ハンドラSTEP | | 1.消費者は、必要に応じて支払いプロトコルメッセージをカプセル化する有料要求ブロックを生成し、存在する場合署名ブロックで支払いハンドラに送信します
C --> P PAYMENT REQUEST. IotpMsg: Trans Ref Block; Signature
Block; Pay Request Block
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.お支払いハンドラプロセスは要求ブロックを払って、オプションの署名をチェックし、消費者との交流ペイブロックにカプセル化支払プロトコルメッセージを、交換を開始
C <-> P PAYMENT EXCHANGE. IotpMsg: Trans Ref Block; Pay Exchange
Block
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.消費者と支払いハンドラ最終的に支払いプロトコルメッセージが終了するまでお支払いハンドラは、その後、オファーレスポンスボックからの情報を使用して、有料応答ブロック内の有料領収書のコンポーネント、および署名ブロック内のオプション署名コンポーネントを作成しますので、お支払いの交換ブロックを交換し続けます配達応答ブロックを作成し、消費者と停止の両方を送信します。
C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref
Block; Signature Block; Pay Response Block; Delivery
Response Block
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.消費者のチェックをお支払いレスポンスと配信レスポンスブロックはOKです。必要に応じて記録保持のためにIOTPトランザクションに関する情報を保持し、いずれかが存在する場合、必要な取引の役割に、停止したり、トランザクションのための次のIOTPメッセージを作成し、署名ブロックと一緒に送信します
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 23 Payment and Delivery Document Exchange
図23支払いと配達ドキュメント交換
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.
配達応答ブロックと支払い応答ブロックは、彼女が配達応答ブロックを送信できるように支払いハンドラは、入手可能な情報を持っている場合にのみ、同じIOTPメッセージに結合することができます。これはと思われるが、商人、支払いハンドラと配信ハンドラの役割を組み合わせた場合、必ずしも、発生しません。
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.
配達応答ブロックと支払いの応答ブロックが同じIOTPメッセージに結合されている場合はFalseに設定されている場合、オファー応答ブロック内に含まれる配信コンポーネントのDelivAndPayResp属性は（セクション7.13を参照してください）（セクション8.3を参照）をTrueに設定されています配達応答ブロックと支払い応答ブロックは、別のIOTPメッセージで送信されます。
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).
支払い要求IOTPメッセージまたは支払交換IOTPメッセージを受信すると、支払ハンドラは支払いドキュメント取引所（セクション9.1.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).
支払取引IOTPメッセージを受信すると、消費者はまた、支払い文書交換（セクション9.1.3.1を参照）と同じアクションを実行する必要があります。
On receiving a Payment Response and Delivery Response IOTP Message then the IOTP Transaction is complete and should take no further action.
支払レスポンスと配信レスポンスIOTPメッセージを受信すると、その後IOTPトランザクションが完了し、それ以上の行動を取るべきではありません。
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.
消費者がキャンセルブロックを含むIOTPメッセージを受信した場合、その後、IOTPメッセージに含まれる情報は、消費者に報告しなければならないが、それ以上のアクションは取られません。
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.
支払ハンドラは、ブロックをキャンセル含むIOTPメッセージを受信した場合、その後、消費者はそれ以上のアクションが起こり得る、そこから支払ハンドラのための組織コンポーネントで取引Role要素で指定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メッセージを受信した場合、その後、消費者が支払いを完了したが、何らかの理由でトランザクションを続行していないはずです。この場合、消費者はそれ以上のアクションが起こり得る、そこから商人のための組織コンポーネントで取引Role要素で指定CancelNetLocnに行く可能性があります。
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.3.2を参照）での支払い要求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).
このメッセージの内容は、お支払いお支払いドキュメント取引所における取引IOTPメッセージ（セクション9.1.3.3を参照）と同じです。
The content of this message consists of:
このメッセージの内容は、から構成されています。
o a Payment Response Block,
○お支払応答ブロック、
o an optional Signature Block (Payment Response), and
Oオプションの署名ブロック（支払い応答）、および
o a Delivery Response Block.
O配達応答ブロック。
PAYMENT RESPONSE BLOCK
PAYMENT応答ブロック
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.3.4を参照）に関連した支払い応答IOTPメッセージでのお支払い応答ブロックと同じです。
SIGNATURE BLOCK (PAYMENT RESPONSE)
署名ブロック（PAYMENT応答）
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.3.4を参照）に関連付けられた支払応答IOTPメッセージに署名ブロック（支払い応答）と同じです。
DELIVERY RESPONSE BLOCK
DELIVERY応答ブロック
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).
このブロックのコンテンツ配信ドキュメントエクスチェンジに関連した配信応答IOTPメッセージに配信応答ブロックと同じである（セクション9.1.4.3を参照）。
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:
ベースラインの認証IOTPトランザクションはIOTP取引に関わる取引の役割のいずれかの間の任意の時点で発生する可能性があります。これは、それが発生する可能性を意味します。
o before another IOTP Transaction
別のIOTPトランザクションの前にO
o at the same time as another IOTP Transaction
別のIOTPトランザクションと同時にO
o independently of any other IOTP Transaction.
O独立して、他のIOTPトランザクションの。
The Baseline Authentication IOTP Transaction consists of just an Authentication Document Exchange (see section 9.1.1) as illustrated by the diagram below.
ベースライン認証IOTPトランザクションは、以下の図で示すように単に認証ドキュメント交換（セクション9.1.1を参照）からなります。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
START -------------------------------------------------------
v
----------------
| AUTHENTICATION |
----------------
|
|
|
|
------------------- ----------------- |
| BRAND INDEPENDENT | | BRAND DEPENDENT | |
| OFFER | | OFFER | |
------------------- ----------------- |
|
|
|
|
|
--------- -------------- |
| PAYMENT | | PAYMENT WITH | |
| (first) | | DELIVERY | |
--------- -------------- |
|
|
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {second)| |
---------- --------- |
v
STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 24 Baseline Authentication IOTP Transaction
図24ベースラインの認証IOTPトランザクション
Example uses of the Baseline Authentication IOTP Transaction include:
ベースラインの認証IOTPトランザクションの例の用途は次のとおりです。
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ベースライン認証IOTPトランザクションは、強力な連続性が存在するセッションの初期の一環として行われるとき。例えば、金融機関でした：
- 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
- その後、ベースラインの認証IOTPトランザクションを使用して顧客を認証し、
- 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消費者とDelivTo取引の役割についての情報を含む組織コンポーネントとの商人の役割を提供する手段として、
o so that a Consumer may authenticate a Payment Handler before starting a payment.
消費者が支払いを開始する前にお支払いハンドラを認証できるように、O。
The Baseline Deposit IOTP Transaction supports the deposit of electronic cash with a Financial Institution.
ベースライン預金IOTPトランザクションは、金融機関での電子マネーの入金をサポートしています。
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.
注意：金融機関は、IOTP用語で、サービス（電子現金のすなわち預金）はいくつかの種類の例の銀行手数料のために、料金と引き換えに提供されているという点で、商人の役割を担っています。用語「金融機関は、」図にし、明確にするためのテキストで使用されています。
The Baseline Deposit IOTP Transaction consists of the following Document Exchanges:
ベースラインのデポジットIOTPトランザクションは、次のドキュメント交換で構成されています。
o an optional Authentication Document Exchange (see section 9.1.1)
オプションの認証ドキュメント交換O（セクション9.1.1を参照）
o an Offer Document Exchange (see section 9.1.2), and
オファー文書交換O（セクション9.1.2を参照）、および
o a Payment Document Exchange (see section 9.1.3).
○お支払文書交換は（セクション9.1.3を参照してください）。
The way in which these Document Exchanges may be combined together is illustrated by the diagram below.
これらの文書交換を一緒に組み合わせることができるれる方法は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- |
| | |
| -------------- | -------------
v v v v
------------------- -----------------
| BRAND INDEPENDENT | | BRAND DEPENDENT |
| OFFER | | OFFER |
------------------- -----------------
| |
| |
| |
| -------------------
v v
--------- --------------
| PAYMENT | | PAYMENT WITH |
| (first) | | DELIVERY |
--------- --------------
|
----------------
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {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
IOTPトランザクションの特定のインスタンスに適用された文書交換のどの組み合わせを決定するためのセクション9.1.12「文書交換の有効な組合せ」を参照してください。
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 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.
OAの商人（金融機関）は、電子現金を堆積された消費者の役割は通常、彼らが堆積したい現金の種類を知っているので、それは普通に実際に制約されている、が、電子現金、いくつかの異なるタイプに預金を受け入れることができるかもしれ一種類のみ。しかし、電子現金の同じ「ブランド」のために使用することができるいくつかの異なるプロトコルがあるかもしれません。この場合にはブランド依存オファーは、使用するプロトコルを交渉するために適切であり得ます。
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商人（金融機関）は、消費者だけでなく、支払いが堆積されるべきアカウントだけでなく、を識別するための認証の結果を使用することができます。単一のアカウントが識別できない場合、それは他の手段で取得しなければなりません。例えば：
- the consumer could specify the account number prior to the Baseline Deposit IOTP Transaction starting, or
- 消費者が開始、または以前のベースライン預金IOTPトランザクションに口座番号を指定することができます
- 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.
- 消費者は、ベースラインの認証IOTPトランザクション、および金融機関によって提供されたリストから選択されたアカウントを使用して、例えば、以前に同定されている可能性があります。
o The Baseline Deposit IOTP Transaction without an Authentication Document Exchange might be used:
O認証文書交換せずにベースライン預金IOTPトランザクションが使用されることがあります。
- 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トランザクション場合、例えば、ベースラインまたはベースライン離脱認証は、消費者を認証し、セキュリティチャネルは、消費者の真正性が知られているため、維持されています
- if authentication is achieved as part of a proprietary payment protocol and is therefore included in the 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の範囲の外側、例えば、パスフレーズ、または独自のバンキングソフトウェアソリューションを使用して、いくつかの他の手段によって達成された場合。
The Baseline Purchase IOTP Transaction supports the purchase of goods or services using any payment method. It consists of the following Document Exchanges:
ベースラインの購入IOTPトランザクションは、任意の支払い方法を使用して商品やサービスの購入をサポートしています。これは、次のドキュメント交換で構成されています。
o an optional Authentication Document Exchange (see section 9.1.1)
オプションの認証ドキュメント交換O（セクション9.1.1を参照）
o an Offer Document Exchange (see section 9.1.2)
オファー文書交換O（セクション9.1.2を参照してください）
o either:
efther：
- a Payment Document Exchange (see section 9.1.3) followed by
- 続い支払いドキュメント取引所（セクション9.1.3を参照してください）
- a Delivery Document Exchange (see section 9.1.4)
- 配達ドキュメントエクスチェンジ（セクション9.1.4を参照してください）
o a Payment Document Exchange only, or
○お支払文書交換のみ、または
o a combined Payment and Delivery Document Exchange (see section 9.1.5).
O組み合わせる支払いと配達ドキュメント取引所（セクション9.1.5を参照してください）。
The ways in which these Document Exchanges are combined is illustrated by the diagram below.
これらの文書交換を組み合わせた方法は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 26 Baseline Purchase IOTP Transaction
図26ベースラインの購入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.
IOTPトランザクションの特定のインスタンスに適用された文書交換の組み合わせを決定するセクション9.1.12「文書交換の有効な組合せ」を参照してください。
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払い戻しの要求は加盟店への消費者によって行われ、一般的に実証する証拠でサポートされています：
- 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。これは、商人が同意すれば、消費者と商人の間にいくつかの交渉に関与してもよく、
o a refund payment by the Merchant to the Consumer.
消費者への商人によって返金の支払いO。
The Baseline Refund IOTP Transaction supports a subset of the above, specifically it supports:
ベースラインの払い戻しIOTPトランザクションは、具体的にはサポートして、上記のサブセットをサポートしています。
o stand alone authentication of the Consumer using a separate Baseline Authentication IOTP Transaction (see section 9.1.6)
O別々のベースラインの認証IOTPトランザクションを使用して消費者の一人で認証をスタンド（セクション9.1.6を参照してください）
o a refund payment by the Merchant to the Consumer using the following two Trading Exchanges:
次の二つの貿易取引所を利用して消費者に商人によって還付支払O：
- an optional Authentication Document Exchange (see section 9.1.1)
- オプションの認証ドキュメント交換（セクション9.1.1を参照）
- an Offer Document Exchange (see section 9.1.2), and
- オファードキュメントエクスチェンジ（セクション9.1.2を参照）、および
- a Payment Document Exchange (see section 9.1.3).
- お支払いドキュメントエクスチェンジ（セクション9.1.3を参照してください）。
The ways in which these Document Exchanges are combined is illustrated by the diagram below.
これらの文書交換を組み合わせた方法は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- |
| | |
| -------------- | -------------
v v v v
------------------- -----------------
| BRAND INDEPENDENT | | BRAND DEPENDENT |
| OFFER | | OFFER |
------------------- -----------------
| |
| |
| |
| -------------------
v v
--------- --------------
| PAYMENT | | PAYMENT WITH |
| (first) | | DELIVERY |
--------- --------------
|
----------------
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {second)| |
---------- --------- |
|
-----------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 27 Baseline Refund IOTP Transaction
図27ベースラインの払い戻しIOTPトランザクション
A Baseline Refund IOTP Transaction without an Authentication Document Exchange might be used:
認証文書の交換をせずベースライン払い戻しIOTPトランザクションが使用されることがあります。
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、例えば、消費者は自分とコードが適用される払い戻しを識別するために、いくつかの以前に供給されたコードを入力しました。コードは、Webページや電子メールなどによって、供給することができます。
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トランザクション、例えばベースライン認証は、消費者を認証し、セキュリティチャネルは、消費者の真正性が知られており、したがって、以前に合意された払い戻しを同定することができるため、維持されています。
o when the authentication of the consumer is carried out by the Payment Handler using a payment scheme authentication algorithm.
O消費者の認証は、支払スキームの認証アルゴリズムを使用して支払ハンドラによって行われたとき。
The Baseline Withdrawal IOTP Transaction supports the withdrawal of electronic cash from a Financial Institution.
ベースラインの撤退IOTPトランザクションは、金融機関から電子現金の引き出しをサポートしています。
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.
注：金融機関は、IOTP用語で、その商人の役割サービス（電子現金のすなわち撤退は）いくつかの種類の例の銀行手数料のために、料金と引き換えに提供されています。用語「金融機関は、」図にし、明確にするためのテキストで使用されています。
The Baseline Withdrawal IOTP Transaction consists of the following Document Exchanges:
ベースラインの撤退IOTPトランザクションは、次のドキュメント交換で構成されています。
o an optional Authentication Document Exchange (see section 9.1.1)
オプションの認証ドキュメント交換O（セクション9.1.1を参照）
o an Offer Document Exchange (see section 9.1.2), and
オファー文書交換O（セクション9.1.2を参照）、および
o a Payment Document Exchange (see section 9.1.3).
○お支払文書交換は（セクション9.1.3を参照してください）。
The way in which these Document Exchanges may be combined together is illustrated by the diagram below.
これらの文書交換を一緒に組み合わせることができるれる方法は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- |
| | |
| -------------- | -------------
v v v v
------------------- -----------------
| BRAND INDEPENDENT | | BRAND DEPENDENT |
| OFFER | | OFFER |
------------------- -----------------
| |
| |
| |
| -------------------
v v
--------- --------------
| PAYMENT | | PAYMENT WITH |
| (first) | | DELIVERY |
--------- --------------
|
----------------
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {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商人（金融機関）は、電子現金、いくつかの異なるタイプの撤退を提供することができるかもしれません。実際には通常、電子マネーの一形態のみが提供されることがあります。しかし、電子現金の同じ「ブランド」のために使用することができるいくつかの異なるプロトコルがあるかもしれません。
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離脱が行われるべきであるから、消費者だけでなく、アカウントないだけを識別するための認証の結果を使用してもよいです。単一のアカウントが識別できない場合、それは他の手段で取得しなければなりません。例えば：
- the consumer could specify the account number prior to the Baseline Withdrawal IOTP Transaction starting, or
- 消費者が開始、または以前のベースラインの撤退IOTPトランザクションに口座番号を指定することができます
- 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.
- 消費者は、ベースラインの認証IOTPトランザクション、および金融機関によって提供されたリストから選択されたアカウントを使用して、例えば、以前に同定されている可能性があります。
o a Baseline Withdrawal without an authentication might be used:
O認証なしでベースラインの撤退が使用されることがあります。
- 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トランザクション場合、例えば、ベースラインまたはベースラインデポジット認証は、消費者を認証し、セキュリティチャネルは、消費者の真正性が知られているため、維持されています
- if authentication is achieved as part of a proprietary payment protocol and is therefore included in the 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.
- 消費者の認証は例えば、パスフレーズ、または独自のバンキング・ソフトウェア・ソリューションを使用することによって、いくつかの他の手段によって達成された場合。
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:
ベースライン値為替取引は、1つの通貨の価値の交換をサポートするために、支払文書交換を使用して、同じまたは別のお支払い方法を使用して、同じまたは別の通貨での値で1つの支払い方法を使用して得られました。その使用の例としては、
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電子現金前貸し。例えば、最初の支払いは、第二の支払いはビザ現金ドルで電子マネーのダウンロードされた状態で、クレジットカードを使用して「ドルSET支払い」である可能性があります。
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外国為替。例えば、支払いは英国ポンドでのモンデックス値のアップロードやユーロでのモンデックス値の第二のダウンロードかもしれません
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でゲルトカルテのダウンロードを続けることができます。
The Baseline Value Exchange uses the following Document Exchanges:
ベースライン値取引所は、次の文書交換を使用しています。
o an optional Authentication Document Exchange (see section 9.1.1)
オプションの認証ドキュメント交換O（セクション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
値と通貨が交換されるかの詳細を提供オファードキュメント取引所（セクション9.1.2を参照）、O、および
o two Payment Document Exchanges (see section 9.1.3) which carry out the two payments involved.
関与する2回の支払いを行っO 2つの支払文書交換（セクション9.1.3を参照してください）。
The way in which these Document Exchanges may be combined together is illustrated by the diagram below.
これらの文書交換を一緒に組み合わせることができるれる方法は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 29 Baseline Value Exchange IOTP Transaction
図29のベースライン値取引所IOTPトランザクション
The Baseline Value Exchange IOTP Transaction occurs in two basic forms:
ベースライン値交換IOTPトランザクションは、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.
注意：役割上記の値取引を行う組織は、銀行や他の金融機関であっても商人です。銀行は、彼らは消費者が受け入れるか拒否するかのオファーを作っているという点で、商人として機能しているためです。
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.
オファー応答ブロックの内容が値Exchangeで使用されるペイメントブランドと支払プロトコルを選択した結果として変更されない場合はTPOブロックと応答ブロックを提供は、同じIOTPメッセージに結合することができます。
BASELINE VALUE EXCHANGE SIGNATURES
BASELINE VALUE EXCHANGE署名
The use of signatures to ensure the integrity of a Baseline Value Exchange is illustrated by the diagram below.
ベースライン値のExchangeの完全性を保証するために署名の使用は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 30 Baseline Value Exchange Signatures
図30のベースライン値為替署名
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.
次の図は、文書交換の組み合わせが有効であるかどうかを判断するために消費者取引の役割で使用することができ、様々な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
| ---------------------- 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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 31 Valid Combinations of Document Exchanges
文書交換の31有効な組合せ図
1) If first IOTP Message of an IOTP Transaction contains an Authentication Request then:
1）IOTPトランザクションの最初のIOTPメッセージは、認証要求が含まれている場合：
a) IOTP Transaction includes an Authentication Document Exchange (see section 9.1.1). (Note 1)
a）はIOTPトランザクションは、認証文書交換を（セクション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）の認証文書交換の最後のIOTPメッセージは、TPOブロックとオファー応答ブロックが含まれている場合：
i) IOTP Transaction includes a Brand Independent Offer Document Exchange (see section 9.1.2.2). (Note 2)
ⅰ）IOTPトランザクションは、ブランドの独立オファー文書交換を（セクション9.1.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）そうでない場合は、認証交換の最後のIOTPメッセージはTPOブロックが、NOオファー応答ブロックが含まれている場合、次のようになります。
i) IOTP Transaction includes a Brand Dependent Offer Document Exchange (see section 9.1.2.1). (Note 2)
ⅰ）IOTPトランザクションはブランド依存オファー文書交換を（セクション9.1.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）それ以外の場合は、認証文書交換の（認証ステータスIOTPメッセージはTPOブロックけどもオファー応答ブロック）も含みません
i) IOTP Transaction consists of just an Authentication Document Exchange. (Note 3)
ⅰ）IOTPトランザクションは、単に認証文書交換で構成されています。 （注3）
2) Otherwise (no Authentication Request in first IOTP Message):
最初IOTPメッセージ2）そうでない場合（No認証要求なし）。
e) IOTP Transaction does not include an Authentication Document Exchange (Note 2)
e）はIOTP認証文書交換が含まれていないトランザクション（注2）
f) If first IOTP Message contains an Offer Response Block, then:
f）は最初のIOTPメッセージは、その後、オファー応答ブロックが含まれている場合：
i) the IOTP Transaction contains a Brand Independent Offer Document Exchange (Note 2)
ⅰ）IOTPトランザクションは、ブランドの独立オファードキュメント取引所（注2）が含まれてい
g) Otherwise (no Offer Response Block in first IOTP Message):
グラム）そうでない場合（ノーオファー最初IOTPメッセージで応答ブロック）：
i) the IOTP Transaction includes a Brand Dependent Offer Document Exchange (Note 2)
ⅰ）IOTPトランザクションはブランド依存オファードキュメント取引所（注2）を含み、
3) If an Offer Response Block exists in any IOTP message then:
3）オファー応答ブロックは、任意のIOTPメッセージに存在する場合：
h) If the Offer Response Block contains a Delivery Component then:
H）オファーが応答ブロックは、その後、配信コンポーネントが含まれている場合：
i) If the DelivAndPayResp attribute of the Delivery Component is set to True, then: (1) the IOTP Transaction consists of a Payment And Delivery Document Exchange (see section 9.1.5) (Note 4)
I）配信コンポーネントのDelivAndPayResp属性がTrueに設定されている場合は、：（1）IOTPトランザクションが支払い、配送ドキュメント交換で構成されています（セクション9.1.5を参照）（注4）
ii) otherwise (the DelivAndPayResp attribute of the Delivery Component is set to False)
ⅱ）それ以外の場合は（配達コンポーネントの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)
i) otherwise (the Offer Response Block does not contain a Delivery Component)
ⅰ）それ以外の場合は（オファーが応答ブロックが配信コンポーネントが含まれていません）
i) if the Offer Response Block contains just one Payment Component, then:
ⅰ）オファー応答ブロックが一つだけ支払コンポーネントが含まれている場合は、次のようになります。
(1) the IOTP Transaction contains just one Payment Document Exchange (Note 5)
（1）IOTPトランザクションは、ちょうど1支払いドキュメントエクスチェンジ（注5）が含まれてい
ii) if the Offer Response Block contains two Payment Components, then:
ⅱ）オファー応答ブロックは、その後、2つの支払コンポーネントが含まれている場合：
(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)
iii) if the Offer Response Block contains no or more than two Payment Components, then there is an error
オファー応答ブロックがないか、または二つ以上の支払コンポーネントが含まれている場合III）、エラーはありません
4) Otherwise (no Offer Response Block) there is an error.
4）それ以外の場合は（何のオファーレスポンスブロックは）エラーが発生していません。
The following table indicates the types of IOTP Transactions which can validly have the conditions indicated above.
以下の表は、正当上記で示した条件を有することができるIOTPトランザクションのタイプを示しています。
Note IOTP Transaction Validity
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.失敗した認証のいずれかのベースラインの認証、またはベースライン購入、払い戻し、入金、出金やバリュー交換
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.
前のセクションで認証ドキュメントエクスチェンジは同一IOTPトランザクションIDを持つ単一IOTPトランザクションの一部として提供ドキュメント交換の前に示されています。
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トランザクションと平行して、任意の時点で別々の認証トランザクションを実行することも可能です。通常、これは使用されます。
o by a Consumer to authenticate a Merchant, Payment Handler or a Delivery Handler, or
マーチャント、支払いハンドラまたは配達ハンドラを認証するために消費者が、O、または
o by a Payment Handler or Delivery Handler to authenticate a Consumer.
消費者を認証する支払ハンドラまたは配達ハンドラによって、O。
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
それが行われている現在のIOTPトランザクションを中断し、別の役割の認証を行うために望んでいることを決定貿易の役割O
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スタンドアロン認証トランザクションは、その後に行われます。これは、実装の選択により、トランザクションリファレンスブロックにおけるコンポーネントに関連を使用して、元のIOTPトランザクション（セクション3.3.3を参照）に連結させることができます。
o if the Authentication transaction is successful, then the original IOTP Transaction is restarted
認証トランザクションが成功した場合、O、元IOTPトランザクションが再開されます
o if the Authentication fails then the original IOTP Transaction is cancelled.
認証が失敗した場合、O、元IOTPトランザクションがキャンセルされます。
For example, a Consumer could:
例えば、消費者でした：
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商人からのオファーレスポンスを受信するまで、その支払いハンドラに支払い要求を送信する前に、お支払いのための支払いハンドラを認証
o authenticate a Delivery Handler for a Delivery between receiving the Payment Response from a Payment Handler and before sending the Delivery Request
○お支払ハンドラからの支払い応答を受信間、および配信要求を送信する前に配信の配信ハンドラを認証
A Payment Handler could authenticate a Consumer after receiving the Payment Request and before sending the next Payment related message.
お支払いハンドラは、支払い要求を受信した後、次のお支払いに関連するメッセージを送信する前に消費者を認証することができます。
A Delivery Handler could authenticate a Consumer after receiving the Delivery Request and before sending the Delivery Response.
配達ハンドラは、配信要求を受けた後と配信応答を送信する前に消費者を認証することができます。
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.
注：一部のお支払い方法は、お支払いの交換内の認証を実行することができます。この場合、認証を行うために必要な情報は、決済スキームのコンポーネントに含まれます。
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.
この例ではIOTP対応アプリケーションは、認証要求情報が含まれている支払制度のコンポーネントは、他の決済スキームのコンポーネントと区別がつかないことになるので、認証が発生したことを認識しません。
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:
インフラ取引は、取引が成功したか、取引の役割のサーバーが正常に動作しているかどうかの問い合わせをサポートするように設計されています。トランザクションの2種類があります。
o a Transaction Status Inquiry Transaction which provides information on the status of an existing or complete IOTP transaction, and
既存または完全なIOTPトランザクションの状態に関する情報を提供し、トランザクションのステータス照会トランザクションO、および
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.
別の取引の役割でIOTP対応のアプリケーションが動作しているかどうかを確認し、署名が処理できるかどうかを確認するために、1つのIOTP対応のアプリケーションを可能にOのPINGトランザクション。
Each of these is described below
これらのそれぞれは、以下に記載されます
The Baseline IOTP Transaction Status Inquiry provides information on the status of an existing or complete IOTP transaction.
ベースラインIOTPトランザクション状態のお問い合わせは、既存または完全なIOTPトランザクションのステータスに関する情報を提供します。
The Trading Blocks used by the Baseline Transaction Status Inquiry Transaction are:
ベースラインの取引状況照会トランザクションで使用される取引のブロックは、次のとおりです。
o an Inquiry Request Trading Block (see section 8.12),
O問い合わせ要求取引ブロック（セクション8.12を参照）、
o an Inquiry Response Trading Block (see section 8.13)
お問い合わせの対応のトレーディングブロック（セクション8.13を参照してください）O
o an optional Signature Block (see section 8.16).
オプションの署名ブロックO（セクション8.16を参照）。
The Inquiry IOTP Transaction can be used for a variety of reasons. For example:
お問い合わせIOTPトランザクションは、様々な理由のために使用することができます。例えば：
o to help in resuming a suspended transaction to determine the current state of processing of one of the other roles,
oは、他のロールのいずれかの処理の現在の状態を決定するために中断されたトランザクションを再開するのを助けるために
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などが、完成しました。例えば、消費者はその支払いが行われたと主張かもしれないが、何の署名IOTPの領収書は、それを証明するために利用できませんでした。商人が支払ハンドラの問い合わせを行う場合は、マーチャントは、支払いが行われたかどうかを判断することができます。
Note: Inquiries on Baseline Ping IOTP Transactions (see section 9.2.2) are ignored.
注：ベースラインのPing IOTP取引（セクション9.2.2を参照）に関するお問い合わせは無視されます。
MAKING INQUIRIES OF ANOTHER TRADING ROLE
ANOTHER TRADINGロールのお問い合わせの
One Trading Role may make an inquiry of any other Trading Role at any point in time.
一つの取引の役割は、任意の時点で、他の取引の役割の問い合わせを行うことができます。
IOTP aware software that supports the Consumer Trading Role may not:
消費者取引の役割をサポートしている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それがオンラインではないかもしれないので、すべての問い合わせ要求に応答し、あるいは、例えば、要求がデジタル署名されていないし、以降の要求が妥当でないことを考慮してもよいです。
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の消費者は、以下のイベントが発生した後にのみ、取引の役割にトランザクションステータスの照会ブロックを送信する必要があります。
- to the Merchant, after sending a TPO Selection Block,
- 商人に、TPOの選択ブロックを送信した後、
- to the Payment Handler, after sending a Payment Request Block,
- お支払いハンドラに、支払要求ブロックを送信した後、
- to the Delivery Handler, after sending a Delivery Request Block,
- 配信ハンドラに、配信要求ブロックを送信した後、
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他の取引の役割は消費者からのメッセージを受信した後、消費者に、最終的な「応答」メッセージを送信する前に消費者へのトランザクションのステータスの照会ブロックを送信する必要があります
o there are no restrictions on non-Consumer Trading Roles sending Inquiries to other trading roles.
O他の取引の役割へのお問い合わせを送信する非消費者取引の役割に制限はありません。
TRANSACTION STATUS INQUIRY TRANSPORT SESSION
TRANSACTIONステータスの照会TRANSPORT SESSION
For a Transaction Status Inquiry on an ongoing transaction a different transport session from the ongoing transaction is used. For a Transaction Status Inquiry on a past transaction, how the IOTP module on the software at the Trading Role is started upon the receipt of Inquiry Request message is defined in each Mapping to Transport supplement for IOTP.
現在進行中のトランザクションのトランザクション状態のお問い合わせに関しては、進行中のトランザクションは異なるトランスポートセッションが使用されています。過去の取引上のトランザクション・ステータス・お問い合わせについては、取引の役割で、ソフトウェア上のIOTPモジュールは、問い合わせ要求メッセージの受信時に開始されたかIOTPのためのサプリメントを輸送するために、各マッピングに定義されています。
TRANSACTION STATUS INQUIRY ERROR HANDLING
トランザクション処理のステータス問い合わせERROR
Errors in a Transaction Status Inquiry can be categorised into one of the following three cases:
トランザクション状態問合せでのエラーは、次の3つのケースのいずれかに分類できます。
o Business errors (see section 4.2) in the original (inquired) messages
O事業エラーが元に（セクション4.2を参照）のメッセージを（照会）
o Technical errors (see section 4.1) - both IOTP and payment scheme specific ones - in the original IOTP (inquired) messages
技術的なエラー（セクション4.1を参照）O - IOTPと決済スキームの両方の特定のもの - オリジナルIOTPでは、メッセージを（照会しました）
o Technical errors in the message containing the Inquiry Request Block itself
照会要求ブロック自体を含むメッセージテクニカルエラーO
The following outlines what the software should do in each case
以下は、ソフトウェアがそれぞれの場合に何をすべきかを概説します
BUSINESS ERRORS IN THE ORIGINAL MESSAGES
オリジナルのメッセージにビジネスエラー
Return an Inquiry Response Block containing the Status Component which was last sent to the Consumer Role.
最後に消費者の役割に送信された状況コンポーネントを含む問い合わせ応答ブロックを返します。
TECHNICAL ERRORS IN THE ORIGINAL MESSAGES
オリジナルのメッセージに技術的なエラー
Return an Inquiry Response Block containing a Status Component. The Status Component should contain a ProcessState attribute set to ProcessError. In this case send back an Error Block indicating where the error was found in the original message.
状況コンポーネントを含む問い合わせ応答ブロックを返します。状況コンポーネントはProcessErrorに設定ProcessState属性が含まれている必要があります。この場合、エラーは元のメッセージで見つかったことを示すエラーブロックを送り返します。
TECHNICAL ERRORS IN THE INQUIRY REQUEST BLOCK
問い合わせ要求ブロックに技術的なエラー
Return an Error message. That is, send back an Error Block containing the Error Code (see section 7.21.2) which describes the nature of the error in the Inquiry Request message.
エラーメッセージを返します。つまり、問い合わせ要求メッセージにエラーの性質を記述している（セクション7.21.2を参照してください）エラーコードを含むエラーブロックを返送されます。
INQUIRY TRANSACTION MESSAGES
INQUIRYトランザクションメッセージ
The following Figure outlines the Baseline IOTP Transaction Status Inquiry process.
以下の図は、ベースラインIOTPトランザクションステータス問い合わせプロセスの概要を説明します。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊＋＊
1st Role | 2nd Role STEP | | 1. The first role decides to inquire on an IOTP Transaction by, for example, clicking on the inquiry button of an IOTP Aware Application. This will then generate an Inquiry Request Block and send it to the appropriate Trading Role.
第一の役割|第二ロールSTEP | | 1.最初の役割はIOTP対応アプリケーションの照会ボタンをクリックするなどして、IOTPトランザクションに問い合わせることにしました。これは、その後、問い合わせ要求ブロックを生成し、適切な取引の役割に送信します。
1 --> 2 INQUIRY REQUEST. IotpMsg: TransRef Block; Signature Block
(optional); Inquiry Request Block
2. The Trading Role checks the digital signature (if present). If the recipient wants to respond, then the Trading Role checks the transaction status of the transaction that is being inquired upon by using the IotpTransId in the Transaction ID Component of the Transaction Reference Block, then generates the appropriate Inquiry Response Block, sends the message back to the 1st Role and stops
2.取引の役割は、デジタル署名（存在する場合）をチェックします。受信者が応答したい場合は、取引の役割は、トランザクションのリファレンスブロックのトランザクションIDコンポーネントでIotpTransIdを使用して時に照会されているトランザクションのトランザクション・ステータスをチェックし、その後、適切な問い合わせ応答ブロックを生成し、バックメッセージを送信第一の役割と停止へ
1 <-- 2 INQUIRY RESPONSE. IotpMsg: TransRef Block; Inquiry
Response Block; Signature Block (Optional)
3. First role checks the Inquiry Response Block and optional signature, takes whatever action is appropriate or perhaps stops. This may include displaying status information to the end user.
まず役割は、問い合わせ応答ブロックおよび任意の署名をチェック停止おそらく適切であるか、またはどのような行動とります。これは、エンドユーザーにステータス情報を表示することを含むことができます。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 32 Baseline Transaction Status Inquiry
図32ベースラインの取引状況照会
The remainder of this sub-section on the Baseline Transaction Status Inquiry IOTP Transaction defines the contents of each Trading Block. Note that the term "original transaction" is the transaction which a trading role wants to discover some information about.
ベースライントランザクションステータス問い合わせIOTPトランザクションにこのサブセクションの残りの部分は各取引ブロックの内容を定義します。用語「元のトランザクションは、」取引の役割がに関するいくつかの情報を発見したいトランザクションであることに注意してください。
TRANSACTION REFERENCE BLOCK
TRANSACTION参照ブロック
A Trading Role making an inquiry must use a Transaction Id Component (see section 3.3.1) where both the IotpTransId and TransTimeStamp attributes are the same as in the Transaction Id Component of the original transaction that is being inquired upon. The IotpTransId attribute in this component serves as the key in querying the transaction logs maintained at the Trading Role's site. The value of the ID attribute of the Message Id Component should be different from those of any in the original transaction (see section 3.4.1).
問い合わせを行う取引の役割は、両方IotpTransIdとTransTimeStamp属性は時に照会されている元のトランザクションのトランザクションIDコンポーネントの場合と同じであるトランザクションIDコンポーネント（セクション3.3.1を参照）を使用する必要があります。このコンポーネントでIotpTransId属性は、取引の役割のサイトで維持され、トランザクション・ログを照会することでキーとして機能します。メッセージIDコンポーネントのID属性の値は、元のトランザクション内の任意のものと異なる必要があり（セクション3.4.1を参照）。
If up-to-date status information is required then the MsgId Component, and in particular the ID attribute for the MsgId Component must be different from any other IOTP Message that has been sent by the Trading Role. This is required because of the way that Idempotency is handled by IOTP (see section 4.5.2.2 Checking/Handling Duplicate Messages).
最新のステータス情報が必要な場合は、その後のMsgIdコンポーネントは、特にのMsgIdコンポーネントのID属性は、取引の役割によって送られてきた他のIOTPメッセージと異なっている必要があります。これは、理由は冪等がIOTP（セクション4.5.2.2は、重複メッセージの処理/チェックを参照）によって処理される方法に要求されます。
INQUIRY REQUEST BLOCK
問い合わせ要求BLOCK
The Inquiry Request Block (see section 8.12) contains the following components:
問い合わせ要求のブロックは、（セクション8.12を参照）、以下のコンポーネントが含まれています。
o one Inquiry Type Component (see section 7.18). This identifies whether the inquiry is on an offer, payment, or delivery.
1問い合わせ種類コンポーネントO（セクション7.18を参照）。これは、問い合わせを提示申し出、支払い、または配達にあるかどうかを識別する。
o zero or one Payment Scheme Components (see section 7.10). This is for encapsulating payment scheme specific inquiry messages for inquiries on a payment.
O、ゼロまたは1つのお支払いスキームコンポーネント（セクション7.10を参照してください）。これは、支払いに関するお問い合わせのための支払スキーム、特定の照会メッセージをカプセル化するためです。
SIGNATURE BLOCK (INQUIRY REQUEST)
署名ブロック（問い合わせ要求）
If a signature block is present on the message containing the Inquiry Request Block then it may be checked to determine if the Inquiry Request is authorised.
署名ブロックが問い合わせ要求ブロックを含むメッセージに存在する場合、問い合わせ要求が許可されるかどうかを決定するためにチェックすることができます。
If present, the Inquiry Request Signature Block (see section 8.12) contains the following components:
存在する場合、問い合わせ要求署名ブロック（セクション8.12を参照）、次のコンポーネントが含まれています。
o one Signature Component (see section 7.19)
1つのシグネチャコンポーネントO（セクション7.19を参照）
o one or more Certificate Components, if required.
一つ以上の証明書コンポーネントO、必要な場合。
Inquiry Response Blocks should only be generated if the Transaction is authorised.
トランザクションが許可されている場合はお問い合わせレスポンスブロックにのみ生成されなければなりません。
Note: Digital signatures on an Inquiry Request is only likely to occur if the recipient of the request expects the Inquiry Request to be signed. In this version of IOTP this will require some kind of pre-existing agreement. This means that:
注意：問い合わせ要求にデジタル署名が要求の受信者が署名する問い合わせ要求を期待していた場合に発生する唯一の可能性があります。 IOTPのこのバージョンでは、これは、既存の契約のいくつかの種類が必要になります。この意味は：
o Consumers are unlikely to generate requests with signatures, although it is not an error if they do
彼らがしなければ、それはエラーではありませんが、O消費者は、署名付きリクエストを生成する可能性は低いです
o the other trading roles may agree that digital signatures are required. For example a Payment Handler may require that an Inquiry Request is digitally signed by the Merchant so that they can check that the request is valid.
O他の取引の役割は、デジタル署名が必要であることを合意することができます。彼らは要求が有効であることを確認できるように、例えば支払いハンドラは、問い合わせ要求がデジタル商人によって署名されていることを必要とするかもしれません。
On the other hand if the original transaction to which the Inquiry relates was carried out over a secure channel (e.g., [SSL]) then it is probably reasonable to presume that if the sender of the Inquiry knows the Transaction Id component of the original message (including for example the timestamp) then the inquiry is likely to be genuine.
一方、元のトランザクションは、お問い合わせは、お問い合わせの送信者が元のメッセージのトランザクションIDコンポーネントを知っているならば、あることを推測することはおそらく妥当であるセキュアなチャネル（例えば、[SSL]）上で実施した関係する場合その後、問い合わせが本物である可能性が高い（タイムスタンプを例えば含みます）。
INQUIRY RESPONSE BLOCK
問合せ応答BLOCK
The Inquiry Response Block (see section 8.13) contains the following components:
問い合わせ応答ブロックは（セクション8.13を参照）、以下のコンポーネントが含まれています。
o one Status Component (see section 7.16). This component holds the status information on the inquired transaction,
1つのステータスコンポーネントO（セクション7.16を参照してください）。このコンポーネントは尋ねたトランザクションのステータス情報を保持し、
o zero or one Payment Scheme Components. These contain encapsulated payment scheme specific inquiry messages for inquiries on payment.
ゼロOまたは1つの決済スキームのコンポーネント。これらは、支払いに関するお問い合わせのためのカプセル化された決済スキーム特定の照会メッセージが含まれています。
SIGNATURE BLOCK (INQUIRY RESPONSE)
署名ブロック（照会応答）
If a signature block is present on the message containing the Inquiry Response Block then it may be checked by the receiver of the block to determine if the Inquiry Response is valid.
署名ブロックは、問い合わせ応答ブロックを含むメッセージに存在する場合、問い合わせ応答が有効であるかどうかを決定するためにブロックの受信機によってチェックすることができます。
If present, the Inquiry Response Signature Block (see section 8.13) contains the following components:
存在する場合、問い合わせ応答標示ブロック（セクション8.13を参照）、次のコンポーネントが含まれています。
o one Signature Component (see section 7.19)
1つのシグネチャコンポーネントO（セクション7.19を参照）
o one or more Certificate Components, if required.
一つ以上の証明書コンポーネントO、必要な場合。
Note: Digital signatures on an Inquiry Response is only likely to occur if the recipient of the response expects the Inquiry Request to be signed. In this version of IOTP this will require some kind of pre-existing agreement. This means that:
注意：お問い合わせの対応のデジタル署名は、応答の受信者が署名する問い合わせ要求を期待していた場合に発生する唯一の可能性があります。 IOTPのこのバージョンでは、これは、既存の契約のいくつかの種類が必要になります。この意味は：
o Consumers are unlikely to generate responses with signatures, although it is not an error if they do
彼らがしなければ、それはエラーではありませんが、O消費者は、署名付き応答を生成する可能性は低いです
o the other trading roles may agree that digital signatures are required. For example a Merchant may require that an Inquiry Response is digitally signed by the Payment Handler so that they can check that the request response is valid.
O他の取引の役割は、デジタル署名が必要であることを合意することができます。例えば、商人は、彼らが要求応答が有効であることを確認することができるように問い合わせレスポンスがデジタル支払ハンドラによって署名されていることを必要とするかもしれません。
The purpose of the Baseline IOTP Ping Transaction is to test basic connectivity between the Trading Roles that may take part in an IOTP Transaction.
ベースラインIOTP PINGトランザクションの目的は、IOTPトランザクションに参加することが取引の役割の間の基本的な接続をテストすることです。
It enables IOTP aware application software to:
それはにIOTP対応のアプリケーションソフトを可能にします：
o determine if the IOTP aware application at another Trading Role is operating, and
O別の取引の役割でIOTP対応のアプリケーションが動作しているかどうかを判断し、
o verify whether or not the two trading roles signatures can be processed.
O 2人の取引の役割署名を処理することができるかどうかを確認します。
For example it can be used by a Merchant to determine if a Payment Handler or Delivery Handler is up and running prior to starting a Purchase transaction that uses those trading roles.
例えば、支払いハンドラまたは配達ハンドラが起動して実行前に、これらの取引の役割を使用して購入取引を開始するかどうかを判断するために商人によって使用することができます。
The Trading Blocks used by the Baseline Ping IOTP Transaction are:
ベースラインのPing IOTPトランザクションによって使用される取引のブロックは、次のとおりです。
o a Ping Request Block (see section 8.14)
Ping要求のブロックO（セクション8.14を参照してください）
o a Ping Response Block (see section 8.15), and
Pingの応答ブロック（セクション8.15を参照）、O、および
o a Signature Block (see section 8.16).
署名ブロックO（セクション8.16を参照）。
PING MESSAGES
pingメッセージ
The following figure outlines the message flows in the Baseline IOTP Ping Transaction.
次の図は、メッセージがベースラインIOTP PINGトランザクションに流れる概説します。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1st Role | 2nd Role STEP | | 1. The IOTP Aware Application in the first Trading Role decides to check whether the counterparty IOTP application is up and running. It generates a Ping Request Block and optional Signature Block and sends them to the second trading role.
* + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + * + *第一の役割|第二ロールSTEP | | 1.最初の取引の役割でIOTP対応アプリケーションは、相手方のIOTPアプリケーションが稼働しているかどうかを確認することを決定しました。これは、Ping要求ブロックとオプションの署名ブロックを生成し、第二の取引の役割に送信します。
1 --> 2 PING REQUEST. IotpMsg: Trans Ref Block; Signature Block
(Optional); Ping Request Block
2. The second Trading Role which receives the Ping Request Block generates a Ping Response Block and sends it back to the sender of the original Ping Request with a signature block if required.
2. Ping要求ブロックを受信する第2の取引の役割は、Pingの応答ブロックを生成し、必要に応じて署名ブロックと元のping要求の送信者に返信します。
1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block
(Optional); Ping Response Block
3. The first Trading Role checks the Ping Response Block and takes appropriate action, if necessary
3.最初の取引の役割は、Pingの応答ブロックをチェックし、必要に応じて、適切なアクションを実行します
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊ー＊
Figure 33 Baseline Ping Messages
33ベースラインのpingメッセージを図
The verification that signatures can be handled is indicated by the sender of the Ping Request Block including:
署名を含むping要求ブロックの送信者によって示されて取り扱うことができる検証。
o Organisation Components that identify itself and the intended recipient of the Ping Request Block, and
O組織自体とping要求ブロックの意図された受信者を特定のコンポーネント、および
o a Signature Block that signs data in the Ping Request.
Ping要求内のデータに署名署名ブロックO。
In this way the receiver of the Ping Request:
このように、ping要求の受信機：
o knows who is sending the Ping Request and can therefore verify the Signature on the Request, and
oはPing要求を送信しているため、要求の署名を検証することができ、そして誰が知っています
o knows who to generate a signature for on the Ping Response.
oはPingの応答のための署名を生成するために誰が知っています。
Note that a Ping Request:
そのPing要求に注意してください。
o does not affect any on-going transaction o does NOT initiate an IOTP transaction, unlike other IOTP transaction messages such as TPO or Transaction Status Inquiry.
このようTPOや取引状況照会などの他のIOTPトランザクションメッセージとは異なり、IOTPトランザクションを開始しません〇〇は、任意の、進行中のトランザクションに影響を与えません。
All IOTP aware applications must return a Ping Response message to the sender of a Ping Request message when it is received.
それを受信したときにすべてのIOTP対応のアプリケーションは、ping要求メッセージの送信者にPingの応答メッセージを返す必要があります。
A Baseline IOTP Ping request can also contain an optional Signature Block. IOTP aware applications can, for example, use the Signature Block to check the recipient of a Ping Request can successfully process and check signatures it has received.
ベースラインIOTP Ping要求は、オプションの署名ブロックを含めることができます。 IOTP対応アプリケーションは、例えば、正常に処理して、受信した署名を確認することができますping要求の受信者を確認するために署名ブロックを使用することができます。
For each Baseline Ping IOTP Transaction, each IOTP role shall establish a different transport session from other IOTP transactions.
各ベースラインのPing IOTPトランザクションについて、各IOTPの役割は、他のIOTP取引は異なるトランスポートセッションを確立しなければなりません。
Any IOTP Trading Role can send a Ping request to any other IOTP Trading Role at any time it wants. A Ping message has its own IotpTransId, which is different from other IOTP transactions.
どれIOTP取引の役割は、それが望んでいる任意の時点で、他のIOTP取引の役割にPing要求を送信することができます。 Pingメッセージは、他のIOTP取引とは異なり、独自のIotpTransIdを持っています。
The remainder of this sub-section on the Baseline Ping IOTP Transaction defines the contents of each Trading Block.
ベースラインのPing IOTPトランザクションにこのサブセクションの残りの部分は各取引ブロックの内容を定義します。
TRANSACTION REFERENCE BLOCK
TRANSACTION参照ブロック
The IotpTransId of a Ping transaction should be different from any other IOTP transaction.
PINGトランザクションのIotpTransIdは、他のIOTPトランザクションは異なるべきです。
PING REQUEST BLOCK
PING要求ブロック
If the Ping Transaction is anonymous then no Organisation Components are included in the Ping Request Block (see section 8.7).
PINGトランザクションが匿名であれば、いかなる組織コンポーネントがping要求ブロックに含まれていません（セクション8.7を参照してください）。
If the Ping Transaction is not anonymous then the Ping Request Block contains Organisation Components for:
PINGトランザクションが匿名でない場合、ping要求のブロックがために組織コンポーネントが含まれています。
o the sender of the Ping Request Block, and
OのPing要求ブロックの送信者、および
o the verifier of the Signature Component
署名コンポーネントの検証O
If Organisation Components are present, then it indicates that the sender of the Ping Request message has generated a Signature Block. The signature block must be verified by the Trading Role that receives the Ping Request Block.
組織成分が存在する場合、それはping要求メッセージの送信者が署名ブロックを生成したことを示しています。署名ブロックは、Ping要求のブロックを受け取る取引役割によって検証されなければなりません。
SIGNATURE BLOCK (PING REQUEST)
署名ブロック（pingリクエスト）
The Ping Request Signature Block (see section 8.16) contains the following components: o one Signature Component (see section 7.19)
Ping要求署名ブロック（セクション8.16を参照）以下の成分を含有する：1つのシグネチャコンポーネント（セクション7.19を参照）O
o one or more Certificate Components, if required.
一つ以上の証明書コンポーネントO、必要な場合。
PING RESPONSE BLOCK
PING応答ブロック
The Ping Response Block (see section 8.15) contains the following component:
pingの応答ブロックは（セクション8.15を参照）、以下のコンポーネントが含まれています。
o the Organisation Component of the sender of the Ping Response message
Pingの応答メッセージの送信者の組織コンポーネントO
If the Ping Transaction is not anonymous then the Ping Response additionally contains:
PINGトランザクションが匿名でない場合、ping応答がさらに含まれています。
o copies of the Organisation Components contained in the Ping Request Block.
O組織コンポーネントのコピーがping要求のブロックに含まれています。
SIGNATURE BLOCK (PING RESPONSE)
署名ブロック（ping応答）
The Ping Response Signature Block (see section 8.16) contains the following components:
Pingの応答署名ブロックは（セクション8.16を参照）、以下のコンポーネントが含まれています。
o one Signature Component (see section 7.19)
1つのシグネチャコンポーネントO（セクション7.19を参照）
o one or more Certificate Components, if required.
一つ以上の証明書コンポーネントO、必要な場合。
This section describes how to retrieve logos for display by IOTP aware software using the Logo Net Locations attribute contained in the Brand Element (see section 7.7.1) and the Organisation Component (see section 7.6).
このセクションでは、ネットの場所は、ブランド要素（セクション7.7.1を参照）と組織コンポーネント（7.6節を参照）に含まれる属性のロゴを使用してIOTP対応のソフトウェアで表示するためのロゴを取得する方法について説明します。
The full address of a logo is defined as follows: Logo_address ::=
Logo_net_location "/" Logo_size Logo_color_depth ".gif"
Where:
どこ：
o Logo_net_location is obtained from the LogoNetLocn attribute in the Brand Element (see section 7.7.1) or the Organisation Component. Note that:
O Logo_net_locationブランド要素（セクション7.7.1を参照）、または組織成分中LogoNetLocn属性から得られます。ご了承ください：
- the content of this attribute is dependent on the Transport Mechanism (such as HTTP) that is used. See the Transport Mechanism supplement,
- この属性のコンテンツが使用される（例えば、HTTPなどの）トランスポート機構に依存しています。搬送機構サプリメントを参照してください、
- implementers should check that if the rightmost character of Logo Net Location is set to right-slash "/" then another, right slash should not be included when generating the Logo Address,
- ロゴのアドレスを生成するときに実装者がロゴネット場所の右端の文字が右スラッシュに設定されている場合、「/」、別の、右のスラッシュが含まれるべきでないことを確認する必要があり、
o Logo_size identifies the size of the logo,
O Logo_sizeはロゴの大きさを特定し、
o Logo_color_depth identifies the colour depth of the logo
O Logo_color_depthロゴの色深度を識別する
o "gif" indicates that the logos are in "gif" format
O「GIF」ロゴは「GIF」形式であることを示しています
Logo_size and Logo_color_depth are specified by the implementer of the IOTP software that is retrieving the logo depending on the size and colour that they want to use.
Logo_sizeとLogo_color_depthは、彼らが使用したいサイズや色によってロゴを取得しているIOTPソフトウェアの実装によって指定されています。
There are five standard sizes for logos. The sizes in pixels and the corresponding values for Logo Size are given in the table below.
ロゴのための5つの標準的なサイズがあります。ピクセルサイズおよびロゴのサイズに対応する値を以下の表に示されています。
Size in Logo Size
Pixels Value
32 x 32 or exsmall 32 x 20
32×32または32×20 exsmall
53 x 33 small
53 X 33小
103 x 65 medium
103 X 65媒体
180 x 114 large
180 X 114大
263 x 166 exlarge
263 X 166 exlarge
There are three standard colour depths. The colour depth (including bits per pixel) and the corresponding value for Logo_Color_Depth are given in the table below.
3つの標準色の深さがあります。 （ピクセル当たりのビット数を含む）色深度とLogo_Color_Depthに対応する値を以下の表に示されています。
Color Depth Logo Color
(bits per pixel) Depth Value
4 (16 colors) 4
4（16色）4
8 (256 colors) nothing
8（256色）何も
24 (16 million colors) 24
24（1600万色）24
Note that if Logo Color Depth is omitted then a logo with the default colour depth of 256 colours will be retrieved.
ロゴカラー深度が省略されている場合、256色のデフォルトの色深度を持つロゴが検索されることに注意してください。
If Logo Net Location was set to "ftp://logos.xzpay.com", then:
ロゴネットロケーション「ftp://logos.xzpay.com」に設定されていた場合、次のようになります。
o "ftp://logos.xzpay.com/medium.gif" would retrieve a medium size 256 colour logo
O「ftp://logos.xzpay.com/medium.gif」中サイズ256色のロゴを取得します
o "http://logos.xzpay.com/small4.gif" would retrieve a small size 16 colour logo
O「http://logos.xzpay.com/small4.gif」小さなサイズ16色のロゴを取得します
Note: Organisations which make logos available for use with IOTP should always make available "small" and "medium" size logos and use the "gif" format.
注：IOTPで使用するロゴを利用できるようにする組織は、常に利用可能な「小さな」と「中」サイズのロゴを作成し、「GIF」形式を使用する必要があります。
This section contains:
このセクションには含まれています。
o a definition of Brands and an outline of Brand Selection using Brand Lists, and
ブランドの定義とブランドのリストを使用してブランドの選択の概要O、および
o some XML examples of Brand Lists
ブランドリストのいくつかのXMLの例O
One of the key features of IOTP is the ability for a merchant to offer a list of Brands from which a consumer may make a selection. This section provides an overview of what is involved and provides guidance on how selection of a brand and associated payment instrument can be carried out by a Consumer. It covers:
IOTPの重要な特徴の一つは、消費者が選択を行うことがあり、そこからブランドのリストを提供する商人のための機能です。このセクションでは、関与しているものの概要を提供し、ブランドと関連した決済手段の選択は消費者によって行うことができる方法についてのガイダンスを提供します。これは、説明します。
o definitions of Payment Instruments and Brands - what are Payment Instruments and Brands in an IOTP context. Further categorises Brands as optionally a "Dual Brand" or a "Promotional Brand",
○お支払楽器やブランドの定義は - IOTPの文脈における決済手段とブランドものです。さらに必要に応じて「デュアルブランド」または「プロモーションブランド」としてブランドを分類し、
o identification and selection of Promotional Brands - Promotional Brands offer a Consumer some additional benefit, for example loyalty points or a discount. This means that both Consumers and Merchant must be able to correctly identify that a valid Promotional Brand is being used.
Oプロモーションブランドの識別と選択 - プロモーションブランドは、例えば、ロイヤルティ・ポイントや割引のために、消費者にいくつかの追加の利点を提供します。これは、両方の消費者や商人が正しく、有効なプロモーションブランドが使用されていることを確認することができなければならないことを意味します。
Also see the following sections: o Brand List Component (section 7.7) which contains definitions of the XML elements which contain the list of Brands offered by a Merchant to a Consumer, and
また、次のセクションを参照してください：消費者への商人によって提供されるブランドのリストを含むXML要素の定義が含まれているブランドリストコンポーネント（セクション7.7）O、および
o Brand Selection Component (section 7.8) for details of how a Consumer records the Brand, currency, amount and payment protocol that was selected.
ブランドセレクションコンポーネント消費者が選択されたブランド、通貨、金額や支払プロトコルを記録する方法の詳細については、（セクション7.8）O。
A Payment Instrument is the means by which a Consumer pays for goods or services offered by a Merchant. It can be, for example:
支払手段は、消費者が加盟店が提供する商品やサービスの代金を支払うするための手段です。それは、たとえば、ことができます：
o a credit card such as MasterCard or Visa;
そのようなマスターカードやビザなどのクレジットカードO;
o a debit card such as MasterCard's Maestro;
このようMasterCardのマエストロとしてデビットカードO;
o a smart card based electronic cash payment instrument such as a Mondex Card, a GeldKarte card or a Visa Cash card
このようモンデックスカード、ゲルトカルテカードやビザキャッシュカードなどのスマートカードベースの電子現金決済手段O
o a software based electronic payment account such as a CyberCash or DigiCash account.
Oソフトウェアは、サイバーキャッシュやデジキャッシュアカウントとして電子決済口座をベース。
Most Payment Instruments have a number, typically an account number, by which the Payment Instrument can be identified.
ほとんどの決済手段は、支払手段を識別することが可能な数、一般的に口座番号を、持っています。
A Brand is the mark which identifies a particular type of Payment Instrument. A list of Brands are the payment options which are presented by the Merchant to the Consumer and from which the Consumer makes a selection. Each Brand may have a different Payment Handler. Examples of Brands include:
ブランドは、支払手段の特定のタイプを識別する目印です。ブランドのリストは、消費者に消費者が選択を行う、そこから商人によって提示される支払いオプションです。各ブランドは、異なる支払いハンドラを有することができます。ブランドの例としては、
o payment association and proprietary Brands, for example MasterCard, Visa, American Express, Diners Club, Mondex, GeldKarte, CyberCash, etc.
などの例マスターカード、ビザ、アメリカン・エキスプレス、ダイナースクラブ、モンデックス、ゲルトカルテ、サイバーキャッシュ、用○お支払協会と独自のブランド、
o promotional brands (see below). These include:
Oプロモーションブランド（下記参照）。これらは、次のとおりです。
- store brands, where the Payment Instrument is issued to a Consumer by a particular Merchant, for example Walmart, Sears, or Marks and Spencer (UK)
- 支払手段が特定の商人によって消費者に対して発行されたストアブランド、例えば、ウォルマート、シアーズ、またはマークスアンドスペンサー（UK）
- cobrands, for example American Advantage Visa, where an Organisation uses their own brand in conjunction with, typically, a payment association Brand.
- cobrands、組織は一般的に、と一緒に、独自のブランドを使用する例アメリカの優位ビザ、決済関連ブランドのため。
A Dual Brand means that a single payment instrument may be used as if it were two separate Brands. For example there could be a single Japanese "UC" MasterCard which can be used as either a UC card or a regular MasterCard. The UC card Brand and the MasterCard Brand could each have their own separate Payment Handlers. This means that:
デュアルブランドは、2つの別々のブランドであるかのように、単一の支払い手段を用いてもよいことを意味します。例えば、UCカードや定期的なMasterCardのいずれかとして使用することができ、単一の日本の「UC」のMasterCardがあるかもしれません。 UCカードブランドとMasterCardブランドは、それぞれ独自の個別の支払ハンドラを持つことができます。この意味は：
o the merchant treats, for example "UC" and "MasterCard" as two separate Brands when offering a list of Brands to the Consumer,
商人の扱いO、たとえば「UC」2つの別々のブランドとして「マスターカード」の消費者にブランドのリストを提供する、のための
o the consumer chooses a Brand, for example either "UC" or "MasterCard,
消費者は、いずれかの「UC」または「マスター例えばブランド、選択O、
o the consumer IOTP aware application determines which Payment Instrument(s) match the chosen Brand, and selects, perhaps with user assistance, the correct Payment Instrument to use.
OコンシューマIOTP対応のアプリケーションは、支払機器（単数または複数）が、おそらくユーザー支援、使用する正しい支払手段と、選択されたブランド、及び選択に一致するかを決定します。
Note: Dual Brands need no special treatment by the Merchant and therefore no explicit reference is made to Dual Brands in the DTD. This is because, as far as the Merchant is concerned, each Brand in a Dual Brand is treated as a separate Brand. It is at the Consumer, that the matching of a Brand to a Dual Brand Payment Instrument needs to be done.
注：デュアルブランドはマーチャントによって特別な処理を必要としないため、明示的な参照は、DTD内のデュアルブランドに行われません。限り商人に関しては、デュアルブランドの各ブランド別ブランドとして扱われるためです。これは、デュアルブランドの決済手段にブランドのマッチングが行われる必要があることを、消費者です。
A Promotional Brand means that, if the Consumer pays with that Brand, then the Consumer will receive some additional benefit which can be received in two ways:
プロモーションブランドは、消費者がそのブランドで支払う場合、消費者は、2つの方法で受信することができますいくつかの追加の利点を受ける、ということを意味します。
o at the time of purchase. For example if a Consumer pays with a "Walmart MasterCard" at a Walmart web site, then a 5% discount might apply, which means the consumer actually pays less,
購入時、O。消費者は、ウォルマートのウェブサイトで「ウォルマートマスター」で支払う場合たとえば、その後、5％割引は、消費者が実際にあまりを支払う意味し、適用される場合があります
o from their Payment Instrument (card) issuer when the payment appears on their statement. For example loyalty points in a frequent flyer scheme could be awarded based on the total payments made with the Payment Instrument since the last statement was issued.
彼らの支払手段（カード）発行者からのOの支払いが彼らの声明に表示されます。最後の文が発行されたので、例えばマイレージ制度における忠誠ポイントは、支払手段で作られた総支払額に基づいて授与することができます。
Note that:
ご了承ください：
o the first example (obtaining the benefit at the time of purchase), requires that:
最初の例（購入時の利益を得る）O、それを必要とします。
- the Consumer is informed of the benefits which arise if that Brand is selected
- 消費者がそのブランドを選択した場合に生じるメリットを知らされます
- if the Brand is selected, the Merchant changes the relevant IOTP Components in the Offer Response to reflect the correct amount to be paid
- ブランドを選択した場合は、商人が支払われるべき正しい金額を反映するために、オファーレスポンスに関連するIOTPコンポーネントを変更
o the second (obtaining a benefit through the Payment Instrument issuer) does not require that the Offer Response is changed
O（支払手段発行者による利益を取得）第二は、オファーレスポンスが変更されている必要はありません
o each Promotional Brand should be identified as a separate Brand in the list of Brands offered by the Merchant. For example: "Walmart", "Sears", "Marks and Spencer" and "American Advantage Visa", would each be a separate Brand.
O各プロモーションブランドはマーチャントによって提供ブランドのリスト内の別のブランドとして識別されるべきです。例：「ウォルマート」、「シアーズ」、「マークスアンドスペンサー」と「アメリカの優位ビザ」、それぞれ別々のブランドになります。
There are two problems which need to handled in identifying Promotional Brands:
プロモーションブランドを識別するのに取り扱うために必要な2つの問題があります。
o how does the Merchant or their Payment Handler positively identify the promotional brand being used at the time of purchase
Oどのようマーチャントまたはその支払ハンドラは、積極的に購入時に使用されているプロモーションブランドを識別しません
o how does the Consumer reliably identify the correct promotional brand from the Brand List presented by the Merchant
O消費者は確実に商人が提示するブランド一覧から正しいプロモーションブランドを特定しない方法
The following is a description of how this could be achieved.
以下は、これを達成することができる方法の説明です。
Note: Please note that the approach described here is a model approach that solves the problem. Other equivalent methods may be used.
注：ここで説明するアプローチは、問題を解決モデルアプローチであることに注意してください。他の同等の方法を用いることができます。
Correct identification that the Consumer is paying using a Promotional Brand is important since a Consumer might fraudulently claim to have a Promotional Brand that offers a reduced payment amount when in reality they do not.
消費者が不正現実にはそうではない時に減少した支払額を提供していますプロモーションブランドを持っていると主張するかもしれないので、消費者がプロモーションブランドを使用して支払っていることを、正しい識別が重要です。
Two approaches seem possible:
2つのアプローチが可能に思えます。
o use some feature of the Payment Instrument or the payment method to positively identify the Brand being used. For example, the SET certificate for the Brand could be used, if one is available, or
O積極的に使用されているブランドを識別するために、支払手段や支払い方法のいくつかの機能を使用します。 1が利用可能な場合たとえば、ブランドのためのSET証明書は、使用することができ、または
o use the Payment Instrument (card) number to look up information about the Payment Instrument on a Payment Instrument issuer database to determine if the Payment Instrument is a promotional brand.
O支払手段がプロモーションのブランドであるかどうかを判断するために支払手段発行者データベース上の支払手段に関する情報を検索する支払手段（カード）番号を使用します。
Note that:
ご了承ください：
o the first assumes that SET is available.
o最初SETが使用可能であることを前提としています。
o the second is only possible if the Merchant, or alternatively the Payment Handler, has access to card issuer information.
O第二は、商人、あるいは支払ハンドラは、カード発行者情報へのアクセス権を持っている場合にのみ可能です。
IOTP does not provide the Merchant with Payment Instrument information (e.g., a card or account number). This is only sent as part of the encapsulated payment protocol to a Payment Handler. This means that:
IOTPは、支払手段情報（例えば、カードや口座番号）と商人を提供していません。これが唯一の支払いハンドラにカプセル化された支払プロトコルの一部として送信されます。この意味は：
o the Merchant would have to assume that the Payment Instrument selected was a valid Promotional Brand, or
マーチャントは、選択した支払手段が有効なプロモーションブランドだったと仮定しなければならないであろうO、または
o the Payment Handler would have to check that the Payment Instrument was for the valid Promotional Brand and fail the payment if it was not.
○お支払ハンドラは、支払手段が有効なプロモーションブランドのためだったことを確認し、それがなかった場合は、支払いを失敗しなければなりません。
A Payment Handler checking that a brand is a valid Promotional Brand is most likely if the Payment Handler is also the Card Issuer.
支払ハンドラはまた、カード発行者であれば、ブランドが有効なプロモーションブランドであることを確認お支払いハンドラは、最も可能性が高いです。
Two ways by which a Consumer can correctly select a Promotional Brand are:
消費者が正しくプロモーションブランドを選択することが可能な2つの方法があります。
o the Consumer visually matching a logo for the Promotional Brand which has been provided to the Consumer by the Merchant,
Oの消費者は、視覚的に、商人によって消費者に提供されているプロモーションブランドのロゴをマッチング
o the Consumer's IOTP aware application matching a code for the Promotional Brand which the application has registered against a similar code contained in the list of Brands offered by the Merchant.
アプリケーションは、商人が提供するブランドのリストに含まれている類似したコードに対して登録されているプロモーションブランドのためのコードに一致する消費者のIOTP対応アプリケーションO。
In the latter case, the code contained in the Consumer wallet must match exactly the code in the list offered by the Merchant otherwise no match will be found. Ways in which the Consumer's IOTP Aware Application could obtain such a code include:
後者の場合、消費者の財布の中に含まれるコードは、まさにそうでない一致が見つからないであろう商人によって提供されるリスト内のコードと一致する必要があります。消費者のIOTP Awareのアプリケーションは、このようなコードを入手できる方法は、次のとおりです。
o the Consumer types the code in directly. This is error prone and not user friendly, also the consumer needs to be provided with the code. This approach is not recommended,
直接の消費者タイプのコードO。これは、フレンドリーエラーが発生しやすいといないユーザーも、消費者がコードを提供する必要があります。このアプローチは、推奨されません
o using one of the Brand Identifiers defined by IOTP and pre-loaded into the Consumers IOTP Aware application or wallet by the developer of the Wallet,
ブランド識別子IOTPによって定義され、ウォレットの開発者が消費者IOTP認識アプリケーションまたは財布に予めロードされたのいずれかを使用して、O、
o using some information contained in the software or other data associated with the Payment Instrument. This could be:
支払機器に関連したいくつかのソフトウェアに含まれる情報または他のデータを用いて、O。これは次のようになります。
- a SET certificate for Brands which use this payment method
- この支払い方法を使用するブランドのためのSET証明書
- a code provided by the payment software which handles the particular payment method, this could apply to, for example, GeldKarte, Mondex, CyberCash and DigiCash,
- 特定の支払い方法を扱う支払ソフトウェアによって提供されるコードは、これが適用可能性、例えば、ゲルトカルテ、モンデックス、サイバーキャッシュとデジキャッシュ、
o the consumer making an initial "manual" link between a Promotional Brand in the list of Brands offered by the Merchant and an individual Payment Instrument, the first time the promotional brand is used. The IOTP Aware application would then "remember" the code for the Promotional Brand for use in future purchases.
消費者は商人や個々の支払手段が提供するブランド、プロモーションブランドが使用されている最初の時間のリストにプロモーションブランドの間の最初の「マニュアル」のリンクを作り、O。 IOTP Awareのアプリケーションは、将来の購入で使用するためのプロモーションブランドのためのコードを「覚えている」でしょう。
New Brand Ids are allocated under IANA procedures (see section 12 IANA Considerations). Which also contains an initial list of Brand Identifiers.
新ブランドIdsが（セクション12 IANAの考慮事項を参照してください）IANA手続きの下に割り当てられています。どちらもブランド識別子の最初のリストが含まれています。
It is recommended that implementers of consumer IOTP aware applications (e.g., software wallets) pre-load their software with the then current set of Brand Ids and provide a method by which they can be updated. For example, by going to the software developer's web site.
消費者のIOTP対応アプリケーション（例えば、ソフトウェア財布）の実装は、ブランドIDの現在のセットで彼らのソフトウェアを事前にロードして、彼らは更新することができる方法を提供することをお勧めします。例えば、ソフトウェア開発者のウェブサイトに行くこともできます。
This example contains three examples of the XML for a Brand List Component. It covers:
この例では、ブランドのリストコンポーネントのためのXMLの3つの例を含んでいます。これは、説明します。
o a simple credit card based example
シンプルなクレジットカードベースの例O
o a credit card based brand list including promotional credit card brands, and
プロモーションクレジットカードのブランドを含むクレジットカードベースのブランドリストO、および
o a complex electronic cash based brand list
O複雑な電子現金ベースのブランド一覧
Note that:
ご了承ください：
o brand lists can be as complex or as simple as required
Oブランドのリストが必要なだけ複雑かのように単純なことができ
o all example techniques described in this appendix can be included in one brand list.
Oこの付録に記載されているすべての例の技術は、1つのブランドのリストに含めることができます。
This is a simple example involving:
これは、関与する単純な例です：
o only major credit card payment brands
唯一の主要なクレジットカード決済ブランドO
o a single price in a single currency
単一通貨での単一価格のO
o a single Payment Handler, and
単一支払ハンドラO、および
o a single payment protocol
単一の支払プロトコルO
<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase book including s&h' PayDirection='Debit' > <Brand ID ='M1.30' BrandId='MasterCard' BrandName='MasterCard Credit' BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit' ProtocolAmountRefs='M1.33'> </Brand> <Brand ID ='M.31' BrandId='Visa' BrandName='Visa Credit' BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit' ProtocolAmountRefs='M1.33'> </Brand> <Brand ID ='M1.32' BrandId='AmericanExpress' BrandName='American Express' BrandLogoNetLocn='ftp://otplogos.amex.com' ProtocolAmountRefs ='M1.33' > </Brand > <ProtocolAmount ID ='M1.33' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.34'> </ProtocolAmount> <CurrencyAmount ID ='M1.34' Amount='10.95' CurrCode='USD'/> <PayProtocol ID ='M1.35' ProtocolId='SCCD1.0' ProtocolName='Secure Channel Credit/Debit' PayReqNetLocn='http://www.example.com/etill/sccd1' > </PayProtocol> </BrandList>
<BrandList ID = 'M1.2' XML：ラング= '私たち-en' とshortDesc属性PayDirection = 'デビット' = 'S＆Hなどの購入帳'> <ブランドID = 'M1.30' BrandId = 'マスター' 新しい名称= 'マスターカードクレジット」BrandLogoNetLocn = 'FTP：//otplogos.mastercard.com/mastercardcredit' ProtocolAmountRefsの= 'M1.33'> </ブランド> <ブランドID = 'M.31' BrandId = 'ビザ' 新しい名称= 'ビザクレジット' BrandLogoNetLocn = 'FTP：//otplogos.visa.com/visacredit' ProtocolAmountRefsの= 'M1.33'> </ブランド> <ブランドID = 'M1.32' BrandId = 'アメリカン・エキスプレス' 新しい名称= 'アメリカンエクスプレス' BrandLogoNetLocn = 'FTP ：//otplogos.amex.com」ProtocolAmountRefsの= 'M1.33'> </ブランド> <ProtocolAmount ID = 'M1.33' PayProtocolRef = 'M1.35' CurrencyAmountRefsの= 'M1.34'> </ ProtocolAmount> < CurrencyAmount ID = 'M1.34' 金額= '10 0.95' CurrCode = 'USD' /> <PayProtocol ID = 'M1.35' ProtocolId = 'SCCD1.0' ProtocolName = 'セキュリティで保護されたチャネルクレジット/デビット' PayReqNetLocn = 'のhttp： //www.example.com/etill/sccd1' > </ PayProtocol> </ BrandList>
An example of a Credit Card based Brand List follows. It includes:
クレジットカードベースのブランドリストの例は次の通りです。これは含まれています：
o two ordinary card association brands and two promotional credit card brands. The promotional brands consist of one loyalty based (British Airways MasterCard) which offers additional loyalty points and one store based (Walmart) which offers a discount on purchases over a certain amount
O 2つの通常のカード協会のブランドと2つのプロモーションクレジットカードのブランド。プロモーションブランドは、追加のロイヤリティポイントとしています1つの忠誠ベース（ブリティッシュ・エアウェイズマスターカード）で構成され、一定量以上購入で割引を提供しています（ウォルマート）に基づく1つのストア
o two payment protocols:
O 2つの支払プロトコル：
- SET (Secure Electronic Transactions) see [SET], and
- SET（電子取引を固定）[SET]を参照、及び
- SCCD (Secure Channel Credit Debit) see [SCCD].
- SCCD（セキュアチャネルクレジットデビット）は[SCCD]を参照してください。
<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Purchase ladies coat' PayDirection='Debit' > <Brand ID ='M1.3' BrandId='MasterCard' BrandName='MasterCard Credit' BrandLogoNetLocn='ftp://otplogos.mastercard.com' ProtocolAmountRefs='M1.7 M1.8'> <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'> </ProtocolBrand> </Brand> <Brand ID ='M1.4' BrandId='Visa' BrandName='Visa Credit' BrandLogoNetLocn='ftp://otplogos.visa.com' ProtocolAmountRefs='M1.7 M1.8'> <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'> </ProtocolBrand> </Brand> <Brand ID ='M1.5' BrandId='BritishAirwaysMC' BrandName='British Airways MasterCard' BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk' BrandNarrative='Double air miles with British Airways MasterCard' ProtocolAmountRefs ='M1.7 M1.8' > <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'> </ProtocolBrand> </Brand > <Brand ID ='M1.6' BrandId='Walmart' BrandName='Walmart Store Card'
<BrandList ID = 'M1.2' XML：ラング= '私たち-en' とshortDesc属性= '購入の女性のコート' PayDirection = 'デビット'> <ブランドID = 'M1.3' BrandId = 'マスター' 新しい名称= 'MasterCardのクレジット'BrandLogoNetLocn =' FTP：//otplogos.mastercard.com」ProtocolAmountRefs = 'M1.7 M1.8'> <ProtocolBrand ProtocolId = 'SET1.0' ProtocolBrandId = 'マスター'> </ ProtocolBrand> </ブランド> <ブランドID = 'M1.4' BrandId = 'ビザ' 新しい名称= 'ビザクレジット' BrandLogoNetLocn = 'FTP：//otplogos.visa.com' ProtocolAmountRefsの= 'M1.7のM1.8'> <ProtocolBrand ProtocolId = 'SET1。 0' ProtocolBrandId = 'ビザ：'> </ ProtocolBrand> </ブランド> <ブランドID = 'M1.5' BrandId = 'BritishAirwaysMC' 新しい名称= 'ブリティッシュ・エアウェイズMasterCardの' BrandLogoNetLocn = 'FTP：//otplogos.britishairways.coブリティッシュ・エアウェイズMasterCardの 'ProtocolAmountRefsの= 'M1.7のM1.8'> <ProtocolBrand ProtocolId = 'SET1.0' ProtocolBrandId = 'マスターカードとの.ukの」BrandNarrative =' ダブルエアーマイル：BA'> </ ProtocolBrand> </ブランド> <ブランドID = 'M1.6' BrandId = 'ウォルマート' 新しい名称= 'ウォルマートストアカード'
BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandLogoNetLocn = 'FTP：//otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card on purchases over $150' ProtocolAmountRefs='M1.8'> </Brand> <ProtocolAmount ID ='M1.7' PayProtocolRef='M1.10' CurrencyAmountRefs='M1.9' > <PackagedContent Transform="BASE64"> 238djqw1298erh18dhoire </PackagedContent> </ProtocolAmount> <ProtocolAmount ID ='M1.8' PayProtocolRef='M1.11' CurrencyAmountRefs='M1.9' > <PackagedContent Transform="BASE64"> 238djqw1298erh18dhoire </PackagedContent> </ProtocolAmount> <CurrencyAmount ID ='M1.9' Amount='157.53' CurrCode='USD'/> <PayProtocol ID ='M1.10' ProtocolId='SET1.0' ProtocolName='Secure Electronic Transaction Version 1.0' PayReqNetLocn='http://www.example.com/etill/set1' > <PackagedContent Transform="BASE64"> 8ueu26e482hd82he82 </PackagedContent> </PayProtocol> <PayProtocol ID ='M1.11' ProtocolId='SCCD1.0' ProtocolName='Secure Channel Credit/Debit' PayReqNetLocn='http://www.example.com/etill/sccd1' > <PackagedContent Transform="BASE64"> 82hd82he8226e48ueu </PackagedContent> </PayProtocol> </BrandList>
BrandNarrative = 'あなたのウォルマートカードで5％オフ$ 150以上のお買い上げで' ProtocolAmountRefs = 'M1.8'> </ブランド> <ProtocolAmount ID = 'M1.7' PayProtocolRef = 'M1.10' CurrencyAmountRefsの= 'M1.9' > <PackagedContent変換= "BASE64"> 238djqw1298erh18dhoire </ PackagedContent> </ ProtocolAmount> <ProtocolAmount ID = 'M1.8' PayProtocolRef = 'M1.11' CurrencyAmountRefsの= 'M1.9'> <PackagedContent> = "BASE64" を変換238djqw1298erh18dhoire </ PackagedContent> </ ProtocolAmount> <CurrencyAmount ID = 'M1.9' 金額= '157.53' CurrCode = 'USD' /> <PayProtocol ID = 'M1.10' ProtocolId = 'SET1.0' ProtocolName = 'セキュア電子取引のバージョン1.0' PayReqNetLocn = 'のhttp：//www.example.com/etill/set1'> <PackagedContentトランスフォーム= "BASE64"> 8ueu26e482hd82he82 </ PackagedContent> </ PayProtocol> <PayProtocol ID = 'M1.11' ProtocolId = 'SCCD1.0' ProtocolName = 'セキュリティで保護されたチャネルクレジット/デビット' PayReqNetLocn = 'のhttp：//www.example.com/etill/sccd1'> <PackagedContentトランスフォーム= "BASE64"> 82hd82he8226e48ueu </ PackagedContent> </ PayProtocol> </ブランドルイスト>
In order to pay by 'British Airways' MasterCard using the example above using SET and therefore getting double air miles, the Brand Selection would be:
SETを使用したため、二重の空気マイルを取得し、上記の例を使用して「ブリティッシュ・エアウェイズのマスターカードで支払うためには、ブランドの選択は次のようになります。
<BrandSelection ID='C1.2'
<BrandSelection ID = 'C1.2'
BrandListRef='M1.3' BrandRef='M1.5' ProtocolAmountRef='M1.7' CurrencyAmountRef='M1.9' > </BrandSelection>
BrandListRef = 'M1.3' BrandRef = 'M1.5' ProtocolAmountRef = 'M1.7' CurrencyAmountRef = 'M1.9'> </ BrandSelection>
The following is an fairly complex example which includes:
以下は、かなり複雑な例です。
o payments using either Mondex, GeldKarte, CyberCash or DigiCash
モンデックス、ゲルトカルテ、サイバーキャッシュまたはデジキャッシュのいずれかを使用して支払いO
o in currencies including US dollars, British Pounds, Italian Lira, German Marks and Canadian Dollars
米ドル、英国ポンド、イタリア・リラ、ドイツの印とカナダドルなどの通貨でのO
o a discount on the price if the payment is made in Mondex using British pounds or US dollars, and
価格の割引O支払いは英国ポンドやドルを使っモンデックスに行われた場合、および
o more than one Payment Handler is used for payments involving Mondex or CyberCash
Oつ以上の支払いハンドラは、モンデックスやサイバーキャッシュを伴う支払いに使用されています
o support for more than one version of a CyberCash CyberCoin payment protocol.
Oサイバーキャッシュサイバーコインの支払いプロトコルの複数のバージョンをサポート。
<BrandList ID='M1.2' XML:Lang='us-en' ShortDesc='Company report on XYZ Co' PayDirection='Debit' > <Brand ID ='M1.13' BrandId='Mondex' BrandName='Mondex Electronic Cash' BrandLogoNetLocn='ftp://otplogos.mondex.com' ProtocolAmountRefs='M1.17 M1.18'> </Brand> <Brand ID ='M1.14' BrandId='GeldKarte' BrandName='GeldKarte Electronic Cash' BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de' ProtocolAmountRefs='M1.19'> </Brand> <Brand ID ='M1.15' BrandId='CyberCoin' BrandName='CyberCoin Eletronic Cash' BrandLogoNetLocn='http://otplogos.cybercash.com' ProtocolAmountRefs ='M1.20' > </Brand > <Brand ID ='M1.16' BrandId='DigiCash'
<BrandList ID = 'M1.2' XML：ラングPayDirection = 'デビット' = '私たち-en' とshortDesc属性= 'XYZ共同で企業報告'> <ブランドID = 'M1.13' BrandId = 'モンデックス' 新しい名称=」モンデックス電子マネー 'BrandLogoNetLocn = 'FTP：//otplogos.mondex.com' ProtocolAmountRefs = 'M1.17 M1.18'> </ブランド> <ブランドID = 'M1.14' BrandId = 'ゲルトカルテ' 新しい名称=' ゲルトカルテ電子マネー 'BrandLogoNetLocn = 'FTP：//otplogos.geldkarte.co.de' ProtocolAmountRefs = 'M1.19'> </ブランド> <ブランドID = 'M1.15' BrandId = 'サイバーコイン' 新しい名称=' サイバーコインEletronic現金'BrandLogoNetLocn =' のhttp：//otplogos.cybercash.com」ProtocolAmountRefsの= 'M1.20'> </ブランド> <ブランドID = 'M1.16' BrandId = 'デジキャッシュ'
BrandName='DigiCash Electronic Cash' BrandLogoNetLocn='http://otplogos.digicash.com' BrandNarrative='5% off with your Walmart Card on purchases over $150' ProtocolAmountRefs='M1.22'> </Brand> <ProtocolAmount ID ='M1.17' PayProtocolRef='M1.31' CurrencyAmountRefs='M1.25 M1.29'> </ProtocolAmount> <ProtocolAmount ID ='M1.18' PayProtocolRef='M1.32' CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'> </ProtocolAmount> <ProtocolAmount ID ='M1.19' PayProtocolRef='M1.35' CurrencyAmountRefs='M1.28'> </ProtocolAmount> <ProtocolAmount ID ='M1.20' PayProtocolRef='M1.34 M1.33' CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'> </ProtocolAmount> <ProtocolAmount ID ='M1.21' PayProtocolRef='M1.36' CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'> </ProtocolAmount> <CurrencyAmount ID ='M1.23' Amount='20.00' CurrCode='USD'/> <CurrencyAmount ID ='M1.24' Amount='12.00' CurrCode='GBP'/> <CurrencyAmount ID ='M1.25' Amount='19.50' CurrCode='USD'/> <CurrencyAmount ID ='M1.26' Amount='11.75' CurrCode='GBP'/> <CurrencyAmount ID ='M1.27' Amount='36.00' CurrCode='DEM'/> <CurrencyAmount ID ='M1.28' Amount='100.00' CurrCode='FFR'/> <CurrencyAmount ID ='M1.29' Amount='22.00' CurrCode='CAD'/> <CurrencyAmount ID ='M1.30'
新しい名称= 'デジキャッシュ電子マネー' BrandLogoNetLocnは= 'のhttp：//otplogos.digicash.com' ProtocolAmountRefsの= 'M1.22'> </ブランド> <ProtocolAmount ID BrandNarrative = '$ 150以上のお買い上げで、あなたのウォルマートカードで5％オフ' = 'M1.17' PayProtocolRef = 'M1.31' CurrencyAmountRefsの= 'M1.25 M1.29'> </ ProtocolAmount> <ProtocolAmount ID = 'M1.18' PayProtocolRef = 'M1.32' CurrencyAmountRefsの= 'M1.26 M1.27 M1.28 M1.30 '> </ ProtocolAmount> <ProtocolAmount ID =' M1.19' PayProtocolRef = 'M1.35' CurrencyAmountRefsの= 'M1.28'> </ ProtocolAmount> <ProtocolAmount ID = 'M1。 20' PayProtocolRef = 'M1.34 M1.33' CurrencyAmountRefsの= 'M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'> </ ProtocolAmount> <ProtocolAmount ID = 'M1.21' PayProtocolRef = 'M1.36' CurrencyAmountRefsの= 'M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'> </ ProtocolAmount> <CurrencyAmount ID = 'M1.23' 金額= '20 .00' CurrCode = 'USD '/> <CurrencyAmount ID =' M1.24' 金額= '12 .00' CurrCode = 'GBP' /> <CurrencyAmount ID = 'M1.25' 金額= '19 0.50' CurrCode = 'USD' /> <CurrencyAmount ID =」 M1.26' 金額= '11 0.75' CurrCode =」 GBP '/> <CurrencyAmount ID =' M1.27' 金額= '36 .00' CurrCode = 'DEM' /> <CurrencyAmount ID = 'M1.28' 金額= '100.00' CurrCode = 'FFR' /> <CurrencyAmount ID = 'M1.29' 金額= '22 .00' CurrCode = 'CAD' /> <CurrencyAmount ID = 'M1.30'
Amount='15000' CurrCode='ITL'/> <PayProtocol ID ='M1.31' ProtocolId='MXv1.0' ProtocolName='Mondex IOTP Protocol Version 1.0' PayReqNetLocn='http://www.mxbankus.com/etill/mx' > </PayProtocol> <PayProtocol ID ='M1.32' ProtocolId='MXv1.0' ProtocolName='Mondex IOTP Protocol Version 1.0' PayReqNetLocn='http://www.mxbankuk.com/vserver' > </PayProtocol> <PayProtocol ID ='M1.33' ProtocolId='Ccashv1.0' ProtocolName='CyberCoin Version 1.0' PayReqNetLocn='http://www.cybercash.com/ccoin' > </PayProtocol> <PayProtocol ID ='M1.34' ProtocolId='CCashv2.0' ProtocolName='CyberCoin Version 2.0' PayReqNetLocn='http://www.cybercash.com/ccoin' > </PayProtocol> <PayProtocol ID ='M1.35' ProtocolId='GKv1.0' ProtocolName='GeldKarte Version 1.0' PayReqNetLocn='http://www.example.com/pgway' > </PayProtocol> <PayProtocol ID ='M1.36' ProtocolId='DCashv1.0' ProtocolName='DigiCash Protocol Version 1.0' PayReqNetLocn='http://www.example.com/digicash' > </PayProtocol> </BrandList>
金額= '15000' CurrCode = 'ITL' /> <PayProtocol ID = 'M1.31' ProtocolId = 'MXv1.0' ProtocolName = 'モンデックスIOTPプロトコルバージョン1.0' PayReqNetLocn = 'のhttp：//www.mxbankus.com/ etill / MX」> </ PayProtocol> <PayProtocol ID = 'M1.32' ProtocolId = 'MXv1.0' ProtocolName = 'モンデックスIOTPプロトコルバージョン1.0' PayReqNetLocn = 'のhttp：//www.mxbankuk.com/vserver'> </ PayProtocol> <PayProtocol ID = 'M1.33' ProtocolId = 'Ccashv1.0' ProtocolName = 'サイバーコインバージョン1.0' PayReqNetLocn = 'のhttp：//www.cybercash.com/ccoin'> </ PayProtocol> <PayProtocol ID = 'M1.34' ProtocolId = 'CCashv2.0' ProtocolName = 'サイバーコインバージョン2.0' PayReqNetLocn = 'HTTP：//www.cybercash.com/ccoin'> </ PayProtocol> <PayProtocol ID = 'M1.35' ProtocolId = 'GKv1.0' ProtocolName = 'ゲルトカルテバージョン1.0' PayReqNetLocn = 'のhttp：//www.example.com/pgway'> </ PayProtocol> <PayProtocol ID = 'M1.36' ProtocolId = 'DCashv1.0' ProtocolName = 'デジキャッシュプロトコルバージョン1.0' PayReqNetLocn = 'のhttp：//www.example.com/digicash'> </ PayProtocol> </ BrandList>
This section describes the codes that are controlled by IANA, and also how new codes can be created for testing purposes that are not controlled by IANA.
このセクションでは、IANAによって制御されているコードを記述し、IANAによって制御されていないテスト目的のために作成することができますまた、どのように新しいコード。
To help ensure interoperability, there is a need for codes used by IOTP to be maintained in a controlled environment so that their meaning and usage are well defined and duplicate codes avoided. [IANA] is the mechanism to be used for this purpose as described in RFC 2434.
相互運用性を確保するために、その意味や用法が明確に定義され、避けコードを複製されるように制御された環境で維持されることがIOTPによって使用されるコードの必要性があります。 [IANA] RFC 2434に記載されているように、この目的のために使用される機構です。
The element types and attributes names to which this procedure applies is shown in the table below together with the initial values that are valid for these attributes.
要素の種類と、この手順が適用される名前属性は、これらの属性の有効な初期値とともに、以下の表に示されています。
Note that:
ご了承ください：
o the IETF Trade mailing list's email address is ietf-trade@elistx.com
O IETF貿易メーリングリストのメールアドレスがietf-trade@elistx.comです
o "Designated Experts" (see [IANA]) are appointed by the IESG.
O "指定専門家"（[IANA]参照）はIESGによって任命されています。
Element Type/ Attribute Values Attribute Name
要素タイプ/属性値は、属性名
Algorithm/ "sha1" - indicates that a [SHA1] authentication Name will apply (When Algorithm is a child of an "signature" - indicates that authentication AuthReq consists of the generation of a digital signature. Component) "Pay:ppp" where "ppp" may be set to any valid value for "iotpbrand" (see below)
アルゴリズム/「SHA1」は、 - （アルゴリズムが「署名」の子である場合 - 認証AUTHREQは、デジタル署名成分の発生で構成されていることを示す。）[SHA1]認証名が適用されることを示し、「有料：PPP」 " PPPはiotpbrand 『」のための任意の有効な値に設定することができる』（下記参照）
With the exception of Algorithms that begin with
"pay:", new values are allocated following review
on the IETF Trade mailing list and by the
Designated Expert.
Note: The Algorithm element is likely to be eventually defined within the [DSIG] name space. It is likely that the maintenance procedure defined here may need to vary over time, as the DSIG proposals become more widely adopted.
注意：アルゴリズムの要素は、最終的には[DSIG]名前空間内で定義される可能性があります。 DSIGの提案は、より広く採用になると、ここで定義されたメンテナンスの手順は、時間の経過とともに変化する必要があるかもしれないと思われます。
Element Type/ Attribute Values Attribute Name
要素タイプ/属性値は、属性名
Brand/BrandId The following list of initial BrandIds have been taken from those Organisations that have applied for SET certificates as at 1st June 1999:
：ブランド/初期BrandIdsの以下のリストは、1999年6月1日時点のSET証明書のために適用されているこれらの組織から取られていBrandId
"Amex" - American Express
「アメックス」 - アメリカン・エキスプレス
"Dankort" - Dankort
「クレジットカード」 - OEM
"JCB" - JCB
"JCB" - JCB
"Maestro" - Maestro
「マエストロ」 - マエストロ
"MasterCard" - MasterCard
「マスターカード」 - マスターカード
"NICOS" - NICOS
"NICOS" - NICOS
"VISA" - Visa
"SHOW" - ビュー
In addition the following Brand Id values are defined:
また、以下のブランドIDの値は定義されています。
"Mondex"
「モンデックス」
"GeldKarte"
「ゲルトカルテ」
New values of BrandId must be announced to the IETF Trade mailing list and, if there are no objections within three weeks, are allocated on a "first come first served" basis.
BrandIdの新しい値は、IETF貿易メーリングリストに発表されなければならないと、3週間以内に異議がない場合、基礎を「最初の最初の務め来る」に割り当てられています。
CurrencyAmount/ Currency codes are dependent on CurrCodeType (see CurrCode below).
CurrencyAmount /通貨コードがCurrCodeTypeに依存している（下記CurrCodeを参照してください）。
If CurrCodeType is "ISO4217-A" then the currency
code is an alphabetic currency code as defined by
[ISO4217].
If CurrCodeType is "IOTP" then new values must be announced to the IETF Trade mailing list and, if there are no objections within three weeks, are allocated on a "first come first served" basis.
CurrCodeTypeは「IOTP」であれば、新しい値は、IETF貿易メーリングリストに発表されなければならないと、3週間以内に異議がない場合、基礎を「最初の最初の務め来る」に割り当てられています。
Note: The Currency Code Type of IOTP, is designed to allow the support of "new" psuedo currencies such as loyalty or frequent flyer points. At the time of writing this specification, no currency codes of this type have been defined.
注意：IOTPの通貨コードの種類を、そのような忠誠心やマイレージポイントとして「新しい」擬似通貨のサポートを可能にするように設計されています。この仕様書を書いている時点で、このタイプのない通貨コードが定義されていません。
Element Type/ Attribute Values Attribute Name
要素タイプ/属性値は、属性名
CurrencyAmount/ "ISO4217-A" CurrCodeType "IOTP"
CurrencyAmount / "ISO4217-A" CurrCodeType "IOTP"
New values of CurrCodeType attribute are allocated
following review on the IETF Trade mailing list
and by the Designated Expert.
DeliveryData/ "Post" DelivMethod
DeliveryData / "ポスト" DelivMethod
"Web"
"ウェブ"
"Email"
"Eメール"
New values of Delivery Method attribute are allocated following review on the IETF Trade mailing list and by the Designated Expert. This may require the publication of additional documentation to describe how the delivery method is used.
配信方法属性の新しい値は、IETF貿易メーリングリスト上で、指定された専門家によるレビュー、次の割り当てられています。これは、配信方法が使用される方法を説明するために追加のドキュメントの発行を必要とするかもしれません。
PackagedContent/ "PCDATA" Content "MIME"
PackagedContentは/ "PCDATA" コンテンツ "MIME"
"MIME:mimetype" (where mimetype must be the same
as content-type as defined by [MIME] )
"XML"
"XML"
If the Content attribute is of the form "MIME"mimetype", then control of new values for "mimetype" is as defined in [MIME].
コンテンツ属性は、フォーム「MIME」MIMEタイプ」、のための新しい値の後、制御 『MIMEタイプ』である場合は、[MIME]で定義されているようです。
Otherwise, new values of the Content attribute are allocated following review on the IETF Trade mailing list and by the Designated Expert. This may require the publication of additional documentation to describe how the new attribute is used within a Packaged Content element.
それ以外の場合は、コンテンツの属性の新しい値は、IETF貿易メーリングリスト上で、指定された専門家によるレビュー、次の割り当てられています。これは、新しい属性がパッケージ化されたコンテンツ要素内で使用される方法を説明するために、追加のドキュメントの公開を要求することができます。
RelatedTo/ "IotpTransaction" RelationshipType "Reference"
RelatedTo / "IotpTransaction" RelationshipType "リファレンス"
New values of the RelationshipType attribute are
allocated following review on the IETF Trade
Working Group mailing list and by the Designated
Expert. This may require the publication of
additional documentation to describe how the
Element Type/ Attribute Values Attribute Name delivery method is used.
要素タイプ/属性値は、名前の配信方法が使用される属性。
Status/ Offer StatusType Payment
ステータス/オファーStatusType支払い
Delivery
配達
Authentication
認証
Unidentified
不明
New values of the Status Type attribute are allocated following: o publication to the IETF Trade Working Group, of an RFC describing the Trading Exchange, Trading Roles and associated components that relate to the Status, and o review of the document on the IETF Trade mailing list and by the Designated Expert.
取引所を記述するRFCのIETF展覧会ワーキンググループの出版物、役割とステータスに関連する関連するコンポーネントトレーディング、およびIETF貿易郵送上のドキュメントの入出力見直し○：ステータスタイプ属性の新しい値は、次の割り当てられていますリストと指定専門家によります。
Note: The document describing new values for the Status Type attribute may be combined with documents that describe new Trading Roles and types of signatures (see below).
注意：ステータスタイプ属性の新しい値を記述した文書では、（下記参照）の署名の新しい貿易の役割と種類を説明した文書と組み合わせることができます。
TradingRole/ "Consumer" TradingRole "Merchant"
TradingRole / "消費者" TradingRole "商人"
"PaymentHandler"
"PaymentHandler"
"DeliveryHandler"
"DeliveryHandler"
"DelivTo"
"DelivTo"
"CustCare"
"CustCare"
New values of the Trading Role attribute are allocated following: o publication to the IETF Trade Working Group, of an RFC describing the Trading Exchange, Trading Roles and associated components that relate to the Trading Role, and o review of the document on the IETF Trade mailing list and by the Designated Expert.
取引所を記述するRFCのIETF展覧会ワーキンググループの出版物、役割と取引の役割に関連する関連するコンポーネントトレーディング、およびIETFの貿易上のドキュメントの入出力見直し○：取引role属性の新しい値は、次の割り当てられていますメーリングリストと指定専門家によります。
Note: The document describing new values for the Trading Role attribute may be
注：取引role属性の新しい値を記述した文書であってもよいです
Element Type/ Attribute Values Attribute Name combined with documents that describe new Status Types (see above) and types of signatures (see below).
要素タイプ/属性値は、（下記参照）新しいステータスの種類を記述した文書（上記参照）と署名の種類と組み合わせた属性名。
TransId/ "BaselineAuthentication" IotpTransType "BaselineDeposit"
TRANSID / "BaselineAuthentication" IotpTransType "BaselineDeposit"
"BaselinePurchase"
"BaselinePurchase"
"BaselineRefund"
"BaselineRefund"
"BaselineWithdrawal"
「ベースラインの撤退」
"BaselineValueExchange"
"BaselineValueExchange"
"BaselineInquiry"
「ベースラインのお問い合わせ」
"BaselinePing"
"BaselinePing"
New values of the IotpTransType attribute are allocated following: o publication to the IETF Trade mailing list, of an RFC describing the new IOTP Transaction, and o review of the document on the IETF Trade Working Group mailing list and by the Designated Expert.
新しいIOTPトランザクションを記述するRFCのIETF貿易メーリングリストへの掲載、および文書のO審査IETF展覧会ワーキンググループのメーリングリストで、指定された専門家による○：IotpTransType属性の新しい値は、次の割り当てられています。
Attribute/ Content (see Signature "OfferResponse" Component) "PaymentResponse"
属性/コンテンツ「PaymentResponse」（署名「OfferResponse」コンポーネントを参照してください）
"DeliveryResponse"
「配信レスポンス」
"AuthenticationRequest"
"AuthenticationRequest"
"AuthenticationResponse"
"AuthenticationResponse"
"PingRequest"
"PingRequest"
"PingResponse"
"PingResponse"
New values of the code that define the type of a signature are allocated following: o publication to the IETF Trade Working Group, of an RFC describing the Trading Exchange where the signature is being used, and o review of the document on the IETF Trade mailing list and by the Designated Expert.
署名が使用されている取引所を記述するRFCのIETF展覧会ワーキンググループへのO出版、およびIETF貿易郵送上のドキュメントの入出力レビュー：署名のタイプを定義するコードの新しい値は、次のように割り当てられていますリストと指定専門家によります。
Element Type/ Attribute Values Attribute Name
要素タイプ/属性値は、属性名
Note: The document describing new values for the types of signatures may be combined with documents that describe new Status Types and Trading Roles (see above).
注意：署名の種類の新しい値を記述した文書は、（上記参照）新しいステータスの種類を記述した文書や取引の役割と組み合わせることができます。
In addition to the formal development and registration of codes as described above, there is still a need for developers to experiment using new IOTP codes. For this reason, "user defined codes" may be used to identify additional values for the codes contained within this specification without the need for them to be registered with IANA.
正式な開発とコードの登録、上述したように加えて、新しいIOTPコードを使用して実験する開発者が依然として必要とされています。この理由のために、「ユーザー定義コード」は、それらがIANAに登録するために必要とすることなく、本明細書内に含まれるコードの追加の値を識別するために使用されてもよいです。
The definition of a user defined code is as follows:
次のようにユーザー定義コードの定義は次のとおりです。
user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
NameChar NameChar has the same definition as the [XML] definition of NameChar
NameChar NameCharはNameCharの[XML]定義と同じ定義を有します
Use of domain names (see [DNS]) to make user defined codes unique is recommended although this method cannot be relied upon.
この方法では依拠することはできませんが、ユーザー定義コードを一意にするためにドメイン名の使用は（[DNS]を参照）が推奨されます。
This section contains the XML DTD for the Internet Open Trading Protocols.
このセクションでは、インターネットのオープン・トレーディングプロトコル用のXML DTDが含まれています。
<!-- ****************************************************** * * * INTERNET OPEN TRADING PROTOCOL VERSION 1.0 DTD * * Filename: ietf.org/rfc/rfc2801.dtd * * * * Changes from version 07 (iotp-v1.0-protocol-07.dtd)* * - NO CHANGES * * * * * * * * * * Copyright Internet Engineering Task Force 1998-2000* * * ******************************************************
<！ - ********************************************** ******** * * * INTERNET OPEN TRADINGプロトコルバージョン1.0 DTD * *ファイル名：ietf.org/rfc/rfc2801.dtd * * * *バージョン07からの変更点（IOTP-v1.0のプロトコル-07。 DTD）* * - NO CHANGES * * * * * * * * * *著作権インターネットエンジニアリングタスクフォース1998-2000 * * * ********************** ********************************
****************************************************** * IOTP MESSAGE DEFINITION * ****************************************************** -->
************************************************** **** * IOTP・メッセージ定義* ***************************************** ************* - >
<!ELEMENT IotpMessage ( TransRefBlk, IotpSignatures?, ErrorBlk?, ( 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' >
<！ELEMENT IotpMessage（TransRefBlk、IotpSignatures？ErrorBlk ?,（AuthReqBlk | AuthRespBlk | AuthStatusBlk | CancelBlk | DeliveryReqBlk | DeliveryRespBlk | InquiryReqBlk | InquiryRespBlk | OfferRespBlk | PayExchBlk | PayReqBlk | PayRespBlk | PingReqBlk | PingRespBlk | TpoBlk | TpoSelectionBlk）*）> < ！ATTLIST IotpMessage CDATAのxmlns 'IOTP：ietf.org/iotp-v1.0'>
<!-- ****************************************************** * TRANSACTION REFERENCE BLOCK DEFINITION * ****************************************************** -->
<！ - ********************************************** ******** * TRANSACTIONリファレンスブロック定義* ************************************ ****************** - >
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) > <!ATTLIST TransRefBlk ID ID #REQUIRED >
<！ELEMENT TransRefBlk（TRANSID、のMsgId、のRelatedTo *）> <！ATTLIST TransRefBlk ID ID #REQUIRED>
<!ELEMENT TransId EMPTY > <!ATTLIST TransId ID ID #REQUIRED Version NMTOKEN #FIXED '1.0' IotpTransId CDATA #REQUIRED IotpTransType CDATA #REQUIRED TransTimeStamp CDATA #REQUIRED >
<！ELEMENT TRANSID EMPTY> <！ATTLIST TRANSID ID ID #REQUIREDバージョンNMTOKEN #FIXED '1.0' IotpTransId CDATA #REQUIRED IotpTransType CDATA #REQUIRED TransTimeStamp CDATA #REQUIRED>
<!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タイムスタンプCDATA #IMPLIED>
<!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関係CDATA #REQUIRED RelnKeyWords NMTOKENS #IMPLIED>
<!-- ****************************************************** * Packaged Content Common Element * ****************************************************** -->
<！ - ********************************************** ******** *パッケージ化されたコンテンツ共通の要素* ************************************ ****************** - >
<!ELEMENT PackagedContent (#PCDATA) > <!ATTLIST PackagedContent Name CDATA #IMPLIED Content NMTOKEN "PCDATA" Transform (NONE|BASE64) "NONE" >
<！ELEMENT PackagedContent（#PCDATA）> <！ATTLIST PackagedContent名CDATA #IMPLIEDコンテンツNMTOKEN "PCDATA" 変換（NONE | BASE64） "NONE">
<!-- ****************************************************** * TRADING COMPONENTS * ****************************************************** --> <!-- PROTOCOL 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 >
<！ - ********************************************** ******** * TRADINGコンポーネント* ************************************** ！！！**************** - > < - プロトコルオプションの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>
<!-- AUTHENTICATION DATA COMPONENT --> <!ELEMENT AuthReq (Algorithm, PackagedContent*)> <!ATTLIST AuthReq ID ID #REQUIRED AuthenticationId CDATA #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ - 認証データCOMPONENT - > <！ELEMENT AUTHREQ（アルゴリズム、PackagedContent *）> <！ATTLIST AUTHREQ ID ID #REQUIRED AuthenticationId CDATA #REQUIRED ContentSoftwareId CDATA #IMPLIED>
<!-- AUTHENTICATION RESPONSE COMPONENT --> <!ELEMENT AuthResp (PackagedContent*) > <!ATTLIST AuthResp ID ID #REQUIRED AuthenticationId CDATA #REQUIRED SelectedAlgorithmRef NMTOKEN #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ - 認証応答COMPONENT - > <！ELEMENT AuthResp（PackagedContent *）> <！ATTLIST AuthResp ID ID #REQUIRED AuthenticationId CDATA #REQUIRED SelectedAlgorithmRef NMTOKEN #REQUIRED ContentSoftwareId CDATA #IMPLIED>
<!-- TRADING ROLE INFO REQUEST COMPONENT --> <!ELEMENT TradingRoleInfoReq EMPTY> <!ATTLIST TradingRoleInfoReq ID ID #REQUIRED TradingRoleList NMTOKENS #REQUIRED >
<！ - トレーディングROLE INFO要求コンポーネント - > <！ELEMENT TradingRoleInfoReq EMPTY> <！ATTLIST TradingRoleInfoReq ID ID #REQUIRED TradingRoleList NMTOKENS #REQUIRED>
<!-- 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注文（PackagedContent *）> <ATTLIST注文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>
<!-- ORGANISATION COMPONENT --> <!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 >
<！ - 組織COMPONENT - > <ATTLIST組織ID ID #REQUIREDのXML：LANG NMTOKEN #REQUIRED ORGID CDATA #REQUIRED氏名権CDATA #IMPLIED shortDesc属性CDATA <ELEMENT組織（TradingRole +、のContactInfo？PersonNameの?,のPostalAddress？）！>！ #IMPLIED LogoNetLocn CDATA #IMPLIED>
<!ELEMENT TradingRole EMPTY > <!ATTLIST TradingRole ID ID#REQUIRED TradingRole NMTOKEN #REQUIRED IotpMsgIdPrefix NMTOKEN #REQUIRED CancelNetLocn CDATA #IMPLIED ErrorNetLocn CDATA #IMPLIED ErrorLogNetLocn CDATA #IMPLIED >
<！ELEMENT TradingRole EMPTY> <！ATTLIST TradingRole ID ID＃REQUIRED TradingRole NMTOKEN #REQUIRED IotpMsgIdPrefix NMTOKEN #REQUIRED CancelNetLocn CDATA #IMPLIED ErrorNetLocn CDATA #IMPLIED ErrorLogNetLocn CDATA #IMPLIED>
<!ELEMENT ContactInfo EMPTY > <!ATTLIST ContactInfo xml:lang NMTOKEN #IMPLIED Tel CDATA #IMPLIED Fax CDATA #IMPLIED Email CDATA #IMPLIED NetLocn CDATA #IMPLIED >
<！ELEMENTのContactInfo EMPTY> <！ATTLISTのContactInfoのxml：langのNMTOKEN #IMPLIED電話CDATA #IMPLIEDファックスCDATA #IMPLIEDメールCDATA #IMPLIED NetLocn CDATA #IMPLIED>
<!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タイトルCDATA #IMPLIED GIVENNAME CDATA #IMPLIEDイニシャルCDATA #IMPLIED FamilyNameでCDATA #IMPLIED>
<!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住所1 CDATA #IMPLIED住所2 CDATA #IMPLIED CityOrTown CDATA #IMPLIED StateOrRegion CDATA #IMPLIED郵便番号CDATA #IMPLIED国CDATA #IMPLIED LegalLocation（TRUE | FALSE） '偽'>
<!-- 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 >
<！ - BRANDリストコンポーネント - > <ATTLIST BrandList ID ID #REQUIREDのXML <ELEMENT BrandList（ブランド+、ProtocolAmount +、CurrencyAmount +、PayProtocol +）！>：！LANG NMTOKEN #REQUIRED shortDesc属性CDATA #REQUIRED PayDirection（デビット|クレジット）#REQUIRED >
<!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ブランド（ProtocolBrand *、PackagedContent *）> <ATTLISTブランドID ID #REQUIREDのXML：LANG NMTOKEN #IMPLIED BrandId CDATA #REQUIRED新しい名称CDATA #REQUIRED BrandLogoNetLocn CDATA #REQUIRED BrandNarrative CDATA #IMPLIED ProtocolAmountRefs IDREFS #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT ProtocolBrand (PackagedContent*) > <!ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #REQUIRED >
<！ELEMENT ProtocolBrand（PackagedContent *）> <！ATTLIST ProtocolBrand ProtocolId CDATA #REQUIRED ProtocolBrandId CDATA #REQUIRED>
<!ELEMENT ProtocolAmount (PackagedContent*) > <!ATTLIST ProtocolAmount ID ID #REQUIRED PayProtocolRef IDREF #REQUIRED CurrencyAmountRefs IDREFS #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT ProtocolAmount（PackagedContent *）> <！ATTLIST ProtocolAmount ID ID #REQUIRED PayProtocolRef IDREF #REQUIRED CurrencyAmountRefs IDREFS #REQUIRED ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT CurrencyAmount EMPTY > <!ATTLIST CurrencyAmount ID ID #REQUIRED Amount CDATA #REQUIRED
<！ELEMENT CurrencyAmount EMPTY> <！ATTLIST CurrencyAmount ID ID #REQUIRED額CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED >
CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED>
<!ELEMENT PayProtocol (PackagedContent*) > <!ATTLIST PayProtocol ID ID #REQUIRED xml:lang NMTOKEN #IMPLIED ProtocolId NMTOKEN #REQUIRED ProtocolName CDATA #REQUIRED ActionOrgRef NMTOKEN #REQUIRED PayReqNetLocn CDATA #IMPLIED SecPayReqNetLocn CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT PayProtocol（PackagedContent *）> <ATTLIST PayProtocol ID ID #REQUIREDのXML：LANG NMTOKEN #IMPLIED ProtocolId NMTOKEN #REQUIRED ProtocolName CDATA #REQUIRED ActionOrgRef NMTOKEN #REQUIRED PayReqNetLocn CDATA #IMPLIED SecPayReqNetLocn CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED>
<!-- BRAND SELECTION COMPONENT --> <!ELEMENT BrandSelection (BrandSelBrandInfo?, BrandSelProtocolAmountInfo?, BrandSelCurrencyAmountInfo?) > <!ATTLIST BrandSelection ID ID #REQUIRED BrandListRef NMTOKEN #REQUIRED BrandRef NMTOKEN #REQUIRED ProtocolAmountRef NMTOKEN #REQUIRED CurrencyAmountRef NMTOKEN #REQUIRED >
<！ - BRAND選択コンポーネント - > <！ELEMENT BrandSelection（？BrandSelBrandInfo ?, BrandSelProtocolAmountInfo ?, BrandSelCurrencyAmountInfo）> <！ATTLIST BrandSelection ID ID #REQUIRED BrandListRef NMTOKEN #REQUIRED BrandRef NMTOKEN #REQUIRED ProtocolAmountRef NMTOKEN #REQUIRED CurrencyAmountRef NMTOKEN #REQUIRED>
<!ELEMENT BrandSelBrandInfo (PackagedContent+) > <!ATTLIST BrandSelBrandInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT BrandSelBrandInfo（PackagedContent +）> <！ATTLIST BrandSelBrandInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) > <!ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT BrandSelProtocolAmountInfo（PackagedContent +）> <！ATTLIST BrandSelProtocolAmountInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED>
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) > <!ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ELEMENT BrandSelCurrencyAmountInfo（PackagedContent +）> <！ATTLIST BrandSelCurrencyAmountInfo ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED>
<!-- PAYMENT COMPONENT --> <!ELEMENT Payment EMPTY > <!ATTLIST Payment ID ID #REQUIRED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED BrandListRef NMTOKEN #REQUIRED
<！ - 支払いCOMPONENT - > <！ELEMENT支払いEMPTY> <ATTLIST支払ID ID #REQUIRED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED BrandListRef NMTOKEN #REQUIRED！
SignedPayReceipt (True | False) #REQUIRED StartAfterRefs NMTOKENS #IMPLIED >
SignedPayReceipt（TRUE | FALSE）#REQUIRED StartAfterRefs NMTOKENS #IMPLIED>
<!-- PAYMENT SCHEME COMPONENT --> <!ELEMENT PaySchemeData (PackagedContent+) > <!ATTLIST PaySchemeData ID ID #REQUIRED PaymentRef NMTOKEN #IMPLIED ConsumerPaymentId CDATA #IMPLIED PaymentHandlerPayId CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED >
<！ - 支払いスキーマコンポーネント - > <！ELEMENT PaySchemeData（PackagedContent +）> <！ATTLIST PaySchemeData ID ID #REQUIRED PaymentRef NMTOKEN #IMPLIED ConsumerPaymentId CDATA #IMPLIED PaymentHandlerPayId CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED>
<!-- PAYMENT RECEIPT COMPONENT --> <!ELEMENT PayReceipt (PackagedContent*) > <!ATTLIST PayReceipt ID ID #REQUIRED PaymentRef NMTOKEN #REQUIRED PayReceiptNameRefs NMTOKENS #IMPLIED ContentSoftwareId CDATA #IMPLIED >
<！ - 領収書のCOMPONENT - > <！ELEMENT PayReceipt（PackagedContent *）> <！ATTLIST PayReceipt ID ID #REQUIRED PaymentRef NMTOKEN #REQUIRED PayReceiptNameRefs NMTOKENS #IMPLIED ContentSoftwareId CDATA #IMPLIED>
<!-- PAYMENT NOTE COMPONENT --> <!ELEMENT PaymentNote (PackagedContent+) > <!ATTLIST PaymentNote ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED >
<！ - PAYMENT注記COMPONENT - > <！ELEMENT PaymentNote（PackagedContent +）> <！ATTLIST PaymentNote ID ID #REQUIRED ContentSoftwareId CDATA #IMPLIED>
<!-- DELIVERY COMPONENT --> <!ELEMENT Delivery (DeliveryData?, PackagedContent*) > <!ATTLIST Delivery ID ID #REQUIRED xml:lang NMTOKEN #REQUIRED DelivExch (True | False) #REQUIRED DelivAndPayResp (True | False) #REQUIRED ActionOrgRef NMTOKEN #IMPLIED >
<！ - 配信コンポーネント - > <ELEMENT配達（DeliveryData ?, PackagedContent *）> <！ATTLIST配信ID ID #REQUIREDのXML：LANG NMTOKEN #REQUIRED DelivExch（TRUE | FALSE）#REQUIRED DelivAndPayResp（TRUE | FALSE）＃ REQUIRED ActionOrgRef NMTOKEN #IMPLIED>
<!ELEMENT DeliveryData (PackagedContent*) > <!ATTLIST DeliveryData xml:lang NMTOKEN #IMPLIED OkFrom CDATA #REQUIRED OkTo CDATA #REQUIRED DelivMethod NMTOKEN #REQUIRED DelivToRef NMTOKEN #REQUIRED DelivReqNetLocn CDATA #IMPLIED SecDelivReqNetLocn 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 #IMPLIED SecDelivReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
ContentSoftwareId CDATA #IMPLIED>
<!-- CONSUMER DELIVERY DATA COMPONENT --> <!ELEMENT ConsumerDeliveryData EMPTY > <!ATTLIST ConsumerDeliveryData ID ID #REQUIRED ConsumerDeliveryId CDATA #REQUIRED >
<！ - CONSUMER配信データのCOMPONENT - > <！ELEMENT ConsumerDeliveryData EMPTY> <！ATTLIST ConsumerDeliveryData ID ID #REQUIRED ConsumerDeliveryId CDATA #REQUIRED>
<!-- DELIVERY NOTE COMPONENT --> <!ELEMENT DeliveryNote (PackagedContent+) > <!ATTLIST DeliveryNote ID ID #REQUIRED xml:lang NMTOKEN #REQUIRED DelivHandlerDelivId CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED >
<！ - 納品書COMPONENT - > <ELEMENT DeliveryNote（PackagedContent +）> <！ATTLIST DeliveryNote ID ID #REQUIREDのXML：LANG NMTOKEN #REQUIRED DelivHandlerDelivId CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED>
<!-- STATUS COMPONENT --> <!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ステータスEMPTY> <！ - ！ - 状況コンポーネント> <ATTLISTステータス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>
<!-- TRADING ROLE DATA COMPONENT --> <!ELEMENT TradingRoleData (PackagedContent+) > <!ATTLIST TradingRoleData ID ID #REQUIRED OriginatorElRef NMTOKEN #REQUIRED DestinationElRefs NMTOKENS #REQUIRED >
<！ - TRADING ROLEのデータコンポーネント - > <！ELEMENT TradingRoleData（PackagedContent +）> <！ATTLIST TradingRoleData ID ID #REQUIRED OriginatorElRef NMTOKEN #REQUIRED DestinationElRefs NMTOKENS #REQUIRED>
<!-- INQUIRY TYPE COMPONENT --> <!ELEMENT InquiryType EMPTY > <!ATTLIST InquiryType ID ID #REQUIRED Type NMTOKEN #REQUIRED ElRef NMTOKEN #IMPLIED ProcessReference CDATA #IMPLIED >
<！ - お問い合わせの種類のCOMPONENT - > <！ELEMENT InquiryType EMPTY> <！ATTLIST InquiryType ID ID #REQUIREDタイプNMTOKEN #REQUIRED ElRef NMTOKEN #IMPLIED ProcessReference CDATA #IMPLIED>
<!-- 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 >
<！ - エラーコンポーネント - > <ATTLIST ErrorComp ID NMTOKEN #REQUIREDのXML <ELEMENT ErrorComp（ErrorLocation +、PackagedContent *）！>：！LANG NMTOKEN #REQUIREDのErrorCode NMTOKEN #REQUIRED ErrorDesc CDATA #REQUIRED重大度（警告| TransientError | HardError） #REQUIRED MinRetrySecs CDATA #IMPLIED SwVendorErrorRef CDATA #IMPLIED>
<!ELEMENT ErrorLocation EMPTY > <!ATTLIST ErrorLocation ElementType NMTOKEN #REQUIRED IotpMsgRef NMTOKEN #IMPLIED BlkRef NMTOKEN #IMPLIED CompRef NMTOKEN #IMPLIED ElementRef NMTOKEN #IMPLIED AttName NMTOKEN #IMPLIED >
<！ELEMENT ErrorLocation EMPTY> <！ATTLIST ErrorLocationのElementType NMTOKEN #REQUIRED IotpMsgRef NMTOKEN #IMPLIED BlkRef NMTOKEN #IMPLIED CompRef NMTOKEN #IMPLIED ElementRef NMTOKEN #IMPLIED AttName NMTOKEN #IMPLIED>
<!-- ****************************************************** * TRADING BLOCKS * ****************************************************** -->
<！ - ********************************************** ******** * TRADINGブロック* ************************************** **************** - >
<!-- TRADING PROTOCOL OPTIONS BLOCK --> <!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) > <!ATTLIST TpoBlk ID ID #REQUIRED >
<！ - TRADINGプロトコルオプションBLOCK - > <！ELEMENT TpoBlk（ProtocolOptions、BrandListの*、組織*）> <！ATTLIST TpoBlk ID ID #REQUIRED>
<!-- TPO SELECTION BLOCK --> <!ELEMENT TpoSelectionBlk (BrandSelection+) > <!ATTLIST TpoSelectionBlk ID ID #REQUIRED >
<！ - TPO選択ブロック - > <！ELEMENT TpoSelectionBlk（BrandSelection +）> <！ATTLIST TpoSelectionBlk ID ID #REQUIRED>
<!-- OFFER RESPONSE BLOCK --> <!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*) > <!ATTLIST OfferRespBlk ID ID #REQUIRED >
<！ - OFFER応答ブロック - > <！ELEMENT OfferRespBlk（ステータス、注文?,支払*、配達?, TradingRoleData *）> <！ATTLIST OfferRespBlk ID ID #REQUIRED>
<!-- AUTHENTICATION REQUEST BLOCK --> <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) > <!ATTLIST AuthReqBlk ID ID #REQUIRED >
<！ - 認証要求BLOCK - > <！ELEMENT AuthReqBlk（？AUTHREQ *、TradingRoleInfoReq）> <！ATTLIST AuthReqBlk ID ID #REQUIRED>
<!-- AUTHENTICATION RESPONSE BLOCK --> <!ELEMENT AuthRespBlk (AuthResp?, Org*) > <!ATTLIST AuthRespBlk ID ID #REQUIRED >
<！ - 認証応答BLOCK - > <！ELEMENT AuthRespBlk（AuthResp ?,組織*）> <！ATTLIST AuthRespBlk ID ID #REQUIRED>
<!-- AUTHENTICATION STATUS BLOCK --> <!ELEMENT AuthStatusBlk (Status) > <!ATTLIST AuthStatusBlk ID ID #REQUIRED >
<！ - 認証状態BLOCK - > <！ELEMENT AuthStatusBlk（ステータス）> <！ATTLIST AuthStatusBlk ID ID #REQUIRED>
<!-- PAYMENT REQUEST BLOCK --> <!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection, Payment, PaySchemeData?, Org*, TradingRoleData*) > <!ATTLIST PayReqBlk ID ID #REQUIRED >
<！ - 支払要求BLOCK - > <！ELEMENT PayReqBlk（ステータス+、BrandList、BrandSelection、支払い、PaySchemeData ?,組織*、TradingRoleData *）> <！ATTLIST PayReqBlk ID ID #REQUIRED>
<!-- PAYMENT EXCHANGE BLOCK --> <!ELEMENT PayExchBlk (PaySchemeData) > <!ATTLIST PayExchBlk ID ID #REQUIRED >
<！ - 支払い交換BLOCK - > <！ELEMENT PayExchBlk（PaySchemeData）> <ATTLIST PayExchBlk ID ID #REQUIRED！>
<!-- PAYMENT RESPONSE BLOCK --> <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?, PaymentNote?, TradingRoleData*) > <!ATTLIST PayRespBlk ID ID #REQUIRED > <!-- DELIVERY REQUEST BLOCK --> <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery, ConsumerDeliveryData?, TradingRoleData*) > <!ATTLIST DeliveryReqBlk ID ID #REQUIRED >
<！ - PAYMENT応答ブロック - > <！ELEMENT PayRespBlk（ステータス、PayReceipt？、？、PaySchemeData PaymentNote ?, TradingRoleData *）> <！ATTLIST PayRespBlk ID ID #REQUIRED> <！ - 配信要求BLOCK - > < ！ELEMENT DeliveryReqBlk（ステータス+、注文、組織*、配達、ConsumerDeliveryData ?, TradingRoleData *）> <！ATTLIST DeliveryReqBlk ID ID #REQUIRED>
<!-- DELIVERY RESPONSE BLOCK --> <!ELEMENT DeliveryRespBlk (Status, DeliveryNote) > <!ATTLIST DeliveryRespBlk ID ID #REQUIRED >
<！ - DELIVERY応答ブロック - > <！ELEMENT DeliveryRespBlk（ステータス、DeliveryNote）> <ATTLIST DeliveryRespBlk ID ID #REQUIRED！>
<!-- INQUIRY REQUEST BLOCK --> <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) > <!ATTLIST InquiryReqBlk ID ID #REQUIRED >
<！ - 問合せ要求BLOCK - > <！ELEMENT InquiryReqBlk（？InquiryType、PaySchemeData）> <！ATTLIST InquiryReqBlk ID ID #REQUIRED>
<!-- INQUIRY RESPONSE BLOCK --> <!ELEMENT InquiryRespBlk (Status, PaySchemeData?) > <!ATTLIST InquiryRespBlk ID ID #REQUIRED LastReceivedIotpMsgRef NMTOKEN #IMPLIED LastSentIotpMsgRef NMTOKEN #IMPLIED >
<！ - 照会応答BLOCK - > <！ELEMENT InquiryRespBlk（？ステータス、PaySchemeData）> <！ATTLIST InquiryRespBlk ID ID #REQUIRED LastReceivedIotpMsgRef NMTOKEN #IMPLIED LastSentIotpMsgRef NMTOKEN #IMPLIED>
<!-- PING REQUEST BLOCK --> <!ELEMENT PingReqBlk (Org*)> <!ATTLIST PingReqBlk ID ID #REQUIRED>
<！ - PING要求ブロック - > <！ELEMENT PingReqBlk（組織*）> <！ATTLIST PingReqBlk ID ID #REQUIRED>
<!-- PING RESPONSE BLOCK --> <!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>
<！ - PING応答ブロック - > <！ELEMENT PingRespBlk（組織+）> <！ATTLIST PingRespBlk ID ID #REQUIRED PingStatusCode（OK |ビジー|ダウン）#REQUIRED SigVerifyStatusCode（OK |はNotSupported |失敗）#IMPLIEDのxml：langのNMTOKEN #IMPLIED PingStatusDesc CDATA #IMPLIED>
<!-- ERROR BLOCK --> <!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) > <!ATTLIST ErrorBlk ID ID #REQUIRED >
<！ - エラーブロック - > <！ELEMENT ErrorBlk（ErrorComp +、PaySchemeData *）> <！ATTLIST ErrorBlk ID ID #REQUIRED>
<!-- CANCEL BLOCK --> <!ELEMENT CancelBlk (Status) > <!ATTLIST CancelBlk ID ID #REQUIRED >
<！ - CANCEL BLOCK - > <！ELEMENT CancelBlk（ステータス）> <！ATTLIST CancelBlk ID ID #REQUIRED>
<!-- ****************************************************** * IOTP SIGNATURES BLOCK DEFINITION * ****************************************************** -->
<！ - ********************************************** ******** * IOTP署名ブロック定義* ************************************ ****************** - >
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) > <!ATTLIST IotpSignatures ID ID #IMPLIED >
<！ELEMENT IOTP署名（署名、証明書*）> <！ATTLIST IOTP署名ID ID #IMPLIED>
<!-- ****************************************************** * IOTP SIGNATURE COMPONENT DEFINITION * ****************************************************** -->
<！ - ********************************************** ******** * IOTPのSIGNATUREコンポーネント定義* ************************************ ****************** - >
<!ELEMENT Signature (Manifest, Value+) > <!ATTLIST Signature ID ID #IMPLIED >
<！ELEMENT署名（マニフェスト、バリュー+）> <！ATTLIST署名ID ID #IMPLIED>
<!ELEMENT Manifest ( Algorithm+, Digest+, Attribute*, OriginatorInfo, RecipientInfo+ ) >
<！ELEMENTマニフェスト（アルゴリズム、ダイジェスト+、属性*、発信情報、のRecipientInfo）>
<!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED >
<！ATTLISTマニフェストLocatorHRefBase CDATA #IMPLIED>
<!ELEMENT Algorithm (Parameter*) > <!ATTLIST Algorithm ID ID #REQUIRED type (digest|signature) #IMPLIED name NMTOKEN #REQUIRED >
<！ELEMENTアルゴリズム（パラメータ*）> <！ATTLISTアルゴリズムID ID #REQUIREDタイプ（ダイジェスト|署名を）#IMPLIED名前NMTOKEN #REQUIRED>
<!ELEMENT Digest (Locator, Value) > <!ATTLIST Digest DigestAlgorithmRef IDREF #REQUIRED >
<！ELEMENTダイジェスト（ロケータ、バリュー）> <！ATTLISTダイジェストDigestAlgorithmRef IDREF #REQUIRED>
<!ELEMENT Attribute ( ANY ) > <!ATTLIST Attribute type NMTOKEN #REQUIRED critical ( true | false ) #REQUIRED >
<！ELEMENT属性（ANY）> <ATTLISTクリティカル（真|偽）タイプNMTOKEN #REQUIRED属性！#REQUIRED>
<!ELEMENT OriginatorInfo ANY >
<！ELEMENT OriginatorInfo ANY>
<!ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED >
<！ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED>
<!ELEMENT RecipientInfo ANY > <!ATTLIST RecipientInfo SignatureAlgorithmRef IDREF #REQUIRED SignatureValueRef IDREF #IMPLIED SignatureCertRef IDREF #IMPLIED RecipientRefs NMTOKENS #IMPLIED >
<！ELEMENTのRecipientInfo ANY> <！ATTLISTのRecipientInfo SignatureAlgorithmRef IDREF #REQUIRED SignatureValueRef IDREF #IMPLIED SignatureCertRef IDREF #IMPLIED RecipientRefs NMTOKENS #IMPLIED>
<!ELEMENT KeyIdentifier EMPTY> <!ATTLIST KeyIdentifier value CDATA #REQUIRED >
<！ELEMENT KeyIdentifier EMPTY> <！ATTLIST KeyIdentifier値CDATA #REQUIRED>
<!ELEMENT Parameter ANY > <!ATTLIST Parameter type CDATA #REQUIRED >
<！ELEMENTパラメーターANY> <！ATTLISTパラメータタイプCDATA #REQUIRED>
<!-- ****************************************************** * IOTP CERTIFICATE COMPONENT DEFINITION * ****************************************************** -->
<！ - ********************************************** ******** * IOTP CERTIFICATEコンポーネント定義* ************************************ ****************** - >
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) ) >
<！ELEMENT証明書（IssuerAndSerialNumber、（バリュー|ロケータ））>
<!ATTLIST Certificate ID ID #IMPLIED type NMTOKEN #REQUIRED >
<！ATTLIST証明書ID ID #IMPLIEDタイプNMTOKEN #REQUIRED>
<!ELEMENT IssuerAndSerialNumber EMPTY > <!ATTLIST IssuerAndSerialNumber issuer CDATA #REQUIRED number CDATA #REQUIRED >
<！ELEMENT IssuerAndSerialNumber EMPTY> <！ATTLIST IssuerAndSerialNumber発行者CDATA #REQUIRED数CDATA #REQUIRED>
<!-- ****************************************************** * IOTP SHARED COMPONENT DEFINITION * ******************************************************
<！ - ********************************************** ******** * IOTP共有コンポーネントの定義* ************************************ ******************
--> <!ELEMENT Value ( #PCDATA ) > <!ATTLIST Value ID ID #IMPLIED encoding (base64|none) 'base64' >
- > <ELEMENT値（#PCDATA）> <ATTLISTバリューID ID #IMPLIEDエンコーディング（base64で|なし）！！ 'base64で'>
<!ELEMENT Locator EMPTY> <!ATTLIST Locator xml:link CDATA #FIXED 'simple' href CDATA #REQUIRED >
<！ELEMENTロケータEMPTY> <！ATTLISTロケータのxml：リンクCDATA #FIXED 'シンプル' のhref CDATA #REQUIRED>
This section contains a glossary of some of the terms used within this specification in alphabetical order.
このセクションでは、アルファベット順に、この明細書内で使用される用語のいくつかの用語集が含まれています。
NAME DESCRIPTION
NAME説明
Authenticator The Organisation which is requesting the authentication of another Organisation, and
別の組織の認証を要求している組織認証者、および
Authenticatee The Organisation being authenticated by an Authenticator
被認証者ザ・組織は、Authenticatorが認証されます
Business Error See Status Component.
ビジネスエラーは、状況コンポーネントを参照してください。
Brand A Brand is the mark which identifies a particular type of Payment Instrument. A list of Brands are the payment options which are presented by the Merchant to the Consumer and from which the Consumer makes a selection. Each Brand may have a different Payment Handler. Examples of Brands include: o payment association and proprietary Brands, for example MasterCard, Visa, American Express, Diners Club, American Express, Mondex, GeldKarte, CyberCash, etc. o Promotional Brands (see below). These include: o store Brands, where the Payment Instrument is issued to a Consumer by a particular Merchant, for example Walmart, Sears, or Marks and Spencer (UK) o coBrands, for example American Advantage Visa, where an a company uses their own Brand in conjunction with, typically, a payment association Brand.
ブランドAブランドは支払手段の特定のタイプを識別する目印です。ブランドのリストは、消費者に消費者が選択を行う、そこから商人によって提示される支払いオプションです。各ブランドは、異なる支払いハンドラを有することができます。ブランドの例としては、例えば、マスターカード、ビザ、アメリカン・エキスプレス、ダイナースクラブ、アメリカンエクスプレス、モンデックス、ゲルトカルテ、サイバーキャッシュ、などのOプロモーションブランドの支払い協会と独自のブランド、O（下記参照します）。これらを含める：支払手段が特定の商人によって消費者に発行されたストアブランド、O、coBrands Oたとえば、ウォルマート、シアーズ、またはマークスアンドスペンサー（UK）のために、会社が自分を使用する例アメリカの優位ビザのために、一般的に、決済関連ブランドと一緒にブランド。
Consumer The Organisation which is to receive the benefit of and typically pay for the goods or services.
恩恵を受け、一般的に商品やサービスの支払いにある消費者ザ・組織。
ContentSoftwareId This contains information which identifies the software which generated the content of the element. 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: 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
これは、要素の内容を生成したソフトウェアを特定する情報が含まれていContentSoftwareId。その目的は、異なるソフトウェアによって生成されたメッセージの間の非互換性の結果として発生する可能性のある相互運用性の問題を解決することです。 LANG：これは、XMLで定義された言語での単一のテキスト文字列です。ソフトウェアのバージョンOソフトウェアの名称Oソフトウェアの製造元の名前O、およびソフトウェアのビルドO：それは最低限として、含まれている必要があります
It is recommended that this attribute is included
whenever the software which generated the content
cannot be identified from the SoftwareId attribute
on the Message Id Component (see section 3.3.2)
Customer Care An Organisation that is providing customer care Provider typically on behalf of a Merchant. Examples of customer care include, responding to problems raised by a Consumer arising from an IOTP Transaction that the Consumer took part in.
カスタマーケア商人に代わって一般的に顧客ケアプロバイダを提供しているアン組織。顧客ケアの例としては、消費者が参加したIOTP取引から生じる消費者が提起した問題への対応、含まれています。
Delivery Handler The Organisation that directly delivers the goods or services to the Consumer on behalf of the Merchant. Delivery can be in the form of either digital goods (e.g., a [MIME] message), or physically delivered using the post or a courier.
直接加盟店に代わって消費者に商品やサービスを提供する配信ハンドラザ・組織。送達は、デジタル財（例えば、[MIME]メッセージ）のいずれかの形態であっても、または物理的郵便または宅配便を使用して送達することができます。
Document Exchange A Document Exchange consists of a set of IOTP Messages exchanged between two parties that 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.
文書交換A文書交換は、同時にインターネット経由で送信する必要があり、実際のIOTPメッセージの数を最小限にするために、一部または2つの取引の取引所のすべてを実装する2つの当事者間で交換IOTPメッセージのセットで構成されます。
Document Exchanges are combined together in
sequence to implement a particular IOTP
Transaction.
Dual Brand A Dual Brand means that a single Payment Instrument may be used as if it were two separate Brands. For example there could be a single Japanese "UC" MasterCard which can be used as either a UC card or a regular MasterCard. The UC card Brand and the MasterCard Brand could each have their own separate Payment Handlers. This means that: o the Merchant treats, for example "UC" and "MasterCard" as two separate Brands when offering a list of Brands to the Consumer, o the Consumer chooses a Brand, for example either "UC" or "MasterCard, o the Consumer IOTP aware application determines which Payment Instrument(s) match the chosen Brand, and selects, perhaps with user assistance, the correct Payment Instrument to use.
デュアルブランドAデュアルブランドは、2つの別々のブランドであるかのように、単一の支払手段を使用することができることを意味します。例えば、UCカードや定期的なMasterCardのいずれかとして使用することができ、単一の日本の「UC」のMasterCardがあるかもしれません。 UCカードブランドとMasterCardブランドは、それぞれ独自の個別の支払ハンドラを持つことができます。消費者がブランドを選択しoを例えば「UC」や「MasterCardのいずれかで、消費者にブランドのリストを提供するとき、O、マーチャント扱いO、たとえば「UC」や「マスターカード」のための2つの独立したブランドとして：これはその意味します消費者IOTP認識アプリケーションが支払機器（単数または複数）が、おそらくユーザー支援、使用する正しい支払手段と、選択されたブランド、及び選択に一致するかを決定します。
Error Block An Error Block reports that a Technical Error was found in an IOTP Message that was previously received. Typically Technical Errors are caused by errors in the XML which has been received or some technical failure of the processing of the IOTP Message. Frequently the generation or receipt of an Error Block will result in failure of the IOTP Transaction. They are distinct from Business Errors, reported in a Status Component, which can also cause failure of an IOTP Transaction.
エラーブロックエラーブロックは、技術的なエラーが以前に受信したIOTPメッセージで発見されたことを報告します。典型的には、技術的なエラーが受信されたXMLまたはIOTPメッセージの処理のいくつかの技術的な失敗のエラーによって引き起こされます。頻繁にエラーブロックの発生や領収書はIOTPトランザクションの失敗になります。彼らはまた、IOTPトランザクションの障害を引き起こす可能性ステータスのコンポーネントで報告事業エラー、区別されます。
Exchange Block An Exchange Block is sent between the two Trading Roles involved in a Trading Exchange. It contains one or more Trading Components. Exchange Blocks are always sent after a Request Block and before a Response Block in a Trading Exchange. The content of an Exchange Block is dependent on the type of Trading Exchange being carried out.
交換ブロックアン交換ブロックは、取引所に関与する2つの取引の役割との間で送信されます。これは、1つのまたは複数の取引コンポーネントが含まれています。交換ブロックは常に要求ブロックの後や取引所における応答ブロックの前に送信されます。交換ブロックの内容が行われて取引所の種類に依存しています。
IOTP Message An IOTP Message is the outermost wrapper for the document(s) which are sent between Trading Roles that are taking part in a trade. It is a well formed XML document. The documents it contains consist of: o a Transaction Reference Block to uniquely identify the IOTP Transaction of which the IOTP Message is part, o an optional Signature Block to digitally sign the Trading Blocks or Trading Components associated with the IOTP Transaction o an optional Error Block to report on technical errors contained in a previously received IOTP Message, and
IOTPメッセージアンIOTPメッセージは、取引に参加しているトレーディングロール間で送信される文書（単数または複数）のための最も外側のラッパーです。これはよく形成されたXML文書です。トランザクション参照ブロックOA一意IOTPメッセージをデジタルに任意誤差ブロックoをIOTPトランザクションに関連付けられた取引ブロックまたは取引コンポーネントに署名するオプションの署名ブロックOの一部であるIOTPトランザクションを識別するため：それはから成っ含まドキュメント以前に受信したIOTPメッセージに含まれる技術的なエラーの報告、および
o a collection of IOTP Trading Blocks which
carries the data required to carry out an IOTP
Transaction.
IOTP Transaction An instance of an Internet Open Trading Protocol Transaction consists of a set of IOTP Messages transferred between Trading Roles. The rules for what may be contained in the IOTP Messages is defined by the Transaction Type of the IOTP Transaction.
IOTPトランザクションは、インターネットオープン取引議定書のトランザクションのインスタンスは、取引の役割との間で転送さIOTPメッセージのセットで構成されます。 IOTPメッセージに含まれていても良い何のためのルールはIOTPトランザクションのトランザクションタイプによって定義されます。
IOTP Transaction A Transaction Type identifies the type an of IOTP Type Transaction. Examples of Transaction Type include: Purchase, Refund, Authentication, Withdrawal, Deposit (of electronic cash). The Transaction Type specifies for an IOTP Transaction: o the Trading Exchanges which may be included in the transaction, o how those Trading Exchanges may be combined to meet the business needs of the transaction o which Trading Blocks may be included in the IOTP Messages that make up the transaction o Consult this specification for the rules that apply for each Transaction Type.
IOTPトランザクションAトランザクションタイプはIOTPタイプのトランザクションのタイプを識別します。トランザクションタイプの例としては、購入、返金、認証、撤退、預金（電子現金を）。トランザクションタイプはIOTPトランザクションのために指定されています。トランザクションに含まれていてもよい貿易取引所O、それらのトレーディング取引所は、取引のブロックが作るIOTPメッセージに含まれていてもよい取引oのビジネスニーズを満たすために組み合わせることができるO方法トランザクションOまで各トランザクションタイプに適用する規則については、この仕様を参照してください。
Merchant The Organisation from whom the service or goods are being obtained, who is legally responsible for providing the goods or services and receives the benefit of any payment made
商品やサービスを提供するための法的責任があると行われた支払いの恩恵を受けマーチャントサービスや商品が求められている誰から組織、
Merchant Customer The Organisation that is involved with customer Care Provider dispute negotiation and resolution on behalf of the Merchant
商人に代わって顧客ケアプロバイダ紛争の交渉と解決に関与しているマーチャントカスタマー組織
Organisation A company or individual that takes part in a Trade as a Trading Role. The Organisations may take one or more of the roles involved in the Trade
組織取引の役割として、展覧会に参加する企業または個人。組織は、取引に関与した役割の1以上かかる場合があります
Payment Handler The Organisation that physically receives the payment from the Consumer on behalf of the Merchant
物理的に加盟店に代わって消費者からの支払いを受け取る支払いハンドラザ・組織
Payment A Payment Instrument is the means by which
Instrument Consumer pays for goods or services offered by a
Merchant. It can be, for example:
o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro;
o a smart card based electronic cash Payment
Instrument such as a Mondex Card, a GeldKarte
card or a Visa Cash card
o a software based electronic payment account
such as a CyberCash's CyberCoin or DigiCash
account.
All Payment Instruments have a number, typically an account number, by which the Payment Instrument can be identified.
すべての決済手段は、支払手段を識別することが可能な数、一般的に口座番号を、持っています。
Promotional Brand A Promotional Brand means that, if the Consumer pays with that Brand, then the Consumer will receive some additional benefit which can be received in two ways: o at the time of purchase. For example if a Consumer pays with a "Walmart MasterCard" at a Walmart web site, then a 5% discount might apply, which means the Consumer actually pays less, o from their Payment Instrument (card) issuer when the payment appears on their statement. For example loyalty points in a frequent flyer scheme could be awarded based on the total payments made with the Payment Instrument since the last statement was issued.
購入時にO：プロモーションブランドAプロモーションブランドは、消費者がそのブランドで支払う場合、消費者は、2つの方法で受信することができますいくつかの追加の利点を受ける、ということを意味します。消費者は、ウォルマートのウェブサイトで「ウォルマートマスター」で支払う場合例えば、彼らの支払手段（カード）発行者からの支払いは、自分の文に表示されたときにoを5％割引は、消費者が実際にあまりを支払う意味し、適用される場合があります。最後の文が発行されたので、例えばマイレージ制度における忠誠ポイントは、支払手段で作られた総支払額に基づいて授与することができます。
Each Promotional Brand should be identified as a
separate Brand in the list of Brands offered by
the Merchant.
Receipt Component A Receipt Component is a record of the successful completion of a Trading Exchange. Examples of Receipt Components include: Payment Receipts, and Delivery Notes. It's content may dependent on the technology used to perform the Trading Exchange. For example a Secure Electronic Transaction (SET) payment receipt consists of SET payment messages which record the result of the payment.
領収書のコンポーネントは、領収書のコンポーネントは、取引所が正常に完了の記録です。領収書のコンポーネントの例としては、支払領収書、および納品書を。これは、取引所を実行するために使用される技術に依存する内容5月です。例えば、安全な電子トランザクション（SET）の支払いの領収書は、レコード支払いの結果SET支払メッセージで構成されています。
Request Block A Request Block is Trading Block that contains a request for a Trading Exchange to start. The Trading Components in a Request Block may be signed by a Signature Block so that their authenticity may be checked and to determine that the Trading Exchange being requested is authorised. Authorisation for a Trading Exchange to start can be provided by the signatures contained on Receipt Components contained in
ブロックを要求する要求ブロックは、取引所が開始するための要求を含む取引ブロックです。その信憑性を確認することができると要求されている取引所が許可されていることを決定するためになるように要求ブロックにおける取引コンポーネントは、署名ブロックによって署名することができます。開始する取引所の認可はに含まれている領収書のコンポーネントに含まれる署名によって提供することができます
Response Blocks resulting from previously
completed Trading Exchanges. Examples of Request
Blocks are Payment Request and Delivery Request
Response Block A Response Block is a Trading Block that indicates that a Trading Exchange is complete. It is sent by the Trading Role that received a Request Block to the Trading Role that sent the Request Block. The Response Block contains a Status Component that contains information about the completion of the Trading Exchange, for example it indicates whether or not the Trading Exchange completed successfully. For some Trading Exchanges the Response Block contains a Receipt Component that forms a record of the Trading Exchange. Receipt Components may be digitally signed using a Signature Block to make completion non-refutable. Examples of Response Blocks include Offer Response, Payment Response and Delivery Response.
応答ブロックA応答ブロックは、取引所が完了したことを示す取引ブロックです。これは、要求ブロックを送った取引の役割に要求ブロックを受けた取引の役割によって送信されます。応答ブロックは、取引所の完了に関する情報が含まれていますたとえば、それは貿易取引が正常に完了しているか否かを示すステータス・コンポーネントが含まれています。いくつかの取引交換の応答ブロックは、取引所の記録を形成領収書のコンポーネントが含まれています。受信コンポーネントは、デジタル完了非反駁するために署名ブロックを使用して署名することができます。レスポンスブロックの例としては、オファーレスポンス、支払レスポンスと配信レスポンスが含まれます。
Signature Block A Signature Block is a Trading Block that contains one or more digital signatures in the form of Signature Components. A Signature Component may digitally sign any Block or Component in any IOTP Message in the same IOTP Transaction.
署名は、署名ブロックが署名コンポーネントの形で1つ以上のデジタル署名を含んでいる取引ブロックされたブロック。署名コンポーネントは、デジタル同じIOTPトランザクション内の任意のIOTPメッセージで任意のブロックまたはコンポーネントに署名することができます。
Status Component A Status Component contains information that describes the state of a Trading Exchange.
ステータスコンポーネントAの状況コンポーネントは、取引所の状態を記述する情報が含まれています。
Before the Trading Exchange is complete the Status
Component can indicate information about how the
Trading Exchange is progressing.
Once a Trading Exchange is complete the Status Component can only indicate the success of the Trading Exchange or that a Business Error has occurred.
取引所が完了するとステータスコンポーネントは、ビジネスのエラーが発生したことのみ取引所の成功を示すか、することができます。
A Business Error indicates that continuation with the Trading Exchange was not possible because of some business rule or logic, for example, "insufficient funds available", rather than any Technical Error associated with the content or format of the IOTP Messages in the IOTP Transaction.
ビジネスエラーは、「利用可能資金不足」、というよりもIOTPトランザクションでIOTPメッセージの内容や形式に関連付けられている任意の技術的なエラー、例えば、理由はいくつかのビジネスルールやロジックの取引所とその継続が不可能だった示しています。
Technical Error See Error Block.
技術的なエラーはエラーブロックを参照してください。
Trading Block A Trading Block consists of one or more Trading Components. One or more Trading Blocks may be contained within the IOTP Messages which are physically sent in the form of [XML] documents between the different Trading Roles that are taking part in a trade. Trading Blocks are of three main types: o a Request Block, o an Exchange Block, or a o a Response Block
貿易ブロックA取引ブロックは、1つまたは複数の取引コンポーネントで構成されています。一つまたは複数のトレーディング・ブロックは、物理的にトレードに参加している異なる取引の役割との間の文書[XML]の形式で送信されたIOTPメッセージ内に含まれてもよいです。貿易・ブロックは、3つの主要なタイプがあります。リクエストブロックOは、Exchangeブロック、またはO応答ブロックoを
Trading Component A Trading Component is a collection of XML elements and attributes. Trading Components are the child elements of the Trading Blocks. Examples of Trading Components are: Offer, Brand List, Payment Receipt, Delivery [information], Payment Amount [information]
取引コンポーネントA取引コンポーネントは、XMLの要素と属性のコレクションです。取引コンポーネントは、貿易ブロックの子要素です。取引コンポーネントの例としては、オファー、ブランド一覧、支払領収書、配達[情報]、お支払い金額[情報]
Trading Exchange A Trading Exchange consists of the exchange, between two Trading Roles, of a sequence of documents. The documents may be in the form of Trading Blocks or they may be transferred by some other means, for example through entering data into a web page. Each Trading Exchange consists of three main parts: o the sending of a Request Block by one Trading Role (the initiator) to another Trading Role (the recipient), o the optional exchange of one or more Exchange Blocks between the recipient and the initiator, until eventually, o the Trading Role that received the Request Block sends a Response Block to the initiator.
取引所A取引所は、文書の配列の2つの取引の役割との間の交流、から構成されています。文書は、貿易ブロックの形態であってもよく、またはそれらは、Webページにデータを入力を通じて例えば、いくつかの他の手段によって転送することができます。各取引所は、3つの主要部分から構成さ：受信者とイニシエータの間に1つの以上の交換ブロックのオプション交換O、別の取引の役割（受信者）1つの取引の役割（イニシエータ）からの要求ブロックの送信O、最終的になるまで、リクエストブロックを受けた取引の役割oをイニシエータに応答ブロックを送信します。
A Trading Exchange is designed to implement a
useful service of some kind. Examples of Trading
Exchanges/services are:
o Offer, which results in a Consumer receiving
an offer from a Merchant to carry out a
business transaction of some kind,
o Payment, where a Consumer makes a payment to a
Payment Handler,
o Delivery, where a Consumer requests, and
optionally obtains, delivery of goods or
services from a Delivery Handler, and
o Authentication, where any Trading Role may
request and receive information about another
Trading Role.
Trading Role A Trading Role identifies the different ways in which Organisations can participate in a trade. There are five Trading Roles: Consumer, Merchant, Payment Handler, Delivery Handler, and Merchant Customer Care Provider.
取引の役割は、取引の役割は、組織が取引に参加できるさまざまな方法を示しています。消費者、商人、支払いハンドラ、配達ハンドラ、およびマーチャント・カスタマーケアプロバイダ：5つの取引の役割があります。
Transaction A Transaction Reference Block identifies an IOTP Reference Block Transaction. It contains data that identifies: o the Transaction Type, o the IOTP Transaction uniquely, through a globally unique transaction identifier o the IOTP Message uniquely within the IOTP Transaction, through a message identifier
トランザクションAトランザクションリファレンスブロックがIOTPリファレンスブロックのトランザクションを識別します。メッセージ識別子を通じて、一意IOTPトランザクション内のIOTPメッセージOグローバルに一意のトランザクション識別子によって、トランザクションタイプO、IOTPトランザクションoを一意に：それは識別するデータが含まれています
The Transaction Reference Block may also contain
references to other transactions which may or may
not be IOTP Transactions
This section contains references to related documents identified in this specification.
このセクションでは、この仕様で規定されている関連文書への参照が含まれています。
[Base64] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[Base64で]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[DOM-HASH] Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.
[DOMHASH]丸山、H.、田村、K.およびN. Uramoto、 "DOM（DOMHASH）のためのダイジェスト値"、RFC 2803、2000年4月。
[DNS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS] Mockapetris、P.、 "ドメイン名 - 概念と施設"、STD 13、RFC 1034、1987年11月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[DSA] The Digital Signature Algorithm (DSA) published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS), which is a part of the US government's Capstone project.
[DSA]デジタル署名アルゴリズム（DSA）は、米国政府のキャップストーンプロジェクトの一部であるデジタル署名標準（DSS）に国立標準技術研究所（NIST）によって公開。
[ECCDSA] Elliptic Curve Cryptosystems Digital Signature Algorithm (ECCDSA). Elliptic curve cryptosystems are analogues of public-key cryptosystems such as RSA in which modular multiplication is replaced by the elliptic curve addition operation. See: V. S. Miller. Use of elliptic curves in cryptography. In Advances in Cryptology - Crypto '85, pages 417-426, Springer-Verlag, 1986.
【ECCDSA】楕円曲線暗号デジタル署名アルゴリズム（ECCDSA）。楕円曲線暗号は、モジュラ乗算は楕円曲線加算演算により置換されているRSAのような公開鍵暗号の類似体です。参照：V. S. Miller氏を。暗号における楕円曲線の使用。暗号'85、ページ417から426、シュプリンガー・フェアラーク、1986 - 暗号学の進歩に。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML]バーナーズ=リー、T.、およびD.コノリー、 "ハイパーテキストマークアップ言語 - 2.0"、RFC 1866、1995年11月。
[HTML] Hyper Text Mark Up Language. The Hypertext Mark-up Language (HTML) is a simple mark-up language used to create hypertext documents that are platform independent. See the World Wide Web (W3C) consortium web site at: http://www.w3.org/MarkUp/
[HTML]ハイパーテキストマークアップ言語。ハイパーテキストマークアップ言語（HTML）は、プラットフォームに依存しているハイパーテキスト文書を作成するために使用される単純なマークアップ言語です。 http://www.w3.org/MarkUp/：で、ワールド・ワイド・ウェブ（W3C）コンソーシアムのWebサイトを参照してください
[HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[HTTP]バーナーズ=リー、T.、フィールディング、R.、およびH. Frystyk、 "ハイパーテキスト転送プロトコル - HTTP / 1.0"、RFC 1945、1996年5月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC 2616, June 1999.
[HTTP]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、T.およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、RFC 2616、1999年6月。
[IANA] The Internet Assigned Numbers Authority. The organisation responsible for co-ordinating the names and numbers associated with the Internet. See http://www.iana.org/
[IANA]インターネットは数の権威を割り当てられました。インターネットに関連したコーディネート名前と番号を担当する組織。 http://www.iana.org/を参照してください。
[ISO4217] ISO 4217: Codes for the Representation of Currencies. Available from ANSI or ISO.
[ISO4217] ISO 4217：通貨の表現のためのコード。 ANSIやISOから入手できます。
[IOTPDSIG] Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000.
"v1.0のインターネットオープン取引プロトコル（IOTP）のデジタル署名" [IOTPDSIG]ダビッドソン、K.とY. Kawatsura、RFC 2802、2000年4月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest氏、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[MIME] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[MIME]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[MIME] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text" RFC 2047, November 1996.
[MIME]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張" RFC 2047、1996年11月。
[MIME] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[MIME]解放され、N.、Klensin、J.とJ.ポステル、 "多目的インターネットメール拡張（MIME）第四部：登録手順"、RFC 2048、1996年11月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples" RFC 2049, November 1996.
[MIME]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート5：適合基準と例" RFC 2049は、1996年11月。
[OPS] Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others.
[OPS]開くプロファイリング標準。個人とウェブサイト間のプロファイル情報の信頼できる交換のための組み込みのプライバシー保護対策でフレームワークを提供して提案された標準。とりわけNetscapeとMicrosoft社によって開発されています。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RSA] RSA is a public-key cryptosystem for both encryption and authentication supported by RSA Data Security Inc. See: R. L. Rivest, A. Shamir, and L.M. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21(2): 120-126, February 1978.
[RSA] RSAは、暗号化と認証の両方のための公開鍵暗号は、RSA Data Security Inc.によってサポートされて参照してください：R. L. Rivest氏、A. Shamir、およびL.M.エーデルマンを。デジタル署名と公開鍵暗号を得るための方法。 ACMのコミュニケーション、21（2）：120-126、1978年2月。
[SCCD] Secure Channel Credit Debit. A method of conducting a credit or debit card payment where unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL/TLS. An IOTP supplement describing how SCCD works is under development.
[SCCD]セキュリティで保護されたチャネルのクレジット・デビット。アカウント情報への不正アクセスは、SSL / TLSなどのセキュアチャネル・トランスポート・メカニズムを使用して防止しているクレジットカードまたはデビットカードでの支払いを行う方法。 SCCDがどのように機能するかを記述したIOTPサプリメントが開発中です。
[SET] Secure Electronic Transaction Specification, Version 1.0, May 31, 1997. Supports credit and debit card payments using certificates at the Consumer and Merchant to help ensure authenticity. Download from: <http://www.setco.org>.
[SET]セキュアな電子取引仕様、バージョン1.0、5月31日、1997年には、信頼性を確保するため、消費者や商人で証明書を使用してクレジットカードやデビットカードでのお支払いをサポートします。 <http://www.setco.org>：からダウンロードしてください。
[SSL/TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[SSL / TLS]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[SHA1] [FIPS-180-1]"Secure Hash Standard", National Institute of Standards and Technology, US Department Of Commerce, April 1995. Also known as: 59 Fed Reg. 35317 (1994). See http://www.itl.nist.gov/div897/pubs/fip180-1.htm
[SHA1] [FIPS-180-1]としても知られ、アメリカ国立標準技術研究所、米国商務省、1995年4月「ハッシュ標準のSecure」：59連銀レッグを。 35317（1994）。 http://www.itl.nist.gov/div897/pubs/fip180-1.htmを参照してください。
[UTC] Universal Time Co-ordinated. A method of defining time absolutely relative to Greenwich Mean Time (GMT). Typically of the form: "CCYY-MM-DDTHH:MM:SS.sssZ+n" where the "+n" defines the number of hours from GMT. See ISO DIS8601.
[UTC]世界時コーディネート。グリニッジ標準時（GMT）に絶対相対時間を定義する方法。典型的には、フォームの "CCYY-MM-DDTHH：MM：SS.sssZ + N" "+ N" GMTから時間数を定義します。 ISO DIS8601を参照してください。
[UTF16] The Unicode Standard, Version 2.0. The Unicode Consortium, Reading, Massachusetts. See ISO/IEC 10646 1 Proposed Draft Amendment 1
[UTF16] Unicode規格、バージョン2.0。ユニコードコンソーシアム、読書、マサチューセッツ州。参照ISO / IEC 10646 1原案の修正1
[X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate)
[X.509] ITU勧告X.509 1993 |改正案1を含む1995年：ISO / IEC 9594から8証明書エクステンション（バージョン3の証明書）
[XML Recommendation for Namespaces in XML, World Wide Web Namespace] Consortium, 14 January 1999, "http://www.w3.org/TR/REC-xml-names"
[XMLでの名前空間のためのXML勧告、ワールド・ワイド・ウェブの名前空間]コンソーシアム、1999年1月14日、「http://www.w3.org/TR/REC-xml-names」
[XML] Extensible Mark Up Language. A W3C recommendation. See http://www.w3.org/TR/1998/REC-xml-19980210 for the 10 February 1998 version.
[XML]拡張マークアップ言語。 W3C勧告。 1998年2月10日版のためhttp://www.w3.org/TR/1998/REC-xml-19980210を参照してください。
The author of this document is:
本書の著者は次のようになります。
David Burdett Commerce One 4440 Rosewood Drive, Bldg 4 Pleasanton California 94588 USA
デビッド・バーデットコマースワン4440ローズウッドドライブ、ビル4プレザントン、カリフォルニア94588 USA
Phone: +1 (925) 520 4422 EMail: david.burdett@commerceone.com
電話：+1（925）520 4422 Eメール：david.burdett@commerceone.com
The author of this document particularly wants to thank Mondex International Limited (www.mondex.com) for the tremendous support provided in the formative stages of the development of this specification.
本書の著者は、特に、この仕様の開発の発達段階に提供多大なサポートのためにモンデックス・インターナショナル・リミテッド（www.mondex.com）を感謝したいです。
In addition the author appreciates the following contributors to this protocol (in alphabetic order of company) without which it could not have been developed.
また、著者は、それが開発されていない可能性があるなしに（会社のアルファベット順）このプロトコルに以下の貢献を高く評価しています。
- Phillip Mullarkey, British Telecom plc
- フィリップMullarkey、ブリティッシュテレコムピーエルシー
- Andrew Marchewka, Canadian Imperial Bank of Commerce
- アンドリューMarchewka、コマースのカナディアン・インペリアル・バンク・オブ・
- Brian Boesch, CyberCash Inc.
- ブライアンBoesch、サイバーキャッシュ株式会社
- Tom Arnold, CyberSource
- トム・アーノルド、サイバーソース
- Terry Allen, Commerce One (formally Veo Systems)
- テリー・アレン、コマースワン（正式にVEOファイルシステム）
- Richard Brown, GlobeSet Inc.
- リチャード・ブラウン、GlobeSet株式会社
- Peter Chang, Hewlett Packard
- ピーター・チャン、ヒューレット・パッカード
- Masaaki Hiroya, Hitachi Ltd
- 正明博也、日立製作所
- Yoshiaki Kawatsura, Hitachi Ltd
ー よしあき かわつら、 ひたち Ｌｔｄ
- Mark Linehan, International Business Machines
- マーク・Linehan、インターナショナル・ビジネス・マシーンズ
- Jonathan Sowler, JCP Computer Services Ltd
- ジョナサンSowler、JCPコンピュータサービス株式会社
- John Wankmueller, MasterCard International
- ジョンWankmueller、マスターカード・インターナショナル
- Steve Fabes, Mondex International Ltd
- スティーブFabes、モンデックス・インターナショナル株式会社
- Donald Eastlake 3rd, Motorola Inc (formerly International Business Machines Inc)
- ドナルドイーストレイク3日、モトローラ社（旧インターナショナル・ビジネス・マシーンズ社）
- Surendra Reddy, Oracle Corporation
- スレンドラレディ、オラクル・コーポレーション
- Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)
- 明弘中野、ぷらっとホーム株式会社（旧日立製作所）
- Chris Smith, Royal Bank of Canada
- クリス・スミス、カナダのロイヤルバンク
- Hans Bernhard-Beykirch, SIZ (IT Development and Coordination
- ハンス・ベルンハルト・Beykirch、SIZ（IT開発と調整
Centre of the German Savings Banks Organisation)
ドイツの貯蓄銀行組織のセンター）
- W. Reid Carlisle, Spyrus (ex Citibank Universal Card Services, formally AT&T Universal Card Services)
- W.リードカーライル、Spyrus（元シティバンクユニバーサル・カードサービス、正式にAT＆Tユニバーサルカードサービス）
- Efrem Lipkin, Sun Microsystems
- エフレムLipkin、サン・マイクロシステムズ
- Tony Lewis, Visa International
- トニー・ルイス、ビザ・インターナショナル
The author would also like to thank the following organisations for their support:
著者はまた、彼らのサポートのために、以下の組織に感謝したいと思います：
- Amino Communications
- アミノコミュニケーションズ
- DigiCash
- デジキャッシュ
- Fujitsu
ー ふじつ
- General Information Systems
- 一般的な情報システム
- Globe Id Software
- グローブイドソフトウェア
- Hyperion
- ハイペリオン
- InterTrader
- InterTrader
- Nobil I T Corp
- ノーブルI T社
- Mercantec
- Mercantec
- Netscape
- ネットスケープ
- Nippon Telegraph and Telephone Corporation
- 日本電信電話株式会社
- Oracle Corporation
- オラクル・コーポレーション
- Smart Card Integrations Ltd.
- スマートカードの統合（株）
- Spyrus
- Spyrus
- Verifone
- Verifone
- Unisource nv
- Unisource NV
- Wells Fargo Bank
- ウェルズ・ファーゴ銀行
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。