[要約] RFC 2801は、IOTPバージョン1.0に関する仕様書であり、インターネット上での取引プロトコルを定義しています。その目的は、安全で信頼性の高いオンライン取引を実現することです。
Network Working Group D. Burdett
Request for Comments: 2801 Commerce One
Category: Informational April 2000
Internet Open Trading Protocol - IOTP Version 1.0
インターネットオープントレーディングプロトコル-IOTPバージョン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.
Copyright（c）The Internet Society（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）は、インターネットコマースの相互運用可能なフレームワークを提供します。これは、支払いシステムが独立しており、セット、セキュアチャンネルクレジット/デビット、モンデックス、サイバーコイン、ゲルドカルテなどの支払いシステムをカプセル化します。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
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、Mondex、Cybercash、Digicash、Geldkarteなどの支払いシステムをカプセル化しています。IOTPは、ショッピングサイト、支払いハンドラー、商品やサービスの配送ハンドラーなどの商人の役割を扱うことができます。また、カスタマーサポートのプロバイダーは、さまざまな関係者または1つの当事者によって実行されます。
The developers of IOTP seek to provide a virtual capability that safely replicates the real world, the paper based, traditional, understood, accepted methods of trading, buying, selling, value exchanging that has existed for many hundreds of years. The negotiation of who will be the parties to the trade, how it will be conducted, the presentment of an offer, the method of payment, the provision of a payment receipt, the delivery of goods and the receipt of goods. These are events that are taken for granted in the course of real world trade. IOTP has been produced to provide the same for the virtual world, and to prepare and provide for the introduction of new models of trading made possible by the expanding presence of the virtual world.
IOTPの開発者は、何百年もの間存在してきた取引、購入、販売、価値交換の紙に基づいた、伝統的、理解された、受け入れられた方法を安全に複製する仮想機能を提供しようとしています。誰が貿易の当事者になるか、それがどのように実施されるか、オファーの提示、支払い方法、支払い領収書の提供、商品の配達、商品の領収書の交渉。これらは、現実世界貿易の過程で当たり前のことと考えられているイベントです。IOTPは、仮想世界に同じものを提供し、仮想世界の拡大する存在によって可能になった新しい取引モデルの導入を準備し、提供するために生産されています。
The other fundamental ideal of the IOTP effort is to produce a definition of these trading events in such a way that no matter where produced, two unfamiliar parties using electronic commerce capabilities to buy and sell that conform to the IOTP specifications will be able to complete the business safely and successfully.
IOTPの取り組みのもう1つの基本的な理想は、これらの取引イベントの定義を作成した場所に関係なく、電子商取引能力を使用してIOTP仕様に準拠して販売する2つの馴染みのない当事者が、IOTP仕様に準拠することができるようにすることです。安全かつ成功裏にビジネス。
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が懸念している非常に根本的な変化の1つは、消費者と商人が取引する方法で行われることです。著しく変更された取引の特性は次のとおりです。
o Presence: Face-to-face transactions become the exception, not the rule. Already with the rise of mail order and telephone order placement this change has been felt in western commerce. Electronic commerce over the Internet will further expand the scope and volume of transactions conducted without ever seeing the people who are a part of the enterprise with whom one does business.
o 存在：対面トランザクションは、ルールではなく例外になります。すでに通信販売と電話の注文の配置が増加しているため、この変更は西部の商業で感じられています。インターネット上の電子商取引は、ビジネスをしている企業の一部である人々を見ることなく、実施される取引の範囲と量をさらに拡大します。
o Authentication: An important part of personal presence is the ability of the parties to use familiar objects and dialogue to confirm they are who they claim to be. The seller displays one or several well known financial logos that declaim his ability to accept widely used credit and debit instruments in the payment part of a purchase. The buyer brings government or financial institution identification that assures the seller she will be paid. People use intangibles such as personal appearance and conduct, location of the store, apparent quality and familiarity with brands of merchandise, and a good clear look in the eye to reinforce formal means of authentication.
o 認証：個人的な存在の重要な部分は、当事者が馴染みのあるオブジェクトと対話を使用して、彼らが誰であるかを確認する能力です。売り手は、購入の支払い部分で広く使用されているクレジットおよびデビット手段を受け入れる能力を宣言する、1つまたはいくつかの有名な財務ロゴを表示します。買い手は、売り手に支払われることを保証する政府または金融機関の識別をもたらします。人々は、個人的な外観や行動、店舗の場所、商品のブランドに見かけの品質と精通などの無形資産を使用し、正式な認証手段を強化するための目の明確な外観を使用します。
o Payment Instruments: Despite the enormous size of bank card financial payments associations and their members, most of the world's trade still takes place using the coin of the realm or barter. The present infrastructure of the payments business cannot economically support low value transactions and could not survive under the consequent volumes of transactions if it did accept low value transactions.
o 支払い手段：銀行カードの金融支払い協会とそのメンバーの膨大な規模にもかかわらず、世界の貿易のほとんどは、領域または物々交換のコインを使用して依然として行われています。支払い事業の現在のインフラストラクチャは、低価格取引を経済的にサポートすることはできず、低価値トランザクションを受け入れた場合、結果として生存することはできません。
o Transaction Values: New meaning for low value transactions arises in the Internet where sellers may wish to offer for example, pages of information for fractions of currency that do not exist in the real world.
o トランザクション値：低価値のトランザクションの新しい意味は、販売者が現実世界に存在しない通貨分数の情報のページを提供することを望むインターネットで発生します。
o Delivery: New modes of delivery must be accommodated such as direct electronic delivery. The means by which receipt is confirmed and the execution of payment change dramatically where the goods or services have extremely low delivery cost but may in fact have very high value. Or, maybe the value is not high, but once delivery occurs the value is irretrievably delivered so payment must be final and non-refundable but delivery nonetheless must still be confirmed before payment. Incremental delivery such as listening or viewing time or playing time are other models that operate somewhat differently in the virtual world.
o 配信：直接電子配信など、新しい配達モードに対応する必要があります。領収書が確認された手段と、商品やサービスの配送コストが非常に低いが、実際には非常に高い価値がある場合がある場合、支払いの実行が劇的に変更されます。または、値が高くないかもしれませんが、配送が発生すると、値は取り返しのつかないほど配信されるため、支払いは最終的かつ返金不可でなければなりませんが、それでも配達は支払い前にまだ確認する必要があります。リスニングや視聴時間、プレイ時間などの増分配信は、仮想世界で多少異なる動作をする他のモデルです。
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.
この期間中、この仕様の範囲に変更がないことが予想されます。これは、問題が見つかった補正に限定される唯一の変更だけであると予想されます。ソフトウェアソリューションは、この仕様の以前のバージョン（たとえば、1998年初頭に公開されたバージョン0.9および1999年に公開されたバージョン1.0の以前の改訂版）に基づいて開発されており、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.
このプロトコルは、支払人から受取人への電子価値の移動が1つだけではあるが重要な多くのステップが取引を完了するために関与する可能性のある多くのステップである完全な購入プロセスを対象とするため、あらゆる電子支払いスキームに適用できるように設計されています。
Payment Scheme which IOTP could support include MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton, etc.
IOTPがサポートできる支払いスキームには、MasterCardクレジット、Visa Credit、Mondex Cash、Visa Cash、Geldkarte、Ecash、Cybercoin、Millicent、Protonなどが含まれます。
Each payment scheme contains some message flows which are specific to that scheme. These scheme-specific parts of the protocol are contained in a set of payment scheme supplements to this specification.
各支払いスキームには、そのスキームに固有のメッセージフローが含まれています。プロトコルのこれらのスキーム固有の部分は、この仕様の一連の支払いスキームサプリメントに含まれています。
The document does not prescribe the software and processes that will need to be implemented by each participant. It does describe the framework necessary for trading to take place.
このドキュメントは、各参加者が実装する必要があるソフトウェアとプロセスを規定していません。取引が行われるために必要なフレームワークを説明しています。
This document also does not address any legal or regulatory issues surrounding the implementation of the protocol or the information systems which use them.
また、このドキュメントは、プロトコルまたはそれらを使用する情報システムの実装を取り巻く法的または規制上の問題にも対処していません。
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-セキュリティ上の考慮事項：このセクションでは、IETFの観点から、IOTPがセキュリティに対処する方法から考慮します。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 Section 5 - Security Considerations
o セクション4 -IOTPエラー処理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 認証。これは、ある組織または個人が、別の組織または個人が誰であるかを確認するためにサポートします。
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。これにより、1つのIOTP認識アプリケーションが他の場所で実行されている別のIOTPアプリケーションが機能しているかどうかを判断できる簡単なクエリがサポートされます。
These IOTP Transactions are "Baseline" transactions since they have been identified as a minimum useful set of transactions. Later versions of IOTP may include additional types of transactions.
これらのIOTPトランザクションは、最小限の有用なトランザクションセットとして特定されているため、「ベースライン」トランザクションです。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
o 最も簡単な場合、1つの物理的な組織（例：商人）は、購入を処理し、支払いを受け入れ、商品を配達し、商人のカスタマーケアを提供できます。
o at the other extreme, a merchant could handle the purchase but instruct the consumer to pay a bank or financial institution, request that delivery be made by an overnight courier firm and to contact an organisation which provides 24x7 service if problems arise.
o もう一方の極端な場合、商人は購入を処理することができますが、消費者に銀行または金融機関に支払うように指示し、一晩の宅配会社が配達を行うことを要求し、問題が発生した場合に24時間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バリューエクスチェンジトランザクションは、オファー取引交換と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.
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.
o [HTML]ページを消費者の「ショッピングエクスペリエンス」の一部として使用します。
o Using the Open Profiling Standard [OPS] which has recently been proposed,
o 最近提案されたオープンプロファイリング標準[OPS]を使用して、
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.
o IOTPの後のバージョンの注文コンポーネントとして。
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.
C --> M Information on what is being paid for (outside scope of IOTP
c-> mの支払額に関する情報（IOTPの外部範囲
2. Merchant decides which payment brand, payment protocols and currencies/amounts to offer, places then in a Brand List Component and sends them to the Consumer
2. Merchantは、提供する支払いブランド、支払いプロトコル、通貨/金額を決定し、その後、ブランドリストコンポーネントで場所を決定し、消費者に送信します
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
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. 支払いハンドラーは、オプションの署名を含む情報をチェックします。
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.
o ブランドリストコンポーネントには、支払いブランドのリスト（MasterCard、Visa、Mondex、Geldkarteなど）、支払いプロトコル（たとえば、バージョン1.0のセット、Secure Channelクレジットデビット（SCCD-クレジットカードまたはデビットカードの支払いに使用される名前）が含まれています。アカウント情報への不正アクセスは、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 ブランド選択コンポーネントには、消費者の選択が含まれています。支払いブランド、プロトコル、通貨/金額、および場合によってはプロトコル固有の情報が商人に送り返されます。この情報は、オファー交換の情報を変更するために使用できます。たとえば、商人は、ストアカードの使用を促進するために割引を提供することを選択できます。
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 支払いコンポーネントには、支払額、通貨、支払いの方向の詳細が含まれています
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 Scheme Component is defined in the supplements that describe how IOTP works with various payment protocols.
o 支払いスキームコンポーネントには、取引で使用される支払いプロトコルからのメッセージが含まれています。たとえば、メッセージ、Mondexメッセージ、Geldkarteメッセージ、またはIOTPがサポートする他の支払い方法の1つにすることができます。支払いスキームコンポーネントのコンテンツは、IOTPがさまざまな支払いプロトコルでどのように機能するかを説明するサプリメントで定義されています。
o The Payment Receipt Component contains a record of the payment. The content depends upon the payment protocol used.
o 支払い領収書コンポーネントには、支払いの記録が含まれています。コンテンツは、使用される支払いプロトコルに依存します。
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.
配達交換の目標は、購入した商品をオンラインまたは物理的配送のいずれかで消費者に配送することです。2番目の目標は、消費者に「配送」を提供し、配送追跡番号などの配送に関する詳細を提供することです。配達の結果は、物理的な配信の問題の場合にカスタマーケアに使用できるように署名することもできます。メッセージフローを以下の図に示します。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
CONSUMER DELIVERY
| HANDLER
| Merchant |
STEP | | |
1. Consumer decides to trade and sends information
about what to deliver and who is to take delivery,
to the Merchant e.g., using HTML.
C --> M Information on what is being delivered (outside scope of IOTP)
c-> m配信されているものに関する情報（IOTPの外側の範囲）
2. Merchant checks the information provided by the Consumer, adds information about how the delivery will occur, information about the Organisations involved in the delivery and optionally sings it and sends it to the Consumer
2. マーチャントは、消費者から提供された情報をチェックし、配達の発生方法に関する情報、配達に関与する組織に関する情報を追加し、オプションでそれを歌い、消費者に送信します
C <-- M Components: Delivery; Organisations (Delivery Handler, Deliver To); Order, Optional Offer Response Signature
C <-Mコンポーネント：配信;組織（配信ハンドラー、配信）;注文、オプションのオファー応答署名
3. Consumer checks delivery information is OK, obtains authorisation for the delivery, for example by making a payment, and sends the delivery information to the Delivery Handler
3. 消費者のチェック配達情報は問題ありません。たとえば、支払いを行うことで配達の許可を取得し、配達情報を配達ハンドラーに送信します
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. 配達ハンドラーは情報と承認をチェックします。配達を開始またはスケジュールして、オプションで署名できる消費者をトットするのではなく、配送を作成し、送信します。
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. 消費者のチェック配信ノートは問題なく、配達紙幣に記載されているように配達を受け入れるか待ちます。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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 ステータスコンポーネントは、以前の交換（たとえば、オファー交換や支払い交換）が正常に完了し、配達ハンドラーが配送交換の完了ステータスを示すことを配達ハンドラーに示すために使用されます。
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 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. 2番目の組織は、チャレンジデータ、および認証に使用される可能性のあるアルゴリズムのリストを含む認証要求を生成します。
1 <-- 2 AUTHENTICATION REQUEST. Components: Authentication Request, Trading Role Information Request
1 <-2認証リクエスト。コンポーネント：認証要求、トレーディングロール情報リクエスト
3. The first Organisation optionally checks any signature associated with the Authentication Request then uses the specified authentication algorithm to generate an Authentication Response which is sent back to the second Organisation together with details of any Organisation information requested
3. 最初の組織はオプションで認証要求に関連付けられた署名をチェックし、指定された認証アルゴリズムを使用して、要求された任意の組織情報の詳細とともに2番目の組織に送り返される認証応答を生成します
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.
5. 最初の組織は、オプションで、ステータスと関連する署名で示された結果をチェックし、適切なアクションまたは停止を実行します。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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:
3つのタイプを持つことができる支払いハンドラー：
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 Store価値価値消費者支払い配送発行者取得者ハンドラーハンドラー
TRANSACTIONS
トランザクション
Purchase Must Must
購入する必要があります
Merchants
商人
ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler
Ecash Ecash Store価値価値消費者支払い配送発行者取得者ハンドラーハンドラー
Refund Must b)
Depends
Authentication May Must May b) Depends
認証はb）依存する場合があります
Value Exchange May Must
価値交換はしなければなりません
Withdrawal Must b)
Depends
Deposit Must b) Depends
預金はb）依存する必要があります
Inquiry Must Must Must May Must Must
照会はしなければならないかもしれない
Ping Must Must Must May Must Must
pingはしなければならないかもしれません
TRADING BLOCKS
トレーディングブロック
TPO Must Must Must Must
TPOはしなければならない必要があります
TPO Selection Must Must Must Must
TPOの選択は、しなければならない必要があります
Auth-Request a) a) a) Depends Depends Depends
auth-request a）a）a）依存
Auth-Reply a) a) a) Depends Depends Depends
auth-reply a）a）a）依存
Offer Response Must Must Must MustPayment 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 Store価値価値消費者支払い配送発行者取得者ハンドラーハンドラー
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 request must必要しなければならない必要があります
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 「5月」とは、実装が開発者のオプションでトランザクションまたは取引ブロックをサポートする可能性があることを意味します。
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ソリューションは、上記のテーブルに記載されているように、少なくとも1つの役割（列）で必要なすべての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
o トランザクションリファレンスブロックを含むIOTPメッセージのXML定義 - IOTPトランザクションとその中のIOTPメッセージを識別するXML要素
o the definitions of the XML ID Attributes which are used to identify IOTP Messages, Trading Blocks and Trading Components and how these are referred to using Element References from other XML elements
o IOTPメッセージ、トレーディングブロック、取引コンポーネントを識別するために使用されるXML ID属性の定義と、これらが他のXML要素からの要素参照を使用する方法とどのように参照されるか
o how extra XML Elements and new user defined values for existing IOTP codes can be used when Extending IOTP,
o IOTPを拡張するときに、既存のIOTPコードの追加のXML要素と新しいユーザー定義値をどのように使用できるか、
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 認証。これは、さまざまな認証アルゴリズムを使用した別の取引役割によるある取引役割のリモート認証と、たとえばオファーの作成で使用されるために認証されている取引役割に関する組織情報の提供をサポートします。
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これは、1つのIOTP認識アプリケーションが他の場所で実行されている別の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'
<！要素IoTPMessage（transRefblk、sigblk？、errorblk？、（authreqblk | authrespblk | authstatusblk | cancelblk | dexilerreqblk | inquiryreqblk | inquiryrespblk | offerrespblk | bayexchblk | payreqblk | payreqspblk | payrecblk | pingrecblk k）*）> <！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これには、IOTPトランザクション内のIOTPメッセージを説明する情報が含まれています（すぐ下のセクション3.3を参照）
AuthReqBlk, These are the Trading Blocks. AuthRespBlk, DeliveryReqBlk, The Trading Blocks present within an IOTP Message, DeliveryRespBlk and the content of a Trading Block itself is ErrorBlk dependent on the type of IOTP Transaction being InquiryReqBlk, carried out - see the definition of each InquiryRespBlk, transaction in section 9 Internet Open Trading OfferRespBlk, Protocol Transactions. PayExchBlk, PayReqBlk, Full definitions of each Trading Block are PayRespBlk, described in section 8. PingReqBlk, PingRespBlk, SigBlk, TpoBlk, TpoSelectionBlk
authreqblk、これらは取引ブロックです。authRespblk、DeliveryReqblk、IOTPメッセージ内に存在する取引ブロック、DeliveryRespblk、およびトレーディングブロック自体のコンテンツは、実行されるInquiryRespblkの定義を参照してください。Trading operersERSPBLK、プロトコルトランザクション。Payexchblk、payreqblk、各取引ブロックの完全な定義は、セクション8で説明されています。
Attributes:
属性：
xmlns The [XML Namespace] definition for IOTP messages.
XMLNS IOTPメッセージの[XML NameSpace]定義。
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ドキュメントPrologが先行する必要があります。例えば：
<?XML Version='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,
o IOTPトランザクションをグローバルに一意に識別するトランザクションIDコンポーネント。トランザクション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
o IOTPメッセージに関する制御情報を提供し、IOTPトランザクション内のIOTPメッセージを一意に識別するメッセージIDコンポーネントと
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 >
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.
TransID 3.3.1トランザクションIDコンポーネントのすぐ下を参照してください。
MsgId See 3.3.2 Message Id Component immediately below.
MSGID 3.3.2メッセージIDコンポーネントを参照してください。
RelatedTo See 3.3.3 Related To Component immediately below.
関連するには、下のコンポーネントに関連する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 >
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
Values of IotpTransType are managed under the procedure described in section 12 IANA Considerations which also allows user defined values of IotpTransType to be defined.
IOTPTRANSTYPEの値は、IOTPTRANSTYPEのユーザー定義値を定義できるセクション12 IANAの考慮事項で説明した手順で管理されます。
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 >
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.
ID IOTPトランザクション内のIOTPメッセージを一意に識別する識別子（セクション3.4 ID属性を参照）。IOTPメッセージがresしている場合、この属性の値は同じままであることに注意してください。
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.
sendertradingroleref IoTPメッセージを生成した取引役割の要素参照（セクション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：Langは、XML：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.
charsetpreflist [xml]文字に準拠した文字セット識別子のオプションリスト。送信者は、優先シーケンスで、応答を生成するときにメッセージの受信者が理想的に使用する必要があることを設定するために、送信者によって使用されます。指定された文字セットのいずれかを使用して応答する義務はありませんが、文字セットのいずれかを使用すると、ユーザーエクスペリエンスが向上する可能性があります。
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
SoftworyIDこれには、IOTPメッセージを生成したソフトウェアを識別する情報が含まれています。その目的は、異なるソフトウェアによって生成されたメッセージ間の非互換性の結果として発生する可能性のある相互運用性の問題を解決するのを支援することです。XML：Langで定義された言語の単一のテキスト文字列です。最小限に、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 >
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：langは、XML：lang属性によって子要素の属性によって上書きされない限り、このコンポーネント内の属性または子要素によって使用される言語を定義します。セクション3.8の識別言語を参照してください。
RelationshipType Defines the type of the relationship. Valid values are:
RelationtsTypeは、関係のタイプを定義します。有効な値は次のとおりです。
o IotpTransaction. in which case the Packaged Content Element contains an IotpTransId of another IOTP Transaction o Reference in which case the Packaged Content Element contains the reference of some other, non-IOTP document.
o IoTpTransaction。この場合、パッケージ化されたコンテンツ要素には、別のIOTPトランザクションo参照のIoTPTransidが含まれています。この場合、パッケージ化されたコンテンツ要素には、他の非OTIOTPドキュメントの参照が含まれています。
Values of RelationshipType are controlled under the procedures defined in section 12 IANA Considerations which also allows user defined values to be defined.
関係タイプの値は、ユーザー定義の値を定義できるセクション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.
関係関係属性には、XML：Langで定義された言語のフレーズが含まれています。これは、このコンポーネントと別のIOTPトランザクションまたはその他のイベントを含むIOTPトランザクションの関係の性質を説明しています。使用する正確な単語は、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.
属性の目的は、取引間の関係の性質の説明を受けて、IOTPトランザクションに関与する取引の役割を提供することです。
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を参照）には、関連するトランザクションを識別するデータが含まれています。その形式は、関係タイプの値によって異なります。
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要素。これらの識別子は、1つの要素を別の要素で参照できるように使用されます。これらのすべての属性には、属性名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属性の値は、IOTPトランザクション、つまり同じグローバルに一意のトランザクションIDコンポーネントを持つ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).
その結果、これらのIDを使用して、要素参照を使用して同じIOTPトランザクションの他のIOTPメッセージ、ブロック、またはコンポーネントからIOTPメッセージ、ブロック、またはコンポーネントのコンテンツを参照して見つけることができます（セクション3.5を参照）。
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
o 「M」 - 商人O "C" - 消費者
For messages which contain an Inquiry Request Trading Block or a Ping Request Trading Block, the prefix is set to "I" for Inquiry.
お問い合わせ要求トレーディングブロックまたは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
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
o 取引ロールによって送信された最初のIOTPメッセージには、接尾辞 "1"が与えられますo同じ取引ロールによって送信された2番目と後続のIoTPメッセージは、各メッセージに対して1つによって増分されますoサフィックスには先頭のゼロは含まれていません
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」、2番目の「C2」、3番目の「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.
IoTPMSGID_VALUEブロックまたはコンポーネントが最初に使用されるIOTPメッセージのメッセージIDコンポーネントのID属性。
In IOTP, Trading Components and Trading Blocks are copied from one IOTP Message to another. The ID attribute does not change when an existing Trading Block or Component is copied to another IOTP Message.
IOTPでは、取引コンポーネントとトレーディングブロックが1つのIOTPメッセージから別のメッセージにコピーされます。ID属性は、既存の取引ブロックまたはコンポーネントが別のIOTPメッセージにコピーされた場合、変更されません。
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
o 取引ロールによって送信された最初のブロックまたはコンポーネントには、suffix "1"が与えられますo 2番目と後続のブロックまたはコンポーネントのID属性は、IoTPメッセージに追加された新しいブロックまたはコンポーネントごとに1つずつ増加しますoリーディングゼロは含まれません接尾辞で
Put more simply, the first new Block or Component added to the second IOTP Message sent, for example, by a consumer would have a an ID attribute of "C2.1", the second "C2.2", the third "C2.3" etc.
より簡単に言えば、最初の新しいブロックまたはコンポーネントは、たとえば、消費者が送信した2番目のIOTPメッセージに追加され、「C2.1」、2番目の「C2.2」、3番目の「C2」のID属性があります。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
図8 ID属性の使用例
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,
o ダイジェストが署名コンポーネントに含まれているXML要素を識別する、
o referring to the Payment Handler Organisation Component which is used when making a Payment
o 支払いを行うときに使用される支払いハンドラー組織コンポーネントを参照する
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トランザクション（つまり、IOTPメッセージのトランザクションIDコンポーネント）に属し、
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のベースラインと将来のバージョンは、2つのメカニズムを介してIOTPへのユーザー拡張機能をサポートします。
o new values for existing IOTP codes.
o 既存のIOTPコードの新しい値。
The XML element and attribute names used within IOTP constitute an [XML Namespace] as identified by the xmlns attribute on the IotpMessage element. This allows IOTP to support the inclusion of additional XML elements within IOTP messages through the use of [XML Namespaces].
IOTP内で使用されるXML要素と属性名は、IOTPMESSAGE要素のXMLNS属性によって識別されるように[XML名前空間]を構成します。これにより、IOTPは[XMLネームスペース]を使用してIOTPメッセージ内に追加のXML要素を含めることをサポートできます。
Using XML Namespaces, extra XML elements may be included at any level within an IOTP message including:
XMLネームスペースを使用して、以下を含むIOTPメッセージ内の任意のレベルで追加のXML要素を含めることができます。
o new Trading Blocks
o 新しいトレーディングブロック
o new Trading Components
o 新しい取引コンポーネント
o new XML elements within a Trading Component.
o 取引コンポーネント内の新しいXML要素。
The following rules apply:
次のルールが適用されます。
o any new XML element must be declared according to the rules for [XML Namespaces]
o [XMLネームスペース]のルールに従って、新しいXML要素を宣言する必要があります
o new XML elements which are either Trading Blocks or Trading Components must contain an ID attributes with an attribute name of ID.
o トレーディングブロックまたはトレーディングコンポーネントである新しいXML要素には、IDの属性名を持つID属性を含める必要があります。
In order to make sure that extra XML elements can be processed properly, IOTP reserves the use of a special attribute, IOTP:Critical, which takes the values True or False and may appear in extra elements added to an IOTP message.
余分なXML要素を適切に処理できるようにするために、IOTPは、値をtrueまたはfalseとし、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.
o 追加のXML要素に「true」の値を持つ「IOTP：クリティカル」属性があり、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:
o 余分なXML要素に「false」の値を持つ「IOTP：クリティカル」属性がある場合、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要素内に含まれる追加のXML要素は、IOTP XML要素がIOTPで使用またはコピーされる場合はいつでも、その要素に含める必要があります
- the content of the extra element must be ignored except that it must be included when it is used in the creation of a digest as part of the generation of a signature
- 余分な要素の内容は、署名の生成の一部としてダイジェストの作成に使用されるときに含める必要があることを除いて、無視する必要があります
o if an extra XML element has no "IOTP:Critical" attribute then it must be treated as if it had an "IOTP:Critical" attribute with a value of "True"
o 余分なXML要素に「IOTP：critical」属性がない場合、「true」の値を持つ「IoTP：クリティカル」属性があるかのように扱わなければなりません。
o if an XML element contains an "IOTP:Critical" attribute, then the value of that attribute is assumed to apply to all the child elements within that element
o XML要素に「IOTP：critical」属性が含まれている場合、その属性の値は、その要素内のすべての子要素に適用されると想定されます
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：critical」を含むドキュメントが有効であることを確認するために、それは次のように余分な要素のDTDの一部として宣言されます。
IOTP:Critical (True | False ) 'True'
IOTP：批判的（true | false） 'true'
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,
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" >
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>
The name attribute may be omitted, for example if there is only one Packaged Content element.
たとえば、パッケージ化されたコンテンツ要素が1つしかない場合、名前属性は省略できます。
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.
コンテンツこれは、パッケージ化されたコンテンツ要素のコンテンツ内に含まれるデータの種類を識別します。コンテンツ属性の有効な値は次のとおりです。OPCDATA。パッケージ化されたコンテンツ要素のコンテンツは、それ以上の処理なしでPCDATAとして扱うことができます。o mime。パッケージ化されたコンテンツ要素のコンテンツは、完全なmimeアイテムです。処理には、パッケージ化されたコンテンツ要素内のMIMEヘッダーを探すことを含める必要があります。O Mime：MimeType。パッケージ化されたコンテンツ要素のコンテンツはMIMEコンテンツで、次のヘッダー「コンテンツタイプ：MIMETYPE」があります。MIME：MIMETYPEを使用してMIMETYPEを使用しないことは可能ですが、変換属性セットをbase64に設定する可能性がはるかに高くなります。変換に使用されない場合、コンテンツ全体が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.
o XML。パッケージ化されたコンテンツ要素のコンテンツは、XMLドキュメントとして扱うことができます。エンティティとCDATAセクション、またはBase64に設定された変換は、パッケージ化されたコンテンツ要素のコンテンツが正当な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.
o なし。パッケージ化されたコンテンツ要素のPCDATAコンテンツは、データの正しい表現です。データを調べる前に、エンティティの拡張が最初に行われなければならない（つまり、＆＃9;の交換）が必要であることに注意してください。CDATAセクションは、変換属性がなしに設定されているパッケージ化されたコンテンツ要素で合法的に発生する場合があります。o base64。パッケージ化されたコンテンツ要素のPCDATAコンテンツは、実際のコンテンツのbase64エンコードを表します。
Content:
コンテンツ：
PCDATA This is the actual data which has been embedded. The format of the data and rules on how to decode it are contained in the Content and the Transform attributes
PCDATAこれは、埋め込まれた実際のデータです。データの形式とそれをデコードする方法に関するルールは、コンテンツと変換属性に含まれています
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
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 以前の要件を満たすために複数のパッケージ化されたコンテンツ要素が親要素に含まれている場合、他のすべてのパッケージ要素への参照を決定できるトップレベルのパッケージコンテンツの名前属性は、メインの値を持つ必要があります
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 あるパッケージ化されたコンテンツ要素から別のパッケージ化されたコンテンツ要素への他のドキュメント、画像などへの相対的な参照は、同じレベルおよび同じ親要素内で別のパッケージ化されたコンテンツ要素の名前属性に対する相対参照の値を設定することにより実現されます。
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コンソーシアムの最新の推奨事項に従う必要があります。
Note: At the time of writing this specification, standards are under development that specify XML style sheets that show how XML documents should be displayed. See:
注：この仕様を書く時点では、XMLドキュメントの表示方法を示すXMLスタイルシートを指定する標準が開発中です。見る：
o "Extensible Stylesheet Language (XSL) Specification" at http://www.w3.org/TR/WD-xsl, and
o http://www.w3.org/tr/wd-xsl、および「拡張可能なStyleSheet Language（XSL）仕様」および
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は[XML]言語識別を使用して、IOTPメッセージのコンテンツと属性内で使用される言語を指定します。
The following principles have been used in order to determine which XML elements contain an xml:lang Attributes:
どのXML要素がXMLを含むかを決定するために、次の原則が使用されています。
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を参照）。このようなメッセージの受信者に、リストされている言語/文字セットのいずれかを使用して応答する義務はないことに注意してください。また、これらのリストを処理する能力は、この仕様に準拠するための要件ではないことを意味します。ただし、たとえば、指定された言語/文字セットの1つを使用するなど、応答する機能は、より良いユーザーエクスペリエンスを提供する可能性があります。
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トランザクションがキャンセルされた場合（つまり、「リクエスト」ブロックの送信とマッチング「応答」ブロックの受信との間の間隔）、キャンセルブロックは、取引取引所の次の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ブロック（セクション8.1を参照）に含まれるプロトコルオプションコンポーネント（セクション7.1を参照）に含まれるsenderenetlocnまたはsecureSenderenetlocnによって識別された場所。これは通常、商人取引の役割です。
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トランザクションをキャンセルした後、消費者は、キャンセルブロックが送信された組織の取引ロール要素に含まれる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.
キャンセルブロックが非消費者の役割によって受信された場合、取引の役割は、消費者が取引ロールの取引役割要素に含まれる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.
通信が十分に動作している場合、技術的エラーは、エラーコンポーネント（セクション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からの「宛先へのルートなし」エラーなど、明示的な輸送レベルエラーの表示、またはリクエストへの応答が受け取られていないタイムアウトのいずれかによって示されます。
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を参照）で示されます。エラーコンポーネントには、エラーが警告であり、無視される可能性があるかどうかを示す重大度属性、再試行が問題を解決するか、その場合はトランザクションが失敗する必要があることを示すトランジェエラーが含まれます。
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 トランザクション参照ブロック（セクション3.3を参照）および署名ブロックのみのブロックレベルの技術エラー（セクション4.3.3を参照）。これらのブロックのチェックは、XMLが有効である場合にのみ実行する必要があります
Note that checks on the Signature Block include checking, where possible, that each Signature Component is correctly calculated. If the Signature is incorrectly calculated then the data that should have been covered by the signature can not be trusted and must be treated as erroneous. A description of how to check a signature is correctly calculated is contained in section 6.2.
署名ブロックのチェックには、可能であれば、各署名コンポーネントが正しく計算されることを確認することに注意してください。署名が誤って計算されている場合、署名によってカバーされるべきデータは信頼できず、誤ったものとして扱わなければなりません。署名を確認する方法の説明は、セクション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つの問題を示します（トランザクション参照または署名ブロックを除く）。メッセージは適切に輸送されており、メッセージ構造全体とトランザクションの参照ブロックと署名ブロックを含むブロック/コンポーネントは意味がありますが、他のブロックの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 If a technical error occurs related to a block or component, then an Error Component is generated for return.
o 一時的な技術エラーブロックまたはコンポーネントに関連する技術エラーが発生した場合、リターンのためにエラーコンポーネントが生成されます。
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.
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
o IOTPメッセージに存在するブロックおよび/またはコンポーネントの組み合わせが、このIOTP仕様に含まれるルールと一致することを確認する
o checking for consistency between attributes and element content within the blocks within the same IOTP message.
o 同じIOTPメッセージ内のブロック内の属性と要素コンテンツ間の一貫性を確認します。
o checking for consistency between attributes and elements in blocks in this IOTP message and blocks received in earlier IOTP messages for the same IOTP transaction
o このIOTPメッセージと同じIOTPトランザクションの以前のIOTPメッセージで受信したブロック内の属性と要素間の一貫性を確認する
If the block passes the "Block Level Attribute and Element Checks" and the "Block and Component Consistency Checks" then it is processed either by the IOTP Aware application or perhaps by some "back-end" system such as a payment server.
ブロックが「ブロックレベルの属性と要素チェック」と「ブロックとコンポーネントの一貫性チェック」を渡す場合、IOTP認識アプリケーションまたはおそらく支払いサーバーなどの「バックエンド」システムによって処理されます。
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).
ブロックの処理中に、少し後で送信した他の取引役割によって回復する可能性のある一時的な障害が発生する可能性があります。この場合、他の役割には、過渡エラーがトランジェントエラーに設定された重大度属性を使用してエラーコンポーネント（セクション7.21を参照）を送信し、MinretrySecs属性を使用している輸送メカニズムおよび/または支払いプロトコルに適した価値に設定することにより通知されます。（適切な輸送および支払いプロトコルサプリメントを参照）。
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.
支払いや配達などのプロセスでビジネスエラーが発生した場合、適切なタイプの応答ブロックが返されます。ステータスコンポーネント（セクション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.
「一時的な」ビジネスエラーからの回復は、完了コードに依存します。可能なことについては、ステータスコンポーネントの定義を参照してください。
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.
IOTPメッセージは、実際には3.1.1 IOTPメッセージ構造で説明されているように、ブロックとコンポーネントの組み合わせです。特に、IOTPの将来の拡張では、このようなブロックとコンポーネントの豊富な種類の組み合わせが発生する可能性があります。状態を変更するアクションの「同じ」リクエストの複数の送信/受領が、そのアクションが複数回発生しないことが重要です。これはiDempotencyと呼ばれます。たとえば、注文の代金を支払う顧客は、一度だけ全額を支払う必要があります。ほとんどのネットワークトランスポートメカニズムには、メッセージを複数回配信するか、まったくない可能性があり、おそらく再送信が必要です。一方、ステータスのリクエストは合理的に繰り返される可能性があり、受信するたびに新鮮に処理する必要があります。
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) o an Authentication Transaction (see section 9.1.6)
o Pingトランザクション（セクション9.2.2を参照）o認証トランザクション（セクション9.1.6を参照）
o a Payment Related Transaction such as:
o 次のような支払い関連トランザクション：
- 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であり、IoTPメッセージ内のトランザクション識別子（TransIDコンポーネントのIoTpTransID属性）が、応答を生成するために必要になるため、正常に識別できることを確認することが重要です。
If the input message is not well formed then generate an Error Component with a Severity of HardError and ErrorCode of XmlNotWellFrmd.
入力メッセージが十分に形成されていない場合は、xmlnotwellfrmdのharderrorとエラーコードの重大度を持つエラーコンポーネントを生成します。
If the message is well formed but the IotpTransId cannot be identified then generate an ErrorComponent with:
メッセージが適切に形成されているが、IoTptransidを識別できない場合は、次のことを生成します。
o a Severity of HardError and an ErrorCode of AttMissing, o a PackagedContent containing "IotpTransId" - the missing attribute.
o harderrorの重大度とaTtmissingのエラーコード、o「IoTpTransid」を含むパッケージコンテンテント - 欠落属性。
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.
新しいTransactionIDコンポーネントを使用して、新しい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のエラーコードを持つエラーコンポーネントを生成して、メッセージが処理されていることを示し、適切な後に元のメッセージがresすることを要求する入力メッセージの送信者に送信します期間。
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のエラーコードを持つエラーコンポーネントを生成し、適切な期間後に元のメッセージがresすることを要求する入力メッセージの送信者に送信する必要があります。
Note: Some servers may occasionally become very busy due to unexpected increases in workload. This approach allows short peaks in workloads to be handled by delaying the input of messages by asking the sender of the message to resubmit later.
注：ワークロードの予期せぬ増加により、一部のサーバーが非常に忙しくなる場合があります。このアプローチにより、メッセージの送信者に後で再送信するように依頼することにより、メッセージの入力を遅らせることにより、ワークロードの短いピークを処理できます。
CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED
トランザクションの確認はまだ誤っていないか、キャンセルされていません
Check that:
それを確認します：
o previous messages received or sent did not contain or result in Hard Errors, and
o 受信または送信された以前のメッセージは、困難なエラーを封じ込めたり、結果としても発生したりしませんでした。
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:
トランザクションがまだ問題ない場合は、メッセージレベルエラーを確認してください。これには次のことが含まれます。
o checking the XML is valid
o XMLを確認することは有効です
o checking that the elements, attributes and content of the Transaction Reference Block are without error and conform to this specification
o トランザクション参照ブロックの要素、属性、およびコンテンツがエラーなしであり、この仕様に準拠していることを確認する
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 ...
注：簡潔さの理由で、ブロックシーケンスでエラーを確認する方法の次の説明は、「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ブロックと提供を提供する（1つのメッセージで）以前に送信された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:
o 支払い要求ブロック（支払いハンドラーのみ）。次のように確認してください：
- if the Payment Request Block refers to an IOTP Transaction that is not recognised then its OK, otherwise
- 支払い要求ブロックが認識されていない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:
o 支払い交換ブロック（支払いハンドラーのみ）。次のように確認してください：
- 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.
エラーコンポーネントが生成されている場合は、入力メッセージの送信者に送信するためのエラーブロックに収集します。エラーブロックは、指定されている場合は、送信者の取引役割について、メッセージの送信者と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:
注：上記の認証応答と支払いリクエストのシーケンスをチェックすると、前のアクションリクエストが失敗したため、繰り返しのアクションリクエストを再サブリットする消費者がサポートされます。
o because they did not know the correct response (e.g., a password) on an authentication or,
o 彼らは認証に関する正しい応答（たとえば、パスワード）を知らなかったので、または
o they were unable to pay as there were insufficient funds on a credit card
o クレジットカードに不十分な資金があったため、彼らは支払うことができませんでした
PROCESS THE ERROR FREE INPUT MESSAGE
エラーのない入力メッセージを処理します
If the input message passes the previous checks then it can be processed to produce an output message if required. Note that:
入力メッセージが以前のチェックに合格した場合、必要に応じて出力メッセージを生成するために処理できます。ご了承ください：
o Inquiry Requests on Ping Transactions should be ignored
o pingトランザクションに関する問い合わせリクエストは無視する必要があります
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
o 入力メッセージに、Harderrorまたはキャンセルブロックを含むエラーコンポーネントが含まれている場合は、トランザクションのさらにすべての処理を停止します。これには、現在生成されているメッセージの送信を抑制するか、受信された新しい非重複していないメッセージに応答することが含まれます
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.
出力メッセージが生成された場合、同一の入力メッセージが再び受信された場合に必要に応じてresすることができるように保存する必要があります。過渡エラーを含む出力メッセージは、入力メッセージが再び受信されたときに新たに処理できるように保存されないことに注意してください。
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
o IoTPTransidがPingトランザクションを指している場合、リクエストに失敗します。
o determine which Document Exchange to cancel and generate a Cancel Block and send it to the other party
o キャンセルブロックをキャンセルして生成するドキュメント交換を決定し、相手に送信します
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トランザクションをキャンセルする必要があるという命令を使用して、Process/Serverから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.
メッセージが受信されていない場合、元のメッセージがresする必要があります。これは、使用されている輸送メカニズムの信頼性に依存する最大数回まで発生する必要があります。
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
o トランザクションが後で回復する可能性がある場合、または
o TimedOutNoRcvr if the transaction is non-recoverable
o Timedoutnorcvrトランザクションが再建不可の場合
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) o an Authentication Transaction (see section 9.1.6)
o Pingトランザクション（セクション9.2.2を参照）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サーバーについては、セクション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を参照）。
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:
o TPOブロック。次のように確認してください：
- 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トランザクションがConsumer Roleのシステムによって認識されている場合、それ以外の場合はハードエラーがあります。
- 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トランザクションがConsumer Roleのシステムによって認識されている場合、それ以外の場合はハードエラーがあります。
- 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
- 支払い交換ブロックが、消費者の役割のシステムによって認識されている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
- 支払い交換が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.
このセクションでは、IETFの観点から、IOTPがセキュリティにどのように対処するかを検討します。次のセクション（セクション6を参照）では、Digital SignaturesとIOTPを参照）では、IOTPが必要なときにデジタル署名を使用する方法について説明します。
This section covers:
このセクションでは：
o determining whether to use digital signatures
o デジタル署名を使用するかどうかを決定します
o data privacy, and
o データプライバシー、および
o payment protocol security.
o 支払いプロトコルセキュリティ。
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
- たとえば、「Better Business Bureau」からのいくつかの保証が提供されていた場合
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.
o 支払いハンドラーまたは配送ハンドラーは、支払いまたは配達の完了ステータスの再洗練不可能な記録を提供したいと考えています。支払い応答または配送応答が署名された場合、消費者は後で支払いまたは配達の記録を使用して、それが発生したことを証明できます。これは、たとえば、カスタマーケアの目的で使用できます。
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は、デジタル署名を使用せずにうまく機能することができますが、オープンネットワーク環境では安全性が低くなります。
However, this section describes how to use digital signatures in the many situations when they will be needed. Topics covered are:
ただし、このセクションでは、デジタル署名が必要になる場合にデジタル署名を使用する方法について説明します。カバーされているトピックは次のとおりです。
o an overview of how IOTP uses digital signatures
o IOTPがデジタル署名を使用する方法の概要
o how to check a signature is correctly calculated
o 署名を確認する方法は正しく計算されます
o how Payment Handlers and Delivery Handlers check they can carry out payments or deliveries on behalf of a Merchant.
o 支払いハンドラーと配送ハンドラーがどのようにチェックするかは、商人に代わって支払いまたは配達を行うことができます。
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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で別の署名署名のある署名の典型的な例は、オファーが最初に「オファー応答」署名を作成する商人によって署名されたときです。支払い領収書 "署名。このようにして、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およびReciontientInfo要素を使用して、署名に関連する組織を識別する方法
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).
署名コンポーネントのマニフェスト要素には、次のようなダイジェストが含まれています。TransRefブロック（表示なし）。トランザクション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署名タイプに設定された型属性を使用した属性要素のコンテンツの値は、署名した組織の取引役割と一致する必要があることに注意してください。そうでない場合は、エラーです。以下の表には、有効な組み合わせが示されています。
IOTP Signature Type Valid Trading Role
IOTP署名タイプ有効な取引ロール
OfferResponse Merchant
OfferResponse商人
PaymentResponse PaymentHandler
PayuneResponse PaymentHandler
DeliveryResponse DeliveryHandler
DeliveryResponse DeliveryHandler
AuthenticationRequest any role
AuthenticationRequestの役割
AuthenticationResponse any role
AuthenticationResponse任意の役割
PingRequest any role
PingRequestの役割
PingResponse any role
pingResponseあらゆる役割
The RecipientRefs attribute of the RecipientInfo element in the Signature Component contains Element References to the Organisation Components of the Organisations that should use the signature to verify that:
署名コンポーネントのReciontientINFO要素のRESICELIENTREFS属性には、署名を使用してそれを確認する必要がある組織の組織コンポーネントへの要素参照が含まれています。
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.
対称的な暗号化が使用されている場合、共有されたシークレットキーの異なるセットごとに個別のレシピエンテンフと値要素が署名コンポーネント内にある可能性が高いことに注意してください。
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つのRecipentRefs属性がすべて同じ証明書を使用している場合、複数の組織コンポーネントを参照する場合があります。
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
- 2回目の支払いリクエストで、バリューエクスチェンジIOTPトランザクションで2回目の支払いを許可する別の支払いハンドラー
o Delivery Response, when a Delivery Handler is generating a Delivery Note. This can be used to prove after the event what the Delivery Handler said they would do
o 配達ハンドラーが配達メモを生成しているとき。これは、イベント後に配達ハンドラーが彼らがすると言ったことを証明するために使用できます
o Authentication Response. One method of authenticating another party to a trade is to send an Authentication Request specifying that a Digital Signature should be used for authentication
o 認証応答。取引の別の当事者を認証する1つの方法は、デジタル署名を認証に使用する必要があることを指定する認証リクエストを送信することです
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。署名を理解できることをチェックできるように、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 署名ブロックが存在し、1つ以上の署名コンポーネントが含まれていることを確認します
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 署名チェックを実行している組織の組織属性を含む組織コンポーネントを特定します。複数の組織コンポーネントが見つかった場合、それはエラーです
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 組織コンポーネントのID属性を使用して、その組織コンポーネントを指すReciontientRefs属性を含むRecipientINFO要素を見つけます。注意することは、確認する署名がない場合があります
o check the Signature Component that contains the identified RecipientInfo element as follows:
o 次のように、識別されたRecipientIntInfo要素を含む署名コンポーネントを確認します。
- 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
- それぞれ識別する署名ValuEREFおよび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
- 署名アルゴリズム要素が対称暗号化が使用されていることを示している場合、ReciontientInfo要素の内容を使用して、使用する正しい共有秘密キーを識別します
- 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.
- マニフェスト要素のダイジェスト要素が、ダイジェストが参照するコンポーネントまたはブロックが署名をチェックする組織によって受信されている場合に正しく計算されることを確認します。
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 支払い要求または配送リクエストが正しい組織に送信されたことを確認してください
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:
o 支払いコンポーネントのブランドリストとブランド選択コンポーネントを特定します。これには次のことが含まれます。
- 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属性の値がブランド選択コンポーネントのプロトコラモーントレフ属性の値と一致する要素です。一致するプロトコルの量要素が見つかった場合、エラーがあります
- 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
- 選択されたPayプロトコル要素（セクション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属性の値がブランド選択コンポーネントのCurnencyAmountref属性の値と一致する要素です。1つ以上の一致する通貨額要素が見つかった場合、エラーがあります
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属性と一致する識別されたブランド要素のプロトコラモンストレフ属性に要素参照が存在することを確認します。一致する要素の参照が見つからない場合、エラーがあります
- 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.
- 識別されたプロトコル量要素のcurencyAmountrefs属性には、識別された通貨量要素の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:
o 支払い要求ブロックを受け取った支払いハンドラーが、消費者が選択した支払いハンドラーであることを確認してください。これには次のことが含まれます。
- 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属性が識別されたPayプロトコル要素のActionorGref属性と一致する組織コンポーネントです。複数の一致する組織コンポーネントが見つかった場合、エラーがあります
- checking the Organisation Component has a Trading Role Element with a Role attribute of PaymentHandler. If not there is an error
- 組織コンポーネントのチェックには、Paybed Handlerの役割属性を持つトレーディングロール要素があります。そうでない場合はエラーがあります
- 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)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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
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 商人を特定します。これは、商人の値を持つ役割属性を持つトレーディングロール要素を持つ組織コンポーネントです。複数の取引ロール要素が見つからない場合、エラーがあります
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トランザクションに応じて（セクション9を参照）、1つまたは2つの署名が特定される場合があります
- checking that the Signature Components are correct. This involves checking that Digest elements exist within the Manifest Element that refer to the necessary Trading Components (see section 6.3.3.1).
- 署名コンポーネントが正しいことを確認します。これには、必要な取引コンポーネントを参照するマニフェスト要素内にダイジェスト要素が存在することを確認することが含まれます（セクション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
o 署名コンポーネントを含むIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照）。これにより、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).
o 署名を含む最初のIOTPメッセージのトランザクション参照ブロック（セクション3.3を参照）。これにより、メッセージIDコンポーネント内に含まれるIOTPメッセージに関する情報とIoTpTransidが結合します（セクション3.3.2を参照）。
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.
- トランザクションで以前の支払いハンドラーによって署名された1つ以上の署名コンポーネント。
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 支払いコンポーネント
o Payment Scheme Component
o 支払いスキームコンポーネント
o Payment Receipt Component
o 支払い領収書コンポーネント
o Delivery Component
o 配信コンポーネント
o Delivery Data Component
o 配信データコンポーネント
o Delivery Note Component
o 配信ノートコンポーネント
o Signature Component
o 署名コンポーネント
o Certificate Component
o 証明書コンポーネント
o Error Component
o エラーコンポーネント
Note that the following components are listed in other sections of this specification:
次のコンポーネントは、この仕様の他のセクションにリストされていることに注意してください。
o Transaction Id Component (see section 3.3.1)
o トランザクションIDコンポーネント（セクション3.3.1を参照）
o Message Id Component (see section 3.3.2)
o メッセージIDコンポーネント（セクション3.3.2を参照）
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 >
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：Langは、XML：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.
ShortDESCこれには、XML：Langで定義された言語の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.
これは、消費者、商人などによって保存されているIOTPトランザクションのデータベースなど、同様のトランザクションのリストから個々のトランザクションを選択するために使用されます。
SenderNetLocn This contains the non secured net location of the sender of the TPO Block in which the Protocol Options Component is contained.
これには、プロトコルオプションコンポーネントが含まれているTPOブロックの送信者のセキュリティで担かれていないネット位置が含まれています。
It is the net location to which the recipient of the TPO block should send a TPO Selection Block if required.
必要に応じて、TPOブロックの受信者がTPO選択ブロックを送信するネットロケーションです。
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、secureSenderenetlocn、または両方が存在する必要があります。
This Trading Component contains parameter data that is used in an Authentication of one Trading Role by another. Its definition is as follows.
この取引コンポーネントには、ある取引役割の認証で使用されるパラメーターデータが含まれています。その定義は次のとおりです。
<!ELEMENT AuthReq (Algorithm, 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 Authenticatorが指定した識別子は、認証要求を受信する組織によって返された場合、認証機がどの認証が参照されているかを識別できるようにします。
ContentSoftwareId See section 14.Glossary
ContentsoftWareIDセクション14を参照してください
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これには、アルゴリズム要素によって定義されたアルゴリズムを使用することに応答する1つ以上のパッケージコンテンツ（セクション3.7を参照）としてチャレンジデータが含まれています。
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.
使用できるアルゴリズムは、アルゴリズム要素の名前属性によって識別されます。有効な値については、セクション12を参照してください。IANAの考慮事項。
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).
認証応答コンポーネントには、認証要求の結果が含まれています。認証要求ブロック（セクション8.4を参照）から選択された認証要求コンポーネント（セクション7.2を参照）に含まれるアルゴリズムを使用します。
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 >
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.
ContentsoftWareIDセクション14を参照してください。
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
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 >
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には、情報が要求されている情報が要求されている1つ以上の取引ロールのリスト（取引ロール要素 - セクション7.6.2の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 >
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：langは、XML：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.
shortDESC XML：Langで定義された言語の順序の短い説明。これは、消費者、商人などによって保存されている注文データベースなど、注文リストから個別の注文を選択するために使用されます。
OkFrom The date and time in [UTC] format after which the offer made by the Merchant lapses.
[UTC]形式で日付と時刻をOKから、その後、商人が失ったことによって行われたオファー。
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.
XMLで定義された言語のフレーズ：問題や紛争の解決に適用される管轄権の州または管轄権を説明するLang。
ContentSoftwareId See section 14.Glossary.
ContentsoftWareIDセクション14を参照してください。
Content:
コンテンツ：
PackagedContent An optional description of the order information as one or more Packaged Contents (see section 3.7).
PackagedContent 1つ以上のパッケージ化されたコンテンツとしての注文情報のオプションの説明（セクション3.7を参照）。
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
o OKFrom日付は、この注文に関連付けられている支払いコンポーネントのOKFROM日付（セクション7.9を参照）よりも遅い場合があります。
o similarly, the OkTo date may be earlier that the OkTo date on the Payment Component (see section 7.9).
o 同様に、Oktoの日付は、Octoが支払いコンポーネントの日付を早くする可能性があります（セクション7.9を参照）。
Note: Disclaimer. The following information provided in this note does not represent formal advice of any of the authors of this specification. Readers of this specification must form their own views and seek their own legal counsel on the usefulness and applicability of this information.
注：免責事項。このメモに記載されている以下の情報は、この仕様の著者の正式なアドバイスを表していません。この仕様の読者は、独自の意見を形成し、この情報の有用性と適用性について独自の弁護士を求めなければなりません。
The merchant in the context of Internet commerce with anonymous consumers initially frames the terms of the offer on the web page, and in order to obtain the goods or services, the consumer must accept them.
匿名の消費者とのインターネットコマースのコンテキストでの商人は、最初にWebページのオファーの条件を枠組みし、商品やサービスを取得するために、消費者はそれらを受け入れなければなりません。
If there is to be a time-limited offer, it is recommended that merchants communicate this to the consumer and state in the order description in a manner which is clear to the consumer that:
時間制限のあるオファーがある場合、商人はこれを消費者に伝えることをお勧めします。
o the offer is time limited
o オファーは時間制限です
o the OkFrom and OkTo timestamps specify the validity of the offer
o OKFROMとOKTOタイムスタンプは、オファーの有効性を指定します
o the clock, e.g., the merchant's clock, that will be used to determine the validity of the offer
o オファーの有効性を判断するために使用される商人の時計などの時計、たとえば
Also note that although the OkFrom and OkTo dates are likely to appear in the Packaged Content of the Order Description it is the dates contained in the Order Component that is authoritative. This means it is important that the OkFrom and OkTo dates actually being used is prominently displayed to the Consumer.
また、OKFROMとOKTOの日付は、注文説明のパッケージ化されたコンテンツに表示される可能性が高いが、それは権威ある注文コンポーネントに含まれる日付であることに注意してください。これは、実際に使用されているOktofromと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 >
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：langは、XML：lang属性によって子要素の属性によって上書きされない限り、このコンポーネント内の属性または子要素によって使用される言語を定義します。セクション3.8の識別言語を参照してください。
OrgId A code which identifies the Organisation described by the Organisation Component. See 7.6.1 Organisation IDs, below.
組織コンポーネントによって説明されている組織を識別するコードを組織します。以下の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.
企業である組織のLegalNameこれは、XML：Langによって定義された言語の法的名です。消費者や削除以外の取引役割を持つ組織には必要です。
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".
shortDESC XML：Langで定義された言語の組織の短い説明。通常、組織が一般的に知られている名前です。たとえば、法的名が「Blue Meadows Financial Services Inc.」である場合。その短い名前は、おそらく「青い牧草地」になるでしょう。
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.
これは、消費者が保存しているIOTPトランザクションに関与する組織のデータベースから、組織のリストから個々の組織を選択するのを促進するために使用されます。
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トレーディングロール要素を参照してください。
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.
郵便放送郵便局は、以下の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は、あるIOTPトレーディングロールによって別の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,
o 消費者取引の役割の組織IDは、IOTPトランザクションで他の取引役割の1つによって割り当てられ、その他の役割の組織IDと同時にそれを連結することによりユニークになります。
o once a Consumer is allocated an Organisation Id within an IOTP Transaction the same Organisation Id is used by all the other trading roles in that IOTP transaction to identify that Consumer.
o 消費者がIOTPトランザクション内で組織IDを割り当てると、同じ組織IDがその消費者を特定するためにそのIOTPトランザクションの他のすべての取引役によって使用されます。
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
o one or more characters which conform to the definition of an XML "namechar". See [XML] specifications, followed by o the NonConsumerOrgId for the Organisation which allocated the ConsumerOrgId. It is normally the Merchant role.
o XML「Namechar」の定義に準拠する1つ以上の文字。[XML]仕様を参照してください。その後、消費者を割り当てた組織の非消費性が続きます。通常、マーチャントの役割です。
Use of upper and lower case is not significant.
上限と小文字の使用は重要ではありません。
NonConsumerOrgId If the Role is not Consumer then this contains the Canonical Name for the non-consumer Organisation being described by the Organisation Component. See [DNS] optionally followed by additional characters, if required, to make the NonConsumerOrgId unique.
非消費性役割が消費者ではない場合、これには組織コンポーネントによって記述されている非消費者組織の標準名が含まれています。[DNS]を参照して、必要に応じて追加の文字が続いて、非消費性を一意にします。
Note that a NonConsumerOrgId may not start with the ConsumerOrgIdPrefix.
非消費性は、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
o WesternBank.co.uk-支払いハンドラー組織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
ErrorLogNetLocn CDATA #IMPLIED >
Attributes:
属性：
ID An identifier which uniquely identifies the Trading Role Element within the IOTP Transaction.
ID IOTPトランザクション内の取引ロール要素を一意に識別する識別子。
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.
Values of TradingRole are controlled under the procedures defined in section 12 IANA Considerations which also allows user defined values to be defined.
Tradingroleの値は、ユーザー定義の値を定義できるセクション12 IANAの考慮事項で定義されている手順で制御されます。
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トレーディングロールが消費者の役割または削除に設定されている場合、o存在してはなりません。
o must be present when TradingRole is set to Merchant, PaymentHandler or DeliveryHandler.
o TradingroleがMerchant、PaymentHandler、またはDeliveryHandlerに設定されている場合は、存在する必要があります。
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.
errornetlocnこれには、消費者が次のいずれかに設定された重大度属性を持つエラーコンポーネントを含むエラーコンポーネントを含むエラーブロックを受信または生成した後、消費者が表示する必要があるネットロケーションが含まれます。トランザクションO Transienterrorとトランザクションはその後タイムアウトされました。
See section 7.21.1 Error Processing Guidelines for more details.
詳細については、セクション7.21.1エラー処理ガイドラインを参照してください。
This attribute: o must not be present when TradingRole is set to Consumer or DelivTo, o must be present when TradingRole is set to Merchant, PaymentHandler or DeliveryHandler.
この属性：oは、Tradingroleが消費者またはDelivtoに設定されている場合はoを存在しないでください。OTradingroleがMerchant、PaymentHandler、またはDeliveryHandlerに設定されている場合は、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オプション。これには、消費者が次のいずれかに設定された重大度属性を持つエラーコンポーネントを含むエラーブロックを含むIOTPメッセージを送信する必要があるネットロケーションが含まれます。外。
This attribute: o must not be present when TradingRole is set to Consumer role,
この属性：oトレーディングロールが消費者の役割に設定されている場合、o存在しないでください、
o must be present when TradingRole is set to Merchant, PaymentHandler or DeliveryHandler.
o TradingroleがMerchant、PaymentHandler、またはDeliveryHandlerに設定されている場合は、存在する必要があります。
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 >
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.
組織に連絡できる電話番号を電話してください。これはテキストフィールドであり、検証は実行されないことに注意してください。
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.
組織に連絡できるFAX番号をファックスします。これはテキストフィールドであり、検証は実行されないことに注意してください。
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 Webブラウザーを使用して表示できる組織に関する情報を取得できるインターネット上の場所。
The content of this attribute must conform to [RFC1738].
この属性の含有量は[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.
これには、個々の人の名前が含まれています。すべてのフィールドはオプションですが、最小限には与えられた名または家族名のいずれかが存在する必要があります。その定義は次のとおりです。
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
FamilyName CDATA #IMPLIED >
Attributes:
属性：
xml:lang Defines the language used by attributes within this element. See section 3.8 Identifying Languages.
XML：Langは、この要素内の属性によって使用される言語を定義します。セクション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)
独特の名前をタイトル。個人的な控訴、遺伝的であろうとなかろうと、職務（例：裁判官、市長）または貴族（例えば、公爵、公爵夫人、伯爵）を意味したり、その人に宛てたり指すのに使用したりする（例：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.
人が家族、友人、知人によって知られ、特定されている人が知られている主名または主名を与えられます。そうでなければ、名またはキリスト教名と呼ばれます。
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.
家族の名前は、関連する個人の家族が知られている名前です。通常、それは親によって子供に引き継がれる個人の名前の一部です。
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' >
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"
addressLine1郵便アドレスの最初の行。例：「牧草地」
AddressLine2 The second line of a postal address. e.g., "Sandy Lane"
addressline2郵便アドレスの2行目。例：「サンディレーン」
CityOrTown The city of town of the address. e.g., "Carpham"
町の町のシティオルタウン。例：「カーファム」
StateOrRegion The state or region within a country where the city or town is placed. e.g., "Surrey"
国家領土都市または町が配置されている国内の州または地域。例：「サリー」
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.
法律これにより、住所が組織の登録アドレスであるかどうかが識別されます。組織の少なくとも1つのアドレスには、取引の役割が消費者または削除のいずれかでない限り、値に設定されている必要があります。
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),
o 支払いブランド（セクション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 >
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：langは、XML：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.
shortDESC XMLで定義された言語のテキストの説明：ラングブランドリストの目的の詳細を示しています。この情報は、選択を支援するために、ブランドリストの受信者に表示する必要があります。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このブランドリストが関連する支払い要求ブロックの送信者（消費者など）は、支払いハンドラーに支払いを行うか、oこのブランドリストの支払い要求ブロックを送信者にクレジットするAllatesは、支払いハンドラーから支払いを受け取ります。
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 This contains a currency code and an amount.
CurrencyMountこれには、通貨コードと金額が含まれています。
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属性がクレジットに設定されているブランドリストコンポーネントには、1つのブランド要素が1つあります。
<!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 >
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要素識別子は、後の支払い要求メッセージに含まれるブランド選択コンポーネントで潜在的に参照され、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.
Brandidの値は、セクション12 IANAの考慮事項で説明されている手順で管理されます。
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.
Brandnameこれには、MasterCardクレジットなど、ブランドの名前が含まれています。これは、XML：Langによって定義された消費者言語で消費者に表示されるブランドの説明です。たとえば、「アメリカン航空のアドバンテージビザ」かもしれません。この属性は、消費者が保有する支払い手段と一致するためには使用されていないことに注意してください。
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].
この属性の含有量は[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.
ContentsoftWareIDセクション14を参照してください。
Content:
コンテンツ：
ProtocolBrand Protocol Brand elements contain brand information to be used with a specific payment protocol (see section 7.7.2)
プロトコルブランドプロトコルブランド要素には、特定の支払いプロトコルで使用するブランド情報が含まれています（セクション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 >
Attributes:
属性：
ProtocolId This must match the value of a ProtocolId attribute in a Pay Protocol Element (see section 7.7.5).
プロトコリッドこれは、給与プロトコル要素のプロトコリッド属性の値と一致する必要があります（セクション7.7.5を参照）。
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.
この属性の有効な値は、支払いプロトコルが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
o ブランドで使用できる通貨と通貨の金額要素（セクション7.7.4を参照）の金額と
o the Payment Protocols and Payment Handlers defined in a Pay Protocol Element (see section 7.7.5), which can be used with those currencies and amounts.
o 支払いプロトコルと支払いハンドラーは、有料プロトコル要素で定義されています（セクション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 >
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要素識別子、潜在的にブランド要素で参照される可能性があります。または、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には、ブランドで使用できる支払いプロトコルと支払いハンドラーを含むPayプロトコル要素（セクション7.7.5を参照）を指す要素参照（セクション3.5を参照）が含まれています。
CurrencyAmountRefs Contains a list of Element References (see section 3.5) that refer to the Currency Amount Element (see section 7.7.4) that describes the currencies and amounts that can be used with the Brand.
CurrencyAmountrefsには、ブランドで使用できる通貨と金額を説明する通貨量要素（セクション7.7.4を参照）を参照する要素参照のリスト（セクション3.5を参照）が含まれています。
ContentSoftwareId See section 14. Glossary.
ContentsoftWareIDセクション14を参照してください。用語集。
Content:
コンテンツ：
PackagedContent Optional Packaged Content (see section 3.7) elements containing information about the protocol amount which may be used by the payment protocol. The content of this information is defined in the supplement for a payment protocol which describes how the payment protocol works with IOTP.
PackagedContentオプションのパッケージコンテンツ（セクション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 >
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要素識別子、潜在的にブランド要素で参照される可能性があります。または、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のドメインを示します。この属性は、通貨コードが頻繁なフライヤーポイント、取引スタンプなどの非標準の「通貨」をサポートできるように含まれています。その値は次のとおりです。[ISO 4217] o IOTPに準拠する通貨コードは、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.
CurrcodeTypeの値は、セクション12 IANAの考慮事項で説明されている手順で管理されているため、Currcodetypeのユーザー定義値を定義できます。
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
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要素識別子、潜在的にブランド要素で参照される可能性があります。または、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".
プロトコリッドは、プロトコル名とバージョンで構成されています。たとえば、「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.
プロトコリッドの値は、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.
Protocolname XML：Langによって識別された言語の支払いプロトコルとそのバージョンの物語の説明。たとえば、「Secure Electronic Transactionバージョン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].
この属性の含有量は、輸送メカニズムに依存します（そのようなものは[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.
確保された支払いには、支払いハンドラーと通信するために[SSL/TLS]などの安全なチャネルの使用が含まれます。
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.
ContentsoftWareIDセクション14を参照してください。用語集。
Content:
コンテンツ：
PackagedContent Optional Packaged Content elements (see section 3.7) containing information about the protocol which is used by the payment protocol. The content of this information is defined in the supplement for a payment protocol which describes how the payment protocol works with IOTP. An example of its use could be to include a payment protocol message.
PackagedContentオプションのパッケージ化されたコンテンツ要素（セクション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
o ベースラインの購入およびベースライン価値交換IOTPトランザクション内の支払い要求メッセージで、ブランド、プロトコル、支払いハンドラー、または支払いのための支払いハンドラー、または
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
<！要素BrandSelection（BrandselBrandinfo？、BrandselProtocolamountinfo？、BrandselCurrencyAmountinfo？）> <！Attlist BrandSelection
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.
CurrencyMountRef支払いを行うときに使用するブランドリストコンポーネント内の通貨量要素の要素参照。
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が特定の支払いBrandselCurrencyMountinfoブランドまたはプロトコルで必要とされる可能性のある追加データが含まれています。セクション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は、BrandListrefが参照するブランドリストコンポーネントに含まれるブランドのIDを参照する必要があります
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の1つを参照する必要があります
o the CurrencyAmountRef must refer to one of the Element IDs listed in the CurrencyAmountRefs attribute of the Protocol Amount Element identified by ProtocolAmountRef.
o CurrencyAmountrefは、Protocolamountrefによって識別されたプロトコル量要素のCurnencyAmounTrefs属性にリストされている要素IDの1つを参照する必要があります。
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 >
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
ContentsoftWareIDセクション14を参照してください。用語集。
Content:
コンテンツ：
PackagedContent Packaged Content elements (see section 3.7) that contain additional data that may be required by a particular payment brand. See the payment method supplement for IOTP for rules on how this is used.
特定の支払いブランドが必要とする可能性のある追加データを含むPackagedContentパッケージコンテンツ要素（セクション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 >
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
ContentsoftWareIDセクション14を参照してください。用語集。
Content:
コンテンツ：
PackagedContent Packaged Content elements (see section 3.7) that may contain additional data that may be required by a particular payment brand. See the payment method supplement for IOTP for rules on how this is used.
PackagedContentパッケージコンテンツ要素（セクション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 >
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
ContentsoftWareIDセクション14を参照してください。用語集。
Content:
コンテンツ：
PackagedContent Packaged Content elements (see section 3.7) that contain additional data relating to the payment brand and currency. See the payment method supplement for IOTP for rules on how this is used.
PackagedContentパッケージコンテンツ要素（セクション3.7を参照）は、支払いブランドと通貨に関連する追加データを含む。これがどのように使用されるかについてのルールについては、IOTPの支払い方法補足を参照してください。
A Payment Component contains information used to control how a payment is carried out. Its provides information on:
支払いコンポーネントには、支払いの実行方法を制御するために使用される情報が含まれています。その情報を提供します：
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
o ブランド、プロトコル、通貨、および支払いに使用できる金額を識別するブランドリストへの参照（セクション7.7を参照）
o whether or not a payment receipt will be provided o whether another payment precedes this payment.
o 別の支払いがこの支払いに先行するかどうかは、支払い領収書が提供されるかどうか。
Its definition is as follows.
その定義は次のとおりです。
<!ELEMENT Payment EMPTY >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
SignedPayReceipt (True | False) #REQUIRED
StartAfterRefs NMTOKENS #IMPLIED >
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.
[UTC]形式で日付と時刻をOKからOK。
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.
[UTC]形式で日付と時刻をoktoする前に、支払いハンドラーが支払いコンポーネントを含む支払い要求ブロックの処理に受け入れることがあります。
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.
BrandListref IOTPトランザクションのTPO取引ブロック内のブランドリストコンポーネント（セクション7.7を参照）の要素リファレンス（セクション3.5を参照）。ブランドリストは、支払いを行うことができる代替方法を特定します。
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
startterには、この支払いが開始される前に完了しなければならない支払いを説明する他の支払いコンポーネントの要素参照（セクション3.5を参照）が含まれています。属性が存在しない場合、依存関係がなく、すぐに支払いを開始できます
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.
支払いスキームコンポーネントには、たとえば[セット]メッセージの支払いに関与する当事者間で転送される特定の支払いスキームの支払いプロトコル情報が含まれています。その定義は次のとおりです。
<!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).
PayanceRefこの支払いスキームコンポーネントが関連する支払いコンポーネント（セクション7.9を参照）への要素参照（セクション3.5を参照）。支払いスキームコンポーネントがトランザクション調査ステータストランザクションの一部でない限り、必要です（セクション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支払いハンドラーによって指定された識別子。これは、消費者が別の支払いスキームコンポーネントまたは他の手段で返送する場合、支払いハンドラーは支払いが紹介されているかを特定できるようにします。支払い要求ブロックに含まれるものとは別に、すべての支払いスキームコンポーネントで必要です。
ContentSoftwareId See section 14. Glossary.
ContentsoftWareIDセクション14を参照してください。用語集。
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
注：o各パッケージ化されたコンテンツ要素の名前属性の値は、支払いプロトコルサプリメントによって定義されますo各名前の値は、支払いがすべての支払いスキームまたは同じもののある支払い領収書コンポーネントとして定義される支払い内で一意でなければなりませんPayniveRef属性の値
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 >
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
PaybureRefには、この支払い領収書が適用される支払いコンポーネント（セクション7.9を参照）への要素参照（セクション3.5を参照）が含まれています
PayReceiptNameRefs Optionally contains a list of the values of the
Name attributes of Packaged Content elements that
together make up the receipt. The Packaged
Content elements are contained either within:
o Payment Scheme Data components exchanged
between the Payment Handler and the Consumer
roles during the Payment, and/or
o the Payment Receipt component itself.
Note that:
o each payment scheme defines in its supplement
the Names of the Packaged Content elements
that must be listed in this attribute (if
any).
o if a Payment Scheme Component contains
Packaged Content elements with a name that
matches a name within PayReceiptNameRefs, then
those Payment Scheme Components must be
referenced by Digests in the Payment Response
signature component (if such a signature is
being used)
The client software should save all the components referenced so that the payment receipt can be reconstructed when required.
クライアントソフトウェアは、必要に応じて支払い領収書を再構築できるように、参照されているすべてのコンポーネントを保存する必要があります。
ContentSoftwareId See section 14. Glossary.
ContentsoftWareIDセクション14を参照してください。用語集。
Content:
コンテンツ：
PackagedContent Optionally contains payment scheme payment receipt information as Packaged Content elements (see section 3.7). See the payment scheme supplement for the definition of its content.
PackagedContentオプションでは、支払いスキームの支払い領収書情報がパッケージ化されたコンテンツ要素として含まれています（セクション3.7を参照）。コンテンツの定義については、支払いスキームサプリメントを参照してください。
Note that: o the values of the Name attribute of each packaged content element are defined by the Payment Protocol Supplement o the value of each Name must be unique within a Payment where a Payment is defined as all Payment Scheme or Payment Receipt Components, with the same value of the PaymentRef attribute
注：o各パッケージ化されたコンテンツ要素の名前属性の値は、支払いプロトコルサプリメントによって定義されますo各名前の値は、支払いがすべての支払いスキームまたは支払い領収書コンポーネントとして定義される支払い内で一意でなければなりません。PaynedRef属性と同じ値
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 >
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Receipt Component within the IOTP Transaction.
ID IOTPトランザクション内の支払い領収書コンポーネントを一意に識別する識別子。
ContentSoftwareId See section 14. Glossary.
ContentsoftWareIDセクション14を参照してください。用語集。
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 >
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：langは、XML：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
Delevexchは、このIOTPトランザクションに配信交換に関連付けられたメッセージが含まれているかどうかを示します。有効な値は次のとおりです。oo trueは、それが配達交換を含むことを示すo falseは配達交換が含まれていないことを示します
If set to true then a DeliveryData element must be present. If set to false it may be absent.
Trueに設定する場合、配信量要素が存在する必要があります。falseに設定すると、それは存在しない可能性があります。
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は、配信応答ブロック（セクション8.11を参照）と支払い応答ブロック（セクション8.9を参照）が1つのIOTPメッセージに結合されているかどうかを示します。有効な値は次のとおりです。otrueは両方のブロックが同じIOTPメッセージにあることを示し、そして
o False indicates each block will be in a different IOTP Message
o falseは、各ブロックが別のIOTPメッセージに含まれることを示します
DelivAndPayResp should not be true if DelivExch is False.
delevenivexchがfalseである場合、delevandpayrespは真実ではないはずです。
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支払いハンドラーは配達を実行できる必要があります
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.
DervircyDataには、配信の実施方法に関する詳細が含まれています。以下の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には、1つ以上のパッケージ化されたコンテンツ要素として配信ハンドラーが必要とする商人向けに定義された「ユーザー」データが含まれています。セクション3.7を参照してください。
The DeliveryData element contains information about where and how goods are to be delivered. Its definition is as follows.
配信Data要素には、商品がどこでどのように配送されるかについての情報が含まれています。その定義は次のとおりです。
<!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).
[UTC]形式の日付と時刻からOKから、配信ハンドラーが配達要求ブロックの処理を受け入れることができます（セクション8.10を参照）。
OkTo The date and time in [UTC] format before which the Delivery Handler may accept for processing a Delivery Request Block.
[UTC]形式で日付と時刻をオクトし、その前に配達ハンドラーが配達要求ブロックの処理に受け入れることがあります。
DelivMethod Indicates the method by which goods or services may be delivered. Valid values are: o Post the goods will be delivered by post or courier o Web the goods will be delivered electronically in the Delivery Note Component o Email the goods will be delivered electronically by e-mail
DelivMethodは、商品またはサービスを配信する方法を示します。有効な値は次のとおりです。o投稿商品は郵便局または宅配便で配送されますoウェブ商品は配送用メモコンポーネントで電子的に配送されますo電子メールは電子メールで電子的に配送されます
Values of DelivMethod are managed under the procedure described in section 12 IANA Considerations which allows user defined codes to be defined.
DelivMethodの値は、ユーザー定義コードを定義できるセクション12 IANAの考慮事項で説明した手順で管理されます。
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
delivtoref delivtoの役割を持つIOTPトランザクション内の組織コンポーネントの要素リファレンス（セクション3.4を参照）。このブロックの情報は、配信がどこにあるかを決定するために使用されます。DelivMethodと互換性がなければなりません。具体的には、delevmethodが次の場合、o投稿する場合、郵便配達のための十分な情報を含む郵便アドレス要素、o Webが必要な場合、特定の要件はありません。情報はWebページに送信され、消費者o電子メールに送信され、有効な電子メールアドレスを含む連絡先情報要素が必要です
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].
この属性の含有量は輸送メカニズムに依存しており、[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.
保護された配送リクエストには、支払いハンドラーと通信するために[SSL/TLS]などの安全なチャネルの使用が含まれます。
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.
ContentsoftWareIDセクション14を参照してください。用語集。
Content:
コンテンツ：
PackagedContent Additional information about the delivery as one or more Packaged Content elements (see section 3.7) provided to the Delivery Handler by the merchant.
PackagedContent商人が配達ハンドラーに提供する1つ以上のパッケージ化されたコンテンツ要素（セクション3.7を参照）としての配信に関する追加情報。
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>
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.
ConsumerDelivaryID消費者が指定した識別子は、配送ハンドラーによって返された場合、消費者がどの配達が参照されているかを特定できるようにします。
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 >
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：langは、XML：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.
DelivHandlerDelivive配送ハンドラーによって指定されたオプションの識別子は、消費者によって別の配送コンポーネントまたは他の手段で返された場合、配達ハンドラーがどの配達が参照されているかを特定できるようにします。配信要求ブロックに含まれるものとは別に、すべての配送コンポーネントで必要です。
An example use of this attribute is to contain a delivery tracking number.
この属性の使用例は、配信追跡番号を含めることです。
ContentSoftwareId See section 14. Glossary.
ContentsoftWareIDセクション14を参照してください。用語集。
Content:
コンテンツ：
PackagedContent Contains actual delivery note information as one or more Packaged Content elements (see section 3.7).
PackagedContentには、実際の配信メモ情報が1つ以上のパッケージ化されたコンテンツ要素として含まれています（セクション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 >
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.
未定義とは、ドキュメント交換のタイプを特定できないことを意味します。これは、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の値は、セクション12 IANAの考慮事項で説明されている手順で管理されます。これにより、Statustypeのユーザー定義値も定義できます。
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.
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.
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.
CompleateCodeは、プロセスの完了方法を示します。完了コードの有効な値は、存在する必要がある条件と、障害からの回復が可能な場合の条件とともに以下に示されています。
A CompletionCode is a maximum of 14 characters long.
完了コードの長さは最大14文字です。
ProcessReference This optional attribute holds a reference for the
process whose status is being reported. It may
hold the following values:
o when StatusType is set to Offer, it should
contain the OrderIdentifier from the Order
Component
o when StatusType is set to Payment, it should
contain the PaymentHandlerPayId from the
Payment Scheme Data Component
o when StatusType is set to Delivery, it should
contain the DelivHandlerDelivId from the
Delivery Note Component
o when StatusType is set to Authentication, it
should contain the AuthenticationId from the
Authentication Request Component
This attribute should be absent in the Inquiry Request message when the Consumer has not been given such a reference number by the IOTP Service Provider.
この属性は、IOTPサービスプロバイダーによって消費者にそのような参照番号が与えられていない場合、問い合わせリクエストメッセージには存在しないはずです。
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.
StatusDESC XML：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属性が故障に設定されている場合にのみ必要です。次の表には、使用される可能性のある完了コードの有効な値が含まれており、回復が可能かどうかを示します。StatusDESC属性を使用して、必要に応じてさらに説明を提供することをお勧めします。
Value Description
値の説明
AuthError Authentication Error. The check of the Authentication Response which was carried out has failed.
オートヒア認証エラー。実行された認証応答のチェックは失敗しました。
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.
コンセルの消費者がキャンセルされました。消費者は、何らかの理由でトランザクションをキャンセルすることにしました。このコードは、キャンセルブロックまたは照会応答ブロックに含まれるステータスコンポーネントでのみ有効です。
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.
不特定の不特定エラー。他の完了コードの1つに分類されないいくつかの未知の問題またはエラーがあります。
No recovery possible.
回復は不可能です。
TimedOutRcvr Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
Timedoutrcvr回復可能なタイムアウト。メッセージはresしていましたが、応答はありませんでした。したがって、ドキュメント交換は「タイムアウト」されています。このコードは、トランザクションの問い合わせでのみ有効です。
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非回復可能なタイムアウト。メッセージはresしていましたが、応答はありませんでした。したがって、ドキュメント交換は「タイムアウト」されています。このコードは、トランザクションの問い合わせでのみ有効です。
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属性が故障に設定されている場合にのみ必要です。次の表には、使用される可能性のある完了コードの有効な値が含まれており、回復が可能な場所を示しています。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.
コンセルの消費者がキャンセルされました。消費者は、何らかの理由で支払いをキャンセルすることにしました。このコードは、キャンセルブロックまたは照会応答ブロックに含まれるステータスコンポーネントでのみ有効です。
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.
オートヒア認証エラー。実行された支払いスキーム固有の認証チェックは失敗しました。
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.
不足している資金が不足しています。支払いが行われるために利用できる資金が不十分です。
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 Bad Instrument。支払い手段が使用されていることに問題があります。つまり、支払いに使用できません。
See below for recovery options.
回復オプションについては、以下を参照してください。
Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes. The StatusDesc attribute should provide the explanation of the cause.
不特定の不特定エラー。他の完了コードの1つに分類されないいくつかの未知の問題またはエラーがあります。StatusDESC属性は、原因の説明を提供する必要があります。
See below for recovery options.
回復オプションについては、以下を参照してください。
TimedOutRcvr Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
Timedoutrcvr回復可能なタイムアウト。メッセージはresしていましたが、応答はありませんでした。したがって、ドキュメント交換は「タイムアウト」されています。このコードは、トランザクションの問い合わせでのみ有効です。
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非回復可能なタイムアウト。メッセージはresしていましたが、応答はありませんでした。したがって、ドキュメント交換は「タイムアウト」されています。このコードは、トランザクションの問い合わせでのみ有効です。
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、Infcuffunds、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.
次の表には、配信用の完了コード属性の有効な値が含まれています。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が完了している場合にのみ有効です。
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が完了している場合にのみ有効です。
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.
保留中の衝撃出荷。商品は利用可能で、出荷が予定されていますが、まだ出荷されていません。これは、ProcessStateが完了している場合にのみ有効です。
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が完了している場合にのみ有効です。
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.
出荷されたshiptnoconf-配送確認なし。商品は出荷されましたが、商品の配達を確認することはできません。これは、ProcessStateが完了している場合にのみ有効です。
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.
コンセルの消費者がキャンセルされました。消費者は、何らかの理由で配達をキャンセルすることにしました。このコードは、キャンセルブロックまたは照会応答ブロックに含まれるステータスコンポーネントでのみ有効です。
Recovery is not possible.
回復は不可能です。
DelivCancelled Delivery Cancelled. The Delivery Handler declines to complete the Delivery for some reason and cancels the transaction. This code is only valid in a Status Component contained in a Cancel Block or an Inquiry Response Block.
DelivCancelled Deliveryはキャンセルされました。配達ハンドラーは、何らかの理由で配達を完了することを拒否し、取引をキャンセルします。このコードは、キャンセルブロックまたは照会応答ブロックに含まれるステータスコンポーネントでのみ有効です。
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が完了している場合にのみ有効です。
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.
不特定の不特定エラー。他の完了コードの1つに分類されないいくつかの未知の問題またはエラーがあります。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回復可能なタイムアウト。メッセージはresしていましたが、応答はありませんでした。したがって、ドキュメント交換は「タイムアウト」されています。このコードは、トランザクションの問い合わせでのみ有効です。
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非回復可能なタイムアウト。メッセージはresしていましたが、応答はありませんでした。したがって、ドキュメント交換は「タイムアウト」されています。このコードは、トランザクションの問い合わせでのみ有効です。
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属性が故障に設定されている場合にのみ必要です。次の表には、使用される可能性のある完了コードの有効な値が含まれています。StatusDESC属性を使用して、必要に応じてさらに説明を提供することをお勧めします。
Value Description
値の説明
AutEeCancel Authenticatee Cancel. The Organisation being authenticated declines to be authenticated for some reason. This could be, for example because the signature on an Authentication Request was invalid or the Authenticator was not known or acceptable to the Authenticatee.
auteecancel authenticateeキャンセル。認証されている組織は、何らかの理由で認証されることを拒否します。これは、たとえば、認証要求の署名が無効であるか、認証機が認証型に知られていない、または受け入れられなかったためです。
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 Authenticatorキャンセル。認証を要求する組織は、何らかの理由で受け取った認証応答を検証することを拒否し、トランザクションをキャンセルします。
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認証要求は利用できません。Authenticateeには、それらが正常に認証されるように提供する必要があるデータはありません。たとえば、パスワードが忘れられている可能性があり、Authenticateeがまだメンバーになっていないか、スマートカードトークンが存在していません。
Recovery is not possible
回復は不可能です
AuthFailed Authentication Failed. The Authenticator checked the Authentication Response but the authentication failed for some reason. For example a password may have been incorrect.
認証が失敗しました。認証者は認証応答をチェックしましたが、何らかの理由で認証が失敗しました。たとえば、パスワードが間違っていた可能性があります。
Recovery may be possible by the Authenticatee re-sending a revised Authentication Response with corrected data.
Authenticateeが修正されたデータを修正したデータを使用して再配置することにより、回復が可能になる場合があります。
TradRolesIncon Trading Roles Inconsistent. The Trading Roles contained within the TradingRoleList attribute of the Trading Role Information Request Component (see section 7.4) are inconsistent with the Trading Role which the Authenticatee is taking in the IOTP Transaction or is able to take. Examples of inconsistencies include: o asking a PaymentHandler for DeliveryHandler information o asking a Consumer for Merchant information
Tradrololosinconの取引の役割は一貫していません。取引ロール情報要求コンポーネント（セクション7.4を参照）のTradingrolelist属性に含まれる取引の役割は、AuthenticateeがIOTPトランザクションで取っている、または取ることができる取引役割と矛盾しています。矛盾の例は次のとおりです。O配信ハンドラー情報のためにPaybyHandlerに尋ねる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.
不特定の不特定エラー。他の完了コードの1つに分類されないいくつかの未知の問題またはエラーがあります。
Recovery is not possible.
回復は不可能です。
TimedOutRcvr Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
Timedoutrcvr回復可能なタイムアウト。メッセージはresしていましたが、応答はありませんでした。したがって、ドキュメント交換は「タイムアウト」されています。このコードは、トランザクションの問い合わせでのみ有効です。
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非回復可能なタイムアウト。メッセージはresしていましたが、応答はありませんでした。したがって、ドキュメント交換は「タイムアウト」されています。このコードは、トランザクションの問い合わせでのみ有効です。
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属性が故障に設定されている場合にのみ必要です。次の表には、使用される可能性のある完了コードの有効な値が含まれています。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属性が故障に設定されている場合にのみ必要です。次の表には、使用される可能性のある完了コードの有効な値が含まれています。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 >
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).
DestidationELREFSには、「リクエスト」ブロック（たとえば、支払い要求または配信要求ブロックのいずれか）で取引ロールデータコンポーネントを受け取る組織の組織コンポーネントへの要素参照が含まれています。
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属性によって識別された組織の1つに送信されているかどうかを確認してください。「リクエスト」ブロックに含める場合：
- 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 >
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支払いコンポーネントタイプが支払いの場合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構造の定義は、Kent DavidsonとKent DavidsonとYoshiaki Kawatsuraによる「インターネットオープントレーディングプロトコル」というタイトルのドキュメントで説明されています。
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.
各署名コンポーネントは、他の署名コンポーネントを含む1つ以上のブロックまたはコンポーネントにデジタル的に署名します。
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.
マニフェスト要素の署名を含む複数の値要素がある場合があることに注意してください。
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配信応答署名、または
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
署名要素
The ID attribute is mandatory.
ID属性は必須です。
MANIFEST ELEMENT
マニフェスト要素
The optional LocatorHrefBase attribute contains text which should be concatenated before the text contained in the LocatorHREF attribute of all Digest elements within the Manifest.
オプションのLocatorHrefBase属性には、マニフェスト内のすべてのダイジェスト要素の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
アルゴリズムとパラメーター要素
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.
アルゴリズム要素は、署名の生成に使用されるアルゴリズムを識別します。アルゴリズムのタイプは、ダイジェストアルゴリズム、署名アルゴリズム、またはキー契約アルゴリズムとして使用されるかどうかを示す型属性の値によって定義されます。
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"
o [dom-hash]アルゴリズム。これは、アルゴリズム要素の名前属性を「urn：ibm：dom-hash」に設定することによって識別されます。
o a [SHA1] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:fips:sha1", and
o [SHA1]アルゴリズム。これは、アルゴリズム要素の名前属性を「urn：fips：sha1」に設定することによって識別されます。
o a [MD5] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:rsa:md5"
o [md5]アルゴリズム。これは、アルゴリズム要素の名前属性を「urn：rsa：md5」に設定することによって識別されます。
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"
o [DSA]アルゴリズム。これは、アルゴリズム要素の名前属性を「urn：us.gov：dsa」に設定することによって識別されます。
o a [HMAC] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:ibm:hmac"
o [HMAC]アルゴリズム。これは、アルゴリズム要素の名前属性を「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"
o [RSA]アルゴリズム。これは、アルゴリズム要素の名前属性を「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.
さらに、他の支払いスキーム特定のアルゴリズムを使用できます。この場合、使用する名前属性の値は、そのアルゴリズムの支払いスキームサプリメントで指定されています。
One algorithm may make use of other algorithms by use of the Parameter element, for example:
1つのアルゴリズムは、パラメーター要素を使用することにより、他のアルゴリズムを使用する場合があります。たとえば、：
<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>
DIGEST ELEMENT
消化要素
The LocatorHREF attribute identifies the IOTP element which is being digitally signed. Specifically it consists of:
LocatorHref属性は、デジタルで署名されているIOTP要素を識別します。具体的には、次のことです。
o the value of the IotpTransId attribute of the Transaction ID Component, followed by:
o トランザクションIDコンポーネントのIoTPTransID属性の値、次に以下が続きます。
o a sharp character, i.e. "#", followed by
o 鋭いキャラクター、つまり「＃」、続いて
o an Element Reference (see section 3.5) to the element within the IOTP Transaction which is the subject of the digest.
o ダイジェストの主題であるIOTPトランザクション内の要素への要素参照（セクション3.5を参照）。
Before analysing the structure of the LocatorHREF attribute, it must be concatenated with the value of the LocatorHrefBase attribute of the Manifest element (see immediately above).
LocatorHref属性の構造を分析する前に、マニフェスト要素のLocatorHrefBase属性の値と連結する必要があります（上記のすぐ上を参照）。
ATTRIBUTE ELEMENT
属性要素
There must be one and only one Attribute Element that contains a Type attribute with a value of IOTP Signature Type and with content set to either: OfferResponse, PaymentResponse, DeliveryResponse,
IOTP署名タイプの値を持つ型属性を含む属性要素が1つだけあり、コンテンツが設定されている必要があります。
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.
属性要素のコンテンツの値は、ユーザー定義の値を定義できるセクション12 IANAの考慮事項で定義されている手順で制御されます。
The Critical attribute must be set to true.
重要な属性をtrueに設定する必要があります。
ORIGINATORINFO ELEMENT
OriginatorInfo要素
The OriginatorRef attribute of the OriginatorInfo element must always be present and contain an Element Reference (see section 3.5) to the Organisation Component of the Organisation that generated the Signature Component.
OriginatorInfo要素のOriginatorRef属性は常に存在し、署名コンポーネントを生成した組織の組織コンポーネントへの要素参照（セクション3.5を参照）を含める必要があります。
RECIPIENTINFO ELEMENT
ReciontientInfo要素
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.
ReciontEientRefs属性には、要素参照のリスト（セクション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
o オファー応答署名を含むIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照）
o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Offer Response Signature
o オファー応答署名を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
o from the TPO Block:
o TPOブロックから：
- 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.
o マーチャントがブランド選択コンポーネントを含むTPO選択ブロックを受け取った場合、ブランド選択コンポーネントによって識別された支払いハンドラーと配送ハンドラーの配送ハンドラーのダイジェスト要素を生成します。セクション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
o 支払い領収書署名を含むIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照）
o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Payment Receipt Signature
o 支払い領収書署名を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
o the Offer Response Signature Component
o オファー応答署名コンポーネント
o the Payment Receipt Component
o 支払い領収書コンポーネント
o the Payment Note Component
o 支払いノートコンポーネント
o the Status Component o 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
o 配信応答署名を含むIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照）
o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Delivery Response Signature
o 配信応答署名を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
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
o IOTPメッセージとIOTPトランザクションを説明する情報を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
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 :
o TPOブロックの次のコンポーネント：
- 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
o IOTPメッセージとIOTPトランザクションを説明する情報を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
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
証明書コンポーネント
The ID attribute is mandatory.
ID属性は必須です。
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.
エラーコンポーネントには、取引に関与する取引役割の1つによって受信された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 >
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：langは、XML：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には、メッセージのエラーの性質がエラーのエラーコードが含まれています。エラーコードの有効な値は、セクション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
Errordescには、XML：Langで定義された言語のエラーの物語の説明が含まれています。この属性のコンテンツは、エラーコンポーネントを生成したソフトウェアのベンダー/開発者によって定義されます
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トランザクションは引き続き継続できることを示しています。o transienterror。これは、エラーロケーション要素によって言及されている誤差のメッセージがresしている場合、誤差のエラーが回復する可能性があることを示しています
o HardError. This indicates that there is an unrecoverable error in the message in error and the IOTP Transaction must stop.
o ハードエラー。これは、メッセージにエラーが回復不可能なエラーがあり、IOTPトランザクションが停止する必要があることを示しています。
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.
Minretrysecs重大度がTransienterrorに設定されている場合、この属性が存在する必要があります。IOTP認識アプリケーションが、エラーロケーション要素によって識別されたエラーでメッセージを再配置する前に、エラーを報告するメッセージを受信したIOTP認識アプリケーションの最小数秒です。
If Severity is not set to TransientError then the value of this attribute is ignored.
重大度がtransienterrorに設定されていない場合、この属性の値は無視されます。
SwVendorErrorRef This attribute is a reference whose value is set by the vendor/developer of the software which generated the Error Component. It should contain data which enables the vendor to identify the precise location in their software and the set of circumstances which caused the software to generate a message reporting the error. See also the SoftwareId attribute of the Message Id element in the Transaction Reference Block (section 3.3).
SWVENDORERRORREFこの属性は、エラーコンポーネントを生成したソフトウェアのベンダー/開発者によって値が設定されているリファレンスです。ベンダーがソフトウェアの正確な場所と、ソフトウェアがエラーを報告するメッセージを生成する一連の状況を識別できるようにするデータを含める必要があります。トランザクションリファレンスブロック（セクション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.
エラーロケーションこれにより、メッセージの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.
エラーの重大度がTransienterrorでない場合、エラーの性質（セクション7.21.2エラーコードを参照）およびIOTP Awareアプリケーションのベンダー/開発者の裁量で、適切に複数のエラーロケーションを指定できます。
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 Awareアプリケーションのベンダー/開発者の裁量によって、適切に異なる場合があります。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.
エラーを報告するメッセージに複数のエラーコンポーネントがある場合、エラーコンポーネントが最も高い重大度を持つアクションを実行します。これに関連して、ハーデローはトランジェロールよりも高い重症度を持っており、警告よりも重大度が高くなっています。
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 AWAREアプリケーションが、重大度属性が警告に設定されているエラーコンポーネントを使用してエラーを報告するメッセージを生成している場合、エラーを報告するメッセージに、警告よりも高い重大度を持つ別のエラーコンポーネントが含まれていない場合、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:
o IOTP認識アプリケーションの実装者は、ユーザーの裁量で、次のいずれかでなければなりません。
- 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に設定されたエラーコンポーネントを使用してエラーを報告するメッセージを生成することにより、IOTPトランザクションに失敗します（セクション7.21.1.3を参照）。
If the intention is to continue the IOTP transaction then, if there are no other Error Components with a higher severity, check that the necessary Trading Blocks and Trading Components for normal processing of the transaction to continue are present. If they are not then generate a message reporting the error with an Error Component with Severity set to HardError.
IOTPトランザクションを継続することを目的としている場合、重大度が高い他のエラーコンポーネントがない場合は、必要な取引ブロックとトランザクションの通常の処理が存在することを確認します。そうでない場合は、重大度が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 Awareアプリケーションが、重大度属性がTransientErrorに設定されているエラーコンポーネントを使用してエラーを報告するメッセージを生成している場合、エラーを報告するメッセージに1つのエラーコンポーネントのみが必要です。さらに、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
- 警告の重大度を持つエラーコンポーネントを含むエラーを報告するメッセージを生成し、次のIOTPメッセージ（ある場合）に送信して、無効なMinretrySecsでエラーを報告するメッセージを送信したトレーディングロールに送信し、
- use a value for MinRetrySecs which is set by the vendor/developer of the IOTP Aware Application.
- IOTP Awareアプリケーションのベンダー/開発者によって設定されたMinretrysecsの値を使用します。
o check that only one ErrorLocation element is contained within the Error Component and that it refers to an IOTP Message which was sent by the recipient of the Error Component with a Severity of TransientError. If more than one ErrorLocation is present then generate a message reporting the error with a Severity of HardError.
o エラーコンポーネント内に1つのエラーロケーション要素のみが含まれていること、およびエラーコンポーネントの受信者から送信されたIOTPメッセージがTransienterrorの重大度を持つことを参照していることを確認してください。複数のエラーロケーションが存在する場合は、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 Awareアプリケーションが、重大度属性がHarderrorに設定されたエラーコンポーネントを使用してエラーを報告するメッセージを生成している場合、エラーを報告するメッセージに1つのエラーコンポーネントのみが必要です。
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.
次の表には、エラーコンポーネントのエラーコード属性の有効な値が含まれています。説明の最初の文には、表示または報告されたときにエラーを説明するために使用する必要があるテキストが含まれています。個々の実装は、裁量でこれを代替言語に変換する場合があります。
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]を参照してください。具体的には、o XMLドキュメントは、IOTPドキュメントタイプ宣言（DTD）で定義されている制約に準拠していません（セクション13インターネットオープントレーディングプロトコルデータ型定義を参照）、o XMLドキュメントはドキュメントで定義されている制約に準拠していません宣言されている追加の[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.
XMLが十分に形成されていない場合、適切に形成されたエラー応答が生成されるように、トランザクション参照ブロックを抽出する試みを行う必要があります。
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 EXMENSION ELEMENT。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.
エルミス要素がありません。ドキュメントは適切に形成されていて有効ですが、この仕様に含まれるルールと制約が守られている場合、存在するはずの要素が欠落しています。
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 Element Content違法。ドキュメントは適切に形成され、有効ですが、要素コンテンツには、この仕様に含まれるルールと制約に準拠していない値が含まれています。
EncapProtErr Encapsulated protocol error. Although the document is well formed and valid, the PackagedContent of an element contains data from an encapsulated protocol which contains errors.
Encapproterrカプセル化プロトコルエラー。ドキュメントは適切に形成され、有効ですが、要素のパッケージコンテンツには、エラーを含むカプセル化プロトコルからのデータが含まれています。
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.
AstunExpectedの予期しない属性。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 Awareアプリケーションではサポートされていません。
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.
この場合、エラーコンポーネントのPackagedContentを欠落属性のタイプに設定します。
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認識アプリケーションが含む値が含まれています。
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.
伸縮性要素は一貫性がありません。この仕様に含まれるルールと制約に従って、ドキュメントは適切に形成され、有効ですが、o要素の内容は他の要素またはその属性の内容と矛盾しているか、o属性の値は値と矛盾します1つ以上の他の属性の。
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.
トランスポーターロール輸送エラー。このエラーコードは、メッセージの受信を妨げているトランスポートメカニズムに問題があることを示すために使用されます。通常、過渡エラーに関連付けられています。輸送エラーの説明は、ErrorDESC属性内に含まれています。輸送メカニズムのIOTPサプリメントで、トランスポーターターを使用してErrordESC内で使用できる値が指定されています。
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属性によって示される時間までに応答がない場合、元のメッセージがresする必要があります。
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属性によって示される時間までに応答がない場合、元のメッセージはresする必要があります。
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.
未知のエラー不明エラー。他のエラーのいずれでも明示的にカバーされていないために、何らかの理由でトランザクションが完了できないことを示します。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 >
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これは、エラーが配置されている要素のタイプの名前です。たとえば、要素が<！要素組織として宣言された場合、その名前は「org」です。
IotpMsgRef This is the value of the ID attribute of the of the Message Id Component (see section 3.3.2) of the message in error to which this Error Component applies.
IoTPMSGREFこれは、このエラーコンポーネントが適用されるエラーのメッセージのメッセージIDコンポーネント（セクション3.3.2を参照）の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.
エラーが特定の取引コンポーネントに関連付けられている場合、これはエラーが配置されているトレーディングコンポーネントの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エラーが取引コンポーネント内の特定の要素に関連付けられている場合、要素に「属性タイプ」（[XML]を参照）の属性が「ID」を持つ場合、これはその属性の値です。
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エラーが属性の値に関連付けられている場合、これはその属性の名前です。この場合、エラーコンポーネントのパッケージコンテンントには、属性の値を含める必要があります。
Note that as many as the attributes as possible should be included. For example if an attribute in a child element of a Trading Component contains an incorrect value, then all the attributes of ErrorLocation should be present.
できるだけ多くの属性を含める必要があることに注意してください。たとえば、取引コンポーネントの子要素の属性に誤った値が含まれている場合、エラーロケーションのすべての属性が存在する必要があります。
Trading 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.
各取引ブロックは、1つ以上の取引コンポーネントで構成されています（セクション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 )* ) >
<！要素IoTPMessage（transRefblk、sigblk？、errorblk？、（authreqblk | authrespblk | authstatusblk | cancelblk | dexilerreqblk | inquiryreqblk | inquiryrespblk | offerrespblk | bayexchblk | payreqblk | payreqspblk | payrecblk | pingrecblk k）*）>
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 支払い交換ブロック
o Payment Request Block
o 支払い要求ブロック
o Payment Response Block
o 支払い応答ブロック
o Signature Block
o 署名ブロック
o Trading Protocol Options Block
o トレーディングプロトコルオプションブロック
o TPO Selection Block
o TPO選択ブロック
The Transaction Reference Block is described in section 3.3.
トランザクション参照ブロックについては、セクション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 >
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を参照）は、IOTPトランザクション全体に適用されるオプションを定義します（セクション9を参照）。
BrandList This Brand List Component contains one or more payment brands and protocols which may be selected (see section 7.7).
ブランドリストこのブランドリストコンポーネントには、選択できる1つ以上の支払いブランドとプロトコルが含まれています（セクション7.7を参照）。
Org The Organisation Components (see section 7.6) identify the Organisations and their roles in the IOTP Transaction. The roles and Organisations which must be present will depend on the particular type of IOTP Transaction. See the definition of each transaction in section 9. Internet Open Trading Protocol Transactions.
組織コンポーネント（セクション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 オプションで、IOTPトランザクションに配信が含まれている場合、Delevertoの取引役割を持つ組織コンポーネント
o Brand List Components for each payment in the IOTP Transaction
o IOTPトランザクションの各支払いのブランドリストコンポーネント
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 >
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トランザクションで行われる各支払いについて、ブランド選択コンポーネント（セクション7.8を参照）が1つあります。
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 >
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のプロセスステートは違法であることに注意してください。
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.
ステータスコンポーネントのProcessState属性が故障するように設定されていない限り、順序コンポーネントを存在する必要があります。
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
オファー応答ブロックには以下を含める必要があります。oIOTPトランザクションの注文コンポーネント
o Payment Components for each Payment in the IOTP Transaction
o IOTPトランザクションの各支払いの支払いコンポーネント
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.
認証要求ブロックには、ある取引ロールが使用するデータが含まれています。
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 >
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.
1つの認証要求コンポーネントが存在する場合、その認証要求コンポーネントを使用する必要があります。
If more than one Authentication Request Component is present then the recipient should choose one of the components based on personal preference of the recipient or their software.
複数の認証要求コンポーネントが存在する場合、受信者は受信者またはそのソフトウェアの個人的な好みに基づいてコンポーネントのいずれかを選択する必要があります。
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
Tradingrolecforeqトレーディングロール情報要求コンポーネント（セクション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 >
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属性によって要求されているように、取引役割に対応する情報を含むOptional Optional Organizationコンポーネント。
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 >
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 >
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を参照）が含まれています（例：オファー応答や支払い応答など）。これらのステップの成功または失敗を示すために使用されます。前の手順が成功した場合にのみ支払いが発生する必要があります。
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ブランドリストコンポーネントには、選択できる1つ以上の支払いブランドとプロトコルのリストが含まれています（セクション7.7を参照）。
BrandSelection This identifies the choice of payment brand, the payment protocol and the Payment Handler to be used in a payment within the IOTP Transaction. There is one Brand Selection Component (see section 7.8) for each payment to be made in the IOTP Transaction.
Brandselectionこれは、IOTPトランザクション内での支払いで使用される支払いブランド、支払いプロトコル、および支払いハンドラーの選択を識別します。IOTPトランザクションで行われる各支払いについて、ブランド選択コンポーネント（セクション7.8を参照）が1つあります。
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 >
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 >
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のプロセスステートは違法であることに注意してください。
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属性が完了するように設定されている場合は、存在する必要があります。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.
PaybureNoteには、支払いハンドラーが消費者に提供したい追加の非支払い関連の情報が含まれています。たとえば、撤退または預金が行われている場合、転送が完了した後、アカウントの残りの残高に関する情報を含めることができます。セクション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 >
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を参照）が含まれます（支払い応答など）。これらのステップの成功または失敗を示すために使用されます。以前の手順が成功した場合にのみ、配達が発生する必要があります。
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.
消費者向けdataオプション。消費者によって指定された識別子が含まれています。これには、配送ハンドラーによって返されると、消費者がどの配達が紹介されているかを特定できます。
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
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の配信スタッコードを備えた配信ステータス要素が無効であることに注意してください。
<!ELEMENT DeliveryRespBlk (Status, 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のプロセスステートは違法であることに注意してください。
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 >
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 Inquiry Typone Component（セクション7.18を参照）のお問い合わせの種類を含む。
PaySchemeData Payment Scheme Component (see section 7.10) that contains payment scheme specific inquiry messages for inquiries on payments. This is present when the Type attribute of Inquiry Type Component is Payment.
支払いスキームが含まれる支払いに関する具体的な問い合わせメッセージを含むPayschemedata支払いスキームコンポーネント（セクション7.10を参照）。これは、お問い合わせタイプコンポーネントのタイプ属性が支払いである場合に存在します。
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 >
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.3.2を参照）への要素参照（セクション3.5を参照）が含まれています。関連するトランザクションで消費者から以前に受信されたメッセージがない場合、この属性は値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.3.2を参照）への要素参照（セクション3.5を参照）が含まれています。関連するトランザクションで消費者に以前に送信されたメッセージがない場合、この属性には値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属性の型属性が支払いに設定されている場合に存在します。
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>
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.
組織コンポーネントが存在しない場合、pingリクエストは匿名であり、サーバーが動作しているかどうかを単純に判断します。
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.
この場合、送信者には次のものが含まれます。oIOTPトランザクション（マーチャント、支払いハンドラーなど）で取得している取引役割を指定する自体を識別する組織コンポーネントoメッセージの意図された受信者を識別する組織コンポーネント。
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>
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メッセージを処理する送信者ソフトウェアのステータスを表示するコードが含まれています。有効な値は次のとおりです。署名の検証を含め、サービスのすべてが正常に機能しています。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要求ブロックを含むメッセージに署名ブロックも含まれている場合にのみ存在します。有効な値は次のとおりです。署名は正常に検証され、互換性が証明されました。oこのpingリクエストブロックの受信機をサポートしても、署名の検証はサポートされていません。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).
これらは組織コンポーネントです（セクション7.6を参照）。
The Organisation Components of the sender of the Ping Response is always included in addition to the Organisation Components sent in the Ping Request.
PING応答の送信者の組織コンポーネントは、PINGリクエストで送信された組織コンポーネントに加えて、常に含まれます。
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 >
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.
証明書の証明書コンポーネント。セクション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
o 支払いが以前のステップに依存している場合（支払いコンポーネントのstartyter属性で示されているように）、前のステップで生成された支払い領収書署名コンポーネント（セクション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.
支払い応答ブロックと同じメッセージにある署名ブロックには、ステップで生成された支払い領収書署名コンポーネント（セクション7.19.3を参照）のみが含まれています。
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.
エラー取引ブロックには、取引に関与する取引役割の1つによって受信された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.
IN3注：エラー取引ブロックは、複数のエラーコンポーネントを使用して複数の異なるエラーを報告できますが、IOTP認識アプリケーションの開発者には義務はありません。
The structure of an Error Trading Block is as follows.
エラー取引ブロックの構造は次のとおりです。
<!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:
キャンセルブロックは、ある取引の役割によって使用され、トランザクションがキャンセルされたことを他の取引に通知します。使用の例は次のとおりです。
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 >
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
o 別の取引による取引における一方の当事者の認証をサポートする認証IOTPトランザクションおよび/または別の取引役割に関する情報を要求する
o IOTP Transactions that involve one or more payments. Specifically:
o 1つ以上の支払いを含むIOTPトランザクション。具体的には：
- Deposit
- デポジット
- Purchase
- 購入
- Refund
- 返金
- Withdrawal, and
- 撤退、および
- Value Exchange
- 価値交換
o IOTP Transactions designed to check the correct function of the IOTP infrastructure. Specifically:
o IOTPインフラストラクチャの正しい機能を確認するように設計されたIOTPトランザクション。具体的には：
- 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.
認証および支払い関連のIOTPトランザクションは、6つのドキュメント交換で構成され、その後、特定のトランザクションを実装するために順番に組み合わされます。
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 ブランド独立したオファー。これはオファー取引交換でもあります。ただし、この場合、オファー応答のコンテンツは選択されたブランドに依存しません。
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.
o 各IOTPトランザクションがドキュメント交換を使用して目的の結果を実現する方法の説明。
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 AuthenticatorからAuthenticateeに送信される認証リクエスト、
o an Authentication Response being sent in return by the Authenticatee to the Authenticator which is then checked, and
o Authenticateeから認証を受けた認証応答が認証を受け、その後確認され、その後チェックされ、
o an Authentication Status being sent by the Authenticator to the Authenticatee to provide an indication of the success or failure of the authentication.
o 認証の成功または障害の兆候を提供するために、認証ステータスが認証因子に送信されます。
An Authentication Document Exchange also:
認証文書交換：
o provides an Authenticatee with an Organisation Component which describes the Authenticator, and
o Authenticateeは、認証機を記述する組織コンポーネントを提供します。
o optionally provides the Authenticator with Organisation Components which describe the Authenticatee.
o オプションでは、Authenticeeを記述する組織コンポーネントを認証機に提供します。
The Authentication Request may also be digitally signed which allows the Authenticatee to verify the credentials of the Authenticator.
認証要求もデジタル署名されているため、Authenticateeが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 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. 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認識アプリケーションが開始されました。署名ブロックが存在する場合、最初の組織はこれを使用して2番目の組織の資格情報を確認できます。資格情報が問題ない場合、最初の組織は使用する認証要求を選択します（存在し、複数の場合）、選択された認証アルゴリズムを使用して認証応答ブロックを生成します。存在する場合、取引ロール情報要求コンポーネントを使用して、組織コンポーネントを生成します。最後に、必要に応じて署名コンポーネントが作成され、すべてのコンポーネントが検証のために2番目の組織に返送されます。
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. 2番目の組織は、認証要求ブロック内のデータに対する認証応答をチェックして、最初の組織が存在するものであることを確認し、結果を示すために認証ステータスブロックを最初の組織に送信します。
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メッセージ（以下を参照）を受信すると、Authenticateeは次のとおりです。
o generate and send an Authentication Response IOTP Message back to the Authenticator, or
o 認証応答IOTPメッセージを認証応答を生成して送信しますAuthenticatorに戻す、または
o indicate failure to comply with the Authentication Request by sending a Cancel Block back to the Authenticator containing a Status Component with a StatusType of Authentication a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: AutEeCancel, NoAuthReq, TradRolesIncon or Unspecified.
o 認証のSTATUSTYPEを含むステータスコンポーネントを含む認証要求を送信して、認証要求を順守しないことを示します。不特定。
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メッセージ（以下を参照）を受信すると、Authenticatorが送信する必要があります。Statustypeが認証に設定されているステータスコンポーネントを持つステータスブロックを含む認証ステータスIOTPメッセージ（以下を参照）を送信する必要があります。
o the ProcessState attribute of the Status Component is set to CompletedOk which indicates a successful completion, or
o ステータスコンポーネントのProcessState属性は、完了したことを示していることを示している、または
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属性は故障するように設定されており、completeCode属性は次のいずれかに設定されています。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メッセージを受信すると（以下を参照）、Authenticateeはステータスブロックのステータスコンポーネントを確認する必要があります。これが示す場合：
o a successful authentication, then the Authenticatee should either:
o 認証を成功させるには、Authenticateeは次のとおりです。
- continue with the next step in the IOTP Transaction of which the Authentication Document Exchange is part (if any), or
- 認証文書交換が一部（もしあれば）である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.
- AuthercaturtypentのStatustypeを含むキャンセルブロック、故障のプロセスステート、およびAuteeCancelに設定されたComprossTate（セクション7.16.4を参照）を認証型コンポーネントに送信することにより、IOTPトランザクションの残りの部分を継続できないことを示します。
o a failed authentication, then the failure should be reported to the Authenticatee and any further processing stopped.
o 認証に失敗した場合、障害はAuthenticateeに報告され、さらに処理が停止する必要があります。
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.
Authenticatorが消費者からキャンセルブロックを含むIOTPメッセージを受信した場合、Authenticateeは、取引プロトコルオプションブロックに含まれるAuthenticatorの組織コンポーネントのトレーディングロール要素に指定された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)
o 取引プロトコルオプションブロック（セクション8.1を参照）
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
トレーディングプロトコルオプションブロック
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.
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 Authenticatorを説明する1つの組織コンポーネント（セクション7.6を参照）。組織コンポーネントの取引の役割は、認証者が取引で取っている役割、たとえば商人や消費者を示す必要があります。
AUTHENTICATION REQUEST 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 SIGNATURE BLOCK (AUTHENTICATION REQUEST)
o 1つの認証要求コンポーネント（セクション7.2を参照）と署名ブロック（認証要求）
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
o IOTPメッセージとIOTPトランザクションを説明する情報を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
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 :
o TPOブロックの次のコンポーネント：
- 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
認証応答ブロック
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.
o 取引ロールの取引ロールリスト属性で特定されたすべての取引役割の1つの組織コンポーネントは、認証要求ブロックに含まれる情報要求コンポーネントです。
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
o IOTPメッセージとIOTPトランザクションを説明する情報を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
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
認証ステータスブロック
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を参照）を使用して、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
o IOTPメッセージとIOTPトランザクションを説明する情報を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
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
o TPO IOTPメッセージ（セクション9.1.2.3を参照）、または
o a TPO and Offer Response IOTP Message (see section 9.1.2.6)
o TPOと提供対応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.:
ブランド依存のオファードキュメント交換では、TPOブロックとオファー応答ブロックは、商人によって消費者に個別に送信されます。
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,
C --> M Offer information - outside scope of IOTP
2. Merchant decides which payment brand protocols, currencies and amounts apply, places then in a Brand List Component inside a TPO Block and sends to Consumer
2. 商人は、どの支払いブランドプロトコル、通貨、金額が適用されるかを決定し、その後、TPOブロック内のブランドリストコンポーネントに配置し、消費者に送信します
C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block
3. IOTP aware application started. Consumer selects the payment brand, payment protocol and currency/amount to use. Records selection in a Brand Selection Component and sends back to Merchant.
3. IOTP認識アプリケーションが開始されました。Consumerは、支払いブランド、支払いプロトコル、および使用する通貨/金額を選択します。ブランド選択コンポーネントの選択を記録し、商人に送り返します。
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. 消費者のチェックオファーはOKです。次に、TPOブロック、TPO選択ブロック、オファー応答ブロックのコンポーネントを組み合わせて、トランザクションの次のIOTPメッセージを作成し、必要な取引ロールに存在する場合は署名ブロックと一緒に送信します
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.
o キャンセルブロックを送信して、オファーのStatustype、故障のプロセスステート、および完了コード（セクション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.
o キャンセルブロックを送信することにより、IOTPトランザクションを継続しないことを示します。キャンセルブロックは、STATUSTYPEのオファー、故障のプロセスステート、および完了コード（セクション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.
o キャンセルブロックを送信して、オファーのStatustype、故障のプロセスステート、および完了コード（セクション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メッセージを受信した場合、消費者は、販売者の組織コンポーネントの取引ロール要素で指定された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ブロックとオファー応答ブロックの両方を含むIOTPメッセージが1つあります。
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,
C --> M Offer information - outside scope of IOTP
2. Merchant decides which payment brand protocols, currencies and amounts apply, places then in a Brand List Component inside a TPO Block, creates an Offer Response containing details about the IOTP Transaction including price, etc., optionally signs it and sends to Consumer
2. Merchantは、どの支払いブランドプロトコル、通貨、および金額が適用されるか、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認識アプリケーションが開始されました。Consumerは、支払いブランド、支払いプロトコル、および使用する通貨/金額を選択します。ブランド選択コンポーネントでのレコードの選択、チェックオファーはOKであり、ブランド選択コンポーネントをTPOブロックからの情報と組み合わせて、対応ブロックを提供してトランザクションの次のIOTPメッセージを作成し、必要な場合は署名ブロックと一緒に送信します取引の役割。
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.
ブランドの独立したオファードキュメント交換は、商人が消費者に1つの支払いブランド、プロトコル、通貨/金額のみが提供されている場合に常に発生することに注意してください。また、複数のブランドが提供され、支払いハンドラーが同じであり、すべてのブランドが同じプロトコルを使用している場合、必ずしも発生するとは限りませんが、必ずしも発生するとは限りません。
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認識アプリケーションは、最初の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.
o キャンセルブロックを送信して、オファーのStatustype、故障のプロセスステート、および完了コード（セクション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メッセージを受信した場合、消費者は、販売者の組織コンポーネントの取引ロール要素で指定された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（トレーディングプロトコルオプション）ブロック
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.
o IOTPトランザクション全体に適用されるオプションを定義する1つのプロトコルオプションコンポーネント。セクション7.1を参照してください。
o one Brand List Component (see section 7.7) for each Payment in the IOTP Transaction that contain one or more payment brands and protocols which may be selected for use in each payment
o 各支払いで使用するために選択できる1つ以上の支払いブランドとプロトコルを含むIOTPトランザクションの各支払いの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
- 支払いのための支払いハンドラー。支払いハンドラー組織コンポーネントの「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:
o 次の役割を持つ組織コンポーネント：
- DeliveryHandler who will be delivering the goods or services
- 商品やサービスを配信する配信ハンドラー
- DelivTo i.e. the person or Organisation which is to take delivery
- Delivto、つまり配達を受ける人または組織
AUTHENTICATION STATUS AND SIGNATURE BLOCKS
認証ステータスと署名ブロック
If the Offer Document Exchange was preceded by an Authentication Document Exchange, then the TPO IOTP Message may also contain:
オファードキュメントの交換の前に認証ドキュメント交換の前にある場合、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
応答ブロックを提供します
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属性を完了するように設定する必要があります
o one Order Component (see section 7.5) which contains details about the goods and services which are being purchased or the financial transaction which is taking place
o 購入されている商品とサービスに関する詳細、または行われている金融取引に関する1つの注文コンポーネント（セクション7.5を参照）
o one or more Payment Component(s) (see section 7.9) for each payment which is to be made
o 行われる各支払いについて、1つ以上の支払いコンポーネント（セクション7.9を参照）
o zero or one Delivery Components (see section 7.13) containing details of the delivery to be made if the IOTP Transaction includes a delivery
o IOTPトランザクションに配信が含まれている場合、配送の詳細を含むゼロまたは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
o IOTPメッセージとIOTPトランザクションを説明する情報を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
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 :
o TPOブロックの次のコンポーネント：
- 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)
o 取引プロトコルオプションブロック（セクション8.1を参照）
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（トレーディングプロトコルオプション）ブロック
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
応答ブロックを提供します
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).
オファードキュメントの交換の前に認証ドキュメント交換が行われた場合、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:
これは、オファー応答IOTPメッセージ（セクション9.1.2.5を参照）の署名ブロックと同じです。
o if the Offer Document Exchange is Brand Dependent then the Signature Component in the Signature Block additionally contains a Digest Element for the Brand Selection Component contained in the TPO Selection Block
o オファードキュメント交換がブランド依存性である場合、署名ブロックの署名コンポーネントには、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
o 消費者は、トランザクション内の以前のIOTPメッセージからの情報を使用して支払い要求IOTPメッセージを生成し、それを支払いハンドラーに送信することによって、支払いを要求することを要求します
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.
o 支払いハンドラーは、支払いのための領収書を含む消費者に支払い回答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
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. 消費者チェック支払い応答は問題ありません。オプションでは、記録保持目的のために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 支払い応答の交換プロトコルメッセージが完了した場合、または支払い応答を生成して送信します。
o indicate failure to continue with the Payment by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Payment, a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument or Unspecified.
o 支払いのStatustypeを含むステータスコンポーネント、失敗のプロセスステート、および完了コード（セクション7.16.4を参照）を含む消費者にキャンセルブロックを送信して、Brandnotsupp、currnotsupp、Paymtcelled、Autherror、Infcuffunds、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.
o Cancel Blockを支払いハンドラーに送信して支払いを続行しないことを示します。支払いのStatustype、故障のプロセスステート、および完了コード（セクション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 支払い応答の交換プロトコルメッセージが完了した場合、または支払い応答を生成して送信します。
o indicate failure to continue with the Payment by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Payment, a ProcessState of Failed and the CompletionCode (see section 7.16.2) set to either: PaymtCancelled or Unspecified.
o 支払いのステータス型、故障のプロセスステート、および完了コード（セクション7.16.2を参照）を含むステータスコンポーネントを含む消費者にキャンセルブロックを送信することにより、支払いを続行しないことを示します：PaymtCancelledまたは未定のいずれかに設定されています。
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.
o CANCELブロックを送信して、CANCELブロックを送信して、支払いのStatuSType、故障のプロセスステート、および完了コード（セクション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メッセージを受信した場合、消費者は、さらにアクションが行われる可能性のある支払いハンドラーの組織コンポーネントの取引ロール要素に指定された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メッセージを受信した場合、消費者は支払いを完了する必要がありますが、何らかの理由で取引を継続してはなりません。この場合、消費者は、それ以上のアクションが行われる可能性のある商人の組織コンポーネントの取引ロール要素に指定されたCancelNetlocnに移動する可能性があります。
Apart from a Transaction Reference Block (see section 3.3), this message consists of:
トランザクションリファレンスブロック（セクション3.3を参照）とは別に、このメッセージは以下で構成されています。
o a Payment Request Block, and
o 支払い要求ブロック、および
o an optional Signature Block
o オプションの署名ブロック
PAYMENT REQUEST 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:
o TPOブロックからの次のコンポーネント：
- the Organisation Components with the roles of Merchant and for the PaymentHandler that is being sent the Payment Request Block
- 商人の役割を備えた組織コンポーネントと、支払いリクエストブロックが送信されている支払いハンドラーのためのコンポーネント
- 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を参照）、または
- 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番目の支払いは、最初の支払いの支払いコンポーネントを識別する属性（セクション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
o 含める支払いハンドラーは、支払いのためにブランド選択コンポーネント（セクション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属性によって識別されたものです
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 オファーレスポンスブロックから含めるブランド選択コンポーネントは、2回目の支払いのブランドリストコンポーネントを識別する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を参照してください。
(see section 9.1.3.4 Payment Response IOTP Message) then they should both be copied to the Signature Block in the Payment Request IOTP Message.
（セクション9.1.3.4支払い応答IOTPメッセージを参照）その後、両方とも支払いリクエスト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
支払い交換ブロック
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 支払い応答ブロック、および
o an optional Signature Block
o オプションの署名ブロック
PAYMENT RESPONSE BLOCK
支払い応答ブロック
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)
署名ブロック（支払い対応）
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に設定されている署名付きPayreceipt属性によって示されている場合、署名ブロックには、以下のダイジェスト要素を含む署名コンポーネントを含める必要があります。
o the Transaction Reference Block (see section 3.3) for the IOTP Message which contains the first usage of the Payment Response Block,
o 支払い応答ブロックの最初の使用法を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）、
o the Transaction Id Component (see section 3.3.1) within the Transaction Reference Block that globally uniquely identifies the IOTP Transaction,
o トランザクションIDコンポーネント（セクション3.3.1を参照）は、IOTPトランザクションをグローバルに識別するトランザクション参照ブロック内のブロック内で、
o the Payment Receipt Component from the Payment Response Block,
o 支払い応答ブロックからの支払い領収書コンポーネント、
o the Payment Note Component from the Payment Response Block,
o 支払い応答ブロックからの支払いノートコンポーネント、
o the other Components referenced by the PayReceiptNameRefs attribute (if present) of the Payment Receipt Component,
o PayReceiptnamerefs属性（存在する場合）で参照される他のコンポーネント、支払い領収書コンポーネントの属性、
o the Status Component from the Payment Response Block,
o 支払い応答ブロックからのステータスコンポーネント、
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
o 配送リクエストを生成することで配達を要求する消費者は、トランザクション内の以前のIOTPメッセージからの情報を使用してIOTPメッセージを要求し、それを配達ハンドラーに送信する
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 配信ハンドラーは、オプションの署名と一緒にリクエストに対するハンドラーの応答に関する詳細を含む、消費者に配信応答を送信します。
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
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. 消費者チェック配信応答ブロックとオプションの署名ブロックは問題ありません。オプションでは、記録保持目的と停止のために、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.
o 配信のStatustype、故障のプロセスステート、および完了コード（セクション7.16.4を参照）を含むステータスコンポーネントを含む消費者にキャンセルブロックを送信することにより、配送を続行しないことを示します：DERIVCANCELED、または未定のいずれかに設定されています。
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
配信要求ブロック
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
- ：Merchant、DeliveryHandler、Delevertoの役割を備えた組織コンポーネント（セクション7.6を参照）
- the Delivery Component (see section 7.13)
- 配信コンポーネント（セクション7.13を参照）
o the following Component from the Payment Response Block:
o 支払い応答ブロックからの次のコンポーネント：
- 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
配信応答ブロック
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)
in3署名ブロック（配信応答）
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
o 配信応答署名を含むIOTPメッセージのトランザクションIDコンポーネント（セクション3.3.1を参照）
o the Transaction Reference Block (see section 3.3) of the IOTP Message that contains the Delivery Response Signature
o 配信応答署名を含むIOTPメッセージのトランザクションリファレンスブロック（セクション3.3を参照）
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
o 消費者は、トランザクション内の以前のIOTPメッセージからの情報を使用して支払い要求IOTPメッセージを生成し、それを支払いハンドラーに送信することによって、支払いを要求することを要求します
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:
o 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
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. 消費者は支払いの応答と配送の応答ブロックをチェックしてください。オプションでは、記録保持目的のために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.
オファー応答ブロック内に含まれる配信コンポーネント（セクション7.13を参照）のdelivandpayResp属性（セクション8.3を参照）は、配信応答ブロックと支払い応答ブロックが同じIOTPメッセージに結合され、falseに設定されている場合は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メッセージを受信した場合、消費者は、さらにアクションが行われる可能性のある支払いハンドラーの組織コンポーネントの取引ロール要素に指定された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メッセージを受信した場合、消費者は支払いを完了する必要がありますが、何らかの理由で取引を継続してはなりません。この場合、消費者は、それ以上のアクションが行われる可能性のある商人の組織コンポーネントの取引ロール要素に指定された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).
このメッセージの内容は、支払い文書交換の支払い要求IOTPメッセージと同じです（セクション9.1.3.2を参照）。
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 支払い応答ブロック、
o an optional Signature Block (Payment Response), and
o オプションの署名ブロック（支払い応答）、および
o a Delivery Response Block.
o 配信応答ブロック。
PAYMENT RESPONSE BLOCK
支払い応答ブロック
The content of this block is the same as the Payment Response Block in the Payment Response IOTP Message associated with a Payment Document Exchange (see section 9.1.3.4).
このブロックのコンテンツは、支払い文書交換に関連付けられた支払い応答IOTPメッセージの支払い応答ブロックと同じです（セクション9.1.3.4を参照）。
SIGNATURE BLOCK (PAYMENT RESPONSE)
署名ブロック（支払い対応）
The content of this block is the same as the Signature Block (Payment Response) in the Payment Response IOTP Message associated with a Payment Document Exchange (see section 9.1.3.4).
このブロックのコンテンツは、支払い文書交換に関連付けられた支払い応答IOTPメッセージの署名ブロック（支払い応答）と同じです（セクション9.1.3.4を参照）。
DELIVERY RESPONSE BLOCK
配信応答ブロック
The content of this block is the same as the Delivery Response Block in the Delivery Response IOTP Message associated with a Delivery Document Exchange (see section 9.1.4.3).
このブロックの内容は、配信ドキュメント交換に関連付けられた配信応答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
o 別のIOTPトランザクションの前
o at the same time as another IOTP Transaction
o 別のIOTPトランザクションと同時に
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 消費者に関する情報を含む組織コンポーネントで商人の役割を提供する手段として、取引の役割を削除する
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).
o 支払い文書交換（セクション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
セクション9.1.12「ドキュメント交換の有効な組み合わせ」を参照して、IOTPトランザクションの特定のインスタンスにドキュメント交換の組み合わせが適用されるかを決定します
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.
o 商人（金融機関）はいくつかの異なる種類の電子現金で預金を受け入れることができますが、電子現金を預けている消費者の役割は通常、預金したい現金の種類を知っているので、通常は実際には制約されています。1つのタイプのみ。ただし、同じ「ブランド」の電子現金に使用できるいくつかの異なるプロトコルがある場合があります。この場合、使用するプロトコルを交渉するのにブランド依存のオファーが適切かもしれません。
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:
o どちらか：
- 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 支払い文書交換のみ、または
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.
セクション9.1.12「ドキュメント交換の有効な組み合わせ」を参照して、IOTPトランザクションの特定のインスタンスに当てはまるドキュメント交換の組み合わせを決定します。
In business terms the refund process typically consists of:
ビジネス用語では、払い戻しプロセスは通常次のもので構成されています。
o a request for a refund being made by the Consumer to the Merchant, typically supported by evidence to demonstrate:
o 消費者が商人に行われる払い戻しの要求。通常、証拠を示すために証拠によってサポートされています。
- 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 次の2つの取引取引所を使用して、消費者への商人による払い戻し支払い：
- 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).
o 支払い文書交換（セクション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 商人（金融機関）は、いくつかの異なる種類の電子現金の撤回を提供できる場合があります。実際には、通常、電子現金の1つだけが提供される場合があります。ただし、同じ「ブランド」の電子現金に使用できるいくつかの異なるプロトコルがある場合があります。
o the Merchant (Financial Institution) may use the results of the authentication to identify not only the consumer but also the account from which the withdrawal is to be made. If no single account can be identified, then it must be obtained by other means. For example:
o 商人（金融機関）は、認証の結果を使用して、消費者だけでなく、撤退が行われるアカウントを特定することもできます。単一のアカウントを識別できない場合は、他の手段で取得する必要があります。例えば：
- 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 クレジットカードの電子キャッシュアドバンス。たとえば、最初の支払いはクレジットカードを使用した「ドルセットの支払い」であり、2番目の支払いはVisa Cash E-Cashのダウンロードです。
o foreign exchange using the same payment method. For example the payment could be an upload of Mondex value in British Pounds and the second a download of Mondex value in Euros
o 同じ支払い方法を使用した外国為替。たとえば、支払いはイギリスポンドのモンドックスバリューのアップロードであり、2番目はユーロでのモンドックスバリューのダウンロードになる可能性があります
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 異なる支払い方法を使用した外国為替。たとえば、最初の支払いは、カナダのドルの決済支払いである可能性があります。
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
o オファードキュメント交換（セクション9.1.2を参照）。これは、どの値と通貨が交換されるかの詳細を提供し、
o two Payment Document Exchanges (see section 9.1.3) which carry out the two payments involved.
o 関連する2つの支払いを実行する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.
TPOブロックとオファー応答ブロックは、値交換で使用される支払いブランドと支払いプロトコルを選択した結果として、オファー応答ブロックのコンテンツが変更されない場合にのみ、同じIOTPメッセージに結合できます。
BASELINE VALUE EXCHANGE SIGNATURES
ベースライン値交換署名
The use of signatures to ensure the integrity of a Baseline Value Exchange is illustrated by the diagram below.
ベースライン値交換の完全性を確保するための署名の使用は、以下の図に示されています。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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)
i) 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ブロックが含まれているが、応答ブロックが提供されない場合、次のとおりです。
i) IOTP Transaction includes a Brand Dependent Offer Document Exchange (see section 9.1.2.1). (Note 2)
i) 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)
i) IOTPトランザクションは、認証ドキュメント交換のみで構成されています。（注3）
2) Otherwise (no Authentication Request in first IOTP Message):
2) それ以外の場合は（最初のIOTPメッセージに認証要求はありません）：
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)
i) IOTPトランザクションには、ブランド独立オファードキュメント交換が含まれています（注2）
g) Otherwise (no Offer Response Block in first IOTP Message):
g) それ以外の場合は（最初のIOTPメッセージにオファー応答ブロックはありません）：
i) the IOTP Transaction includes a Brand Dependent Offer Document Exchange (Note 2)
i) 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)
ii）それ以外の場合（配信コンポーネントのdelivandpayResp属性はfalseに設定されています）
(1) the IOTP Transaction consists of a Payment Document Exchange (see section 9.1.3) followed by a Delivery Document Exchange (see section 9.1.4) (Note 4)
(1) IOTPトランザクションは、支払い文書交換（セクション9.1.3を参照）で構成されています。
i) otherwise (the Offer Response Block does not contain a Delivery Component)
i) それ以外の場合は（オファー応答ブロックには配信コンポーネントが含まれていません）
i) if the Offer Response Block contains just one Payment Component, then:
i) オファー応答ブロックに1つの支払いコンポーネントのみが含まれている場合、次のとおりです。
(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:
ii）オファー応答ブロックに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)
(1) IOTPトランザクションには、2つの支払いドキュメント交換が含まれています。支払いコンポーネントのStartter属性は、最初にどの支払いが発生するかを示すために使用されます（注6）
iii) if the Offer Response Block contains no or more than two Payment Components, then there is an error
iii）オファー応答ブロックに2つの支払いコンポーネントが含まれていない場合、またはエラーがあります
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トランザクションの妥当性に注意してください
1. Any Payment and Authentication IOTP Transaction
1. 支払いおよび認証IOTPトランザクション
2. Any Payment and Authentication IOTP Transaction except Baseline Authentication
2. ベースライン認証を除く支払いおよび認証IOTPトランザクション
3. Either Baseline Authentication, or a Baseline Purchase, Refund, Deposit, Withdrawal or Value Exchange with a failed Authentication
3. ベースライン認証、またはベースラインの購入、払い戻し、預金、引き出し、または認証の失敗との価値交換
4. Baseline Purchase only
4. ベースライン購入のみ
5. Baseline Purchase, Refund, Deposit or Withdrawal 6. Baseline Value Exchange only
5. ベースラインの購入、払い戻し、預金または引き出し6.ベースライン価値交換のみ
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
o 別の役割の認証を実行したいと判断した取引の役割は、実行中の現在のIOTPトランザクションを一時停止します
o a stand-alone Authentication transaction is then carried out. This may, at implementer's option, be linked to the original IOTP Transaction using a Related To Component (see section 3.3.3) in the Transaction Reference Block.
o その後、スタンドアロン認証トランザクションが実行されます。これは、実装者のオプションで、トランザクションリファレンスブロックのコンポーネント（セクション3.3.3を参照）に関連するAを使用して、元のIOTPトランザクションにリンクすることができます。
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
o 支払いハンドラーから支払い応答を受け取るまでの配送用の配送ハンドラーを認証し、配達リクエストを送信する前に
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
o 既存または完全なIOTPトランザクションのステータスに関する情報を提供するトランザクションステータス調査トランザクション、および
o Ping Transaction that enables one IOTP aware application to determine if the IOTP aware application at another Trading Role is operating and verify whether or not signatures can be handled.
o 1つのIOTP認識アプリケーションを可能にするPingトランザクションは、別の取引役割でのIOTP認識アプリケーションが動作しているかどうかを判断し、署名を処理できるかどうかを確認します。
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)
o 問い合わせ対応トレーディングブロック（セクション8.13を参照）
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 中断されたトランザクションを再開して、他の役割の1つの処理の現在の状態を決定するのを支援するために、
o for a merchant to determine if a payment, delivery, etc., was completed. For example, a Consumer might claim that payment was made but no signed IOTP payment receipt was available to prove it. If the Merchant makes an inquiry of the Payment Handler then the Merchant can determine whether or not payment was made.
o 商人が支払い、配達などが完了したかどうかを判断するために。たとえば、消費者は、支払いが行われたが、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
別の取引役割の問い合わせを行う
One Trading Role may make an inquiry of any other Trading Role at any point in time.
1つの取引の役割は、どの時点でも他の取引の役割を問い合わせている場合があります。
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
トランザクションステータス照会輸送セッション
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
トランザクションステータス照会エラー処理
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
o 技術的なエラー（セクション4.1を参照） - 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
お問い合わせトランザクションメッセージ
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.
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.
3. 最初の役割は、問い合わせ応答ブロックとオプションの署名をチェックし、適切なアクションまたはおそらく停止するものを取ります。これには、エンドユーザーにステータス情報を表示することが含まれます。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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
トランザクションリファレンスブロック
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コンポーネントと同じである場合（セクション3.3.1を参照）（セクション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
お問い合わせリクエストブロック
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.
o 1つの問い合わせタイプコンポーネント（セクション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)
o 1つの署名コンポーネント（セクション7.19を参照）
o one or more Certificate Components, if required.
o 必要に応じて、1つ以上の証明書コンポーネント。
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.
一方、問い合わせが関連する元のトランザクションが安全なチャネル（[SSL]など）で実行された場合、問い合わせの送信者が元のメッセージのトランザクションIDコンポーネントを知っている場合、おそらく合理的です（たとえば、タイムスタンプを含む）その後、問い合わせは本物である可能性があります。
INQUIRY RESPONSE 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,
o 1つのステータスコンポーネント（セクション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)
o 1つの署名コンポーネント（セクション7.19を参照）
o one or more Certificate Components, if required.
o 必要に応じて、1つ以上の証明書コンポーネント。
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)
o ping要求ブロック（セクション8.14を参照）
o a Ping Response Block (see section 8.15), and
o ping応答ブロック（セクション8.15を参照）、および
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.
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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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.
o pingリクエストのデータに署名する署名ブロック。
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.
o TPOやトランザクションステータス照会などの他のIOTPトランザクションメッセージとは異なり、進行中のトランザクションOは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 Awareアプリケーションは、署名ブロックを使用して、受信者が受信した署名を正常に処理および確認できることを確認できます。
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
トランザクションリファレンスブロック
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 Requestメッセージの送信者が署名ブロックを生成したことを示します。署名ブロックは、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を参照）には、次のコンポーネントが含まれています。o1つの署名コンポーネント（セクション7.19を参照）
o one or more Certificate Components, if required.
o 必要に応じて、1つ以上の証明書コンポーネント。
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
o ping応答メッセージの送信者の組織コンポーネント
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)
o 1つの署名コンポーネント（セクション7.19を参照）
o one or more Certificate Components, if required.
o 必要に応じて、1つ以上の証明書コンポーネント。
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は、ブランド要素のlogonetlocn属性（セクション7.7.1を参照）または組織コンポーネントから取得されます。ご了承ください：
- 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 x 32またはexsmall 32 x 20
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
o ブランドリストのいくつかのXML例
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の重要な機能の1つは、商人が消費者が選択を行うことができるブランドのリストを提供できることです。このセクションでは、関与しているものの概要を説明し、消費者がブランドと関連する支払い手段の選択をどのように実行できるかについてのガイダンスを提供します。カバー：
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",
o 支払い手段とブランドの定義 - 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
また、次のセクションを参照してください。Oブランドリストコンポーネント（セクション7.7）には、商人が消費者に提供するブランドのリストを含むXML要素の定義を含む、および
o Brand Selection Component (section 7.8) for details of how a Consumer records the Brand, currency, amount and payment protocol that was selected.
o ブランド選択コンポーネント（セクション7.8）は、消費者が選択されたブランド、通貨、金額、および支払いプロトコルを記録する方法の詳細について。
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 MasterCardやVisaなどのクレジットカード。
o a debit card such as MasterCard's Maestro;
o MasterCardのMaestroなどのデビットカード。
o a smart card based electronic cash payment instrument such as a Mondex Card, a GeldKarte card or a Visa Cash card
o Mondexカード、Geldkarteカード、Visa Cash Cardなどのスマートカードベースの電子キャッシュ支払い機器
o a software based electronic payment account such as a CyberCash or DigiCash account.
o CybercashやDigicashアカウントなどのソフトウェアベースの電子決済アカウント。
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 マスターカード、ビザ、アメリカンエクスプレス、ダイナーズクラブ、モンデックス、ゲルドカルテ、サイバーキャッシュなど、支払い協会および専有ブランド。
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)
- Brandsを保管します。たとえば、Walmart、Sears、Marks and Spencer（英国）など、特定の商人によって消費者に支払い機器が発行されます。
- cobrands, for example American Advantage Visa, where an Organisation uses their own brand in conjunction with, typically, a payment association Brand.
- Cobrands、たとえばAmerican Advantage Visa。組織は、通常、支払い協会のブランドと組み合わせて独自のブランドを使用しています。
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カードまたは通常のマスターカードのいずれかとして使用できる1つの日本の「UC」マスターカードがある場合があります。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」と「MasterCard」を2つの別々のブランドとして扱います。
o the consumer chooses a Brand, for example either "UC" or "MasterCard,
o 消費者は、たとえば「UC」または「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.
o Consumer IOTP Awareアプリケーションは、選択したブランドと一致する支払い手段を決定し、おそらくユーザー支援を使用して、使用する正しい支払い手段を選択します。
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 購入時。たとえば、消費者がWalmartのWebサイトで「Walmart MasterCard」で支払う場合、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 2番目（支払い機器発行者を介して利益を得る）は、オファーの応答が変更されることを必要としません
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 各プロモーションブランドは、商人が提供するブランドのリストの別のブランドとして識別されるべきです。たとえば、「Walmart」、「Sears」、「Marks and Spencer」、「American Advantage Visa」はそれぞれ別のブランドになります。
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 支払い手段または支払い方法のいくつかの機能を使用して、使用されているブランドを積極的に識別します。たとえば、ブランドのセット証明書を使用できる場合、または利用可能な場合、または
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 最初は、セットが利用可能であると仮定します。
o the second is only possible if the Merchant, or alternatively the Payment Handler, has access to card issuer information.
o 2つ目は、商人、または代わりに支払いハンドラーがカード発行者情報にアクセスできる場合にのみ可能です。
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.
o 支払いハンドラーは、支払い手段が有効なプロモーションブランド向けであることを確認し、そうでない場合は支払いに失敗する必要があります。
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.
o 消費者のIOTP認識アプリケーションは、商人が提供するブランドのリストに含まれる同様のコードに対して、アプリケーションが登録したプロモーションブランドのコードを一致させるアプリケーションです。
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認識アプリケーションがそのようなコードを取得できる方法は次のとおりです。
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,
o IOTPによって定義され、消費者IOTP認識アプリケーションまたはウォレットに事前ロードされたブランド識別子のいずれかを使用して、ウォレットの開発者によって、ウォレットがあります。
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
- この支払い方法を使用するブランドのセット証明書
- a code provided by the payment software which handles the particular payment method, this could apply to, for example, GeldKarte, Mondex, CyberCash and DigiCash,
- 特定の支払い方法を処理する支払いソフトウェアが提供するコードは、たとえばGeldkarte、Mondex、Cybercash、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.
新しいブランドIDは、IANAの手順に基づいて割り当てられます（セクション12 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のセットを事前にロードし、更新できる方法を提供することをお勧めします。たとえば、ソフトウェア開発者のWebサイトにアクセスします。
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>
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つのロイヤルティベース（British Airways MasterCard）と、購入の割引を一定の金額で提供する1つの店舗ベース（Walmart）で構成されています。
o two payment protocols:
o 2つの支払いプロトコル：
- SET (Secure Electronic Transactions) see [SET], and
- セット（セキュア電子トランザクション）を参照してください[セット]、および
- 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'
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>
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:
上記の例を使用して「ブリティッシュエアウェイズ」マスターカードが支払うために、2倍のエアマイルを獲得するために、ブランドの選択は次のとおりです。
<BrandSelection ID='C1.2'
<brandselection id = 'c1.2'
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 Mondex、Geldkarte、Cybercash、Digicashのいずれかを使用した支払い
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 MondexまたはCybercashが関与する支払いには、複数の支払いハンドラーが使用されています
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'
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'
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>
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)
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.
「Pay：」で始まるアルゴリズムを除き、IETFトレードメーリングリストのレビューと指定された専門家によって新しい値が割り当てられます。
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:
ブランド/ブランディッド初期ブランディッドの次のリストは、1999年6月1日に設定された証明書を申請した組織から取得されました。
"Amex" - American Express
「アメックス」 - アメリカンエクスプレス
"Dankort" - Dankort
「ダンコート」 - ダンコート
"JCB" - JCB
「JCB」-JCB
"Maestro" - Maestro
「マエストロ」 - マエストロ
"MasterCard" - MasterCard
「MasterCard」 - マスターカード
"NICOS" - NICOS
「ニコス」 - ニコス
"VISA" - Visa
「ビザ」 - ビザ
In addition the following Brand Id values are defined:
さらに、次のブランドID値が定義されています。
"Mondex"
「モンデックス」
"GeldKarte"
「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).
CurrencyMount/ Currencyコードは、CurrcodeTypeに依存します（以下のCurrcodeを参照）。
If CurrCodeType is "ISO4217-A" then the currency code is an alphabetic currency code as defined by [ISO4217].
CurrcodeTypeが「ISO4217-A」の場合、通貨コードは[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週間以内に異議がない場合は、「First Come First Serve」ベースで割り当てられます。
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の通貨コードタイプは、ロイヤルティや頻繁なフライヤーポイントなどの「新しい」PSUEDO通貨のサポートを可能にするように設計されています。この仕様を書く時点では、このタイプの通貨コードは定義されていません。
Element Type/ Attribute Values Attribute Name
要素タイプ/属性値属性名
CurrencyAmount/ "ISO4217-A" CurrCodeType "IOTP"
CurrencyMount/ "ISO4217-A" CurrcodeType "IOTP"
New values of CurrCodeType attribute are allocated following review on the IETF Trade mailing list and by the Designated Expert.
CurrcodeType属性の新しい値は、IETFトレードメーリングリストのレビューと指定された専門家によって割り当てられます。
DeliveryData/ "Post" DelivMethod
DeliveryData/ "Post" 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] )
「mime：mimetype」（[mime]で定義されているものと同じように、mimetypeはコンテンツタイプと同じでなければなりません）
"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 "mimetype」という形式である場合、[mime]で定義されているように、「mime" mimetype」の制御が定義されています。
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"
関連/「IoTpTransaction "RelationssType" Reference "
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
RelationtionsType属性の新しい値は、IETFトレードワーキンググループメーリングリストのレビューと指定された専門家によって割り当てられます。これには、追加のドキュメントの公開が必要になる場合があります。
Element Type/ Attribute Values Attribute Name delivery method is used.
要素タイプ/属性値属性名配信方法が使用されます。
Status/ Offer StatusType Payment Delivery
ステータス/オファーStatustype支払い配信
Authentication
認証
Unidentified
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.
ステータスタイプ属性の新しい値は、次のとおりに割り当てられます。oIETFトレードワーキンググループへの公開、取引交換、取引の役割、ステータスに関連する関連コンポーネント、およびIETF取引郵送に関するドキュメントのレビューを説明するRFCのリストと指定された専門家による。
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/「Consumer」Tradingrole「商人」
"PaymentHandler"
「支払いハンドラー」
"DeliveryHandler"
「DeliveryHandler」
"DelivTo"
「Delivto」
"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.
取引ロール属性の新しい値は、次のとおりに割り当てられます。oIETF取引ワーキンググループへの公開、取引交換、取引の役割、取引の役割に関連する関連コンポーネント、およびIETF取引に関する文書のレビューを説明するRFCのメーリングリストと指定された専門家による。
Note: The document describing new values for the Trading Role attribute may be
注：取引ロール属性の新しい値を説明するドキュメントは
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/「BaselineAuthintication "IoTptranStype" BaselineDeposit "
"BaselinePurchase"
「ベースライン購入」
"BaselineRefund"
「BaselinereFund」
"BaselineWithdrawal"
「ベースライン撤退」
"BaselineValueExchange"
「BaselineValueExchange」
"BaselineInquiry"
「Baselineinquiry」
"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.
IOTPTRANSTYPE属性の新しい値は、次のとおりに割り当てられます。OIETFトレードメーリングリストへの公開、新しいIOTPトランザクションを説明するRFC、およびIETFトレードワーキンググループメーリングリストのドキュメントのレビューと指定された専門家による。
Attribute/ Content (see Signature "OfferResponse" Component) "PaymentResponse"
属性/コンテンツ（署名「OfferResponse」コンポーネントを参照）「PayuneResponse」を参照してください
"DeliveryResponse"
「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.
署名のタイプを定義するコードの新しい値は、次のとおりに割り当てられます。OIETFトレードワーキンググループへの公開、署名が使用されている取引交換を説明するRFC、および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*
* *
******************************************************
******************************************************
* IOTP MESSAGE DEFINITION *
******************************************************
-->
<!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' >
<！要素iotpmessage（transrefblk、iotpsignatures？、errorblk？、（authreqblk | authstatusblk | cancelblk | dexibryreqblk | inficialreqblk | inquiresrespblk | fayexchblk | payreqblk | payreqblk | payreqblk | payreqblk | payreqblk | payreqblk | payreqblk | payreqblk | payreqblk ecectionblk）*）> <！attlist iotpmessage xmlns cdata 'iotp：ietf.org/iotp-v1.0'>
<!--
******************************************************
* TRANSACTION REFERENCE BLOCK DEFINITION *
******************************************************
-->
<!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 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 RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED >
<!--
******************************************************
* Packaged Content Common Element *
******************************************************
-->
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent
Name CDATA #IMPLIED
Content NMTOKEN "PCDATA"
Transform (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 >
<!-- AUTHENTICATION DATA COMPONENT -->
<!ELEMENT AuthReq (Algorithm, 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 >
<!-- TRADING ROLE INFO REQUEST COMPONENT -->
<!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 >
<!-- 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 >
<!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 PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials 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' >
<!-- BRAND LIST COMPONENT -->
<!ELEMENT BrandList (Brand+, ProtocolAmount+,
CurrencyAmount+, PayProtocol+) >
<!ATTLIST BrandList
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
ShortDesc CDATA #REQUIRED
PayDirection (Debit | Credit) #REQUIRED >
<!ELEMENT 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 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 CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount 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 >
<!-- 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 >
<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
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 >
<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment EMPTY >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
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 >
<!-- PAYMENT RECEIPT 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 >
<!-- 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 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 >
<!-- CONSUMER DELIVERY DATA 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 >
<!-- 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 >
<!-- TRADING ROLE DATA COMPONENT -->
<!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 >
<!-- ERROR COMPONENT -->
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
<!ELEMENT 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 PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
<!-- TPO SELECTION BLOCK -->
<!ELEMENT TpoSelectionBlk (BrandSelection+) >
<!ATTLIST TpoSelectionBlk
ID ID #REQUIRED >
<!-- OFFER RESPONSE BLOCK -->
<!ELEMENT OfferRespBlk (Status, Order?, Payment*,
Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
<!ATTLIST AuthReqBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION STATUS BLOCK -->
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk
ID ID #REQUIRED >
<!-- PAYMENT REQUEST BLOCK -->
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
<!-- PAYMENT EXCHANGE 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 >
<!-- DELIVERY RESPONSE BLOCK -->
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
ID ID #REQUIRED >
<!-- INQUIRY REQUEST 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 >
<!-- PING REQUEST BLOCK -->
<!ELEMENT PingReqBlk (Org*)>
<!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>
<!-- ERROR BLOCK -->
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
ID ID #REQUIRED >
<!-- CANCEL BLOCK -->
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk
ID ID #REQUIRED >
<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED
>
<!--
******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED
>
<!ELEMENT Manifest ( Algorithm+, Digest+, Attribute*, OriginatorInfo, RecipientInfo+ ) >
<！要素マニフェスト（アルゴリズム、ダイジェスト、属性*、OriginatorInfo、ReciontientInfo）>
<!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED >
<！ATTLIST MANIFEST LOCATORHREFBASE CDATA #IMPLIED>
<!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
ID ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED
>
<!ELEMENT Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
<!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!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 KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>
<!--
******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) ) >
<！要素証明書（発行者andSerialNumber、（value | locator））>
<!ATTLIST Certificate
ID ID #IMPLIED
type NMTOKEN #REQUIRED
>
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED
>
<!--
******************************************************
* IOTP SHARED COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
ID ID #IMPLIED
encoding (base64|none) 'base64'
>
<!ELEMENT Locator EMPTY>
<!ATTLIST Locator
xml:link CDATA #FIXED 'simple'
href CDATA #REQUIRED
>
This section contains a glossary of some of the terms used within this specification in alphabetical order.
このセクションには、この仕様内でアルファベット順に使用される用語のいくつかの用語集が含まれています。
NAME DESCRIPTION
名前の説明
Authenticator The Organisation which is requesting the authentication of another Organisation, and
認証者別の組織の認証を要求している組織、および
Authenticatee The Organisation being authenticated by an 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.
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
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)
この属性は、メッセージIDコンポーネントのソフトウェアID属性からコンテンツを識別できない場合はいつでもこの属性を含めることをお勧めします（セクション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.
ドキュメント交換ドキュメント交換は、インターネット経由で送信する必要がある実際のIOTPメッセージの数を最小限に抑えるために、2つの取引交換の一部またはすべてを同時に実装する2つの当事者間で交換されるIOTPメッセージのセットで構成されています。
Document Exchanges are combined together in sequence to implement a particular IOTP Transaction.
ドキュメント交換は、特定のIOTPトランザクションを実装するために順番に組み合わされます。
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.
デュアルブランドデュアルブランドとは、単一の支払い手段が2つの別々のブランドであるかのように使用されることを意味します。たとえば、UCカードまたは通常のマスターカードのいずれかとして使用できる1つの日本の「UC」マスターカードがある場合があります。UCカードブランドとMasterCardブランドには、それぞれ独自の支払いハンドラーを持つことができます。これは次のことを意味します。Oマーチャントは、たとえば「UC」と「MasterCard」を消費者にブランドのリストを提供する際に2つの別々のブランドとして扱います。Consumer IOTP Awareアプリケーションは、選択したブランドと一致する支払い手段を決定し、おそらくユーザー支援を使用して、使用する正しい支払い手段を選択します。
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ドキュメントです。それに含まれるドキュメントは次のもので構成されています：oトランザクションリファレンスブロックIOTPトランザクションを一意に識別するIOTPメッセージの一部、oオプションの署名ブロックは、IOTPトランザクションに関連する取引ブロックまたはトレーディングコンポーネントにデジタル的に署名するためのオプションのエラーブロックに関連する取引コンポーネントにデジタルに署名します。以前に受信したIOTPメッセージに含まれる技術的エラーに関するレポート、および
o a collection of IOTP Trading Blocks which carries the data required to carry out an IOTP Transaction.
o IOTPトランザクションを実行するために必要なデータを運ぶIOTPトレーディングブロックのコレクション。
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.
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
支払い手段は、商品消費者が商人が提供する商品またはサービスに対して支払う手段です。たとえば、MasterCardやVisaなどのクレジットカード。o MasterCardのMaestroなどのデビットカード。oスマートカードベースの電子現金支払い
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.
Mondexカード、Geldkarteカード、Visa Cash Cardなどの機器oサイバーキャッシュのサイバーコインやDigicashアカウントなどのソフトウェアベースの電子決済アカウント。
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.
プロモーションブランドAプロモーションブランドは、消費者がそのブランドに支払う場合、消費者は2つの方法で受信できる追加の利点を受け取ることを意味します。たとえば、消費者がWalmartのWebサイトで「Walmart MasterCard」で支払う場合、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.
領収書コンポーネント領収書コンポーネントは、取引交換が正常に完了した記録です。領収書の例には、支払い領収書と配達メモが含まれます。コンテンツは、取引交換の実行に使用されるテクノロジーに依存する場合があります。たとえば、安全な電子取引（セット）支払い領収書は、支払いの結果を記録するセット支払いメッセージで構成されています。
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.
応答ブロック応答ブロックは、取引交換が完了したことを示す取引ブロックです。リクエストブロックを送信した取引ロールの要求ブロックを受け取った取引役割によって送信されます。応答ブロックには、取引交換の完了に関する情報を含むステータスコンポーネントが含まれています。たとえば、取引交換が正常に完了したかどうかを示します。一部の取引交換の場合、応答ブロックには、取引交換の記録を形成する領収書コンポーネントが含まれています。領収書コンポーネントは、署名ブロックを使用してデジタルで署名して、完了を繰り返しできないようにすることができます。応答ブロックの例には、オファー応答、支払い対応、配送の応答が含まれます。
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.
ステータスコンポーネントステータスコンポーネントには、取引交換の状態を説明する情報が含まれています。
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
取引ブロック取引ブロックは、1つ以上の取引コンポーネントで構成されています。1つ以上の取引ブロックは、取引に参加しているさまざまな取引役割の間に[XML]ドキュメントの形で物理的に送信されるIOTPメッセージに含まれる場合があります。トレーディングブロックには、3つの主要なタイプがあります：o要求ブロック、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]
取引コンポーネント取引コンポーネントは、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.
取引交換取引交換は、取引所、2つの取引役割の間、一連の文書の間で構成されています。ドキュメントは、取引ブロックの形である場合があります。または、たとえばデータをWebページに入力することにより、他の手段によって転送される場合があります。各取引交換は、3つの主要な部分で構成されています。1ある取引ロール（イニシエーター）による要求ブロックの送信（イニシエーター）は、受信者とイニシエーター間の1つ以上の交換ブロックのオプションの交換、最終的には、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
トランザクショントランザクション参照ブロックは、IOTP参照ブロックトランザクションを識別します。識別するデータが含まれています。oトランザクションタイプ、o IOTPトランザクションは、グローバルに一意のトランザクション識別子を介して、IoTPトランザクション内のIOTPメッセージを介して、メッセージ識別子を介して一意に
The Transaction Reference Block may also contain references to other transactions which may or may not be IOTP Transactions
トランザクションリファレンスブロックには、IOTPトランザクションである場合とそうでない場合がある他のトランザクションへの参照も含まれている場合があります
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] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[DOM-HASH] Maruyama, H., Tamura, K. and N. Uramoto, "Digest Values for DOM (DOMHASH)", RFC 2803, April 2000.
[dom-hash] maruyama、H.、Tamura、K。and N. uramoto、「Digest for 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]米国政府のCAPstoneプロジェクトの一部であるDigital Signature Standard（DSS）の国立標準技術研究所（NIST）が発行したデジタル署名アルゴリズム（DSA）。
[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.ミラー。暗号化における楕円曲線の使用。暗号学の進歩-Crypto '85、ページ417-426、Springer-Verlag、1986年。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキードハッシング」、RFC 2104、1997年2月。
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[HTML] Berners -Lee、T。およびD. Connolly、「HyperText Markup Language -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）は、プラットフォームに依存しないハイパーテキストドキュメントを作成するために使用されるシンプルなマークアップ言語です。World Wide Web（W3C）コンソーシアムWebサイトをご覧ください：http：//www.w3.org/markup/
[HTTP] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[HTTP] Berners-Lee、T.、Fielding、R。and H. Frystyk、「HyperText Transfer Protocol-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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、T。and T. Berners-Lee、「HyperText Transfer Protocol-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.
[IOTPDSIG] Davidson、K。およびY. Kawatsura、「V1.0 Internet Open Trading Protocol（IOTP）のデジタル署名」、RFC 2802、2000年4月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[MIME] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[Mime] Crocker、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] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[Mime] Freed、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] Moore、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] Freed、N.、Klensin、J。and J. Postel、「多目的インターネットメール拡張機能（MIME）パート4：登録手順」、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] Freed、N。and 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]オープンプロファイリング標準。個人とWebサイト間のプロファイル情報の信頼できる交換のための組み込みのプライバシー保護手段を備えたフレームワークを提供する提案された標準。NetscapeやMicrosoftによって開発されています。
[RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（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. Adlemanデジタル署名とパブリックキー暗号システムを取得する方法。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>.
[セット]安全な電子トランザクション仕様、バージョン1.0、1997年5月31日。消費者と商人の証明書を使用したクレジットおよびデビットカードの支払いをサポートして、信頼性を確保します。ダウンロード：<http://www.setco.org>。
[SSL/TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[SSL/TLS] Dierks、T。およびC. Allen、「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]「Secure Hash Standard」、国立標準技術研究所、米国商務省、1995年4月。59Fed Reg。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を参照してください。
[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 |ISO/IEC 9594-8：1995、修正案を含む1：証明書延長（バージョン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推奨、World Wide Web Namespace]コンソーシアム、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
David Burdett Commerce One 4440 Rosewood Drive、Bldg 4 Pleasanton California 94588 USA
Phone: +1 (925) 520 4422
EMail: 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.
この文書の著者は、特に、この仕様の開発の形成段階で提供された途方もないサポートについて、Mondex International Limited（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
- Phillip Mullarkey、British Telecom Plc
- Andrew Marchewka, Canadian Imperial Bank of Commerce
- アンドリュー・マルチェウカ、カナダ帝国商業銀行
- Brian Boesch, CyberCash Inc.
- Brian Boesch、Cybercash Inc.
- Tom Arnold, CyberSource
- トム・アーノルド、サイバーズール
- Terry Allen, Commerce One (formally Veo Systems)
- テリー・アレン、コマース・ワン（正式にはVEOシステム）
- Richard Brown, GlobeSet Inc.
- リチャード・ブラウン、グローブセット社
- Peter Chang, Hewlett Packard
- ピーター・チャン、ヒューレット・パッカード
- Masaaki Hiroya, Hitachi Ltd
- 正教氏、日立株式会社
- Yoshiaki Kawatsura, Hitachi Ltd
- 川会、日立ヤシアキヤシヤシ
- Mark Linehan, International Business Machines
- マーク・ラインハン、国際ビジネスマシン
- Jonathan Sowler, JCP Computer Services Ltd
- Jonathan Sowler、JCP Computer Services Ltd
- John Wankmueller, MasterCard International
- John Wankmueller、Mastercard International
- Steve Fabes, Mondex International Ltd
- Steve Fabes、Mondex International Ltd
- Donald Eastlake 3rd, Motorola Inc (formerly International Business Machines Inc)
- Donald Eastlake 3rd、Motorola Inc（以前のInternational Business Machines Inc）
- Surendra Reddy, Oracle Corporation
- Surendra Reddy、Oracle Corporation
- Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)
- Akihiro Nakano、Plat Home、Inc。（Ex Hitachi Ltd）
- Chris Smith, Royal Bank of Canada
- カナダ王立銀行のクリス・スミス
- Hans Bernhard-Beykirch, SIZ (IT Development and Coordination
- Hans Bernhard-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. Reid Carlisle、Spyrus（Ex Citibank Universal Card Services、正式にAT＆T Universal Card Services）
- Efrem Lipkin, Sun Microsystems
- Efrem Lipkin、Sun Microsystems
- Tony Lewis, Visa International
- Tony Lewis、Visa International
The author would also like to thank the following organisations for their support:
著者はまた、次の組織のサポートに感謝したいと思います。
- Amino Communications
- アミノ通信
- DigiCash
- digicash
- Fujitsu
- 藤井
- General Information Systems
- 一般情報システム
- Globe Id Software
- Globe IDソフトウェア
- Hyperion
- ハイペリオン
- InterTrader
- インタートレーダー
- Nobil I T Corp
- Nobil I T Corp
- Mercantec
- Mercantec
- Netscape
- netscape
- Nippon Telegraph and Telephone Corporation
- Nippon Telegraph and Telephone Corporation
- Oracle Corporation
- Oracle Corporation
- Smart Card Integrations Ltd.
- Smart Card Integrations Ltd.
- Spyrus
- スピルス
- Verifone
- Verifone
- Unisource nv
- Unisource NV
- Wells Fargo Bank
- ウェルズファーゴバンク
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。