Network Working Group D. Burdett
Request for Comments: 2801 Commerce One
Category: Informational April 2000
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.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Secure Channel Credit/Debit, Mondex, CyberCoin, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the Payment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party.
互联网开放交易协议（IOTP）为互联网商务提供了一个可互操作的框架。它是独立于支付系统的，并封装了支付系统，如SET、安全通道贷记/借记、Mondex、CyberCoin、Geldkart等。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
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
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
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
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
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
图1 IOTP交易角色16图2提供交易所19图3支付交易所22图4交付交易所25图5认证交易所27图6 IOTP消息结构33图7 IOTP交易34图8 ID属性的示例使用46图9元素引用48图10签名摘要79图11使用示例基线购买签名81图12检查支付处理程序可以执行支付87图13检查交付处理程序可以执行交付90图14交易组件94图15品牌列表元素关系113图16交易块164图17支付和验证消息流组合187图18认证文件交换190图19品牌相关报价文件交换196图20品牌独立报价交换198图21支付文件交换204图22交付文件交换210图23支付和交付文件交换214图24基线认证IOTP交易217图25基线存款物联网交易219图26基线购买物联网交易221图27基线退款物联网交易223图28基线取款物联网交易225图29基线值交换物联网交易228图30基线值交换签名230图31有效的文件交换组合231图32基线事务状态查询238图33基线Ping消息242
The Internet Open Trading Protocol (IOTP) provides an interoperable framework for Internet commerce. It is payment system independent and encapsulates payment systems such as SET, Mondex, CyberCash, DigiCash, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the Payment Handler, the Delivery Handler of goods or services, and the provider of customer support are performed by different parties or by one party.
互联网开放交易协议（IOTP）为互联网商务提供了一个可互操作的框架。它独立于支付系统，封装了SET、Mondex、CyberCash、DigiCash、Geldkart等支付系统。IOTP能够处理诸如购物网站、支付处理人、商品或服务交付处理人等商户角色，客户支持的提供者由不同的方或一方执行。
The developers of IOTP seek to provide a virtual capability that safely replicates the real world, the paper based, traditional, understood, accepted methods of trading, buying, selling, value exchanging that has existed for many hundreds of years. The negotiation of who will be the parties to the trade, how it will be conducted, the presentment of an offer, the method of payment, the provision of a payment receipt, the delivery of goods and the receipt of goods. These are events that are taken for granted in the course of real world trade. IOTP has been produced to provide the same for the virtual world, and to prepare and provide for the introduction of new models of trading made possible by the expanding presence of the virtual world.
IOTP的开发者寻求提供一种虚拟能力，安全地复制现实世界，即已有数百年历史的基于纸面、传统、可理解、可接受的交易、买卖和价值交换方法。谁将成为贸易的当事方，如何进行谈判，提出报价，付款方式，提供付款收据，交付货物和接收货物。这些事件在现实世界的贸易过程中被视为理所当然。IOTP的产生是为了为虚拟世界提供同样的服务，并为虚拟世界不断扩大的存在所带来的新交易模式的引入做好准备和准备。
The other fundamental ideal of the IOTP effort is to produce a definition of these trading events in such a way that no matter where produced, two unfamiliar parties using electronic commerce capabilities to buy and sell that conform to the IOTP specifications will be able to complete the business safely and successfully.
IOTP工作的另一个基本理想是以这样一种方式对这些交易事件进行定义，即无论在何处产生，使用符合IOTP规范的电子商务功能进行买卖的两个陌生方都将能够安全、成功地完成业务。
In summary, IOTP supports:
总之，IOTP支持：
o Familiar trading models
o 熟悉的交易模式
o New trading models
o 新的交易模式
o Global interoperability
o 全球互操作性
The remainder of this section provides background to why IOTP was developed. The specification itself starts in the next chapter.
本节剩余部分提供了开发IOTP的背景。规范本身从下一章开始。
The growth of the Internet and the advent of electronic commerce are bringing about enormous changes around the world in society, politics and government, and in business. The ways in which trading partners communicate, conduct commerce, are governed have been enriched and changed forever.
互联网的发展和电子商务的出现正在给世界各地的社会、政治、政府和商业带来巨大的变化。贸易伙伴沟通、开展贸易和治理的方式已经不断丰富和改变。
One of the very fundamental changes about which IOTP is concerned is taking place in the way consumers and merchants trade. Characteristics of trading that have changed markedly include:
IOTP关注的一个非常根本的变化是消费者和商家的交易方式发生了变化。发生显著变化的交易特征包括：
o Presence: Face-to-face transactions become the exception, not the rule. Already with the rise of mail order and telephone order placement this change has been felt in western commerce. Electronic commerce over the Internet will further expand the scope and volume of transactions conducted without ever seeing the people who are a part of the enterprise with whom one does business.
o 在场：面对面交易成为例外，而不是规则。随着邮购和电话订购的兴起，西方商业已经感受到了这种变化。通过互联网进行的电子商务将进一步扩大交易的范围和数量，而不必看到与之有业务往来的企业成员。
o Authentication: An important part of personal presence is the ability of the parties to use familiar objects and dialogue to confirm they are who they claim to be. The seller displays one or several well known financial logos that declaim his ability to accept widely used credit and debit instruments in the payment part of a purchase. The buyer brings government or financial institution identification that assures the seller she will be paid. People use intangibles such as personal appearance and conduct, location of the store, apparent quality and familiarity with brands of merchandise, and a good clear look in the eye to reinforce formal means of authentication.
o 身份验证：个人存在的一个重要部分是双方能够使用熟悉的对象和对话来确认自己是谁。卖方展示一个或多个众所周知的金融标识，表明其在购买的付款部分接受广泛使用的信用和借记工具的能力。买方带来政府或金融机构的身份证明，以确保卖方将获得付款。人们使用无形资产，如个人外观和行为、商店位置、外观质量和对商品品牌的熟悉程度，以及良好清晰的眼神来强化正式的认证手段。
o Payment Instruments: Despite the enormous size of bank card financial payments associations and their members, most of the world's trade still takes place using the coin of the realm or barter. The present infrastructure of the payments business cannot economically support low value transactions and could not survive under the consequent volumes of transactions if it did accept low value transactions.
o 支付工具：尽管银行卡金融支付协会及其成员规模巨大，但世界上大多数贸易仍然使用货币或易货进行。支付业务的现有基础设施在经济上无法支持低价值交易，如果接受低价值交易，则无法在随后的交易量下生存。
o Transaction Values: New meaning for low value transactions arises in the Internet where sellers may wish to offer for example, pages of information for fractions of currency that do not exist in the real world.
o 交易价值：互联网上出现了低价值交易的新含义，卖家可能希望提供例如真实世界中不存在的部分货币的信息页面。
o Delivery: New modes of delivery must be accommodated such as direct electronic delivery. The means by which receipt is confirmed and the execution of payment change dramatically where the goods or services have extremely low delivery cost but may in fact have very high value. Or, maybe the value is not high, but once delivery occurs the value is irretrievably delivered so payment must be final and non-refundable but delivery nonetheless must still be confirmed before payment. Incremental delivery such as listening or viewing time or playing time are other models that operate somewhat differently in the virtual world.
o 交付：必须适应新的交付方式，如直接电子交付。当货物或服务的交付成本极低，但实际上可能具有很高的价值时，确认收货和付款的方式会发生巨大变化。或者，可能价值不高，但一旦交付，价值就无法挽回，因此付款必须是最终的，不可退款，但交付仍必须在付款前确认。增量交付（如收听或观看时间或播放时间）是虚拟世界中运行方式有所不同的其他模式。
ELECTRONIC COMMERCE SOFTWARE VENDORS
电子商务软件供应商
Electronic Commerce Software Vendors will be able to develop e-commerce products which are more attractive as they will inter-operate with any other vendors' software. However, since IOTP focuses on how these solutions communicate, there is still plenty of opportunity for product differentiation.
电子商务软件供应商将能够开发更具吸引力的电子商务产品，因为它们将与任何其他供应商的软件进行交互操作。然而，由于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 他们将能够为商家提供物联网支持
o they will find new opportunities for IOTP related services:
o 他们将发现物联网相关服务的新机会：
- 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.
该协议旨在适用于任何电子支付方案，因为它针对的是完整的购买流程，其中电子价值从付款人转移到收款人只是完成交易可能涉及的许多步骤中的一个，但很重要。
Payment Scheme which IOTP could support include MasterCard Credit, Visa Credit, Mondex Cash, Visa Cash, GeldKarte, eCash, CyberCoin, Millicent, Proton, etc.
IOTP可支持的支付方案包括万事达信用卡、Visa信用卡、Mondex现金、Visa现金、Geldkart、eCash、CyberCoin、Millicent、质子等。
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 第4节-IOTP错误处理
o Section 5 - Security Considerations
o 第5节-安全考虑
o Section 9 - Internet Open Trading Protocol Transactions
o 第9节-互联网公开交易协议交易
o Section 11 - Brands
o 第11节-品牌
o Section 12 - IANA Considerations
o 第12节-IANA考虑因素
o Section 10 - Retrieving Logos
o 第10节-检索徽标
Review the detailed XML definitions:
查看详细的XML定义：
o Section 8 - Trading Blocks
o 第8节-交易区块
o Section 7 - Trading Components
o 第7节-贸易组成部分
o Section 6 - Digital Signatures and IOTP
o 第6节-数字签名和IOTP
The Internet Open Trading Protocols (IOTP) define a number of different types of IOTP Transactions:
互联网开放交易协议（IOTP）定义了许多不同类型的IOTP交易：
o Purchase. This supports a purchase involving an offer, a payment and optionally a delivery
o 购买这支持包含报价、付款和可选交付的购买
o Refund. This supports the refund of a payment as a result of, typically, an earlier purchase
o 退款这支持因提前购买而退款
o Value Exchange. This involves two payments which result in the exchange of value from one combination of currency and payment method to another
o 价值交换。这涉及到两次支付，导致从一种货币和支付方式组合到另一种货币和支付方式的价值交换
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 发出砰的声响。这支持一个简单的查询，该查询使一个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中使用的五个交易角色如下图所示。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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 |
----------
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 在最简单的情况下，一个实体组织（如商户）可以处理购买、接受付款、交付货物并提供商户客户服务
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 在另一个极端，商家可以处理购买，但要求消费者向银行或金融机构付款，要求由隔夜快递公司送货，并在出现问题时联系提供全天候服务的组织。
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:
互联网开放交易协议确定了四个交易交易所，涉及交易角色之间的数据交换。交易所包括：
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价值交换交易由一个要约交易交易所和两个支付交易交易所组成。
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.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
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
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 价值交换将涉及两次付款
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.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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. 商户决定提供哪种支付品牌、支付协议和货币/金额，然后将其放入品牌列表组件并发送给消费者
C <-- M Components: Brand List
C<--M部件：品牌列表
3. Consumer selects the payment brand, protocol and currency/amount to use, creates a Brand Selection component and sends it to the Merchant
3. 消费者选择要使用的支付品牌、协议和货币/金额，创建品牌选择组件并将其发送给商户
C --> M Component: Brand List Selection
C --> M 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
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
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
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
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
o 品牌列表组件包含支付品牌（例如，万事达卡、Visa卡、Mondex、Geldkart）、支付协议（例如SET版本1.0、安全渠道信用借记卡（SCCD）-用于信用卡或借记卡支付的名称，其中
unauthorised access to account information is prevented through use of secure channel transport mechanisms such as SSL/TLS) as well as currencies/amounts that apply. The Merchant sends the Brand List to the Consumer. The consumer compares the payment brands, protocols and currencies/amounts on offer with those that the Consumer supports and makes a selection.
通过使用安全通道传输机制（如SSL/TLS）以及适用的货币/金额，防止未经授权访问帐户信息。商家将品牌列表发送给消费者。消费者将提供的支付品牌、协议和货币/金额与消费者支持的支付品牌、协议和货币/金额进行比较，并做出选择。
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
o 支付方案组件包含来自交易中使用的支付协议的消息。例如，它们可以是SET消息、Mondex消息、GeldKarte消息或IOTP支持的其他支付方法之一。付款内容
Scheme Component is defined in the supplements that describe how IOTP works with various payment protocols.
补充说明中定义了方案组件，说明了IOTP如何与各种支付协议协同工作。
o The Payment Receipt Component contains a record of the payment. The content depends upon the payment protocol used.
o 付款收据组件包含付款记录。内容取决于所使用的支付协议。
o The "Payment Receipt" Signature Component provides proof of payment by digitally signing both the Payment Receipt Component and the Offer Response Signature. The signature on the offer digitally signs the Order, Organisation and Delivery Components contained in the Offer. This signature effectively binds the payment to the offer.
o “付款收据”签名组件通过对付款收据组件和报价响应签名进行数字签名来提供付款证明。报价上的签名对报价中包含的订单、组织和交付组件进行数字签名。此签名有效地约束付款与报价。
The example of a Payment Exchange above is the most general case. Simpler cases are also possible. For example, if the amount paid is not dependent on the payment brand and protocol selected then the payment information generated by step 3 can be sent to the Consumer at the same time as the Brand List Component generated by step 1. These and other variations are described in the Baseline Purchase IOTP Transaction (see section 9.1.8).
上面的支付交换示例是最常见的情况。更简单的情况也是可能的。例如，如果支付的金额不依赖于所选择的支付品牌和协议，则步骤3生成的支付信息可以与步骤1生成的品牌列表组件同时发送给消费者。基线采购IOTP交易（见第9.1.8节）中描述了这些变化和其他变化。
The goal of the Delivery Exchange is to cause purchased goods to be delivered to the consumer either online or via physical delivery. A second goal is to provide a "delivery note" to the consumer, providing details about the delivery, such as shipping tracking number. The result of the delivery may also be signed so that it can be used for customer care in the case of problems with physical delivery. The message flow is illustrated in the diagram below.
交付交换的目标是使购买的商品通过在线或实物交付交付给消费者。第二个目标是向消费者提供“送货单”，提供有关送货的详细信息，如送货跟踪号。还可以签署交付结果，以便在实际交付出现问题时用于客户护理。消息流如下图所示。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
CONSUMER DELIVERY
| HANDLER
| Merchant |
STEP | | |
1. Consumer decides to trade and sends information
about what to deliver and who is to take delivery,
to the Merchant e.g., using HTML.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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)
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
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 Delivery组件包含有关如何进行传递的信息，例如通过邮寄或使用电子邮件。
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.
身份验证交换的目标是允许一个组织（例如金融机构）能够检查另一个组织（例如消费者）是否是他们看起来的样子。
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
+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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. 第二个组织生成认证请求（包括质询数据和可用于认证的算法列表）和/或组织信息请求，然后将其发送给第一个组织
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. 第一组织选择性地检查与认证请求相关联的任何签名，然后使用指定的认证算法生成认证响应，该认证响应连同所请求的任何组织信息的细节一起发送回第二组织
1 --> 2 AUTHENTICATION RESPONSE. Component: Authentication
Response, Organisation(s)
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:
认证交易所使用两个组织之间传递的以下交易组件：
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实施范围的主要决定因素是解决方案设计支持的角色。第2.1节“交易角色”对IOTP中的角色进行了更详细的描述。概括而言，这些角色包括：商户、消费者、支付处理人、交付处理人和客户服务提供商。
Payment Handlers who can be of three types:
支付处理人可以有三种类型：
o those who accept a payment as part of a purchase or make a payment as part of a refund,
o 接受付款作为购买的一部分或付款作为退款的一部分，
o those who accept value as part of a deposit transaction, or
o 接受价值作为存款交易一部分的人，或
o those that issue value a withdrawal transaction
o 那些发行货币的人有权进行取款交易
The following table defines, for each role, the IOTP Transactions and Trading Blocks which must be supported for that role.
下表为每个角色定义了该角色必须支持的IOTP交易和交易区块。
Merchants
商人
ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler
易趣易趣易趣易趣商店价值消费者支付交付发卡机构收单机构处理人
TRANSACTIONS
交易
Purchase Must Must
购买必须
Merchants
商人
ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler
易趣易趣易趣易趣商店价值消费者支付交付发卡机构收单机构处理人
Refund Must b) Depends
退款必须视情况而定
Authentication May Must May b) Depends
身份验证可能必须b）取决于
Value Exchange May Must
价值交换可能必须进行
Withdrawal Must b) Depends
撤回必须视情况而定
Deposit Must b) Depends
押金必须视情况而定
Inquiry Must Must Must May Must Must
必须进行调查
Ping Must Must Must May Must Must
必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必必
TRADING BLOCKS
交易区块
TPO Must Must Must Must
TPO必须
TPO Selection Must Must Must Must
必须选择TPO
Auth-Request a) a) a) Depends Depends Depends
身份验证请求a）a）a）取决于
Auth-Reply a) a) a) Depends Depends Depends
认证回复a）a）a）取决于
Offer Response Must Must Must Must
必须提供响应
Payment Must Must Request
必须要求付款
Payment Must Must Exchange
付款必须兑换
Payment Must Must Response
付款必须有回应
Delivery Must Must Request
必须按要求交货
Delivery Must Must Response
交付必须有响应
Merchants
商人
ECash ECash Store Value Value Consumer Payment Delivery Issuer Acquirer Handler Handler
易趣易趣易趣易趣商店价值消费者支付交付发卡机构收单机构处理人
Inquiry Must Must Must Must Must Must Request
查询必须请求
Inquiry Must Must Must Must Must Must Response
查询必须答复
Ping Request Must Must Must Must Must Must
Ping请求必须
Ping Response Must Must Must Must Must Must
Ping响应必须是
Signature Must Must Must Limited Must Must
签名必须有限制
Error Must Must Must Must Must Must
必须是错误
In the above table:
在上表中：
o "Must" means that a Trading Role must support the Transaction or Trading Block.
o “必须”是指交易角色必须支持交易或交易区块。
o "May" means that an implementation may support the Transaction or Trading Block at the option of the developer.
o “可”是指一个实现可支持开发商选择的交易或交易区块。
o "Depends" means implementation of the Transaction or Trading Block depends on one of the following conditions:
o “依赖”是指交易或交易区块的实施取决于以下条件之一：
- if Baseline Authentication IOTP Transaction is supported;
- 是否支持基线认证IOTP事务；
- if required by a Payment Method as defined in its IOTP Supplement document.
- 如果IOTP补充文件中规定的付款方式要求。
o "Limited" means the Trading Block must be understood and its content manipulated but not in every respect. Specifically, on the Signature Block, Consumers do not have to be able to validate digital signatures.
o “有限”是指交易区块必须被理解，其内容必须被操纵，但不是在所有方面。具体而言，在签名块上，消费者不必能够验证数字签名。
An IOTP solution must support all the IOTP Transactions and Trading Blocks required by at least one role (column) as described in the above table for that solution to be described as "supporting IOTP".
IOTP解决方案必须支持至少一个角色（列）所需的所有IOTP交易和交易区块，如上表所述，该解决方案将被描述为“支持IOTP”。
The previous section provided an introduction which explained:
上一节介绍了以下内容：
o Trading Roles which are the different roles which Organisations can take in a trade: Consumer, Merchant, Payment Handler, Delivery Handler and Customer Care Provider, and
o 交易角色，即组织在交易中可以扮演的不同角色：消费者、商户、支付处理人、交付处理人和客户服务提供商，以及
o Trading Exchanges where each Trading Exchange involves the exchange of data, between Trading Roles, in the form of a set of Trading Components.
o 交易交易所，其中每个交易交易所涉及交易角色之间以一组交易组件的形式交换数据。
This section describes:
本节介绍：
o how Trading Components are constructed into Trading Blocks and the IOTP Messages which are physically sent in the form of [XML] documents between the different Trading Roles,
o 如何将交易组件构建成交易块以及不同交易角色之间以[XML]文档形式物理发送的IOTP消息，
o how IOTP Messages are exchanged between Trading Roles to create an IOTP Transaction
o 如何在交易角色之间交换IOTP消息以创建IOTP交易
o the XML definitions of an IOTP Message including a Transaction Reference Block - an XML element which identifies an IOTP Transaction and the IOTP Message within it
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.
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
该图还介绍了事务参考块的概念。除其他外，该块包含IOTP事务的全局唯一标识符。此外，每个块和组件都有一个ID属性（见第3.4节），该属性在IOTP事务中是唯一的。因此，ID属性和
the globally unique identifier in the Transaction Reference Block is sufficient to uniquely identify any Trading Block or Trading Component.
交易参考区块中的全局唯一标识符足以唯一标识任何交易区块或交易组件。
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
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 价值交换。这涉及到两次支付，导致从一种货币和支付方式组合到另一种货币和支付方式的价值交换
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这支持一个简单的查询，该查询使一个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?,
<!元素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'
（AuthReqBlk | AuthRespBlk | AuthStatusBlk | CancelBlk | DeliveryReqBlk | DeliveryReqBlk | InquiryReqBlk | InquiryRespBlk | offerSpblk | payerqblk | payrecblk | payrecblk | payrecblk | payrecblk | payrecblk | PingReqBlk | PingReqBlk | PingRespBlk！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，这些是交易区。authrepblk，DeliveryReqBlk，IOTP消息中存在的交易区块，DeliveryReqBlk和交易区块本身的内容是ErrorBlk，这取决于正在执行的IOTP交易的类型-请参阅第9节互联网公开交易报价中每个InquiryReqBlk，交易的定义，协议事务。PayXchBLK，PayReqBlk，每个交易区块的完整定义为PayResBLK，如第8节所述。PingReqBlk、PingRespBlk、SigBlk、TpoBlk、TPOSELECTBLK
Attributes:
属性：
xmlns The [XML Namespace] definition for IOTP messages.
xmlns IOTP消息的[XML命名空间]定义。
The IOTP Message is the root element of the XML document. It therefore needs to be preceded by an appropriate XML Document Prolog. For example:
IOTP消息是XML文档的根元素。因此，它前面需要有一个适当的XML文档序言。例如：
<?XML Version='1.0'?>
<!DOCTYPE IotpMessage >
<IotpMessage>
...
</IotpMessage>
<?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组件。包含单个IOTP事务的所有IOTP消息中的事务Id组件相同，
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 消息Id组件，其提供关于IOTP消息的控制信息以及在IOTP事务中唯一标识IOTP消息，以及
o zero or more Related To Components which link this IOTP Transaction to either other IOTP Transactions or other events using the identifiers of those events.
o 零或更多与使用这些事件的标识符将此IOTP事务链接到其他IOTP事务或其他事件的组件相关。
The definition of a Transaction Reference Block is as follows:
事务参考块的定义如下：
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
Attributes:
属性：
ID An identifier which uniquely identifies the Transaction Reference Block within the IOTP Transaction (see section 3.4 ID Attributes).
ID唯一标识IOTP事务中事务参考块的标识符（参见第3.4节ID属性）。
Content:
内容：
TransId See 3.3.1 Transaction Id Component immediately below.
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 >
<!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
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的值根据第12节IANA注意事项中描述的程序进行管理，该节还允许定义用户定义的IotpTransType值。
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事务。它还可能支持Dynamic类型，这表明事务中的步骤顺序是非标准的。
TransTimeStamp Where the system initiating the IOTP Transaction has an internal clock, it is set to the time at which the IOTP Transaction started in [UTC] format.
TransTimeStamp如果启动IOTP事务的系统具有内部时钟，则将其设置为以[UTC]格式启动IOTP事务的时间。
The main purpose of this attribute is to provide an alternative way of identifying a transaction by specifying the time at which it started.
此属性的主要目的是提供一种通过指定事务开始的时间来标识事务的替代方法。
Some systems, for example, hand held devices may not be able to generate a time stamp. In this case this attribute should contain the value "NA" for Not Available.
一些系统，例如手持设备可能无法生成时间戳。在这种情况下，此属性应包含值“NA”，表示不可用。
The Message Id Component provides control information about the IOTP Message as well as uniquely identifying the IOTP Message within an IOTP Transaction. Its definition is as follows.
消息Id组件提供有关IOTP消息的控制信息，以及在IOTP事务中唯一标识IOTP消息。其定义如下。
<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
ID ID #REQUIRED
RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED
SenderTradingRoleRef NMTOKEN #IMPLIED
SoftwareId CDATA #REQUIRED
TimeStamp CDATA #IMPLIED >
<!ELEMENT MsgId EMPTY >
<!ATTLIST MsgId
ID ID #REQUIRED
RespIotpMsg NMTOKEN #IMPLIED
xml:lang NMTOKEN #REQUIRED
LangPrefList NMTOKENS #IMPLIED
CharSetPrefList NMTOKENS #IMPLIED
SenderTradingRoleRef NMTOKEN #IMPLIED
SoftwareId CDATA #REQUIRED
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消息，则此属性的值保持不变。
RespIotpMsg This contains the ID attribute of the Message Id Component of the IOTP Message to which this IOTP Message is a response. In this way all
RespIotpMsg包含IOTP消息的消息ID组件的ID属性，该IOTP消息是对其的响应。就这样
the IOTP Messages in an IOTP Transaction are unambiguously linked together. This field is required on every IOTP Message except the first IOTP Message in an IOTP Transaction.
IOTP事务中的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.
SenderTradingRole已生成IOTP消息的交易角色的元素参考（见第3.5节）。它用于确定交易角色的净位置（见第3.9节），应向其报告任何交易区块的技术错误问题（见第4.1节）。
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.
LangPrefList符合[XML]语言标识的语言代码的可选列表。发送方使用它按首选顺序指示消息接收方在生成响应时理想情况下应该使用的语言。接收方没有义务使用其中一种指定语言进行响应，但使用其中一种语言可能会提供更好的用户体验。
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:
SoftwareId包含识别生成IOTP消息的软件的信息。其目的是帮助解决由于不同软件生成的消息之间不兼容而可能出现的互操作性问题。它是xml:lang定义的语言中的单个文本字符串。它必须至少包含：
o the name of the software manufacturer o the name of the software o the version of the software, and o the build of the software
o 软件制造商的名称o软件的名称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.
时间戳如果发送消息的设备具有内部时钟，则将其设置为以[UTC]格式创建IOTP消息的时间。
The Related To Component links IOTP Transactions to either other IOTP Transactions or other events using the identifiers of those events. Its definition is as follows.
“关联到”组件使用这些事件的标识符将IOTP事务链接到其他IOTP事务或其他事件。其定义如下。
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED
Relation CDATA #REQUIRED
RelnKeyWords NMTOKENS #IMPLIED >
<!ELEMENT RelatedTo (PackagedContent) >
<!ATTLIST RelatedTo
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
RelationshipType NMTOKEN #REQUIRED
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:
RelationshipType定义关系的类型。有效值为：
o IotpTransaction. in which case the Packaged Content Element contains an IotpTransId of another IOTP Transaction o Reference in which case the Packaged Content Element contains the reference of some other, non-IOTP document.
o 物联网交易。在这种情况下，打包的内容元素包含另一个IOTP事务的IotpTransId o引用，在这种情况下，打包的内容元素包含一些其他非IOTP文档的引用。
Values of RelationshipType are controlled under the procedures defined in section 12 IANA Considerations which also allows user defined values to be defined.
RelationshipType的值根据第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".
应注意，关系属性中用于正确指示关系“方向”的词语。例如：一笔交易可能是另一笔先前交易的退款。在这种情况下，作为退款的交易应该在关系属性中包含诸如“退款”之类的词，而不是“退款到”或仅“退款”。
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.
打包内容打包内容（见第3.7节）包含标识相关交易的数据。其格式因RelationshipType的值而异。
IOTP Messages, Blocks (i.e. Transaction Reference Blocks and Trading Blocks), Trading Components (including the Transaction Id Component and the Signature Component) and some of their child elements are each given an XML "ID" attribute which is used to identify an instance of these XML elements. These identifiers are used so that one element can be referenced by another. All these attributes are given the attribute name ID.
IOTP消息、块（即交易参考块和交易块）、交易组件（包括交易Id组件和签名组件）及其一些子元素均被赋予XML“Id”属性，该属性用于标识这些XML元素的实例。使用这些标识符以便一个元素可以被另一个元素引用。所有这些属性都被赋予了属性名称ID。
The values of each ID attribute are unique within an IOTP transaction i.e. the set of IOTP Messages which have the same globally unique Transaction ID Component. Also, once the ID attribute of an element has been assigned a value it is never changed. This means that whenever an element is copied, the value of the ID attribute remains the same.
每个ID属性的值在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)*
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
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.
作为指导原则，前缀应限制为一个字符。
NameChar has the same definition as the [XML] definition of NameChar.
NameChar的定义与NameChar的[XML]定义相同。
IotpMsgIdSuffix The suffix consists of one or more digits. The suffix must be unique within a Trading Role within an IOTP Transaction. The following is recommended as a guideline and must not be relied upon:
IotpMsgIdSuffix后缀由一个或多个数字组成。在IOTP交易中的交易角色中，后缀必须是唯一的。以下建议作为指南，不得依赖：
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，同一交易角色发送的第二条和后续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组件将具有Id属性“C1”、第二条“C2”、第三条“C3”等。
Digit has the same definition as the [XML] definition of Digit.
Digit的定义与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)*
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_值首次使用块或组件的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中，交易组件和交易块从一条IOTP消息复制到另一条IOTP消息。当现有交易区块或组件复制到另一条IOTP消息时，ID属性不会更改。
IdSuffix The suffix consists of one or more digits. The suffix must be unique within the ID attribute of the Message ID Component used to generate the ID attribute. The following is recommended as a guideline and must not be relied upon:
IdSuffix后缀由一个或多个数字组成。后缀在用于生成ID属性的消息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 交易角色发送的第一个区块或组件被赋予后缀“1”。对于添加到IOTP消息中的每个新区块或组件，第二个和后续区块或组件的ID属性将增加1。后缀中不包含前导零
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.
更简单地说，添加到例如由消费者发送的第二IOTP消息的第一个新块或组件将具有ID属性“C2.1”、第二个“C2.2”、第三个“C2.3”等。
Digit has the same definition as the [XML] definition of Digit.
Digit的定义与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消息第二条IOTP消息（例如，从商户到（例如，从消费者到消费者支付处理程序）
IOTP MESSAGE IOTP MESSAGE *
|-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1*
| |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp.
| | Copy Element | | ID=M1.2
| |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 *
| |
|-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5*
| |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15
| Copy Element |
|-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 *
| |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4
| | Copy Element |
| |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5
| | Copy Element |
| |-Comp. ID=M1.6 |-Comp. ID=C1.3 *
| |-Comp. ID=M1.7 |-Comp. ID=C1.4 *
|
|-Trading Block. ID=M1.9
|-Comp. ID=M1.10 * = new elements
|-Comp. ID=M1.11
|-Comp. ID=M1.12
|-Comp. ID=M1.13
IOTP 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消息第二条IOTP消息（例如，从商户到（例如，从消费者到消费者支付处理程序）
IOTP MESSAGE IOTP MESSAGE
|-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1
| |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2
| | must be | |
| |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1
| ^ |
|-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5
| |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15
| AND |
|-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2
| |-Comp. ID=M1.4 | |-Comp. ID=M1.4
| | v |
| |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5
| | and El Ref |
| |-Comp. ID=M1.6 values must |-Comp. ID=C1.3
| | match--------|--> El Ref=M1.5
| |-Comp. ID=M1.7 |-Comp. ID=C1.4
|
|-Trading Block. ID=M1.9
|-Comp. ID=M1.10
|-Comp. ID=M1.11
|-Comp. ID=M1.12
|-Comp. ID=M1.13
IOTP 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.
注意：元素引用属性定义为“NMTOKEN”而不是“IDREF”（参见[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:
基线IOTP定义了支持IOTP的系统必须能够接受的最低协议。随着IOTP新版本的开发，将定义其他类型的IOTP交易。除此之外，IOTP的基准版本和未来版本将通过两种机制支持对IOTP的用户扩展：
o extra XML elements, and
o 额外的XML元素，以及
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元素和属性名称构成一个[XML命名空间]，由IotpMessage元素上的xmlns属性标识。这允许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保留使用一个特殊属性IOTP:Critical，该属性接受True或False值，并可能出现在添加到IOTP消息的额外元素中。
The purpose of this attribute is to allow an IOTP aware application to determine if the IOTP transaction can safely continue. Specifically:
此属性的目的是允许IOTP感知应用程序确定IOTP事务是否可以安全继续。明确地：
o if an extra XML element has an "IOTP:Critical" attribute with a value of "True" and an IOTP aware application does not know how to process the element and its child elements, then the IOTP transaction has a Technical Error (see section 4.1) and must fail.
o 如果额外的XML元素具有值为“True”的“IOTP:Critical”属性，并且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:Critical”属性，则如果支持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使用或复制IOTP XML元素时，IOTP命名空间中定义的XML元素中包含的任何额外XML元素都必须包含在该元素中
- the content of the extra element must be ignored except that it must be included when it is used in the creation of a digest as part of the generation of a signature
- 必须忽略额外元素的内容，除非在创建摘要时将其用作生成签名的一部分时必须将其包括在内
o if an extra XML element has no "IOTP:Critical" attribute then it must be treated as if it had an "IOTP:Critical" attribute with a value of "True"
o 如果额外的XML元素没有“IOTP:Critical”属性，则必须将其视为具有值为“True”的“IOTP:Critical”属性
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：关键（真|假）‘真’
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 要封装支付方案消息，如SET消息，
o to encapsulate a description of an order, a payment note, or a delivery note.
o 封装订单、付款单或交货单的说明。
In general it is used to encapsulate one or more data streams.
通常，它用于封装一个或多个数据流。
This data stream has three standardised attributes that allow for identification, decoding and interpretation of the contents. Its definition is as follows.
该数据流具有三个标准化属性，允许识别、解码和解释内容。其定义如下。
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent
Name CDATA #IMPLIED
Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" >
<!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>
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.
例如，如果只有一个打包的内容元素，则可以省略name属性。
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.
内容标识打包内容元素的内容中包含的数据类型。内容属性的有效值如下：pco PCDATA。打包内容元素的内容可以作为PCDATA处理，无需进一步处理。哦，哑剧演员。打包内容元素的内容是一个完整的MIME项。处理应该包括在打包的内容元素中查找MIME头。o MIME:mimetype。打包内容元素的内容是MIME内容，标题为“content Type:mimetype”。虽然可以将Transform属性设置为NONE的MIME:mimetype，但将Transform属性设置为BASE64的可能性更大。请注意，如果使用Transform is NONE，则整个内容仍必须符合PCDATA。有些字符需要编码为XML默认实体或数字字符实体。
o XML. The content of the Packaged Content Element can be treated as an XML document. Entities and CDATA sections, or Transform set to BASE64, must be used to ensure that the Packaged Content Element contents are legitimate PCDATA.
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内容是数据的正确表示形式。请注意，在检查数据之前，必须首先进行实体扩展（即替换&；和	；）。CDATA节可以合法地出现在打包内容元素中，其中Transform属性设置为NONE。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 如果一个父元素中包含多个打包内容元素以满足前面的要求，则顶级打包内容的Name属性（可从中确定对所有其他打包元素的引用）的值应为Main
o relative references to other documents, images, etc. from one Packaged Content element to another are realised by setting the value of the relative reference to the Name attribute of another Packaged Content element at the same level and within the same parent element
o 从一个打包内容元素到另一个打包内容元素的其他文档、图像等的相对引用是通过将相对引用的值设置为同一级别和同一父元素内另一个打包内容元素的Name属性来实现的
o no external references that require the reference to be resolved immediately should be used. As this could make the HTML difficult or impossible to display completely
o 不得使用要求立即解析引用的外部引用。因为这可能使HTML难以或不可能完全显示
o [MIME] is used to encapsulate the data inside each Packaged Element. This means that the information in the MIME header used to identify the type of data which has been encapsulated and therefore how it should be displayed.
o [MIME]用于将数据封装在每个打包元素中。这意味着MIME头中的信息用于标识已封装的数据类型，以及如何显示该数据。
If the above conventions are not followed by, for example, including external references which must be resolved, then the recipient of the HTML should be informed.
如果没有遵循上述约定，例如，包括必须解析的外部引用，则应通知HTML的收件人。
Note: As an implementation guideline the values of the Name Attributes allocated to Packaged Content elements should make it possible to extract each Packaged Content into a directory and then display the HTML directly
注意：作为实现指南，分配给打包内容元素的Name属性的值应该能够将每个打包内容提取到目录中，然后直接显示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时，例如向消费者显示订单描述的内容，那么实现者应该遵循万维网联盟的最新建议。
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 "Extensible Stylesheet Language (XSL) Specification" at
http://www.w3.org/TR/WD-xsl, and
o "Associating stylesheets with XML documents" at http://www.w3.org/TR/xml-stylesheet.
o “将样式表与XML文档关联”位于http://www.w3.org/TR/xml-stylesheet.
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:lang属性：
o a mandatory xml:lang attribute is contained on every Trading Component which contains attributes or content which may need to be displayed or printed in a particular language
o 每个交易组件上都包含一个必需的xml:lang属性，其中包含可能需要以特定语言显示或打印的属性或内容
o an optional xml:lang attribute is included on child elements of these Trading Components. In this case the value of xml:lang, if present, overrides the value for the Trading Component.
o 这些交易组件的子元素中包含可选的xml:lang属性。在本例中，xml:lang的值（如果存在）将覆盖交易组件的值。
xml:lang attributes which follow these principles are included in the Trading Components and their child XML elements defined in section 7.
xml:lang属性遵循这些原则，包含在第7节中定义的交易组件及其子xml元素中。
A sender of a message, typically a Consumer can indicate a preference for a language, and a character set by specifying a list of preferred languages/character sets in a Message Id Component (see section 3.3.2). Note that there is no obligation on the receiver of such a message to respond using one of the listed languages/character sets as they may not have the technology to be able to do it. It also means that the ability to handle these lists is not a requirement for conformance to this specification. However the ability to respond, for example using one of the stated languages/character sets is likely to provide a better user experience.
消息的发送者（通常是消费者）可以通过在消息Id组件中指定首选语言/字符集列表来指示对语言和字符集的偏好（参见第3.3.2节）。请注意，此类消息的接收者没有义务使用列出的语言/字符集之一进行响应，因为他们可能没有能够做到这一点的技术。这也意味着处理这些列表的能力不是符合本规范的要求。然而，响应的能力，例如使用所述语言/字符集之一，可能提供更好的用户体验。
IOTP contains several "Net Locations" which identify places where, typically, IOTP Messages may be sent. Net Locations come in two types:
IOTP包含多个“网络位置”，用于标识通常可以发送IOTP消息的位置。净位置有两种类型：
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.
如果两个净位置中只有一个存在，则必须使用存在的净位置。
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节）中包含的SenderNetLocn或SecureSsenderNetLocn标识的净位置发送一个带有适当状态组件的取消块。这通常是商户交易角色。
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 在接收到请求块后
o before the response block has been sent
o 在发送响应块之前
If a non-Consumer Trading Role cancels a transaction at any other time it should be treated by the recipient as an error.
如果非消费者交易角色在任何其他时间取消交易，接收方应将其视为错误。
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.
当通信运行充分良好时，检测到IOTP消息中错误的一方向发送错误消息的一方发送的错误块（见第8.17节）中的错误组件（见第7.21节）指示技术错误。
If communications are too poor, a message which was sent may not reach its destination. In this case a time-out might occur.
如果通信太差，发送的消息可能无法到达目的地。在这种情况下，可能会发生超时。
The Error Codes associated with Technical Errors are recorded in the Error Component which lists all the different technical errors which can be set.
与技术错误相关的错误代码记录在错误组件中，该组件列出了可以设置的所有不同技术错误。
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
业务错误通常必须呈现给用户，以便他们可以决定下一步要做什么。例如，如果错误是品牌独立报价中的资金不足（参见第9.1.2.2节），则用户可能希望选择同一品牌或不同品牌或支付系统的不同支付工具/账户。或者，如果
the IOTP based implementation allows it and it makes sense for that instrument, the user might want to put more funds into the instrument/account and try again.
基于IOTP的实施允许这样做，并且对该工具有意义，用户可能希望将更多资金投入工具/账户，然后重试。
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错误可能发生的三个级别是传输级别、消息级别和块级别。下文分别介绍了每种方法。
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
所有消息级错误均为技术错误，并由发送给另一方的错误组件（见第7.21节）表示。错误组件包括一个严重性属性，该属性指示
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.
该错误是一个警告，可以忽略，是一个TransientError，表示重试可以解决问题，或者是一个硬错误，在这种情况下，事务必须失败。
The Technical Errors (see section 7.21.2 Error Codes) that are Message Level errors are:
属于消息级错误的技术错误（见第7.21.2节错误代码）包括：
o XML not well formed. The document is not well formed XML (see [XML])
o XML格式不正确。文档的XML格式不正确（请参见[XML]）
o XML not valid. The document is not valid XML (see [XML])
o XML无效。文档不是有效的XML（请参阅[XML]）
o block level technical errors (see section 4.3.3) on the Transaction Reference Block (see section 3.3) and the Signature Block only. Checks on these blocks should only be carried out if the XML is valid
o 交易参考区块（见第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消息中的块或其组件之一存在问题（除事务引用或签名块外）。消息已正确传输，整体消息结构和块/组件（包括事务引用和签名块）有意义，但存在与其他块之一相关的错误。
Block level errors can be either:
块级错误可以是：
o technical errors, or
o 技术错误，或
o business errors
o 业务错误
Technical Errors are further divided into:
技术错误进一步分为：
o Block Level Attribute and Element Checks, and
o 块级属性和元素检查，以及
o Block and Component Consistency Checks
o 块和组件一致性检查
o Transient Technical Errors
o 暂时性技术错误
If a technical error occurs related to a block or component, then an Error Component is generated for return.
如果出现与块或组件相关的技术错误，则生成错误组件以返回。
Block Level Attribute and Element Checks occur only within the same block. Checks which involve cross-checking against other blocks are covered by Block and Component Consistency Checks.
块级属性和元素检查仅在同一块内进行。涉及与其他块交叉检查的检查包括在块和组件一致性检查中。
The Block Level Attribute & Element checks are:
块级属性和元素检查包括：
o checking that each attribute value within each element in a block conforms to any rules contained within this IOTP specification
o 检查块中每个元素内的每个属性值是否符合此IOTP规范中包含的任何规则
o checking that the content of each element conforms to any rules contained within this IOTP specification
o 检查每个元素的内容是否符合本IOTP规范中包含的任何规则
o if the previous checks are OK, then checking the consistency of attribute values and element content against other attribute values or element content within any other components in the same block.
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节），将严重性属性设置为TransientError，并将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节），ProcessState属性设置为Failed，CompletionCode指示问题的性质。
Some business errors may be "transient" in that the Consumer role may be able to recover and complete the transaction in some other way. For example if the Credit Card that a consumer provided had insufficient funds for a purchase, then the Consumer may recover by using a different credit card.
某些业务错误可能是“暂时的”，因为使用者角色可能能够以其他方式恢复和完成事务。例如，如果消费者提供的信用卡没有足够的资金进行购买，那么消费者可以使用不同的信用卡进行恢复。
Recovery from "transient" business errors is dependent on the CompletionCode. See the definition of the Status Component for what is possible.
从“暂时”业务错误中恢复取决于CompletionCode。请参阅状态组件的定义以了解可能的情况。
Note that no Error Component or Error Block is generated for business errors.
请注意，没有为业务错误生成错误组件或错误块。
IOTP messages are actually a combination of blocks and components as described in 3.1.1 IOTP Message Structure. Especially in future extensions of IOTP, a rich variety of combinations of such blocks and components can occur. It is important that the multiple transmission/receipt of the "same" request for an action that will change state does not result in that action occurring more than once. This is called idempotency. For example, a customer paying for an order would want to pay the full amount only once. Most network transport mechanisms have some probability of delivering a message more than once or not at all, perhaps requiring retransmission. On the other hand, a request for status can reasonably be repeated and should be processed fresh each time it is received.
IOTP消息实际上是块和组件的组合，如3.1.1 IOTP消息结构所述。特别是在IOTP的未来扩展中，可以出现此类块和组件的丰富多样的组合。重要的是，对将改变状态的操作多次发送/接收“相同”请求不会导致该操作发生多次。这就是所谓的幂等性。例如，为订单付款的客户只需支付一次全额。大多数网络传输机制都有可能多次传递消息或根本不传递消息，可能需要重新传输。另一方面，状态请求可以合理地重复，并且应该在每次收到时重新处理。
Correct implementation of IOTP can be modelled by a particular processing order as detailed below. Any other method that is indistinguishable in the messages sent between the parties is equally acceptable.
IOTP的正确实施可以通过特定的处理顺序进行建模，如下所述。在双方之间发送的消息中无法区分的任何其他方法同样可以接受。
"Server roles" are any Trading Role which is not the Consumer role. They are "Server roles" since they typically receive a request which they must service and then produce a response. However server roles can also initiate transactions. More specifically Server Roles must be able to:
“服务器角色”是指非消费者角色的任何交易角色。它们是“服务器角色”，因为它们通常接收一个请求，必须为该请求提供服务，然后生成响应。但是，服务器角色也可以启动事务。更具体地说，服务器角色必须能够：
o Initiate a transaction (see section 4.5.1). These are divided into:
o 启动交易（见第4.5.1节）。这些措施分为：
- payment related transactions and
- 与支付有关的交易及
- infrastructure transactions
- 基础设施事务
o Accept and process a message received from another role (see section 4.5.2). This includes:
o 接受并处理从其他角色收到的消息（见第4.5.2节）。这包括：
- identifying if the message belongs to a transaction that has been received before
- 标识消息是否属于以前收到的事务
- handling duplicate messages
- 处理重复消息
- generating Transient errors if the servers that process the input message are too busy to handle it
- 如果处理输入消息的服务器太忙而无法处理该消息，则生成暂时性错误
- processing the message if it is error free, authorised and, if appropriate, producing a response to send back to the other role
- 处理无错误、经授权的消息，并在适当情况下生成回复以发送回其他角色
o Cancel a current transaction if requested (see section 4.5.3)
o 如有要求，取消当前交易（见第4.5.3节）
o Re-transmit messages if a response was expected but has not been received in a reasonable time (see section 4.5.4).
o 如果预期有响应，但在合理时间内未收到响应，则重新发送消息（见第4.5.4节）。
Server Roles may initiate a variety of different types of transaction. Specifically:
服务器角色可以启动各种不同类型的事务。明确地：
o an Inquiry Transaction (see section 9.2.1)
o 询价交易（见第9.2.1节）
o a Ping Transaction (see section 9.2.2)
o Ping交易（见第9.2.2节）
o an Authentication Transaction (see section 9.1.6)
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)
- a购买（见第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属性）是否可以成功识别至关重要，因为生成响应将需要IotpTransId。
If the input message is not well formed then generate an Error Component with a Severity of HardError and ErrorCode of XmlNotWellFrmd.
如果输入消息格式不正确，则生成一个错误组件，其严重性为HardError，错误代码为XmlNotWellFrmd。
If the message is well formed but the IotpTransId cannot be identified then generate an ErrorComponent with:
如果消息格式正确，但无法识别IotpTransId，则生成一个带有以下内容的ErrorComponent：
o a Severity of HardError and an ErrorCode of AttMissing,
o 严重性为HardError，错误代码为AttMissing，
o a PackagedContent containing "IotpTransId" - the missing attribute.
o 包含“IotpTransId”的PackagedContent—缺少的属性。
Insert the Error Component inside an Error Block with a new TransactionId component with a new IotpTransId and return it to the sender of the original message.
将错误组件插入带有新IotpTransId的新TransactionId组件的错误块中，并将其返回给原始邮件的发件人。
If the input message can be identified as potentially a valid input message then check to see if an "identical" input message has been received before. Identical means that all blocks, components, elements, attribute values and element content in the input message are the same.
如果可以将输入消息识别为可能有效的输入消息，则检查之前是否收到“相同”的输入消息。相同意味着输入消息中的所有块、组件、元素、属性值和元素内容都相同。
Note: The recommended way of checking for identical messages is to check for equal values of their [DOM-HASH]
注意：检查相同消息的推荐方法是检查其[DOM-HASH]的值是否相等
If an identical message has been received before then check to see if the processing of the previous message has completed.
如果之前收到相同的消息，则检查前一消息的处理是否已完成。
If processing has not completed then generate an Error Component with a Severity of Transient Error and an Error Code of MsgBeingProc to indicate the message is being processed and send it back to the sender of the Input Message requesting that the original message be resent after an appropriate period of time.
如果处理尚未完成，则生成严重程度为暂时错误的错误组件和错误代码MsgBeingProc，以指示消息正在处理，并将其发送回输入消息的发送者，请求在适当的时间段后重新发送原始消息。
Otherwise, if processing has completed and resulted in an output message then retrieve the last message that was sent and send it again.
否则，如果处理已完成并产生输出消息，则检索上次发送的消息并再次发送。
If the message is not a duplicate then it should be processed.
如果消息不是重复的，则应进行处理。
Once it's been established that the message is not a duplicate, then it can be processed. This involves:
一旦确定消息不是重复的，就可以对其进行处理。这包括：
o checking that a server is available to handle the message, generating a Transient Error if it is not
o 检查服务器是否可用于处理消息，如果不可用，则生成暂时错误
o checking the Transaction is Not Already in error or cancelled
o 检查交易是否已出错或取消
o validating the input message. This includes:
o 正在验证输入消息。这包括：
- checking for message level errors
- 检查消息级错误
- checking for block level errors
- 检查块级错误
- checking any encapsulated data
- 检查任何封装的数据
o checking for errors in the sequence that blocks have been received
o 检查已接收块的序列中是否存在错误
o generating error components for any errors that result
o 为产生的任何错误生成错误组件
o if neither hard errors nor transient errors result, then processing the message and generating an output message, if required, for return to the sender of the Input Message
o 如果既没有硬错误也没有瞬时错误，则处理消息并生成输出消息（如果需要），以便返回到输入消息的发送者
Note: This approach to handling of duplicate input messages means, if absolutely "identical" messages are received then absolutely "identical" messages are returned. This also applies to Inquiry and Ping transactions when in reality the state of a transaction or the processing ability of the servers may have changed. If up-to-date status of transactions or servers is required, then an IOTP transaction with a new value for the ID attribute of the MsgId component must be used.
注意：这种处理重复输入消息的方法意味着，如果接收到绝对“相同”的消息，则返回绝对“相同”的消息。当事务的状态或服务器的处理能力实际发生变化时，这也适用于查询和Ping事务。如果需要事务或服务器的最新状态，则必须使用具有MsgId组件ID属性新值的IOTP事务。
Each of the above steps is discussed below.
下面讨论上述每个步骤。
CHECKING A SERVER IS AVAILABLE
检查服务器是否可用
The process that is handling the input message should check that the rest of the system is not so busy that a response in a reasonable time cannot be produced.
处理输入消息的进程应检查系统的其余部分是否太忙，以致无法在合理的时间内生成响应。
If the server is too busy, then it should generate an Error Component with a Severity of Transient Error and an Error Code of SystemBusy and send it back to the sender of the Input Message requesting that the original message be resent after an appropriate period of time.
如果服务器太忙，则应生成一个错误组件，其严重程度为暂时错误，错误代码为SystemBusy，并将其发送回输入消息的发送者，请求在适当的时间段后重新发送原始消息。
Note: Some servers may occasionally become very busy due to unexpected increases in workload. This approach allows short peaks in workloads to be handled by delaying the input of messages by asking the sender of the message to resubmit later.
注意：由于工作负载意外增加，某些服务器有时可能会变得非常繁忙。这种方法允许通过请求消息的发送者稍后重新提交来延迟消息的输入，从而处理工作负载的短高峰。
CHECKING THE TRANSACTION IS NOT ALREADY IN ERROR OR CANCELLED
检查交易是否已出错或取消
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
注：为简洁起见，以下关于如何检查块序列中的错误的说明将短语“引用IOTP事务”解释为“包含在IOTP消息中，其中
the Trans Ref Block contains an IotpTransId that refers to". So, for example, " If an Error or Cancel Block refers to an IOTP transaction that is not recognised then ..." should be interpreted as " If an Error or Cancel Block is contained in an IOTP Message where the Trans Ref Block contains an IotpTransId that refers to an IOTP transaction that is not recognised then ...
Trans Ref块包含一个IotpTransId，该IotpTransId表示“。因此，例如，“如果错误或取消块表示无法识别的IOTP事务，则…”应解释为“如果IOTP消息中包含错误或取消块，其中Trans Ref块包含一个IotpTransId，该IotpTransId引用未识别的IOTP事务，则。。。
Errors in the sequence that blocks arrive depends on the block. Blocks where checking for sequence is required are:
块到达顺序中的错误取决于块。需要检查序列的块包括：
o Error and Cancel Blocks. If an Error or Cancel Block refers to an IOTP transaction that is not recognised then it is a Hard Error. Do not return an error if Error or Cancel Blocks have been received for the IOTP Transaction before to avoid looping.
o 错误和取消块。如果错误或取消块涉及无法识别的IOTP事务，则为硬错误。如果之前收到IOTP事务的错误或取消块，请勿返回错误，以避免循环。
o Inquiry Request and Response Blocks. If an Inquiry Request or an Inquiry Response Block refers to an IOTP transaction that is not recognised then it is a Hard Error
o 查询请求和响应块。如果查询请求或查询响应块涉及无法识别的IOTP事务，则这是一个硬错误
o Authentication Request Block. If an Authentication Request Block refers to an IOTP transaction that is recognised it is a Hard Error
o 身份验证请求块。如果身份验证请求块涉及已识别的IOTP事务，则为硬错误
o Authentication Response Block. Check as follows:
o 身份验证响应块。检查如下：
- if an Authentication Response Block does not refer to an IOTP transaction that is recognised it is a Hard Error, otherwise
- 如果身份验证响应块未引用已识别的IOTP事务，则为硬错误，否则为硬错误
- if the Authentication Response Block doesn't refer to an Authentication Request that had been previously sent then it is a Hard Error, otherwise
- 如果身份验证响应块没有引用以前发送的身份验证请求，则这是一个硬错误，否则
- if an Authentication Response for the same IOTP transaction has been received before and the Authentication was successful then it is a Hard Error.
- 如果之前已收到同一IOTP事务的身份验证响应，且身份验证成功，则这是一个硬错误。
o Authentication Status Block. Check as follows:
o 身份验证状态块。检查如下：
- if an Authentication Status Block does not refer to an IOTP transaction that is recognised it is a Hard Error, otherwise
- 如果身份验证状态块未引用已识别的IOTP事务，则为硬错误，否则为硬错误
- if the Authentication Status Block doesn't refer to an Authentication Response that had been previously sent then it is a Hard Error, otherwise
- 如果身份验证状态块没有引用以前发送的身份验证响应，则这是一个硬错误，否则
- if an Authentication Status for the same IOTP transaction has been received before then it is a Warning Error
- 如果之前已收到同一IOTP事务的身份验证状态，则为警告错误
o TPO Selection Block (Merchant only). Check as follows:
o TPO选择块（仅限商户）。检查如下：
- if the TPO Selection Block doesn't refer to an IOTP Transaction that is recognised then it is a Hard Error, otherwise
- 如果TPO选择块未引用已识别的IOTP事务，则为硬错误，否则为硬错误
- if the TPO Selection Block refers to an IOTP Transaction where a TPO Block and Offer Response (in one message) had previously been sent then it is a Hard Error, otherwise
- 如果TPO选择块指的是先前已发送TPO块和提供响应（在一条消息中）的IOTP事务，则为硬错误，否则为硬错误
- if the TPO Selection Block does not refer to an IOTP Transaction where a TPO Block only (i.e. without an Offer Response) had previously been sent then it is a Hard Error, otherwise
- 如果TPO选择块未引用之前仅发送TPO块（即，没有报价响应）的IOTP事务，则为硬错误，否则为硬错误
- if a TPO Selection Block for the same TPO Block has been received before then it is a Hard Error
- 如果之前已收到同一TPO块的TPO选择块，则为硬错误
o Payment Request Block (Payment Handler only). Check as follows:
o 付款请求块（仅限付款处理程序）。检查如下：
- if the Payment Request Block refers to an IOTP Transaction that is not recognised then its OK, otherwise
- 如果付款请求块涉及未识别的IOTP交易，则其为OK，否则为OK
- 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 如果输入消息包含带有硬错误或取消块的错误组件，则停止事务的所有进一步处理。这包括禁止发送当前生成的任何消息或响应接收到的任何新的非重复消息
o processing of encapsulated messages (e.g., Payment Protocol Messages) may result in additional transient errors
o 处理封装的消息（例如，支付协议消息）可能会导致额外的瞬时错误
o a digital signature can only safely be generated once all the blocks and components have been generated and it is known which elements in the message need to be signed.
o 只有在生成了所有块和组件并且知道消息中的哪些元素需要签名后，才能安全地生成数字签名。
If an output message is generated then it should be saved so that it can be resent as required if an identical input message is received again. Note that output messages that contain transient errors are not saved so that they can be processed afresh when the input message is received again.
如果生成了输出消息，则应保存该消息，以便在再次收到相同的输入消息时，可以根据需要重新发送该消息。请注意，不保存包含暂时错误的输出消息，以便在再次接收输入消息时可以重新处理这些消息。
This process is used to cancel a transaction running on an IOTP server. It is initiated by some other process as a result of an external request from another system or server that is being run by the same Trading Role. The processing required is as follows:
此过程用于取消在IOTP服务器上运行的事务。由于来自同一交易角色运行的另一个系统或服务器的外部请求，它由其他进程启动。所需处理如下：
o if the IotpTransId of the transaction to be cancelled is not recognised, or complete then fail the request, otherwise
o 如果要取消的交易的IotpTransId未被识别或未完成，则请求失败，否则
o if the IotpTransId refers to a Ping Transaction then fail the request, otherwise
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服务器发送一条消息，指示应取消IOTP事务。
The server should periodically check for transactions where a message is expected in return but none has been received after a time that is dependent on factors such as:
服务器应定期检查预期会返回消息但在一段时间后未收到任何消息的事务，该时间取决于以下因素：
o the Transport Mechanism being used;
o 正在使用的传输机制；
o the time required to process encapsulated messages (e.g., Payment messages) and
o 处理封装消息（如支付消息）所需的时间，以及
o whether or not human input is required.
o 是否需要人力投入。
If no message has been received the original message should be resent. This should occur up to a maximum number of times dependent on the reliability of the Transport Mechanism being used.
如果未收到任何消息，则应重新发送原始消息。根据所使用的运输机构的可靠性，这种情况应最多出现一次。
If no response is received after the required time then the Transaction should be "timed out". In this case, set the process state of the transaction to Failed, and a completion code of either:
如果在所需时间后未收到响应，则事务应“超时”。在这种情况下，将事务的进程状态设置为Failed，并将完成代码设置为：
o TimedOutRcvr if the transaction can potentially recovered later, or
o TimedOutRcvr，如果事务可能在以后恢复，或
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 Ping交易（见第9.2.2节）
o an Authentication Transaction (see section 9.1.6)
o 认证事务（见第9.1.6节）
Processing of Input Messages for a Consumer Role is the same as for an IOTP Server (see section 4.5.2) except in the area of checking for Errors in Block Sequence (for an IOTP Server see section 4.5.2.4). This is described below
消费者角色的输入消息处理与IOTP服务器（见第4.5.2节）相同，但检查块序列中的错误除外（IOTP服务器见第4.5.2.4节）。下文将对此进行说明
Note: The description of the processing for an IOTP Server includes consideration of multi-threading of input messages and multi-tasking of requests. For the Consumer Role - particularly if running on a stand-alone system such as a PC - use of multi-threading is a decision of the implementer of the consumer role IOTP solution.
注：IOTP服务器处理的描述包括考虑输入消息的多线程和请求的多任务。对于消费者角色，尤其是在单机系统（如PC）上运行时，多线程的使用由消费者角色IOTP解决方案的实施者决定。
The handling of the following blocks is the same as for an IOTP Server (see section 4.5.2.4) except that the Consumer Role is substituted for IOTP Server Role:
以下模块的处理与IOTP服务器相同（见第4.5.2.4节），但消费者角色替代了IOTP服务器角色：
o Error and Cancel Blocks,
o 错误和取消块，
o Inquiry Request and Response Blocks,
o 查询请求和响应块，
o Authentication Request, Response and Status Blocks.
o 身份验证请求、响应和状态块。
For the other blocks a Consumer role might receive, the potential errors in the sequence that blocks arrive depends on the block. Blocks where checking for sequence is required are:
对于使用者角色可能接收的其他块，块到达顺序中的潜在错误取决于该块。需要检查序列的块包括：
o TPO Block. Check as follows:
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事务被消费者角色的系统识别，则存在硬错误，否则
- if the input message also contains an Authentication Status block and the IOTP Transaction is not recognised by the Consumer role's system then there is a Hard Error, otherwise
- 如果输入消息还包含身份验证状态块，且消费者角色的系统无法识别IOTP事务，则存在硬错误，否则
- if input message also contains an Authentication Status Block and the Authentication Status Block has not been sent after an earlier Authentication Response message then there is a hard error
- 如果输入消息还包含身份验证状态块，并且身份验证状态块未在先前的身份验证响应消息之后发送，则存在硬错误
- if input message also contains an Offer Response Block and the IOTP Transaction is recognised by the Consumer role's system then there is a Hard Error, otherwise
- 如果输入消息还包含报价响应块，且消费者角色的系统识别IOTP交易，则存在硬错误，否则
- if the TPO Block occurs on its own and the IOTP Transaction is recognised by the Consumer role's system then there is a Hard Error
- 如果TPO阻塞自行发生，且IOTP事务被消费者角色的系统识别，则存在硬错误
o Offer Response Block. Check as follows:
o 提供响应块。检查如下：
- if the Offer Response Block is part of a Brand Independent Offer Exchange (see section 9.1.2.2) then there is no sequence checking as it is part of the first message received, otherwise
- 如果要约响应块是品牌独立要约交换的一部分（见第9.1.2.2节），则不进行序列检查，因为它是收到的第一条消息的一部分，否则
- if the Offer Response Block is not part of an IOTP Transaction that is recognised by the Consumer role then there is a Hard Error, otherwise
- 如果报价响应块不是消费者角色识别的IOTP交易的一部分，则存在硬错误，否则
- if the Offer Response Block does not refer to an IOTP transaction where a TPO Selection Block was the last message sent then there is a Hard Error
- 如果要约响应块未引用上次发送TPO选择块的IOTP事务，则存在硬错误
o Payment Exchange Block. Check as follows:
o 支付交换区。检查如下：
- if the Payment Exchange Block doesn't refer to an IOTP Transaction that is recognised by the Consumer role's system then there is a Hard Error, otherwise
- 如果支付交换块未引用消费者角色系统识别的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节数字签名和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
最终，由商户或其他交易角色决定IOTP消息是否包含签名，并为消费者提供签名
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:
决定在没有签名的情况下进行交易是否是可接受的风险。如果商户发现没有签名的交易不被接受，他们将：
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
- 如果提供了一些担保，例如“更好的商业局”或类似的担保
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,
o 付款处理人或交付处理人希望提供付款或交付完成状态的不可反驳记录。如果签署了付款回复或交货回复，
then the Consumer can later use the record of the Payment or Delivery to prove that it occurred. This could be used, for example, for customer care purposes.
然后，消费者可以稍后使用付款或交货记录来证明其发生。例如，这可以用于客户关怀目的。
A non-exhaustive list of the reasons why digital signatures might not be used follows:
可能不使用数字签名的原因如下：
o trading roles are combined therefore changes to data made by the consumer can be detected. One of the reasons for using signatures is so that one trading role can determine if data has been changed by the Consumer or some other party. However if the trading roles have access to the necessary data, then it might be possible to compare, for example, the payment information in the Payment Request with the payment information in the Offer Response. Access to the data necessary could be realised by, for example, the Merchant and Payment Handler roles being carried out by the same Organisation on the same system, or the Merchant and Payment Handler roles being carried out on different systems but the systems can communicate in some way. (Note this type of communication is outside the current scope of IOTP)
o 合并交易角色，因此可以检测消费者对数据所做的更改。使用签名的原因之一是，一个交易角色可以确定消费者或其他方是否更改了数据。但是，如果交易角色可以访问必要的数据，则可以比较（例如）付款请求中的付款信息与报价响应中的付款信息。例如，可通过同一组织在同一系统上执行的商户和支付处理人角色，或在不同系统上执行的商户和支付处理人角色实现对必要数据的访问，但系统可以通过某种方式进行通信。（注：此类通信不在IOTP的当前范围内）
o the processing cost of the cryptography is too high. For example, if a payment is being made of only a few cents, the cost of carrying out all the cryptography associated with generating and checking digital signatures might make the whole transaction uneconomic. Co-locating trading roles, could help avoid this problem.
o 加密的处理成本太高。例如，如果只支付几美分，那么执行与生成和检查数字签名相关的所有加密的成本可能会使整个交易变得不经济。共同定位交易角色有助于避免这一问题。
The advantage of using symmetric keys with IOTP is that no Public Key Infrastructure need be set up and just the Merchant, Payment Handler and Delivery Handler need to agree on the shared secrets to use.
在IOTP中使用对称密钥的优点是不需要设置公钥基础设施，只有商户、支付处理方和交付处理方需要就使用的共享秘密达成一致。
However the disadvantage of symmetric cryptography is that the Consumer cannot easily check the credentials of the Merchant, Payment Handler, etc. that they are dealing with. This is likely to reduce, somewhat, the trust that the Consumer will have carrying out the transaction.
然而，对称加密的缺点是消费者无法轻松检查他们正在处理的商户、支付处理人等的凭证。这可能会在一定程度上降低消费者对交易的信任。
However it should be noted that even if asymmetric cryptography is being used, the Consumer does not NEED to be provided with any digital certificates as the integrity of the transaction is determined by, for example, the Payment Handler checking the Offer Response Signature copied to the Payment Request.
然而，应当注意的是，即使正在使用非对称加密，也不需要向消费者提供任何数字证书，因为交易的完整性是由例如支付处理程序检查复制到支付请求的要约响应签名来确定的。
Note that symmetric, asymmetric or both types of cryptography may be used in a single transaction.
请注意，在单个事务中可以使用对称、非对称或两种类型的加密。
Privacy of information is provided by sending IOTP Messages between the various Trading Roles using a secure channel such as [SSL/TLS]. Use of a secure channel within IOTP is optional.
通过使用安全通道（如[SSL/TLS]）在各种交易角色之间发送IOTP消息来提供信息隐私。在IOTP内使用安全通道是可选的。
IOTP is designed to be completely blind to the payment protocol being used to effect a payment. From the security perspective, this means that IOTP neither helps, nor hinders, the achievement of payment security.
IOTP被设计为完全无视用于实现支付的支付协议。从安全角度来看，这意味着IOTP既不帮助也不妨碍支付安全的实现。
If it is necessary to consider payment security from an IOTP perspective, then this should be included in the payment protocol supplement which describes how IOTP supports that payment protocol.
如果有必要从IOTP角度考虑支付安全性，那么这应该包含在支付协议补充中，它描述了IOTP如何支持该支付协议。
However what IOTP is designed to do is to use digital signatures to bind together the record, contained in a "response" message, of each trading exchange in a transaction. For example IOTP can bind together: an Offer, a Payment and a Delivery.
然而，IOTP的设计目的是使用数字签名将交易中每个交易交易所的“响应”消息中包含的记录绑定在一起。例如，IOTP可以绑定在一起：要约、付款和交付。
IOTP can work successfully without using any digital signatures although in an open networking environment it will be less secure - see 5. Security Considerations for a description of the factors that need to be considered.
IOTP可以在不使用任何数字签名的情况下成功工作，尽管在开放网络环境中，它的安全性较低-见5。需要考虑的因素描述的安全注意事项。
However, this section describes how to use digital signatures in the many situations when they will be needed. Topics covered are:
但是，本节介绍了在许多需要数字签名的情况下如何使用数字签名。主题包括：
o an overview of how IOTP uses digital signatures
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消息中包含一个或多个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.
签名组件消化一个或多个元素的方式如下图所示。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE SIGNATURE COMPONENT
IOTP消息签名组件
IOTP Message Signature Id = P1.3
|-Trans Ref Block digest TransRefBlk |-Manifest
| | ID=P1.1-----------------------------|->|-Digest of P1.1--
| |-Trans Id Comp digest TransIdComp | | |
| | ID = M1.2----------------------------|->|-Digest of M1.2--|
| |-Msg Id Comp. digest Signature | | |
| | ID = P1 -------------------|->|-Digest of M1.5--|
| | digest element | | |
|-Signatures Block | -----------------|->|-Digest of M1.7--|
| | ID=P1.2 | | digest element | | |
| |-Signature ID=P1.3 | | ---------------|->|-Digest of C1.4--|
| |-Signature ID=M1.5---- | | | | |
| |-Signature ID=P1.4 | | Points to | -RecipientInfo* |
| |-Certificate ID=M1.6<---|-|---------------|------CertRef=M1.6 |
| | | | Certs to use | Sig.ValueRef=P1.4 |
| | | | | | |
| | | | | | |
|-Trading Block. ID=P1.5 | | | v |
| |-Comp. ID=M1.7---------- | -Value* ID=P1.4: |
| | | JtvwpMdmSfMbhK<--
| |-Comp. ID=P1.6 | r1Ln3vovbMQttbBI
| | | J8pxLjoSRfe1o6k
| |-Comp. ID=C1.4------------ OGG7nTFzTi+/0<-
| |-Comp. ID=C1.5
Digital signature of Manifest element
using certificate identified by CertRef
IOTP 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
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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.
请注意，一个清单可能与多个签名“值”元素关联，其中每个值元素包含同一清单上的数字签名，可能使用相同（或不同）的签名算法，但使用不同的证书或共享密钥。具体而言，它将允许商户与其支付处理程序和交付处理程序就不同的共享密钥达成一致。
The detailed definitions of a Signature component are contained in section 7.19.
签名组件的详细定义见第7.19节。
The remainder of this section contains:
本节剩余部分包括：
o an example of how IOTP uses signatures
o IOTP如何使用签名的示例
o how the OriginatorInfo and RecipientInfo elements within a Signature Component are used to identify the Organisations associated with the signature
o 如何使用签名组件中的OriginatorInfo和RecipientInfo元素来标识与签名关联的组织
o how IOTP uses signatures to prove actions complete successfully
o IOTP如何使用签名证明操作成功完成
An example of how signatures are used is illustrated in the figure below which shows how the various components and elements in a Baseline Purchase relate to one another. Refer to this example in the later description of how signatures are used to check a payment or delivery can occur (see section 6.3).
下图举例说明了如何使用签名，该图显示了基线购买中的各种组件和元素如何相互关联。在后面关于如何使用签名检查付款或交付的描述中，请参考此示例（参见第6.3节）。
Note: A Baseline Purchase transaction has been used for illustration purposes. The usage of the elements and attributes is the same for all types of IOTP Transactions.
注：基线采购交易记录已用于说明目的。元素和属性的使用对于所有类型的IOTP事务都是相同的。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
TPO SELECTION BLOCK TPO BLOCK IOTPSIGNATURE BLOCK
| (Offer Response)
Brand Selection Organisation<--- |------Signature
Component Component | | Component
| | | -Manifest
|BrandList -Trading Role | |
| Ref Element | Originator |-Orig.
v (Merchant) ------------|--Info
Brand List Ref |
>Component |
| |-Protocol ------> Organisation Recipient |-Recipient
| | Amount Elem | Component <------------------|--Info
| | | | | Refs |
| |Pay|Protocol |Action -Trading Role |
| | | Ref |OrgRef Element |
| | v | (Payment Handler) |
| -PayProtocol-- |
| Elem ->Organisation Recipient |-Recipient
| | Component <--------------------Info
| | | Refs
| | -Trading Role
| | Element
| | (Delivery Handler
|
| OFFER RESPONSE BLOCK
| |
|BrandListRef |ActionOrgRef
| |
--Payment ---Delivery
Component Component
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).
签名组件中的Manifest元素包含以下内容的摘要：Trans-Ref块（未显示）；事务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
报价响应商
PaymentResponse PaymentHandler
PaymentResponse PaymentHandler
DeliveryResponse DeliveryHandler
DeliveryResponse DeliveryHandler
AuthenticationRequest any role
身份验证请求任何角色
AuthenticationResponse any role
AuthenticationResponse任意角色
PingRequest any role
请求任何角色
PingResponse any role
PingResponse任何角色
The RecipientRefs attribute of the RecipientInfo element in the Signature Component contains Element References to the Organisation Components of the Organisations that should use the signature to verify that:
签名组件中RecipientInfo元素的RecipientRefs属性包含对应使用签名验证以下内容的组织的组织组件的元素引用：
o they have a pre-existing relationship with the Organisation that generated the signature,
o 他们与生成签名的组织有着预先存在的关系，
o the data which is secured by the signature has not been changed,
o 由签名保护的数据未被更改，
o the data has been signed correctly, and
o 数据已正确签名，并且
o the action they are required to undertake on behalf of the Merchant is therefore authorised.
o 因此，授权他们代表商户采取行动。
Note that if symmetric cryptography is being used then a separate RecipientInfo and Value elements for each different set of shared secret keys are likely within the Signature Component.
请注意，如果使用对称加密，那么签名组件中可能会有一个单独的RecipientInfo和值元素，用于每个不同的共享密钥集。
Alternatively if asymmetric cryptography is being used then the RecpientRefs attribute of one RecipientInfo element may refer to multiple Organisation Components if they are all using the same certificates.
或者，如果使用非对称加密，则一个RecipientInfo元素的RecpientRefs属性可能引用多个组织组件（如果它们都使用相同的证书）。
Proving an action completed successfully, is achieved by signing data on Response messages. Specifically:
通过在响应消息上签名数据来证明操作已成功完成。明确地：
o on the Offer Response, when a Merchant is making an Offer to the Consumer which can then be sent to either:
o 在报价响应中，当商户向消费者发出报价时，该报价可发送至：
- a Payment Handler to prove that the Merchant authorises Payment, or
- 支付处理人证明商户授权支付，或
- a Delivery Handler to prove that Merchant authorises Delivery, provided other necessary authorisations are complete (see below)
- 交付处理人证明商户授权交付，前提是其他必要授权已完成（见下文）
o on the Payment Response, when a Payment Handler is generating a Payment Receipt which can be sent to either:
o 在付款响应中，当付款处理程序生成付款收据时，该收据可发送至：
- a Delivery Handler, in a Delivery Request Block to authorise Delivery together with the Offer Response signature, or
- 交付处理人，在交付请求块中授权交付以及报价响应签名，或
- another Payment Handler, in a second Payment Request, to authorise the second payment in a Value Exchange IOTP Transaction
- 另一个支付处理程序在第二个支付请求中授权价值交换IOTP交易中的第二次支付
o Delivery Response, when a Delivery Handler is generating a Delivery Note. This can be used to prove after the event what the Delivery Handler said they would do
o 交付响应，当交付处理程序生成交付通知时。这可以用来证明事件发生后交付处理程序说他们会做什么
o Authentication Response. One method of authenticating another party to a trade is to send an Authentication Request specifying that a Digital Signature should be used for authentication
o 身份验证响应。对交易的另一方进行身份验证的一种方法是发送身份验证请求，指定应使用数字签名进行身份验证
o Transaction Status Inquiry. The Inquiry Response Block may be digitally signed to attest to the authenticity of the response
o 交易状态查询。可以对查询响应块进行数字签名以证明响应的真实性
o Ping. The Ping Response may be digitally signed so that checks can be made that the signature can be understood.
o 发出砰的声响。可以对Ping响应进行数字签名，以便可以进行检查以确保签名能够被理解。
This proof of an action may, in future versions of IOTP, also be used to prove after the event that the IOTP transaction occurred. For example to a Customer Care Provider.
在IOTP的未来版本中，该行动证明也可用于在事件发生后证明IOTP交易。例如，客户服务提供商。
Checking a signature is correctly calculated is part of checking for Message Level Errors (see section 4.3.2). It is included here so that all signature and security related considerations are kept together.
检查签名是否正确计算是检查消息级错误的一部分（见第4.3.2节）。这里包含了它，以便将所有签名和安全相关的注意事项放在一起。
Before a Trading Role can check a signature it must identify which of the potentially multiple Signature elements should be checked. The steps involved are as follows:
在交易角色可以检查签名之前，它必须确定应该检查哪些潜在的多个签名元素。所涉及的步骤如下：
o check that a Signature Block is present and it contains one or more Signature Components
o 检查签名块是否存在，它是否包含一个或多个签名组件
o identify the Organisation Component which contains an OrgId attribute for the Organisation which is carrying out the signature check. If no or more than one Organisation Component is found then it is an error
o 识别包含执行签名检查的组织的OrgId属性的组织组件。如果未发现或发现多个组织组成部分，则为错误
o use the ID attribute of the Organisation Component to find the RecipientInfo element that contains a RecipientRefs attribute that refers to that Organisation Component. Note there may be no signatures to verify
o 使用组织组件的ID属性查找RecipientInfo元素，该元素包含引用该组织组件的RecipientRefs属性。注：可能没有要验证的签名
o check the Signature Component that contains the identified RecipientInfo element as follows:
o 检查包含已标识RecipientInfo元素的签名组件，如下所示：
- use the SignatureValueRef and the SignatureAlgorithmRef attributes to identify, respectively: the Value element that contains the signature to be checked and the Signature Algorithm element that describes the signature algorithm to be used to verify the Signature, then
- 使用SignatureValueRef和SignatureAlgorithmRef属性分别标识：包含要检查的签名的Value元素和描述用于验证签名的签名算法的signature Algorithm元素，然后
- if the Signature Algorithm element indicates that asymmetric cryptography is being used then use the SignatureCertRef to identify the Certificate to be used by the signature algorithm
- 如果Signature Algorithm元素指示正在使用非对称加密，则使用SignatureCertRef标识签名算法要使用的证书
- if Signature Algorithm element indicates that symmetric cryptography is being used then the content of the RecipientInfo element is used to identify the correct shared secret key to use
- 如果Signature Algorithm元素指示正在使用对称加密，那么RecipientInfo元素的内容将用于标识要使用的正确共享密钥
- use the specified signature algorithm to check that the Value Element correctly signs the Manifest Element
- 使用指定的签名算法检查Value元素是否正确地对Manifest元素签名
- 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)
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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.
- 识别品牌列表组件（见第7.7节），其中其ID属性的值与支付组件的BrandListRef属性匹配。如果未发现或发现多个品牌列表组件，则存在错误。
- 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.
- 识别品牌选择组件（参见第7.8节），其中其BrandListRef属性的值与支付组件的BrandListRef匹配。如果未找到或找到多个匹配的品牌选择组件，则存在错误。
o Identify the Brand, Protocol Amount, Pay Protocol and Currency Amount elements within the Brand List that have been selected by the Consumer as follows:
o 识别品牌列表中消费者已选择的品牌、协议金额、支付协议和货币金额元素，如下所示：
- the Brand Element (see section 7.7.1) selected is the element where the value of its Id attribute matches the value of the BrandRef attribute in the Brand Selection. If no or more than one matching Brand Element is found then there is an error.
- 所选品牌元素（见第7.7.1节）是其Id属性值与品牌选择中BrandRef属性值匹配的元素。如果没有找到或找到多个匹配的品牌元素，则存在错误。
- the Protocol Amount Element (see section 7.7.3) selected is the element where the value of its Id attribute matches the value of the ProtocolAmountRef attribute in the Brand Selection Component. If no or more than one matching Protocol Amount Element is found there is an error
- 选择的协议金额元素（见第7.7.3节）是其Id属性值与品牌选择组件中ProtocolAmountRef属性值匹配的元素。如果未找到或找到多个匹配的协议金额元素，则存在错误
- the Pay Protocol Element (see section 7.7.5) selected is the element where the value of its Id attribute matches the value of the PayProtocolRef attribute in the identified Protocol Amount Element. If no or more than one matching Pay Protocol Element is found there is an error
- 选择的支付协议元素（见第7.7.5节）是其Id属性的值与已识别协议金额元素中PayProtocolRef属性的值匹配的元素。如果未找到或找到多个匹配的支付协议元素，则存在错误
- the Currency Amount Element (see section 7.7.4) selected is the element where the value of its Id attribute matches the value of the CurrencyAmountRef attribute in the Brand Selection Component. If no or more than one matching Currency Amount element is found there is an error
- 选定的货币金额元素（见第7.7.4节）是其Id属性值与品牌选择组件中CurrencyAmountRef属性值匹配的元素。如果未找到或找到多个匹配的货币金额元素，则存在错误
o Check the consistency of the references in the Brand List and Brand Selection Components:
o 检查品牌列表和品牌选择组件中参考的一致性：
- check that an Element Reference exists in the ProtocolAmountRefs attribute of the identified Brand Element that matches the Id attribute of the identified Protocol Amount Element. If no or more than one matching Element Reference can be found there is an error
- 检查已标识品牌元素的ProtocolAmountRefs属性中是否存在与已标识协议金额元素的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.
- 检查标识的协议金额元素的CurrencyCamountRefs属性是否包含与标识的货币金额元素的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属性与已标识的支付协议元素中的ActionOrgRef属性匹配。如果未找到或找到多个匹配的组织组件，则存在错误
- checking the Organisation Component has a Trading Role Element with a Role attribute of PaymentHandler. If not there is an error
- 检查组织组件是否具有角色属性为PaymentHandler的交易角色元素。如果没有，则会出现错误
- 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)
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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 如果交付处理人的组织组件没有角色属性为DeliveryHandler的交易角色元素，则会发生错误
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 识别商户。这是具有交易角色元素的组织组件，其角色属性的值为Merchant。如果未找到或找到多个交易角色元素，则存在错误
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节），可以识别一个或两个签名
- 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节）。这会将全局唯一的IotpTransId绑定到构成IOTP事务的其他组件
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节）。这会将IotpTransId与包含在消息Id组件中的IOTP消息相关信息绑定（参见第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.
- 由交易中以前的支付处理程序签名的一个或多个签名组件。
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.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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 >
<!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.
SenderNetLocn包含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、SecureSenderNetLocn或两者都必须存在。
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 >
<!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
AuthenticationId由认证者指定的标识符，如果接收认证请求的组织返回该标识符，则将启用该标识符
the Authenticator to identify which Authentication is being referred to.
用于标识所引用的身份验证的身份验证程序。
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包含质询数据作为一个或多个打包内容（参见第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.
可以使用的算法由算法元素的Name属性标识。有关有效值，请参见第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 >
<!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.1节术语表。
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 >
<!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包含一个或多个交易角色的列表（请参见交易角色元素的TradingRole属性-第7.6.2节），请求获取这些角色的信息。
An Order Component contains information about an order. Its definition is as follows.
订单组件包含有关订单的信息。其定义如下。
<!ELEMENT Order (PackagedContent*) >
<!ATTLIST Order
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrderIdentifier CDATA #REQUIRED
ShortDesc CDATA #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
ApplicableLaw CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT 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事务中必须是唯一的。如果以这种方式使用，那么就不需要为Order元素指定任何内容，因为引用可用于在数据库中查找必要的信息。
ShortDesc A short description of the order in the language defined by xml:lang. It is used to facilitate selecting an individual order from a list of
ShortDesc用xml:lang定义的语言对订单进行简短描述。它用于帮助从订单列表中选择单个订单
orders, for example from a database of orders which has been stored by a Consumer, Merchant, etc.
订单，例如来自消费者、商户等存储的订单数据库。
OkFrom The date and time in [UTC] format after which the offer made by the Merchant lapses.
Ok从[UTC]格式的日期和时间开始，在此日期和时间之后，商户的报价失效。
OkTo The date and time in [UTC] format before which a Value Acquirer may accept the offer made by the Merchant is not valid.
Ok以[UTC]格式表示的日期和时间无效，在此之前，价值收单机构可以接受商户的报价。
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.1节术语表。
Content:
内容：
PackagedContent An optional description of the order information as one or more Packaged Contents (see section 3.7).
PackagedContent作为一个或多个打包内容对订单信息的可选描述（参见第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 与本订单相关的付款组件（见第7.9节）上的确认起始日期可能晚于确认起始日期，以及
o similarly, the OkTo date may be earlier that the OkTo date on the Payment Component (see section 7.9).
o 类似地，付款部分的截止日期可能早于截止日期（见第7.9节）。
Note: Disclaimer. The following information provided in this note does not represent formal advice of any of the authors of this specification. Readers of this specification must form their own views and seek their own legal counsel on the usefulness and applicability of this information.
注：免责声明。本说明中提供的以下信息不代表本规范任何作者的正式建议。本规范的读者必须形成自己的观点，并就本信息的有用性和适用性寻求自己的法律顾问。
The merchant in the context of Internet commerce with anonymous consumers initially frames the terms of the offer on the web page, and in order to obtain the goods or services, the consumer must accept them.
在与匿名消费者进行互联网商务的情况下，商家最初在网页上制定要约的条款，为了获得商品或服务，消费者必须接受这些条款。
If there is to be a time-limited offer, it is recommended that merchants communicate this to the consumer and state in the order description in a manner which is clear to the consumer that:
如果有限时优惠，建议商家将此告知消费者，并在订单描述中以消费者清楚的方式说明：
o the offer is time limited
o 报价有时间限制
o the OkFrom and OkTo timestamps specify the validity of the offer
o OkFrom和OkTo时间戳指定报价的有效性
o the clock, e.g., the merchant's clock, that will be used to determine the validity of the offer
o 用于确定报价有效性的时钟，例如商户的时钟
Also note that although the OkFrom and OkTo dates are likely to appear in the Packaged Content of the Order Description it is the dates contained in the Order Component that is authoritative. This means it is important that the OkFrom and OkTo dates actually being used is prominently displayed to the Consumer.
还要注意的是，尽管订单描述的打包内容中可能会出现OkFrom和OkTo日期，但具有权威性的是订单组件中包含的日期。这意味着向消费者突出显示实际使用的OkFrom和OkTo日期非常重要。
The Organisation Component provides information about an individual or an Organisation. This can be used for a variety of purposes. For example:
“组织”组件提供有关个人或组织的信息。这可以用于多种目的。例如：
o to describe the merchant who is selling the goods,
o 描述销售商品的商人，
o to identify who made a purchase,
o 要确定谁进行了购买，
o to identify who will take delivery of goods,
o 确定谁将提货，
o to provide a customer care contact,
o 提供客户服务联系人，
o to describe who will be the Payment Handler.
o 描述谁将成为付款处理人。
Note that the Organisation Components which must be present in an IOTP Message are dependent on the particular transaction being carried out. Refer to section 9. Internet Open Trading Protocol Transactions, for more details.
请注意，IOTP消息中必须存在的组织组件取决于正在执行的特定交易。参见第9节。互联网开放交易协议交易，了解更多详情。
Its definition is as follows.
其定义如下。
<!ELEMENT Org (TradingRole+, ContactInfo?,
PersonName?, PostalAddress?)>
<!ATTLIST Org
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
OrgId CDATA #REQUIRED
LegalName CDATA #IMPLIED
ShortDesc CDATA #IMPLIED
LogoNetLocn CDATA #IMPLIED >
<!ELEMENT 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.
OrgId标识组织组成部分描述的组织的代码。见下文7.6.1组织ID。
LegalName For Organisations which are companies this is their legal name in the language defined by xml:lang. It is required for Organisations who have a Trading Role other than Consumer or DelivTo.
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.
交易角色见下文7.6.2交易角色要素。
ContactInfo See 7.6.3 Contact Information Element below.
联系信息见下面的7.6.3联系信息元素。
PersonName See 7.6.4 Person Name below.
人名见下面的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.
一个IOTP交易角色使用组织ID识别另一个。为了避免混淆，这意味着这些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交易中的一个其他交易角色分配，并通过将其与该其他角色的组织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，该IOTP交易中的所有其他交易角色将使用相同的组织Id来识别该消费者。
Specifically, the content of the Organisation ID is defined as follows:
具体而言，组织ID的内容定义如下：
OrgId ::= NonConsumerOrgId | ConsumerOrgId
NonConsumerOrgId ::= DomainName
ConsumerOrgId ::= ConsumerOrgIdPrefix (namechar)+ "/" NonConsumerOrgId
ConsumerOrgIdPrefix ::= "Consumer:"
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
consumerrorgid消费者的组织ID包括：o用于标识组织ID是消费者的标准前缀，后跟
o one or more characters which conform to the definition of an XML "namechar". See [XML] specifications, followed by o the NonConsumerOrgId for the Organisation which allocated the ConsumerOrgId. It is normally the Merchant role.
o 符合XML“namechar”定义的一个或多个字符。参见[XML]规范，然后是分配消费者GID的组织的非消费者。这通常是商家的角色。
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.
请注意，非consumerorgid不能以consumerorgid前缀开头。
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交易中的交易角色。注意，一个组织可能有多个交易角色，并且一个组织元素中可能存在多个角色。其定义如下：
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
ID ID #REQUIRED
TradingRole NMTOKEN #REQUIRED
IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED
ErrorNetLocn CDATA #IMPLIED
<!ELEMENT TradingRole EMPTY >
<!ATTLIST TradingRole
ID ID #REQUIRED
TradingRole NMTOKEN #REQUIRED
IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED
ErrorNetLocn CDATA #IMPLIED
ErrorLogNetLocn CDATA #IMPLIED >
ErrorLogNetLocn CDATA#隐含>
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.
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 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.translate error, please retry
This attribute: o must not be present when TradingRole is set to Consumer role or DelivTo,
当TradingRole设置为Consumer role或DeliverTo时，此属性：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 HardError，o警告，但消费者决定不继续交易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.
此属性：当TradingRole设置为Consumer或Deliverto时，o不得存在；当TradingRole设置为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消息的净位置，该消息包含错误块，错误组件的严重性属性设置为：o HardError，o Warning，但使用者决定不继续事务o TransientError，事务随后已超时。
This attribute: o must not be present when TradingRole is set to Consumer role,
当TradingRole设置为Consumer role时，此属性：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.
其中包含可用于联系组织或个人的信息。所有属性都是可选的，但至少应显示一项联系人信息。其定义如下。
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED
Fax CDATA #IMPLIED
Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED >
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
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.
传真一个可以联系组织的传真号码。请注意，这是一个文本字段，没有对其进行验证。
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.
其中包含个人的姓名。所有字段都是可选的，但至少应显示GivenName或FamilyName。其定义如下。
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
FamilyName CDATA #IMPLIED >
<!ELEMENT PersonName EMPTY >
<!ATTLIST PersonName
xml:lang NMTOKEN #IMPLIED
Title CDATA #IMPLIED
GivenName CDATA #IMPLIED
Initials CDATA #IMPLIED
FamilyName CDATA #IMPLIED >
Attributes:
属性：
xml:lang Defines the language used by attributes within this element. See section 3.8 Identifying Languages.
xml:lang定义此元素中的属性所使用的语言。参见第3.8节识别语言。
Title A distinctive name; personal appellation, hereditary or not, denoting or implying office (e.g., judge, mayor) or nobility (e.g., duke, duchess, earl), or used in addressing or referring to a person (e.g., Mr, Mrs, Miss)
标题：一个独特的名称；个人称谓，世袭与否，表示或暗示职务（如法官、市长）或贵族（如公爵、公爵夫人、伯爵），或用于称呼或指代某人（如先生、夫人、小姐）
GivenName The primary or main name by which a person is known amongst and identified by their family, friends and acquaintances. Otherwise known as first name or Christian Name.
给名字一个人的主要或主要名字，通过这个名字，一个人在他的家人、朋友和熟人中被认识并被识别。另称为名或教名。
Initials The first letter of the secondary names (other than the Given Name) by which a person is known amongst or identified by their family, friends and acquaintances.
姓名首字母是次要姓名的第一个字母（姓名除外），家人、朋友和熟人通过该字母认识或识别某个人。
FamilyName The name by which family of related individuals are known. It is typically the part of an individual's name which is passed on by parents to their children.
FamilyName了解相关个人家庭的名称。它通常是个人名字中父母传给子女的部分。
This contains an address which can be used, for example, for the physical delivery of goods, services or letters. Its definition is as follows.
其中包含一个地址，可用于实际交付货物、服务或信件。其定义如下。
<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
xml:lang NMTOKEN #IMPLIED
AddressLine1 CDATA #IMPLIED
AddressLine2 CDATA #IMPLIED
CityOrTown CDATA #IMPLIED
StateOrRegion CDATA #IMPLIED
PostalCode CDATA #IMPLIED
Country CDATA #IMPLIED
LegalLocation (True | False) 'False' >
<!ELEMENT PostalAddress EMPTY >
<!ATTLIST PostalAddress
xml:lang NMTOKEN #IMPLIED
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邮政地址的第一行。e、 g.“草地”
AddressLine2 The second line of a postal address. e.g., "Sandy Lane"
AddressLine2邮政地址的第二行。e、 g.“沙巷”
CityOrTown The city of town of the address. e.g., "Carpham"
CityOrTown地址所在的城市。e、 g.“卡帕姆”
StateOrRegion The state or region within a country where the city or town is placed. e.g., "Surrey"
州或地区城市或城镇所在的国家或地区。e、 g.“萨里”
PostalCode The code known as, for example a post code or zip code, that is typically used by Postal Organisations to organise postal deliveries into efficient sequences. e.g., "KT22 1AA"
邮政编码（PostalCode）：邮政组织通常使用的一种代码，例如邮政编码或邮政编码，用于将邮件传递组织成有效的序列。e、 g.，“KT22 1AA”
Country The country for the address. e.g., "UK"
国家地址的国家。e、 g.“英国”
LegalLocation This identifies whether the address is the Registered Address for the Organisation. At least one address for the Organisation must have a value set to True unless the Trading Role is either Consumer or DeliverTo.
LegalLocation标识该地址是否为组织的注册地址。组织的至少一个地址的值必须设置为True，除非交易角色是消费者或发货人。
Brand List Components are contained within the Trading Protocol Options Block (see section 8.1) of the IOTP Transaction. They contains lists of:
品牌列表组件包含在IOTP交易的交易协议选项块（见第8.1节）中。它们包含以下内容的列表：
o payment Brands (see also section 11.1 Brand Definitions and Brand Selection),
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 >
<!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:Lang定义的语言进行的文本描述，详细说明品牌列表的用途。此信息必须显示给品牌列表的接收者，以帮助进行选择。当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贷记与该品牌列表相关的支付请求块的发送者将从支付处理程序收到付款。
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可用于品牌的货币和货币金额元素，o可用于这些货币和金额的支付协议和支付处理程序，以及特定品牌
CurrencyAmount This contains a currency code and an amount.
CurrencyAmount包含货币代码和金额。
PayProtocol This contains information about a Payment Protocol and the Payment Handler which may be used with a particular Brand.
PayProtocol包含有关支付协议和支付处理程序的信息，这些信息可能与特定品牌一起使用。
The relationships between the elements which make up the content of the Brand List is illustrated in the diagram below.
构成品牌列表内容的元素之间的关系如下图所示。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Brand List Component
品牌列表组件
| ProtocolAmountRefs
|-Brand Element-----------------------------
| | |
| - Protocol Brand Element-------- |
| | |
| ProtocolId| |
| | |
|-Protocol Amount Element<----------+-------
| | | |
| | | |
| |CurrencyAmountRefs |Pay |
| | |Protocol |
| v |Ref |
|-Currency Amount Element | |
| Element | |
| | |
-PayProtocolElement<------<--------
| 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.
品牌元素描述可用于支付的品牌。这些元素中的一个或多个包含在PayDirection属性设置为借记的每个品牌列表组件中。将PayDirection属性设置为Credit的品牌列表组件中可能只包含一个品牌元素。
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
<!ATTLIST Brand
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandId CDATA #REQUIRED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED
ProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
<!ATTLIST Brand
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
BrandId CDATA #REQUIRED
BrandName CDATA #REQUIRED
BrandLogoNetLocn CDATA #REQUIRED
BrandNarrative CDATA #IMPLIED
ProtocolAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
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.
品牌名称包含品牌名称，例如万事达信用卡。这是以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.
品牌叙事此可选属性旨在由商户使用，以指示如果消费者选择该品牌，将适用的一些特殊条件或利益。例如“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.
ProtocolaMontrefs确定了可用于该品牌的协议、相关货币和金额。指定为品牌列表中包含的协议金额元素ID列表（见第7.7.3节）。
ContentSoftwareId See section 14.Glossary.
ContentSoftwareId请参见第14.1节术语表。
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 >
<!ELEMENT ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED >
Attributes:
属性：
ProtocolId This must match the value of a ProtocolId attribute in a Pay Protocol Element (see section 7.7.5).
ProtocolId必须与支付协议元素中ProtocolId属性的值匹配（参见第7.7.5节）。
The values of ProtocolId should be unique within a Brand Element otherwise there is an error.
ProtocolId的值在品牌元素中应该是唯一的，否则会出现错误。
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.
该属性的有效值在ProtocolId标识的支付协议补充文件中定义，该补充文件描述了支付协议如何与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 >
<!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包含一个元素引用（见第3.5节），该元素引用了支付协议元素（见第7.7.5节），该元素包含可与品牌一起使用的支付协议和支付处理程序。
CurrencyAmountRefs Contains a list of Element References (see section 3.5) that refer to the Currency Amount Element (see section 7.7.4) that describes the currencies and amounts that can be used with the Brand.
CurrencyCamountRefs包含一个元素引用列表（见第3.5节），该列表引用了货币金额元素（见第7.7.4节），描述了可用于品牌的货币和金额。
ContentSoftwareId See section 14. Glossary.
内容见第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:
这些元素中的一个或多个包含在每个品牌列表组件中。其定义如下：
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A'
CurrCode CDATA #REQUIRED >
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
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
ID元素标识符，可能在品牌元素中引用；或者在品牌选择组件中
contained in a later Payment Request message which uniquely identifies the Currency Amount Element within the IOTP Transaction.
包含在稍后的付款请求消息中，该消息唯一标识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”。请注意，允许使用小于最小面额的值。例如，十分之一美分将是“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的域。包含此属性是为了使货币代码可以支持非标准“货币”，如常旅客积分、交易戳记等。其值可能为：o ISO4217-A（默认值）表示货币代码是符合[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.
Pay Protocol元素指定可与品牌一起使用的支付协议和支付处理程序的详细信息。这些元素中的一个或多个包含在每个品牌列表中。
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED SecPayReqNetLocn CDATA #IMPLIED ContentSoftwareId CDATA #IMPLIED >
PayReqNetLocn CDATA#隐含SecPayReqNetLocn CDATA#隐含内容SoftwareID CDATA#隐含>
Attributes:
属性：
ID Element identifier, potentially referenced in a Brand element; or in a Brand Selection Component contained in a later Payment Request message which uniquely identifies the Pay Protocol element within the IOTP Transaction.
ID元素标识符，可能在品牌元素中引用；或者在包含在稍后支付请求消息中的品牌选择组件中，该消息唯一标识IOTP交易中的支付协议元素。
xml:lang Defines the language used by attributes and content of this element. See section 3.8 Identifying Languages.
xml:lang定义此元素的属性和内容所使用的语言。参见第3.8节识别语言。
ProtocolId Consists of a protocol name and version. For example "SETv1.0".
ProtocolId由协议名称和版本组成。例如“SETv1.0”。
The values of ProtocolId are defined by the payment scheme/method owners in the document that describes how to encapsulate a payment protocol within IOTP.
ProtocolId的值由支付方案/方法所有者在描述如何在IOTP中封装支付协议的文档中定义。
ProtocolName A narrative description of the payment protocol and its version in the language identified by xml:lang. For example "Secure Electronic Transaction Version 1.0". Its purpose is to help provide information on the payment protocol being used if problems arise.
协议名称支付协议及其版本的叙述性描述，使用xml:lang标识的语言。例如“安全电子交易版本1.0”。其目的是在出现问题时帮助提供有关所使用的支付协议的信息。
ActionOrgRef An Element Reference (see section 3.5) to the Organisation Component for the Payment Handler for the Payment Protocol.
ActionOrgRef支付协议的支付处理程序的组织组件的要素参考（见第3.5节）。
PayReqNetLocn The Net Location indicating where an unsecured Payment Request message should be sent if this protocol choice is used.
PayReqNetLocn如果使用此协议选项，则指示应在何处发送不安全支付请求消息的净位置。
The content of this attribute is dependent on the Transport Mechanism (such must conform to [RFC1738].
此属性的内容取决于传输机制（必须符合[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.
内容见第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
<!元素品牌选择（BrandSelBrandInfo？、BrandSelProtocolAmountInfo？、BrandSelCurrencyAmountInfo？><！ATTLIST品牌选择
ID ID #REQUIRED BrandListRef NMTOKEN #REQUIRED BrandRef NMTOKEN #REQUIRED ProtocolAmountRef NMTOKEN #REQUIRED CurrencyAmountRef NMTOKEN #REQUIRED >
ID ID#必需BrandListRef NMTOKEN#必需BrandRef NMTOKEN#必需ProtocolAmountRef NMTOKEN#必需CurrencyAmountRef NMTOKEN#必需>
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.
CurrencyCamountRef支付时要使用的品牌列表组件中货币金额元素的元素引用。
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，包含特定支付BrandSelCurrencyAmountInfo品牌或协议可能需要的BrandSelProtocolAmountInfo的任何附加数据。见第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节）中的每个品牌列表组件必须由一个且仅一个品牌选择组件引用
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之一
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标识的协议金额元素的CurrencyAmountRef属性中列出的元素ID之一。
An example of a Brand Selection Component is included in 11.2 Brand List Examples.
11.2品牌列表示例中包含了品牌选择组件的示例。
The Brand Selection Brand Info Element contains any additional data that may be required by a particular payment brand. See the IOTP payment method supplement for a description of how and when it used.
品牌选择品牌信息元素包含特定支付品牌可能需要的任何附加数据。有关使用方式和时间的说明，请参见《IOTP支付方式补充》。
<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
内容见第14节。术语汇编
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的规则，请参阅IOTP的付款方式补充。
The Brand Selection Protocol Amount Info Element contains any additional data that is payment protocol specific that may be required by a particular payment brand or payment protocol. See the IOTP payment method supplement for a description of how and when it used.
品牌选择协议金额信息元素包含特定支付品牌或支付协议可能需要的特定于支付协议的任何附加数据。有关使用方式和时间的说明，请参见《IOTP支付方式补充》。
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
内容见第14节。术语汇编
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的规则，请参阅IOTP的付款方式补充。
The Brand Selection Currency Amount Info Element contains any additional data that is payment brand and currency specific that may be required by a particular payment brand. See the IOTP payment method supplement for a description of how and when it used.
品牌选择货币金额信息元素包含特定支付品牌可能需要的支付品牌和特定货币的任何附加数据。有关使用方式和时间的说明，请参见《IOTP支付方式补充》。
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
属性：
ContentSoftwareId See section 14. Glossary.
内容见第14节。术语汇编
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的规则，请参阅IOTP的付款方式补充。
A Payment Component contains information used to control how a payment is carried out. Its provides information on:
支付组件包含用于控制如何执行支付的信息。Its提供了以下信息：
o the times within which a Payment with a Payment Handler may be started
o 使用支付处理程序开始支付的时间
o a reference to the Brand List (see section 7.7) which identifies the Brands, protocols, currencies and amounts which can be used to make a payment
o 对品牌列表的参考（见第7.7节），其中确定了可用于支付的品牌、协议、货币和金额
o whether or not a payment receipt will be provided
o 是否提供付款收据
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 >
<!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]格式的日期和时间开始，在此日期和时间之后，支付处理程序可以接受处理包含支付组件的支付请求块（参见第8.7节）。
OkTo The date and time in [UTC] format before which a Payment Handler may accept for processing a Payment Request Block containing the Payment Component.
OkTo以[UTC]格式表示的日期和时间，在此日期和时间之前，支付处理程序可以接受处理包含支付组件的支付请求块。
BrandListRef An Element Reference (see section 3.5) of a Brand List Component (see section 7.7) within the TPO Trading Block for the IOTP Transaction. The Brand List identifies the alternative ways in which the payment can be made.
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.
SignedPayReceive表示是否必须对付款处理程序为付款生成的付款响应块（参见第8.9节）进行数字签名。
StartAfter Contains Element References (see section 3.5) of other Payment Components which describe payments which must be complete before this payment can start. If no StartAfter attribute is present then there are no dependencies and the payment can start immediately
StartAfter包含其他支付组件的元素参考（见第3.5节），这些组件描述了在开始支付之前必须完成的支付。如果没有StartAfter属性，则不存在依赖项，可以立即开始付款
A Payment Scheme Component contains payment protocol information for a specific payment scheme which is transferred between the parties involved in a payment for example a [SET] message. Its definition is as follows.
支付方案组件包含特定支付方案的支付协议信息，该支付方案在参与支付的各方之间传输，例如[设置]消息。其定义如下。
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Scheme Component within the IOTP Transaction.
ID唯一标识IOTP交易中支付方案组件的标识符。
PaymentRef An Element Reference (see section 3.5) to the Payment Component (see section 7.9) to which this Payment Scheme Component relates. It is required unless the Payment Scheme Component is part of an Transaction Inquiry Status Transaction (see section 9.2.1).
PaymentRef指与该支付方案组成部分相关的支付组成部分（见第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.
内容见第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每个名称的值在付款中必须是唯一的，其中付款定义为具有相同PaymentRef属性值的所有付款方案或付款收据组件
A Payment Receipt is a record of a payment which demonstrates how much money has been paid or received. It is distinct from a purchase receipt in that it contains no record of what was being purchased.
付款收据是一种付款记录，显示已支付或收到的金额。它与采购收据的不同之处在于，它不包含所采购物品的记录。
Typically the content of a Payment Receipt Component will contain data which describes:
通常，付款收据组件的内容将包含以下数据：
o the amount paid and its currency
o 支付的金额及其货币
o the date and time of the payment
o 付款的日期和时间
o internal reference numbers which identify the payment to the payment system
o 识别支付系统付款的内部参考号
o potentially digital signatures generated by the payment method which can be used to prove after the event that the payment occurred.
o 可能由支付方法生成的数字签名，可用于在发生支付事件后证明。
If the Payment Method being used provides the facility then the Payment Receipt Component should contain payment protocol messages, or references to messages, which prove the payment occurred.
如果使用的付款方法提供了便利，则付款收据组件应包含付款协议消息或对消息的引用，以证明付款已发生。
The precise definition of the content is Payment Method dependent. Refer to the supplement for the payment method being used to determine the rules that apply.
内容的精确定义取决于付款方式。请参阅附录，了解用于确定适用规则的付款方法。
Information contained in the Payment Receipt Component should be displayed or otherwise made available to the Consumer.
应显示或以其他方式向消费者提供付款收据组件中包含的信息。
Note: If the Payment Receipt Component contains Payment Protocol Messages, then the Messages will need to be processed by Payment Method software to convert it into a format which can be understood by the Consumer
注意：如果付款收据组件包含付款协议消息，则需要由付款方法软件处理这些消息，以将其转换为消费者可以理解的格式
The definition of a Payment Receipt Component is as follows.
付款收据组件的定义如下所示。
<!ELEMENT PayReceipt (PackagedContent*) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
PayReceiptNameRefs NMTOKENS #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT PayReceipt (PackagedContent*) >
<!ATTLIST PayReceipt
ID ID #REQUIRED
PaymentRef NMTOKEN #REQUIRED
PayReceiptNameRefs NMTOKENS #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Receipt Component within the IOTP Transaction.
ID唯一标识IOTP交易中付款收据组件的标识符。
PaymentRef Contains an Element Reference (see section 3.5) to the Payment Component (see section 7.9) to which this payment receipt applies
PaymentRef包含本付款收据适用的付款组成部分（见第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)
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.
内容见第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每个名称的值在付款中必须是唯一的，其中付款定义为所有付款方案或付款收据组件，具有相同的PaymentRef属性值
Note that either the PayReceiptNameRefs attribute, the PackagedContent element, or both must be present.
请注意，PayReceiptNameRefs属性、PackagedContent元素或两者都必须存在。
The Payment Note Component contains additional, non payment related, information which the Payment Handler wants to provide to the Consumer. For example, if a withdrawal or deposit were being made then it could contain information on the remaining balance on the account after the transfer was complete. The information should duplicate information contained within the Payment Receipt Component.
付款通知组件包含付款处理程序希望向消费者提供的其他非付款相关信息。例如，如果正在进行取款或存款，则该取款或存款可能包含转账完成后账户上剩余余额的信息。该信息应与付款收据组件中包含的信息重复。
Information contained in the Payment Note Component should be displayed or otherwise made available to the Consumer. For interoperability, the Payment Note Component should support, as a minimum, the content types of "Plain Text", HTML and XML. Its definition is as follows.
应向消费者显示或以其他方式提供付款通知单组件中包含的信息。为了实现互操作性，付款通知组件应至少支持“纯文本”、HTML和XML的内容类型。其定义如下。
<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT PaymentNote (PackagedContent+) >
<!ATTLIST PaymentNote
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Receipt Component within the IOTP Transaction.
ID唯一标识IOTP交易中付款收据组件的标识符。
ContentSoftwareId See section 14. Glossary.
内容见第14节。术语汇编
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包含支付处理程序希望作为一个或多个打包内容元素提供给消费者的其他非支付相关信息（请参见第3.7节）。
The Delivery Element contains information required to deliver goods or services. Its definition is as follows.
Delivery元素包含交付商品或服务所需的信息。其定义如下。
<!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 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
DeliveExch表示此IOTP事务是否包括与传递交换关联的消息。有效值为：o True表示它确实包含传递交换；o False表示它不包含传递交换
If set to true then a DeliveryData element must be present. If set to false it may be absent.
如果设置为true，则必须存在DeliveryData元素。如果设置为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
DeliverandPayResp表示交付响应块（见第8.11节）和支付响应块（见第8.9节）是否合并为一条IOTP消息。有效值为：o True表示两个块将位于同一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.
如果DeliveExch为False，则DeliveAndPayResp不应为true。
In practice combining the Delivery Response Block and Payment Response Block is only likely to be practical if the Merchant, the Payment Handler and the Delivery Handler are the same Organisation since: o the Payment Handler must have access to Order Component information so that they know what to deliver, and o the Payment Handler must be able to carry out the delivery
在实践中，只有当商户、支付处理人和交付处理人是同一组织时，才可能将交付响应块和支付响应块结合起来，因为：o支付处理人必须能够访问订单组件信息，以便他们知道交付什么，o支付处理人员必须能够执行交付
ActionOrgRef An Element Reference to the Organisation Component of the Delivery Handler for this delivery.
ActionOrgRef此交付的交付处理程序的组织组件的元素引用。
Content:
内容：
DeliveryData Contains details about how the delivery will be carried out. See 7.13.1 Delivery Data Element below.
DeliveryData包含有关如何执行交付的详细信息。见下文7.13.1交付数据元素。
PackagedContent Contains "user" data defined for the Merchant which is required by the Delivery Handler as one or more Packaged Content Elements see section 3.7.
PackagedContent包含为商户定义的“用户”数据，交付处理程序需要这些数据作为一个或多个打包内容元素，请参见第3.7节。
The DeliveryData element contains information about where and how goods are to be delivered. Its definition is as follows.
DeliveryData元素包含有关在何处以及如何交付货物的信息。其定义如下。
<!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED
SecDelivReqNetLocn CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #REQUIRED
SecDelivReqNetLocn CDATA #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
属性：
xml:lang Defines the language used by attributes within this component. See section 3.8 Identifying Languages.
xml:lang定义此组件中的属性所使用的语言。参见第3.8节识别语言。
OkFrom The date and time in [UTC] format after which the Delivery Handler may accept for processing a Delivery Request Block (see section 8.10).
从[UTC]格式的日期和时间开始，在此日期和时间之后，交付处理人可以接受处理交付请求块（参见第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
DeliverMethod表示交付商品或服务的方法。有效值为：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.
方法的值根据第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
交付物IOTP交易中具有交付物角色的组织组成部分的要素参考（见第3.4节）。本栏中的信息用于确定交货地点。它必须与方法兼容。具体来说，如果deliverMethod是：o Post，那么必须有一个包含邮政递送的足够信息的邮政地址元素，o 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.
DeliverReqNetLocn包含包含交付组件的不安全交付请求块（见第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.
SecDeliverReqNetLocn包含安全交付请求块（见第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.
内容见第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由商户提供给交付处理人的关于交付的附加信息，作为一个或多个打包内容元素（见第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>
<!ELEMENT ConsumerDeliveryData EMPTY >
<!ATTLIST ConsumerDeliveryData
ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED>
Attributes:
属性：
ID An identifier which uniquely identifies the Consumer Delivery Data Component within the IOTP Transaction.
ID唯一标识IOTP事务中消费者交付数据组件的标识符。
ConsumerDeliveryId An identifier specified by the Consumer which, if returned by the Delivery Handler will enable the Consumer to identify which Delivery is being referred to.
ConsumerDeliveryId由使用者指定的标识符，如果传递处理程序返回该标识符，将使使用者能够识别引用的传递。
A Delivery Note contains delivery instructions about the delivery of goods or services or potentially the actual Delivery Information itself. It is information which the person or Organisation receiving the Delivery Note can use when delivery occurs.
送货单包含关于货物或服务交付的交付说明，或者可能包含实际交付信息本身。该信息是收到交货通知单的人员或组织在交货时可以使用的信息。
For interoperability, the Delivery Note Component Packaged Content should support both Plain Text, HTML and XML.
为了实现互操作性，Delivery Note组件打包的内容应同时支持纯文本、HTML和XML。
It's definition is as follows.
它的定义如下。
<!ELEMENT DeliveryNote (PackagedContent+) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT DeliveryNote (PackagedContent+) >
<!ATTLIST DeliveryNote
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
DelivHandlerDelivId CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
Attributes:
属性：
ID An identifier which uniquely identifies the Delivery Note Component within the IOTP Transaction.
ID唯一标识IOTP事务中的交货通知单组件的标识符。
xml:lang Defines the language used by attributes or child elements within this component, unless overridden by an xml:lang attribute on a child element. See section 3.8 Identifying Languages.
xml: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.
DeliverHandlerDeliverId由交付处理程序指定的可选标识符，如果消费者在另一个交付组件中返回该标识符，或通过其他方式返回该标识符，则交付处理程序将能够识别引用的交付。除了包含在传递请求块中的传递组件之外，每个传递组件都需要它。
An example use of this attribute is to contain a delivery tracking number.
此属性的一个示例用法是包含交货跟踪号。
ContentSoftwareId See section 14. Glossary.
内容见第14节。术语汇编
Content:
内容：
PackagedContent Contains actual delivery note information as one or more Packaged Content elements (see section 3.7).
PackagedContent包含实际的交货通知信息，作为一个或多个打包内容元素（参见第3.7节）。
Note: If the content of the Delivery Message is a Mime message then the Delivery Note may trigger an application which causes the actual delivery to occur.
注意：如果传递消息的内容是Mime消息，则传递消息可能触发导致实际传递发生的应用程序。
A Status Component contains status information about the business success or failure (see section 4.2) of a process.
状态组件包含有关流程的业务成功或失败（参见第4.2节）的状态信息。
Its definition is as follows.
其定义如下。
<!ELEMENT Status EMPTY >
<!ATTLIST Status
ID ID #REQUIRED
xml:lang NMTOKEN #REQUIRED
StatusType NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessState (NotYetStarted | InProgress |
CompletedOk | Failed | ProcessError) #REQUIRED
CompletionCode NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED
StatusDesc CDATA #IMPLIED >
<!ELEMENT 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.
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.
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.
CompletionCode指示流程是如何完成的。以下给出了CompletionCode的有效值，以及必须存在的条件和故障恢复时的指示。
A CompletionCode is a maximum of 14 characters long.
CompletionCode的最大长度为14个字符。
ProcessReference This optional attribute holds a reference for the
process whose status is being reported. It may
hold the following values:
o when StatusType is set to Offer, it should
contain the OrderIdentifier from the Order
Component
o when StatusType is set to Payment, it should
contain the PaymentHandlerPayId from the
Payment Scheme Data Component
o when StatusType is set to Delivery, it should
contain the DelivHandlerDelivId from the
Delivery Note Component
o when StatusType is set to Authentication, it
should contain the AuthenticationId from the
Authentication Request Component
ProcessReference This 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属性设置为Failed时，才需要完成代码。下表包含可能使用的CompletionCode的有效值，并指示是否可能进行恢复。建议在适当的情况下使用StatusDesc属性提供进一步的解释。
Value Description
值描述
AuthError Authentication Error. The check of the Authentication Response which was carried out has failed.
AuthError身份验证错误。对已执行的身份验证响应的检查失败。
Recovery may be possible by the Consumer re-submitting a new Authentication Response Block with corrected information.
消费者可以通过重新提交带有更正信息的新认证响应块来实现恢复。
ConsCancelled Consumer Cancelled. The Consumer decides to cancel the transaction for some reason. This code is only valid in a Status Component contained in a Cancel Block or an Inquiry Response Block.
消费者取消消费取消。消费者出于某种原因决定取消交易。此代码仅在包含在取消块或查询响应块中的状态组件中有效。
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.
水星取消了报价。商户出于某种原因拒绝生成报价并取消交易。此代码仅在包含在取消块或查询响应块中的状态组件中有效。
No recovery possible.
无法恢复。
Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes.
未指定的错误。有一些未知问题或错误不属于其他CompletionCode之一。
No recovery possible.
无法恢复。
TimedOutRcvr Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
TimedOutRcvr可恢复超时。已重新发送消息，但未收到响应。因此，文件交换已“超时”。此代码仅对交易查询有效。
Recovery is possible if the last message from the other Trading Role is received again.
如果再次收到来自其他交易角色的最后一条消息，则可以进行恢复。
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
TimedOutNoRcvr不可恢复超时。已重新发送消息，但未收到响应。因此，文件交换已“超时”。此代码仅对交易查询有效。
No recovery possible.
无法恢复。
The CompletionCode is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used and indicates where recovery may be possible. It is recommended that the StatusDesc attribute is used by individual payment schemes to provide further explanation where appropriate.
只有当ProcessState属性设置为Failed时，才需要CompletionCode。下表包含可能使用的CompletionCode的有效值，并指明了可以进行恢复的位置。建议各个支付方案使用StatusDesc属性，以便在适当的情况下提供进一步的解释。
Value Description
值描述
BrandNotSupp Brand not supported. The payment brand is not supported by the Payment Handler.
不支持BrandNotSupp品牌。付款处理程序不支持付款品牌。
See below for recovery options.
有关恢复选项，请参见下文。
CurrNotSupp Currency not supported. The currency in which the payment is to be made is not supported by either the Payment Instrument or the Payment Handler.
不支持CurrentSupp货币。支付工具或支付处理程序均不支持支付所用的货币。
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.
付款已取消付款已取消。付款处理人出于某种原因拒绝完成付款并取消交易。此代码仅在包含在取消块或查询响应块中的状态组件中有效。
See below for recovery options.
有关恢复选项，请参见下文。
AuthError Authentication Error. The Payment Scheme specific authentication check which was carried out has failed.
AuthError身份验证错误。执行的特定于支付方案的身份验证检查失败。
Recovery may be possible. See the payment scheme supplement to determine what is allowed.
恢复是可能的。请参阅付款方案补充，以确定允许的付款方式。
InsuffFunds Insufficient funds. There are insufficient funds available for the payment to be made.
资金不足。没有足够的资金支付这笔款项。
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.
InstBrand无效的支付工具对品牌无效。使用的支付工具与所选品牌不符。例如，选择万事达卡作为品牌时，使用的是Visa信用卡。
See below for recovery options.
有关恢复选项，请参见下文。
InstNotValid Payment instrument not valid for trade. The Payment Instrument cannot be used for the proposed type of trade, for some reason.
InstNotValid付款工具对交易无效。由于某些原因，支付工具不能用于拟议的交易类型。
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.
坏仪器坏仪器。正在使用的支付工具存在问题，这意味着它无法用于支付。
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.
未指定的错误。有一些未知问题或错误不属于其他CompletionCode之一。StatusDesc属性应提供原因解释。
See below for recovery options.
有关恢复选项，请参见下文。
TimedOutRcvr Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
TimedOutRcvr可恢复超时。已重新发送消息，但未收到响应。因此，文件交换已“超时”。此代码仅对交易查询有效。
Recovery is possible if the last message from the other Trading Role is received again.
如果再次收到来自其他交易角色的最后一条消息，则可以进行恢复。
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
TimedOutNoRcvr不可恢复超时。已重新发送消息，但未收到响应。因此，文件交换已“超时”。此代码仅对交易查询有效。
No recovery possible.
无法恢复。
If the Payment is Brand Independent, then recovery may be possible for some values of the Completion Code, by the Consumer selecting either a different payment brand or a different payment instrument for the same brand. Note that this might involve a different Payment Handler. The codes to which this applies are: BrandNotSupp, PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument and Unspecified.
如果支付是独立于品牌的，则消费者可以通过选择不同的支付品牌或同一品牌的不同支付工具来恢复完成代码的某些值。请注意，这可能涉及不同的支付处理程序。适用的代码有：BrandNotSupp、PaymtCancelled、InOffFunds、InstBrandInvalid、InstNotValid、BadInstrument和Unspecified。
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.
只有在商户发送给消费者的品牌选择组件没有改变的情况下，才能从与品牌相关的购买相关的付款中恢复。实际上，这意味着必须使用相同的品牌、协议金额和付费协议元素。唯一可以改变的就是支付工具。任何其他更改都将使商户的报价无效，因为更改的选择将使报价响应无效。
The following table contains the valid values for the CompletionCode attribute for a Delivery. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
下表包含传递的CompletionCode属性的有效值。建议在适当的情况下使用StatusDesc属性提供进一步的解释。
Value Description
值描述
BackOrdered Back Ordered. The goods to be delivered are on order but they have not yet been received. Shipping will be arranged when they are received. This is only valid if ProcessState is CompletedOk.
延期交货延期交货。待交付的货物已订购，但尚未收到。收到后将安排装运。这仅在ProcessState为CompletedOk时有效。
Recovery is not possible.
恢复是不可能的。
PermNotAvail Permanently Not Available. The goods are permanently unavailable and cannot be re-ordered. This is only valid if ProcessState is Failed.
永久不可用。货物永久不可用，无法重新订购。这仅在ProcessState失败时有效。
Recovery is not possible.
恢复是不可能的。
TempNotAvail Temporarily Not Available. The goods are temporarily unavailable and may become available if they can be ordered. This is only valid if ProcessState is CompletedOk.
TempNotAvail暂时不可用。货物暂时不可用，如果可以订购，则可能可用。这仅在ProcessState为CompletedOk时有效。
Recovery is not possible.
恢复是不可能的。
ShipPending Shipping Pending. The goods are available and are scheduled for shipping but they have not yet been shipped. This is only valid if ProcessState is CompletedOk.
发货待定发货待定。货物已备妥，并已安排装运，但尚未装运。这仅在ProcessState为CompletedOk时有效。
Recovery is not possible.
恢复是不可能的。
Shipped Goods Shipped. The goods have been shipped. Confirmation of delivery is awaited. This is only valid if ProcessState is CompletedOk.
已装运的货物已装运。货物已装船。正在等待交货确认。这仅在ProcessState为CompletedOk时有效。
Recovery is not possible.
恢复是不可能的。
ShippedNoConf Shipped - No Delivery Confirmation. The goods have been shipped but it is not possible to confirm delivery of the goods. This is only valid if ProcessState is CompletedOk.
ShippedNoConf已装运-无交付确认。货物已装运，但无法确认货物已交付。这仅在ProcessState为CompletedOk时有效。
Recovery is not possible.
恢复是不可能的。
ConsCancelled Consumer Cancelled. The Consumer decides to cancel the delivery for some reason. This code is only valid in a Status Component contained in a Cancel Block or an Inquiry Response Block.
消费者取消消费取消。消费者出于某种原因决定取消交货。此代码仅在包含在取消块或查询响应块中的状态组件中有效。
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.
交货取消交货取消。交付处理程序出于某种原因拒绝完成交付，并取消交易。此代码仅在包含在取消块或查询响应块中的状态组件中有效。
Recovery is not possible.
恢复是不可能的。
Confirmed Confirmed. All goods have been delivered and confirmation of their delivery has been received. This is only valid if ProcessState is CompletedOk.
确认。所有货物均已交付，且已收到交付确认书。这仅在ProcessState为CompletedOk时有效。
Recovery is not possible.
恢复是不可能的。
Unspecified Unspecified error. There is some unknown problem or error which does not fall into one of the other CompletionCodes. The StatusDesc attribute should provide the explanation of the cause.
未指定的错误。有一些未知问题或错误不属于其他CompletionCode之一。StatusDesc属性应提供原因解释。
Recovery is not possible.
恢复是不可能的。
TimedOutRcvr Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
TimedOutRcvr可恢复超时。已重新发送消息，但未收到响应。因此，文件交换已“超时”。此代码仅对交易查询有效。
Recovery is possible if the last message from the other Trading Role is received again.
如果再次收到来自其他交易角色的最后一条消息，则可以进行恢复。
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
TimedOutNoRcvr不可恢复超时。已重新发送消息，但未收到响应。因此，文件交换已“超时”。此代码仅对交易查询有效。
No recovery possible.
无法恢复。
Note: Recovery from failed, or partially completed deliveries is not possible. The Consumer should use the Transaction Status Inquiry Transaction (see section 9.2.1) to determine up-to- date information on the current state.
注意：无法从失败或部分完成的交付中恢复。消费者应使用交易状态查询交易（见第9.2.1节）确定当前状态的最新信息。
The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
仅当ProcessState属性设置为Failed时，才需要完成代码。下表包含可能使用的CompletionCode的有效值。建议在适当的情况下使用StatusDesc属性提供进一步的解释。
Value Description
值描述
AutEeCancel Authenticatee Cancel. The Organisation being authenticated declines to be authenticated for some reason. This could be, for example because the signature on an Authentication Request was invalid or the Authenticator was not known or acceptable to the Authenticatee.
AutEeCancel认证取消。被认证的组织出于某种原因拒绝认证。例如，这可能是因为身份验证请求上的签名无效，或者身份验证人不知道或不接受身份验证人。
Recovery is not possible.
恢复是不可能的。
AutOrCancel Authenticator Cancel. The Organisation requesting authentication declines to validate the Authentication Response received for some reason and cancels the transaction.
自动取消验证器取消。请求认证的组织出于某种原因拒绝验证收到的认证响应，并取消交易。
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身份验证请求不可用。AuthenticateTee没有必须提供的数据，因此无法成功对其进行身份验证。例如，密码可能已被遗忘，AuthenticateTee尚未成为成员，或者智能卡令牌不存在。
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.
通过被认证者使用更正的数据重新发送修订的认证响应，可以进行恢复。
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
交易角色与交易角色不一致。交易角色信息请求组件（见第7.4节）的TradingRoleList属性中包含的交易角色与被认证人在IOTP交易中正在扮演或能够扮演的交易角色不一致。不一致的例子包括：o向PaymentHandler询问DeliveryHandler信息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.
未指定的错误。有一些未知问题或错误不属于其他CompletionCode之一。
Recovery is not possible.
恢复是不可能的。
TimedOutRcvr Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
TimedOutRcvr可恢复超时。已重新发送消息，但未收到响应。因此，文件交换已“超时”。此代码仅对交易查询有效。
Recovery is possible if the last message from the other Trading Role is received again.
如果再次收到来自其他交易角色的最后一条消息，则可以进行恢复。
TimedOutNoRcvr Non Recoverable Time Out. Messages were resent but no response received. The document exchange has therefore "Timed Out". This code is only valid on a Transaction Inquiry.
TimedOutNoRcvr不可恢复超时。已重新发送消息，但未收到响应。因此，文件交换已“超时”。此代码仅对交易查询有效。
No recovery possible.
无法恢复。
The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
仅当ProcessState属性设置为Failed时，才需要完成代码。下表包含可能使用的CompletionCode的有效值。建议在适当的情况下使用StatusDesc属性提供进一步的解释。
Value Description
值描述
InMsgHardError Input Message Hard Error. The type of Request Block could not be identified or was inconsistent. Therefore no single Document Exchange could be identified. This will cause a Hard Error in the transaction
InMsgHarderError输入消息硬错误。无法识别请求块的类型或类型不一致。因此，无法确定单一的文件交换。这将导致事务中出现硬错误
The Completion Code is only required if the ProcessState attribute is set to Failed. The following table contains the valid values for the CompletionCode that may be used. It is recommended that the StatusDesc attribute is used to provide further explanation where appropriate.
仅当ProcessState属性设置为Failed时，才需要完成代码。下表包含可能使用的CompletionCode的有效值。建议在适当的情况下使用StatusDesc属性提供进一步的解释。
Value Description
值描述
UnAuthReq Unauthorised Request. The recipient of the Transaction Status Request declines to respond to the request.
未经授权的请求。事务状态请求的收件人拒绝响应该请求。
The Trading Role Data Component contains opaque data which needs to be communicated between the Trading Roles involved in an IOTP Transaction.
交易角色数据组件包含不透明数据，需要在IOTP交易中涉及的交易角色之间进行通信。
Trading Role Components identify:
交易角色组件确定：
o the Organisation that generated the component, and
o 生成组件的组织，以及
o the Organisation that is to receive it.
o 将接收它的组织。
They are first generated and included in a "Response" Block, and then copied to the appropriate "Request" Block. For example a Payment Handler might need to inform a Delivery Handler that a credit card payment had been authorised but not captured. There may also be other information that the Payment Handler has generated where the format is privately agreed with the Delivery Handler which needs to be communicated. In another example a Merchant might need to provide a Payment Handler with some specific information about a Consumer so that consumer can acquire double loyalty points with the payment.
它们首先生成并包含在“响应”块中，然后复制到相应的“请求”块中。例如，支付处理人员可能需要通知交付处理人员信用卡支付已被授权但未被捕获。付款经办人还可能生成其他信息，其中格式与交付经办人私下约定，需要沟通。在另一个示例中，商户可能需要向支付处理程序提供有关消费者的某些特定信息，以便消费者可以通过支付获得双重忠诚度。
Its definition is as follows.
其定义如下。
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData
ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIRED
DestinationElRefs NMTOKENS #REQUIRED >
<!ELEMENT TradingRoleData (PackagedContent+) >
<!ATTLIST TradingRoleData
ID ID #REQUIRED
OriginatorElRef NMTOKEN #REQUIRED
DestinationElRefs NMTOKENS #REQUIRED >
Attributes:
属性：
ID An identifier which uniquely identifies the Trading Role Data Component within the IOTP Transaction.
ID唯一标识IOTP交易中交易角色数据组件的标识符。
OrginatorElRef Contains an element reference to the Organisation Component of the Organisation that created the Trading Role Data Component and included it in a "Response" Block (e.g., an Offer Response or a Payment Response Block).
OrginatorElRef包含对创建交易角色数据组件的组织的组织组件的元素引用，并将其包含在“响应”块（例如，要约响应或支付响应块）中。
DestinationElRefs Contains element references to the Organisation Components of the Organisations that are to receive the Trading Role Data Component in a "Request" Block (e.g., either a Payment Request or a Delivery Request Block).
DestinationElRefs包含对将在“请求”块（例如，付款请求或交付请求块）中接收交易角色数据组件的组织的组织组件的元素引用。
Content:
内容：
PackagedContent This contains the data which is to be sent between the various Trading Roles as one or more PackagedContent elements see section 3.7.
PackagedContent包含作为一个或多个PackagedContent元素在不同交易角色之间发送的数据，请参见第3.7节。
The rules for deciding what to do with Trading Role Data Components are described below.
决定如何处理交易角色数据组件的规则如下所述。
o whenever a Trading Role Data Component is received in a "Response" block identify the Organisation Components of the Organisations that are to receive it as identified by the DestinationElRefs attribute.
o 每当在“响应”块中接收到交易角色数据组件时，请按照DestinationElRefs属性标识要接收该数据的组织的组织组件。
o whenever a "Request" Block is being sent, check to see if it is being sent to one of the Organisations identified by the DestinationElRefs attribute. If it is then include in the "Request" block:
o 每当发送“请求”块时，请检查是否将其发送给DestinationElRefs属性标识的组织之一。如果是，则包括在“请求”块中：
- the Trading Role Data Component as well as,
- 交易角色数据组件以及，
- the Organisation Component of the Organisation identified by the OriginatorElRef attribute (if not already present)
- 由OriginatorElRef属性标识的组织的组织组成部分（如果尚未存在）
The Inquiry Type Component contains the information which indicates the type of process that is being inquired upon. Its definition is as follows.
查询类型组件包含指示正在查询的进程类型的信息。其定义如下。
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
Type NMTOKEN #REQUIRED
ElRef NMTOKEN #IMPLIED
ProcessReference CDATA #IMPLIED >
<!ELEMENT InquiryType EMPTY >
<!ATTLIST InquiryType
ID ID #REQUIRED
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 Offer。查询是关于报价的状态，并发送给商户。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
ElRef包含适用于该查询类型组件的组件的元素参考（见第3.5节）。即，当类型为Offer时，o TPO块
o Payment Component when Type is Payment o Delivery Component when Type is Delivery
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和Yoshiaki Kawatsura与本文件同时发布的题为“互联网开放交易协议的数字签名”的文件中进行了描述-参见[IOTPDSIG]。
In the future it is anticipated that future versions of IOTP will adopt a whatever method for digitally signing XML becomes the standard.
在未来，预计IOTP的未来版本将采用任何方法对XML进行数字签名成为标准。
Each Signature Component digitally signs one or more Blocks or Components including other Signature Components.
每个签名组件对一个或多个块或组件（包括其他签名组件）进行数字签名。
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事务中一个或多个IOTP消息中一个或多个块或组件的摘要，并将结果放入摘要元素中
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:
签名组件可以是以下四种类型之一：
o an Offer Response Signature,
o 报价响应签名，
o a Payment Response Signature,
o 付款响应签名，
o a Delivery Response Signature, or
o 交付响应签名，或
o an Authentication Response Signature.
o 身份验证响应签名。
For a general explanation of signatures see section 6 Digital Signatures.
有关签名的一般说明，请参见第6节数字签名。
Definitions of the elements and attributes are contained in [IOTPDSIG]. The following contains additional information that describes how these elements and attributes are used by IOTP.
元素和属性的定义包含在[IOTPDSIG]中。以下包含描述IOTP如何使用这些元素和属性的附加信息。
SIGNATURE ELEMENT
特征元素
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.
algorithm元素标识生成签名时使用的算法。算法的类型由type属性的值定义，该值指示它是用作摘要算法、签名算法还是密钥协商算法。
The following Digest algorithms must be implemented:
必须实现以下摘要算法：
o a [DOM-HASH] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:ibm:dom-hash"
o [DOM-HASH]算法。这是通过将算法元素的Name属性设置为“urn:ibm:domhash”来标识的
o a [SHA1] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:fips:sha1", and
o [SHA1]算法。这是通过将算法元素的Name属性设置为“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]算法。这是通过将算法元素的Name属性设置为“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]算法。这是通过将算法元素的Name属性设置为“urn:us.gov:dsa”来标识的
o a [HMAC] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:ibm:hmac"
o 一种[HMAC]算法。这是通过将算法元素的Name属性设置为“urn:ibm:hmac”来标识的
It is recommended that the following Signature algorithm is also implemented:
建议还实施以下签名算法：
o a [RSA] algorithm. This is identified by setting the Name attribute of the Algorithm element to "urn:rsa:rsa"
o 一种[RSA]算法。这可以通过将算法元素的Name属性设置为“urn:rsa:rsa”来识别
In addition other payment scheme specific algorithms may be used. In this case the value of the name attribute to use is specified in the payment scheme supplement for that algorithm.
此外，还可以使用其他特定于支付方案的算法。在这种情况下，要使用的name属性的值在该算法的支付方案补充中指定。
One algorithm may make use of other algorithms by use of the Parameter element, for example:
一种算法可以通过使用参数元素使用其他算法，例如：
<Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
<Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID=A2 type="digest" name="urn:fips:sha1">
</Algorithm>
<Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
<Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>
<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 Signature Type且内容设置为以下任一项的类型属性：OfferResponse、PaymentResponse、DeliveryResponse、，
AuthenticationRequest, AuthenticationResponse, PingRequest or PingResponse; depending on the type of the signature.
AuthenticationRequest、AuthenticationResponse、PingRequest或PingResponse；取决于签名的类型。
Values of the content of the Attribute element are controlled under the procedures defined in section 12 IANA Considerations which also allows user defined values to be defined.
属性元素内容的值根据第12节IANA注意事项中定义的程序进行控制，该节还允许定义用户定义的值。
The Critical attribute must be set to true.
临界属性必须设置为true。
ORIGINATORINFO ELEMENT
原始信息元素
The OriginatorRef attribute of the OriginatorInfo element must always be present and contain an Element Reference (see section 3.5) to the Organisation Component of the Organisation that generated the Signature Component.
OriginatorInfo要素的OriginatorRef属性必须始终存在，并包含对生成签名要素的组织的组织要素的要素引用（见第3.5节）。
RECIPIENTINFO ELEMENT
RECIPIENTINFO元素
The RecipientRefs attribute contains a list of Element References (see section 3.5), that point to the Organisations that might need to validate the signature. For details see below.
RecipientRefs属性包含元素引用列表（参见第3.5节），这些元素引用指向可能需要验证签名的组织。详情见下文。
The Manifest Element of a signature which has a type of OfferResponse should contain Digest elements for the following Components:
具有报价响应类型的签名的清单元素应包含以下组件的摘要元素：
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 状态组件
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:
交付响应签名组件的Manifest元素应包含以下组件的摘要元素：
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:
身份验证请求签名组件的Manifest元素应包含以下组件的摘要元素：
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消息的事务参考块（见第3.3节），其中包含描述IOTP消息和IOTP事务的信息
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:
身份验证响应签名组件的Manifest元素应包含以下组件的摘要元素：
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消息的事务参考块（见第3.3节），其中包含描述IOTP消息和IOTP事务的信息
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请求签名组件的Manifest元素应包含所有组织组件的摘要元素。
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.
错误组件包含IOTP消息中有关技术错误的信息（见第4.1节），该消息已由交易中涉及的一个交易角色接收。
For clarity two phrases are defined which are used in the description of an Error Component:
为清楚起见，定义了两个用于描述错误组件的短语：
o message in error. An IOTP message which contains or causes an error of some kind
o 错误消息。包含或导致某种错误的IOTP消息
o message reporting the error. An IOTP message that contains an Error Component that describes the error found in a message in error.
o 报告错误的消息。包含错误组件的IOTP消息，该组件描述在错误消息中发现的错误。
The definition of the Error Component is as follows.
错误组件的定义如下所示。
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
Severity (Warning|TransientError|HardError) #REQUIRED
MinRetrySecs CDATA #IMPLIED
SwVendorErrorRef CDATA #IMPLIED >
<!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
<!ATTLIST ErrorComp
ID NMTOKEN #REQUIRED
xml:lang NMTOKEN #REQUIRED
ErrorCode NMTOKEN #REQUIRED
ErrorDesc CDATA #REQUIRED
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事务仍可以继续。哦，运输员。这表示如果重新发送ErrorLocation元素引用的message in error，则可以恢复message in error中的错误
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如果严重性设置为TransineError，则此属性应存在。它是接收到报告错误消息的IOTP感知应用程序在重新发送ErrorLocation元素标识的出错消息之前应等待的最小整秒数。
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此属性是一个引用，其值由生成错误组件的软件的供应商/开发人员设置。它应包含使供应商能够识别其软件中的精确位置的数据，以及导致软件生成报告错误的消息的一组情况。另请参见事务参考块中消息Id元素的SoftwareId属性（第3.3节）。
Content:
内容：
ErrorLocation This identifies the IOTP Transaction Id of the message in error and, where possible, the element and attribute in the message in error that caused the Error Component to be generated.
ErrorLocation标识出错消息的IOTP事务Id，如果可能，标识出错消息中导致生成错误组件的元素和属性。
If the Severity of the error is not TransientError, more than one ErrorLocation may be specified as appropriate depending on the nature of the error (see section 7.21.2 Error Codes) and at the discretion of the vendor/developer of the IOTP Aware Application.
如果错误的严重程度不是TransientError，则根据错误的性质（见第7.21.2节错误代码）以及IOTP感知应用程序的供应商/开发商的决定，可酌情指定多个错误位置。
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感知应用程序的供应商/开发人员的判断，其内容可能会有所不同。有关包装内容的定义，请参见第3.7节。
If there is more than one Error Component in a message reporting the error, carry out the actions appropriate for the Error Component with the highest severity. In this context, HardError has a higher severity than TransientError, which has a higher severity than Warning.
如果报告错误的消息中有多个错误组件，请执行适用于严重性最高的错误组件的操作。在这种情况下，HardError的严重性高于TransientError，TransientError的严重性高于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感知应用程序正在生成一条消息，其中错误组件的严重性属性设置为警告，则如果报告错误的消息不包含另一个严重性高于警告的错误组件，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感知应用程序正在生成报告错误的消息，其中错误组件的严重性属性设置为TransientError，则报告错误的消息中应该只有一个错误组件。此外，应该存在MinRetrySecs属性。
If a message reporting the error is received with an Error Component where Severity is set to TransientError then:
如果接收到报告错误的消息时错误组件的严重性设置为TransineError，则：
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.
- 使用MinRetrySecs的值，该值由IOTP感知应用程序的供应商/开发人员设置。
o check that only one ErrorLocation element is contained within the Error Component and that it refers to an IOTP Message which was sent by the recipient of the Error Component with a Severity of TransientError. If more than one ErrorLocation is present then generate a message reporting the error with a Severity of HardError.
o 检查错误组件中是否仅包含一个ErrorLocation元素，以及该元素是否引用错误组件收件人发送的严重性为TransientError的IOTP消息。如果存在多个ErrorLocation，则生成一条消息，报告严重性为HardError的错误。
If an IOTP Aware Application is generating a message reporting the error with an Error Component where the Severity attribute set to HardError, then there should be only one Error Component in the message reporting the error.
如果IOTP感知应用程序正在生成报告错误的消息，其中错误组件的严重性属性设置为HardError，则报告错误的消息中应该只有一个错误组件。
If a message reporting the error is received with an Error Component where Severity is set to HardError then terminate the IOTP Transaction.
如果接收到报告错误的消息时错误组件的严重性设置为HardError，则终止IOTP事务。
The following table contains the valid values for the ErrorCode attribute of the Error Component. The first sentence of the description contains the text that should be used to describe the error when displayed or otherwise reported. Individual implementations may translate this into alternative languages at their discretion.
下表包含错误组件的ErrorCode属性的有效值。描述的第一句包含显示或以其他方式报告时应用于描述错误的文本。个别实现可自行决定将其转换为其他语言。
An Error Code must not be more that 14 characters long.
错误代码的长度不得超过14个字符。
Value Description
值描述
Reserved Reserved. This error is reserved by the vendor/developer of the software. Contact the vendor/developer of the software for more information See the SoftwareId attribute of the Message Id element in the Transaction Reference Block(section 3.3).
保留的。此错误由软件供应商/开发人员保留。有关更多信息，请联系软件的供应商/开发人员，参见事务参考块中消息Id元素的SoftwareId属性（第3.3节）。
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意外元素。尽管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与本规范中包含的规则和约束一致，但处理IOTP消息的IOTP感知应用程序不支持o。
ElMissing Element missing. Although the document is well formed and valid, an element is missing that should have been present if the rules and constraints contained in this specification are followed.
缺少ElMissing元素。尽管文档格式良好且有效，但如果遵循本规范中包含的规则和约束，则缺少本应存在的元素。
In this case set the PackagedContent of the Error Component to the type of the missing element.
在这种情况下，将错误组件的PackagedContent设置为缺少元素的类型。
ElContIllegal Element content illegal. Although the document is well formed and valid, the element Content contains values which do not conform to the rules and constraints contained in this specification.
ELCONTLIVALL元素内容非法。尽管文档格式良好且有效，但元素内容包含的值不符合本规范中包含的规则和约束。
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.
EncapProperter封装的协议错误。尽管文档格式良好且有效，但元素的PackagedContent包含来自包含错误的封装协议的数据。
AttUnexpected Unexpected attribute. Although the XML document is well formed and valid, the presence of the attribute is not expected in the particular context according to the rules and constraints contained in this specification.
意外属性。尽管XML文档格式良好且有效，但根据本规范中包含的规则和约束，在特定上下文中不需要属性的存在。
AttNotSupp Attribute not supported. Although the XML document is well formed and valid, and the presence of the attribute in an element is consistent with the rules and constraints contained in this specification, it is not supported by the IOTP Aware Application which is processing the IOTP Message.
不支持AttNotSupp属性。尽管XML文档格式良好且有效，并且元素中属性的存在符合本规范中包含的规则和约束，但处理IOTP消息的IOTP感知应用程序不支持该文档。
AttMissing Attribute missing. Although the document is well formed and valid, an attribute is missing that should have been present if the rules and constraints contained in this specification are followed.
属性缺失。尽管文档格式良好且有效，但如果遵循本规范中包含的规则和约束，则缺少本应存在的属性。
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
ELTOOLAGE元素太大。元素太大，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.
值太小值太小或太早。元素或属性的全部或部分内容的值虽然有效，但太小。
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属性的值与一个或多个其他属性的值不一致。
In this case create ErrorLocation elements which identify all the attributes or elements which are inconsistent.
在这种情况下，创建ErrorLocation元素，该元素标识所有不一致的属性或元素。
TransportError Transport Error. This error code is used to indicate that there is a problem with the Transport Mechanism which is preventing the message from being received. It is typically associated with a Transient Error. Explanation of the Transport Error is contained within the ErrorDesc attribute. The values which can be used inside ErrorDesc with a TransportError is specified in the IOTP supplement for the Transport mechanism.
传输错误传输错误。此错误代码用于指示传输机制存在问题，导致无法接收消息。它通常与瞬时误差有关。传输错误的解释包含在ErrorDesc属性中。传输机制的IOTP补充文件中规定了可在带有TransportError的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属性指示的时间内未收到响应，则应重新发送原始消息。
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.
MinRetrySecs属性指示的时间，则应重新发送原始消息。
Note: If the server/system handling the Transport Mechanism (e.g., HTTP) is busy then a Transport Specific error message should be used instead of an IOTP Error message. This code should be used in association with IOTP servers/systems or other servers/systems to which the IOTP server is connected.
注意：如果处理传输机制（例如HTTP）的服务器/系统正忙，则应使用传输特定的错误消息，而不是IOTP错误消息。此代码应与IOTP服务器/系统或IOTP服务器所连接的其他服务器/系统一起使用。
UnknownError Unknown Error. Indicates that the transaction cannot complete for some reason that is not covered explicitly by any of the other errors. The ErrorDesc attribute should be used to indicate the nature of the problem.
未知错误未知错误。表示由于其他任何错误都没有明确说明的原因，事务无法完成。ErrorDesc属性应用于指示问题的性质。
This could be used to indicate, for example, an internal error in a backend server or client process of some kind.
例如，这可用于指示后端服务器或某种客户端进程中的内部错误。
An Error Location Element identifies an element and optionally an attribute in the message in error which is associated with the error. It contains a reference to the IOTP Message, Trading Block, Trading Component, element and attribute, which is in error.
错误位置元素标识一个元素，还可以标识错误消息中与错误关联的属性。它包含对错误的IOTP消息、交易块、交易组件、元素和属性的引用。
<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED >
<!ELEMENT ErrorLocation EMPTY >
<!ATTLIST ErrorLocation
ElementType NMTOKEN #REQUIRED
IotpMsgRef NMTOKEN #IMPLIED
BlkRef NMTOKEN #IMPLIED
CompRef NMTOKEN #IMPLIED
ElementRef NMTOKEN #IMPLIED
AttName NMTOKEN #IMPLIED >
Attributes:
属性：
ElementType This is the name of the type of the element where the error is located. For example if the element was declared as <!ELEMENT Org ... then its name is "Org".
ElementType这是错误所在元素类型的名称。例如，如果元素被声明为<！元素组织。。。然后它的名字是“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.
CompRef如果错误与特定交易组件关联，则这是错误所在交易组件的ID属性值。
ElementRef If the error is associated with a specific element within a Trading Component then, if the element has an attribute with an "attribute type" (see [XML]) of "ID", then this is the value of that attribute.
ElementRef如果错误与交易组件中的特定元素相关联，则如果该元素具有“属性类型”（参见[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如果错误与属性值关联，则这是该属性的名称。在这种情况下，错误组件的PackagedContent应该包含该属性的值。
Note that as many as the attributes as possible should be included. For example if an attribute in a child element of a Trading Component contains an incorrect value, then all the attributes of ErrorLocation should be present.
请注意，应包含尽可能多的属性。例如，如果交易组件的子元素中的属性包含不正确的值，那么ErrorLocation的所有属性都应该存在。
Trading Blocks are child elements of the top level IOTP Messages that are sent in the form of [XML] documents directly between the different Trading Roles that are taking part in a trade.
交易区块是顶级IOTP消息的子元素，以[XML]文档的形式直接在参与交易的不同交易角色之间发送。
Each Trading Blocks consist of one or more Trading Components (see section 7). This is illustrated in the diagram below.
每个交易区块由一个或多个交易组成（见第7节）。下图对此进行了说明。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
IOTP MESSAGE <-----------IOTP Message - an XML Document
| which is transported between the
| Trading Roles
|-Trans Ref Block <----- Trans Ref Block - contains
| | information which describes the
| | IOTP Transaction and the IOTP
| | Message.
| |-Trans Id Comp. <--- Transaction Id Component -
| | uniquely identifies the IOTP
| | Transaction. The Trans Id
| | Components are the same across
| | all IOTP messages that comprise a
| | single IOTP transaction.
| |-Msg Id Comp. <----- Message Id Component - identifies
| and describes an IOTP Message
| within an IOTP Transaction
|-Signature Block <----- Signature Block (optional) -
| | contains one or more Signature
| | Components and their associated
| | Certificates
| |-Signature Comp. <-- Signature Component - contains
| | digital signatures. Signatures
| | may sign digests of the Trans Ref
| | Block and any Trading Component
| | in any IOTP Message in the same
| | IOTP Transaction.
| |-Certificate Comp. <-Certificate Component. Used to
| check the signature. (Optional)
------> |-Trading Block <--------Trading Block - an XML Element
| | |-Trading Comp. within an IOTP Message that
Trading | |-Trading Comp. contains a predefined set of
Blocks | |-Trading Comp. Trading Components
| | |-Trading Comp.
| | |-Trading Comp. <-----Trading Components - XML Elements
| | within a Trading Block that
------> |-Trading Block contain a predefined set of XML
| |-Trading Comp. elements and attributes
| |-Trading Comp. containing information required
| |-Trading Comp. to support a Trading Exchange
| |-Trading Comp.
| |-Trading Comp.
|
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
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 | DeliveryReqBlk | DeliveryReqBlk | InquiryReqBlk | InquiryRespBlk | offerSpblk | payXchblk | PayReqBlk | payPayReqblk | PayRespBlk | PayReqBlk | PayReqBlk | PingReqBlk | PingReqbl
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 查询响应块
o Offer Response Block
o 报价响应块
o Payment Exchange Block
o 支付交换区
o Payment Request Block
o 付款请求块
o Payment Response Block
o 支付响应块
o Signature Block
o 签名块
o Trading Protocol Options Block
o 交易协议期权组
o TPO Selection Block
o TPO选择块
The Transaction Reference Block is described in section 3.3.
第3.3节描述了事务参考块。
The TPO Trading Block contains options which apply to the IOTP Transaction. The definition of a TPO Trading Block is as follows.
TPO交易区块包含适用于IOTP交易的选项。TPO交易区块的定义如下。
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, 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).
协议选项协议选项组件（见第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).
品牌列表该品牌列表组件包含一个或多个可选择的支付品牌和协议（见第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交易中包含交付，则具有DeliverTo交易角色的组织组成部分
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 >
<!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.
品牌选择-标识在IOTP交易中用于支付的支付品牌和支付协议的选择。IOTP交易中的每笔付款都有一个品牌选择组件（见第7.8节）。
The TPO Selection Block should contain one Brand Selection Component for each Brand List in the TPO Block.
TPO选择块应包含TPO块中每个品牌列表的一个品牌选择组件。
The Offer Response Block contains details of the goods, services, amount, delivery instructions or financial transaction which is to take place. Its definition is as follows.
报价响应栏包含货物、服务、金额、交货说明或即将发生的金融交易的详细信息。其定义如下。
<!ELEMENT OfferRespBlk (Status, Order?, Payment*,
Delivery?, TradingRoleData*) >
<!ATTLIST OfferRespBlk
ID ID #REQUIRED >
<!ELEMENT OfferRespBlk (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.
Status包含有关业务成功（见第4.2节）或生成报价失败的状态信息。请注意，在提供响应块中，NotYetStarted或InProgress的ProcessState是非法值。
Order The Order Component contains details about the goods, services or financial transaction which is taking place see section 7.5.
订单订单组件包含有关正在进行的商品、服务或金融交易的详细信息，请参见第7.5节。
The Order Component must be present unless the ProcessState attribute of the Status Component is set to Failed.
除非状态组件的ProcessState属性设置为Failed，否则订单组件必须存在。
Payment The Payment Components contain information about the payments which are to be made see section 7.9.
付款付款组成部分包含有关要进行的付款的信息，请参见第7.9节。
Delivery The Delivery Component contains details of the delivery to be made (see section 7.13).
交付交付组件包含待交付的详细信息（见第7.13节）。
TradingRoleData The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an IOTP Transaction (see section 7.17).
TradingRoleData交易角色数据组件包含不透明数据，需要在IOTP交易中涉及的交易角色之间进行沟通（见第7.17节）。
The Offer Response Block should contain:
报价响应块应包含：
o the Order Component for the IOTP Transaction
o IOTP事务的订单组件
o Payment Components for each Payment in the IOTP Transaction
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 >
<!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.
如果存在一个身份验证请求组件，则应使用该身份验证请求组件。
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
TradingRoleInfo交易角色信息请求组件（见第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.
身份验证块中必须至少有一个组件（身份验证请求或交易角色信息请求），否则这是一个错误。
The Authentication Response Block contains the response which results from processing the Authentication Request Block. Its definition is as follows.
身份验证响应块包含处理身份验证请求块所产生的响应。其定义如下。
<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk
ID ID #REQUIRED >
<!ELEMENT AuthRespBlk (AuthResp?, 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属性请求的与交易角色对应的信息。
The components present in the Authentication Response Block must match the requirement of the corresponding Authentication Request Block otherwise it is an error.
身份验证响应块中存在的组件必须与相应身份验证请求块的要求相匹配，否则这是一个错误。
The Authentication Status Block indicates the success or failure of the validation of an Authentication Response Block by an Authenticator. Its definition is as follows.
身份验证状态块指示验证器验证身份验证响应块的成功或失败。其定义如下。
<!ELEMENT AuthStatusBlk (Status) >
<!ATTLIST AuthStatusBlk
ID ID #REQUIRED >
<!ELEMENT AuthStatusBlk (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
Status包含有关业务成功（参见第4.2节）或身份验证失败的状态信息
The Payment Request Block contains information which requests that a payment is started. Its definition is as follows.
付款请求块包含请求开始付款的信息。其定义如下。
<!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
Payment, PaySchemeData?, Org*, TradingRoleData*) >
<!ATTLIST PayReqBlk
ID ID #REQUIRED >
<!ELEMENT PayReqBlk (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
Status（状态）包含响应步骤（例如，报价响应和/或付款响应）的状态组件（见第7.13节）
step depends. It is used to indicate the success or failure of those steps. Payment should only occur if the previous steps were successful.
步骤取决于。它用于指示这些步骤的成功或失败。只有在前面的步骤成功的情况下，才应进行付款。
BrandList The Brand List Component contains a list of one or more payment brands and protocols which may be selected (see section 7.7).
品牌列表品牌列表组件包含一个或多个可选择的支付品牌和协议列表（见第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.
品牌选择-标识在IOTP交易中用于支付的支付品牌、支付协议和支付处理程序的选择。IOTP交易中的每笔付款都有一个品牌选择组件（见第7.8节）。
Payment The Payment Components contain information about the payment which is being made see section 7.9.
付款付款组件包含有关正在进行的付款的信息，请参见第7.9节。
PaySchemeData The Payment Scheme Component contains payment scheme specific data see section 7.10.
PaySchemeData支付方案组件包含特定于支付方案的数据，请参见第7.10节。
Org The Organisation Component contains details of Organisations involved in the payment (see section 7.6). The Organisations present are dependent on the IOTP Transaction and the data which is to be signed. See section 6 Digital Signatures for more details.
组织-组织部分包含参与付款的组织的详细信息（见第7.6节）。在场的组织取决于IOTP交易和待签署的数据。有关更多详细信息，请参见第6节数字签名。
TradingRoleData The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an IOTP Transaction (see section 7.17).
TradingRoleData交易角色数据组件包含不透明数据，需要在IOTP交易中涉及的交易角色之间进行沟通（见第7.17节）。
The Payment Request Block should contain:
付款请求块应包含：
o the Organisation Component with a Trading Role of Merchant
o 具有商户交易角色的组织组成部分
o the Organisation Component with the Trading Role of Consumer
o 具有消费者交易角色的组织组成部分
o the Payment Component for the Payment
o 付款的付款组件
o the Brand List Component for the Payment
o 用于付款的品牌列表组件
o the Brand Selection Component for the Brand List
o 品牌列表的品牌选择组件
o the Organisation Component for the Payment Handler of the Payment
o 付款的付款处理程序的组织组件
o the Organisation Component (if any) for the Organisation which carried out the previous step, for example another Payment Handler
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.
支付交换块包含交易中两个角色之间交换的特定于支付方案的数据。其定义如下。
<!ELEMENT PayExchBlk (PaySchemeData+) >
<!ATTLIST PayExchBlk
ID ID #REQUIRED >
<!ELEMENT PayExchBlk (PaySchemeData+) >
<!ATTLIST PayExchBlk
ID ID #REQUIRED >
Attributes:
属性：
ID An identifier which uniquely identifies the Payment Exchange Block within the IOTP Transaction.
ID唯一标识IOTP交易中支付交换块的标识符。
Content:
内容：
PaySchemeData This Trading Component contains payment scheme specific data see section 7.10 Payment Scheme Component.
PaySchemeData此交易组件包含特定于支付方案的数据，请参见第7.10节支付方案组件。
This Payment Response Block contains a information about the Payment Status, an optional Payment Receipt, and an optional payment protocol message. Its definition is as follows.
此付款响应块包含有关付款状态的信息、可选付款收据和可选付款协议消息。其定义如下。
<!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
PaymentNote?, TradingRoleData*) >
<!ATTLIST PayRespBlk
ID ID #REQUIRED >
<!ELEMENT PayRespBlk (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.
Status包含有关业务成功（见第4.2节）或付款失败的状态信息。请注意，在支付响应块中，NotYetStarted或InProgress的ProcessState是非法值。
PayReceipt Contains payment scheme specific data which can be used to verify the payment occurred. See section 7.11 Payment Receipt Component. It must be present if the ProcessState attribute of the Status Component is set to CompletedOk. PayReceipt is optional for other values as specified by the appropriate Payment Scheme supplement.
PayReceive包含特定于付款方案的数据，可用于验证已发生的付款。参见第7.11节“付款收据”部分。如果状态组件的ProcessState属性设置为CompletedOk，则它必须存在。对于适当的付款方案补充文件中指定的其他值，付款收据是可选的。
PaySchemeData Contains payment scheme specific data see section, for example a payment protocol message. See 7.10 Payment Scheme Component.
PaySchemeData包含特定于支付方案的数据，请参见第节，例如支付协议消息。见7.10付款方案组成部分。
PaymentNote Contains additional, non payment related, information which the Payment Handler wants to provide to the Consumer. For example, if a withdrawal or deposit were being made then it could contain information on the remaining balance on the account after the transfer was complete. See section 7.12 Payment Note Component.
PaymentNote包含支付处理程序希望向消费者提供的其他非支付相关信息。例如，如果正在进行取款或存款，则该取款或存款可能包含转账完成后账户上剩余余额的信息。见第7.12节付款通知单组成部分。
TradingRoleData The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an IOTP Transaction (see section 7.17).
TradingRoleData交易角色数据组件包含不透明数据，需要在IOTP交易中涉及的交易角色之间进行沟通（见第7.17节）。
The Delivery Request Block contains details of the goods or services which are to be delivered together with a signature which can be used to check that delivery is authorised. Its definition is as follows.
“交货请求”栏包含将要交付的货物或服务的详细信息，以及可用于检查交付是否得到授权的签名。其定义如下。
<!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
ConsumerDeliveryData?, TradingRoleData*) >
<!ATTLIST DeliveryReqBlk
ID ID #REQUIRED >
<!ELEMENT DeliveryReqBlk (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.
Status包含本步骤所依赖的步骤（如付款响应）响应的状态组件（见第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.
ConsumerDeliveryData可选。包含使用者指定的标识符，如果传递处理程序返回该标识符，将使使用者能够标识引用的传递。
TradingRoleData The Trading Role Data Component contains opaque data which is needs to be communicated between the Trading Roles involved in an IOTP Transaction (see section 7.17).
TradingRoleData交易角色数据组件包含不透明数据，需要在IOTP交易中涉及的交易角色之间进行沟通（见第7.17节）。
The Delivery Request Block contains:
传递请求块包含：
o the Organisation Component with a Trading Role of Merchant
o 具有商户交易角色的组织组成部分
o the Organisation Component for the Consumer and DeliverTo Trading Roles
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.
Delivery Response块包含一个交货通知，其中包含有关如何交货的详细信息。其定义如下。请注意，在交付响应块中，DeliveryStatusCode为NotYetStarted或InProgress的交付状态元素无效。
<!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
<!ATTLIST DeliveryRespBlk
ID ID #REQUIRED >
<!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的ProcessState是非法值。
DeliveryNote The Delivery Note Component contains details about how the goods or services will be delivered (see section 7.15).
交货说明交货说明组件包含有关如何交付货物或服务的详细信息（参见第7.15节）。
The Inquiry Request Trading Block contains an Inquiry Type Component and an optional Payment Scheme Component to contain payment scheme specific inquiry messages.
查询请求交易块包含一个查询类型组件和一个可选的支付方案组件，用于包含特定于支付方案的查询消息。
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
ID ID #REQUIRED >
<!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
<!ATTLIST InquiryReqBlk
ID ID #REQUIRED >
Attributes:
属性：
ID An identifier which uniquely identifies the Inquiry Request Trading Block within the IOTP Transaction.
ID唯一标识IOTP交易中查询请求交易块的标识符。
Content:
内容：
InquiryType Inquiry Type Component (see section 7.18) that contains the type of inquiry.
InquiryType查询类型组件（参见第7.18节），其中包含查询类型。
PaySchemeData Payment Scheme Component (see section 7.10) that contains payment scheme specific inquiry messages for inquiries on payments. This is present when the Type attribute of Inquiry Type Component is Payment.
PaySchemeData支付方案组件（参见第7.10节），其中包含特定于支付方案的查询消息，用于查询支付。当“查询类型”组件的“类型”属性为“付款”时，会出现此选项。
The Inquiry Response Trading Block contains a Status Component and an optional Payment Scheme Component to contain payment scheme specific inquiry messages. Its purpose is to enquire on the current status of an IOTP transaction at a server.
查询响应交易块包含一个状态组件和一个可选的支付方案组件，用于包含特定于支付方案的查询消息。其目的是查询服务器上IOTP事务的当前状态。
<!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
<!ATTLIST InquiryRespBlk
ID ID #REQUIRED
LastReceivedIotpMsgRef NMTOKEN #IMPLIED
LastSentIotpMsgRef NMTOKEN #IMPLIED >
<!ELEMENT InquiryRespBlk (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包含一个元素引用（参见第3.5节），指向此服务器从使用者处收到的最后一条消息的消息Id组件（参见第3.3.2节）。如果在相关事务中没有以前从消费者处接收到的消息，则此属性应包含Null值。此属性的存在是为了调试目的。
LastSentIotpMsgRef Contains an Element Reference (see section 3.5) to the Message Id Component (see section 3.3.2) of the last message this server has sent to the Consumer. If there is no previously sent message to the Consumer in the pertinent transaction, this attribute should contain the value Null. This attribute exists for debugging purposes.
LastSentIotpMsgRef包含一个元素引用（参见第3.5节），指向该服务器发送给消费者的最后一条消息的消息Id组件（参见第3.3.2节）。如果相关事务中没有以前发送给消费者的消息，则此属性应包含Null值。此属性的存在是为了调试目的。
Content:
内容：
Status Contains status information about the business success (see section 4.2) or failure of a certain trading exchange (i.e., Offer, Payment, or Delivery).
Status包含有关某个交易交易所（即报价、付款或交付）的业务成功（见第4.2节）或失败的状态信息。
PaySchemeData Payment Scheme Component (see section 7.10) that contains payment scheme specific inquiry messages for inquiries on payments. This is present when the Type attribute of StatusType attribute of the Status Component is set to Payment.
PaySchemeData支付方案组件（参见第7.10节），其中包含特定于支付方案的查询消息，用于查询支付。当状态组件的StatusType属性的Type属性设置为Payment时，会出现这种情况。
The Ping Request Block is used to determine if a Server is operating and whether or not cryptography is compatible.
Ping请求块用于确定服务器是否正在运行以及加密是否兼容。
The definition of a Ping Request Block is as follows.
Ping请求块的定义如下。
<!ELEMENT PingReqBlk (Org*)>
<!ATTLIST PingReqBlk
ID ID #REQUIRED>
<!ELEMENT PingReqBlk (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.
在这种情况下，发送方包括：o标识自身的组织组件，指定其在IOTP交易中的交易角色（商户、支付处理人等）；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>
<!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 Ok。服务的一切都正常工作，包括签名验证。哦，很忙。一切正常，但可能会有一些延误。哦，下来。服务器未完全运行，但仍可提供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 Ok。签名已成功验证并证明兼容。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
PingStatusDesc包含发送此Ping响应块的服务器状态的简短描述。如果设计人员愿意，服务器可以使用此功能
attribute to send more refined status information than PingStatusCode which can be used for debugging purposes, for example.
属性发送比PingStatusCode更精确的状态信息，例如，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状态代码值不包括Fail之类的值，因为当接收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事务相关联的数据进行签名。有关IOTP如何使用签名的一般性讨论和介绍，请参阅第6节数字签名。签名组件和证书的定义包含在“互联网开放交易协议的数字签名”一文中，见[IOTPDSIG]。第7.19节和第7.20节介绍了IOTP如何使用这些工具。
The definition of a Signature Block is as follows:
签名块的定义如下：
<!ELEMENT IotpSignatures (Signature+, Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED >
<!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 如果付款依赖于较早的步骤（如付款组件上的StartAfter属性所示），则由先前步骤生成的付款收据签名组件（见第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.
错误交易块包含一个或多个错误组件（见第7.21节），其中包含交易中涉及的一个交易角色收到的IOTP消息中的技术错误信息（见第4.1节）。
For clarity two phrases are defined which are used in the description of an Error Trading Block:
为清楚起见，定义了两个短语，用于描述错误交易区块：
o message in error. An IOTP message which contains or causes an error of some kind
o 错误消息。包含或导致某种错误的IOTP消息
o message reporting the error. An IOTP message that contains an Error Trading Block that describes the error found in a message in error.
o 报告错误的消息。包含错误交易块的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 >
<!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
PaySchemeData一个可选的支付方案组件（参见第7.10节），其中包含支付方案消息。请参阅本附录的相应付款方案
determine whether or not this component needs to be present and for the definition of what it must contain.
确定此组件是否需要存在，以及它必须包含的内容的定义。
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 >
<!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
基准互联网公开交易协议支持三种不同目的的交易。这些是
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 涉及一次或多次付款的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
- 发出砰的声响
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交易可以自行操作，但身份验证可以选择在任何“支付”交易之前进行。因此，本节的其余部分分为两部分，包括：
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交易由六个文件交换组成，然后依次组合以实现特定交易。
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消息数量。
The six Document Exchanges are:
六次文件交换是：
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
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 由认证者发送给被认证者的认证请求，
o an Authentication Response being sent in return by the Authenticatee to the Authenticator which is then checked, and
o 被认证者将认证响应发送给认证者，然后进行检查，以及
o an Authentication Status being sent by the Authenticator to the Authenticatee to provide an indication of the success or failure of the authentication.
o 由认证者发送给被认证者的认证状态，以提供认证成功或失败的指示。
An Authentication Document Exchange also:
身份验证文档交换还包括：
o provides an Authenticatee with an Organisation Component which describes the Authenticator, and
o 向认证者提供描述认证者的组织组件，以及
o optionally provides the Authenticator with Organisation Components which describe the Authenticatee.
o 可选地向验证者提供描述验证者的组织组件。
The Authentication Request may also be digitally signed which allows the Authenticatee to verify the credentials of the Authenticator.
认证请求也可以是数字签名的，这允许认证者验证认证者的凭证。
The IOTP Messages which are involved are illustrated by the diagram below.
所涉及的IOTP消息如下图所示。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Organisation 1
(Authenticatee)
| Organisation 2
| (Authenticator)
STEP | |
1. First Organisation takes an action (for example by
pressing a button on an HTML page) which requires that
the Organisation is authenticated
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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. 第二个组织生成：包含一个或多个身份验证请求组件和/或交易角色信息请求组件的身份验证请求块，然后将其发送给第一个组织
1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block;
Signature Block (optional); TPO Block; Auth Request Block
1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block;
Signature Block (optional); TPO Block; Auth Request Block
3. IOTP aware application started. If a Signature Block is present, the first Organisation may use this to check the credentials of the second Organisation. If credentials are OK, the first Organisation selects an Authentication Request to use (if present and more than one), then uses the authentication algorithm selected to generate an Authentication Response Block. If present, the Trading Role Information Request Component is used to generate Organisation Components. Finally a Signature Component is created if required and all components are then sent back to the second Organisation for validation.
3. IOTP感知应用程序已启动。如果存在签名块，第一个组织可以使用该签名块检查第二个组织的凭据。如果凭证正常，则第一个组织选择要使用的身份验证请求（如果存在且不止一个），然后使用所选的身份验证算法生成身份验证响应块。如果存在，交易角色信息请求组件用于生成组织组件。最后，如果需要，将创建一个签名组件，然后将所有组件发送回第二个组织进行验证。
1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block;
Signature Block (optional) ; Auth Response Block
1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block;
Signature Block (optional) ; Auth Response Block
4. The second Organisation checks the Authentication Response against the data in the Authentication Request Block to check that the first Organisation is who they appear to be, and sends an Authentication Status Block to the first Organisation to indicate the result then stops.
4. 第二个组织根据身份验证请求块中的数据检查身份验证响应，以检查第一个组织是他们看起来是谁，并向第一个组织发送身份验证状态块以指示结果，然后停止。
1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block;
Signature Block (optional); Auth Response Block
1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block;
Signature Block (optional); Auth Response Block
5. The first Organisation checks the authentication Status Block and optionally keeps information on the IOTP transaction for record keeping purposes and stops.
5. 第一个组织检查身份验证状态块，并选择性地保留IOTP交易的信息，以备记录和停止。
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 18 Authentication Document Exchange
图18身份验证文档交换
On receiving a TPO & Authentication Request IOTP Message (see below), an Authenticatee may either:
收到TPO和认证请求IOTP消息（见下文）时，认证对象可以：
o generate and send an Authentication Response IOTP Message back to the Authenticator, or
o 生成认证响应IOTP消息并将其发送回认证者，或
o indicate failure to comply with the Authentication Request by sending a Cancel Block back to the Authenticator containing a Status Component with a StatusType of Authentication a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: AutEeCancel, NoAuthReq, TradRolesIncon or Unspecified.
o 通过将取消块发送回包含身份验证状态类型为Failed且CompletionCode（参见第7.16.4节）设置为AutEeCancel、NoAuthReq、TradRolesIncon或UNQUOTED的状态组件的身份验证程序，指示未能遵守身份验证请求。
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消息（见下文）时，身份验证人应返回发送身份验证状态IOTP消息（见下文），该消息包含一个状态块，该状态块带有一个状态组件，其中StatusType设置为Authentication，并且：
o the ProcessState attribute of the Status Component is set to CompletedOk which indicates a successful completion, or
o 状态组件的ProcessState属性设置为CompletedOk，表示成功完成，或
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属性设置为Failed，CompletionCode属性设置为AutoCancel、AuthFailed或Unspecified，表示身份验证失败，
On receiving an Authentication Status IOTP Message (see below), the Authenticatee should check the Status Component in the Status Block. If this indicates:
在收到身份验证状态IOTP消息（见下文）时，被身份验证人应检查状态块中的状态组件。如果这表明：
o a successful authentication, then the Authenticatee should either:
o 如果身份验证成功，则Authenticate应：
- 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.
- 通过向验证器发回一个Cancel块，该块包含一个状态组件，状态组件的身份验证类型为StatusType，ProcessState为Failed，CompletionCode（参见第7.16.4节）设置为AutEeCancel，指示无法继续IOTP事务的其余部分。
o a failed authentication, then the failure should be reported to the Authenticatee and any further processing stopped.
o 如果身份验证失败，则应将失败报告给AuthenticateTee，并停止任何进一步的处理。
If the Authenticator receives an IOTP Message containing a Cancel block from a Consumer, then the Authenticatee may go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Authenticator contained in the Trading Protocol Options Block.
如果验证者从消费者接收到包含取消块的IOTP消息，则被验证者可以转到在组织组件中的交易角色元素上为交易协议选项块中包含的验证者指定的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 一个协议选项组件（见第7.1节），定义适用于整个身份验证文档交换的选项。
o one Organisation Component (see section 7.6) which describes the Authenticator. The Trading Role on the Organisation Component should indicate the role which the Authenticator is taking in the Trade, for example a Merchant or a Consumer.
o 一个描述认证者的组织组成部分（见第7.6节）。组织组成部分上的交易角色应表明认证人在交易中扮演的角色，例如商人或消费者。
AUTHENTICATION REQUEST BLOCK
身份验证请求块
The Authentication Request Block (see section 8.4) must contain the following Trading Components:
认证请求块（见第8.4节）必须包含以下交易组件：
o one Authentication Request Component (see section 7.2), and
o 一个身份验证请求组件（见第7.2节），以及
SIGNATURE BLOCK (AUTHENTICATION REQUEST)
签名块（身份验证请求）
If the Authentication Request is being digitally signed then a Signature Block must be included. It contains Digests of the following XML elements:
如果身份验证请求正在进行数字签名，则必须包括签名块。它包含以下XML元素的摘要：
o the Transaction Reference Block (see section 3.3) for the IOTP Message that contains information that describes the IOTP Message and IOTP Transaction
o IOTP消息的事务参考块（见第3.3节），其中包含描述IOTP消息和IOTP事务的信息
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 一个认证响应组件（见第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 身份验证请求块中包含的交易角色信息请求组件的TradingRoleList属性中标识的每个交易角色对应一个组织组件。
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消息的事务参考块（见第3.3节），其中包含描述IOTP消息和IOTP事务的信息
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 一个状态组件（参见第7.16节），其ProcessState属性设置为CompletedOk。
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消息的事务参考块（见第3.3节），其中包含描述IOTP消息和IOTP事务的信息
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:
要约文件交换有两种基本形式：
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,
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Merchant
STEP | |
1. Consumer decides to trade and sends to the Merchant
information (e.g., using HTML) that enables the Merchant
to create an offer,
C --> M Offer information - outside scope of IOTP
C --> M Offer information - outside scope of IOTP
2. Merchant decides which payment brand protocols, currencies and amounts apply, places then in a Brand List Component inside a TPO Block and sends to Consumer
2. 商户决定采用哪种支付品牌协议、货币和金额，然后将其放入TPO区块内的品牌列表组件中，并发送给消费者
C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block
C <-- M TPO. IotpMsg: Trans Ref Block; TPO Block
3. IOTP aware application started. Consumer selects the payment brand, payment protocol and currency/amount to use. Records selection in a Brand Selection Component and sends back to Merchant.
3. IOTP感知应用程序已启动。消费者选择要使用的支付品牌、支付协议和货币/金额。在品牌选择组件中记录选择并发送回商户。
C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection
Block
C --> M TPO SELECTION. IotpMsg: Trans Ref Block; TPO Selection
Block
4. Merchant uses selected payment brand, payment protocol, currency/amount and the offer information to create an Offer Response Block containing details about the IOTP Transaction including price, etc. Optionally signs it and sends to the Consumer
4. 商户使用选定的支付品牌、支付协议、货币/金额和优惠信息创建一个优惠响应块，其中包含IOTP交易的详细信息，包括价格等。可选择对其进行签名并发送给消费者
C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block
(optional); Offer Response Block
C <-- M OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature Block
(optional); Offer Response Block
5. Consumer checks the Offer is OK, then combines components from the TPO Block, the TPO Selection Block and the Offer Response Block to create the next IOTP Message for the Transaction and sends it together with the Signature block if present to the required Trading Role
5. 消费者检查报价是否正常，然后组合来自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 通过将取消块发送回商户，指示无法继续IOTP交易，该商户包含一个状态组件，其StatusType为Offer，ProcessState为Failed，CompletionCode（参见第7.16.4节）设置为：ConsCancelled或Unspecified。
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 通过向消费者发送一个包含StatusType为Offer、ProcessState为Failed且CompletionCode（参见第7.16.4节）设置为MerchCancelled或Unspecified的状态组件的取消块，指示无法继续IOTP事务。
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 通过将取消块发送回商户，指示无法继续IOTP交易，该商户包含一个状态组件，其StatusType为Offer，ProcessState为Failed，CompletionCode（参见第7.16.4节）设置为：ConsCancelled或Unspecified。
If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant.
如果商户收到包含取消块的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块和报价响应块由商户一起发送给消费者，即，有一条IOTP消息同时包含TPO块和报价响应块。
The message flow is illustrated by the diagram below:
消息流如下图所示：
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Merchant
STEP | |
1. Consumer decides to trade and sends to the Merchant
information (e.g., using HTML) that enables the Merchant
to create an offer,
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Merchant
STEP | |
1. Consumer decides to trade and sends to the Merchant
information (e.g., using HTML) that enables the Merchant
to create an offer,
C --> M Offer information - outside scope of IOTP
C --> M Offer information - outside scope of IOTP
2. Merchant decides which payment brand protocols, currencies and amounts apply, places then in a Brand List Component inside a TPO Block, creates an Offer Response containing details about the IOTP Transaction including price, etc., optionally signs it and sends to Consumer
2. 商户决定采用哪种支付品牌协议、货币和金额，然后将其放入TPO区块内的品牌列表组件中，创建包含IOTP交易详细信息（包括价格等）的报价响应，选择性地签名并发送给消费者
C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature
Block; TPO Block; Offer Response Block
C <-- M TPO & OFFER RESPONSE. IotpMsg: Trans Ref Block; Signature
Block; TPO Block; Offer Response Block
3. IOTP aware application started. Consumer selects the payment brand, payment protocol and currency/amount to use. Records selection in a Brand Selection Component, checks offer is OK, combines the Brand Selection Component with information from the TPO Block and Offer Response Block to create the next IOTP Message for the Transaction and sends it together with the Signature Block if present to the required Trading Role.
3. IOTP感知应用程序已启动。消费者选择要使用的支付品牌、支付协议和货币/金额。在品牌选择组件中记录选择，检查报价是否正常，将品牌选择组件与来自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.
请注意，当商户仅向消费者提供一种支付品牌、协议和货币/金额时，始终会发生与品牌无关的报价文件交换。当提供多个品牌，支付处理程序相同，且所有品牌使用相同的协议集时，也可能发生这种情况，但不一定会发生。
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和Offer Response 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 通过将取消块发送回商户，指示无法继续IOTP交易，该商户包含一个状态组件，该状态组件的StatusType为Offer，ProcessState为Failed，CompletionCode（参见第7.16.1节）设置为：ConsCancelled或Unspecified。
If the Merchant receives an IOTP Message containing a Cancel block, then the Consumer is likely to go to the CancelNetLocn specified on the Trading Role Element in the Organisation Component for the Merchant.
如果商户收到包含取消块的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事务的选项。见第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 IOTP交易中的每笔支付都有一个品牌列表组件（见第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
- 交付给，即接受交付的人员或组织
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 一个品牌选择组件（见第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 一个状态组件（见第7.16节），指示报价响应的状态。ProcessState属性应设置为CompletedOk
o one Order Component (see section 7.5) which contains details about the goods and services which are being purchased or the financial transaction which is taking place
o 一个订单组成部分（见第7.5节），其中包含正在购买的商品和服务或正在进行的金融交易的详细信息
o one or more Payment Component(s) (see section 7.9) for each payment which is to be made
o 每次付款的一个或多个付款部分（见第7.9节）
o zero or one Delivery Components (see section 7.13) containing details of the delivery to be made if the IOTP Transaction includes a delivery
o 零个或一个交付组件（见第7.13节），包含IOTP交易包括交付时的交付细节
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:
如果身份验证状态块正在进行数字签名，则必须包括一个签名块，该签名块包含一个签名组件（见第7.19节），其中包含以下XML元素的摘要元素：
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:
如果对报价响应进行数字签名，则必须包括一个签名块，该签名块包含一个签名组件（见第7.19节），其中包含以下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消息的事务参考块（见第3.3节），其中包含描述IOTP消息和IOTP事务的信息
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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
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
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
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 如果支付协议消息交换完成，则生成并发送支付响应IOTP消息，或
o indicate failure to continue with the Payment by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Payment, a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: BrandNotSupp, CurrNotSupp, PaymtCancelled, AuthError, InsuffFunds, InstBrandInvalid, InstNotValid, BadInstrument or Unspecified.
o 通过向消费者发送一个取消块，该块包含一个状态组件，状态组件的状态类型为Payment，处理状态为Failed，并且完成代码（参见第7.16.4节）设置为：BrandNotSupp、CurrNotSupp、PaymtCancelled、AuthError、InsOffFunds、InstBrandInvalid、InstNotValid，仪器不良或未指明。
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 通过将取消块发送回包含状态组件的付款处理程序，指示继续付款失败，状态组件的状态类型为付款，处理状态为失败，并且完成代码（参见第7.16.2节）设置为：conscenecked或Unspecified。
On receiving a Payment Exchange IOTP Message, the Payment Handler may either:
在收到支付交换IOTP消息时，支付处理程序可以：
o generate and send a Payment Exchange IOTP Message back to the Consumer, if more payment protocol messages need to be exchanged, or
o 如果需要交换更多的支付协议消息，则生成支付交换IOTP消息并将其发送回消费者，或
o generate and send a Payment Response IOTP Message if the exchange of payment protocol messages is complete, or
o 如果支付协议消息交换完成，则生成并发送支付响应IOTP消息，或
o indicate failure to continue with the Payment by sending a Cancel Block back to the Consumer containing a Status Component with a StatusType of Payment, a ProcessState of Failed and the CompletionCode (see section 7.16.2) set to either: PaymtCancelled or Unspecified.
o 通过向消费者发送一个取消块，该块包含一个状态组件，状态组件的状态类型为“付款”，处理状态为“失败”，并且完成代码（参见第7.16.2节）设置为“PaymtCancelled”或“Unspecified”，以指示未能继续付款。
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 通过将取消块发送回商户，指示无法继续IOTP交易，该商户包含状态组件，状态组件的状态类型为付款，处理状态为Failed，且完成代码（见第7.16.1节）设置为：conscelected或Unspecified。
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
- 具有商户角色的组织组件，以及正在发送付款请求块的PaymentHandler
- the Brand List Component for the payment, i.e. the Brand List referred to by the BrandListRef attribute on the Payment Component
- 支付的品牌列表组件，即支付组件上BrandListRef属性引用的品牌列表
o one Brand Selection Component for the Brand List, i.e. the Brand Selection Component where BrandListRef attribute points to the Brand List. This component can be either:
o 品牌列表的一个品牌选择组件，即BrandListRef属性指向品牌列表的品牌选择组件。此组件可以是：
- copied from the TPO Selection Block if the payment was preceded by a Brand Dependent Offer Document Exchange (see section 9.1.2.1), or
- 如果付款之前有品牌相关报价文件交换（见第9.1.2.1节），则从TPO选择块复制；或
- created by the Consumer, containing the payment brand, payment protocol and currency/amount selected from the Brand List, if the payment was preceded by a Brand Independent Offer Document Exchange (see section 9.1.2.2)
- 由消费者创建，包含支付品牌、支付协议和从品牌列表中选择的货币/金额，前提是支付之前有品牌独立的报价文件交换（见第9.1.2.2节）
o an optional Payment Scheme Component (see section 7.10) if required by the payment method used (see the Payment Method supplement to determine if this is needed).
o 如果所使用的支付方法需要，可选的支付方案组件（参见第7.10节）（参见支付方法补充以确定是否需要）。
o zero or more Trading Role Data Components (see section 7.17).
o 零个或多个交易角色数据组件（见第7.17节）。
Note that:
请注意：
o if there is more than one Payment Components in an Offer Response Block, then the second payment is the one within the Offer Response Block that contains a StartAfter attribute (see section 7.9) that identifies the Payment Component for the first payment
o 如果要约响应块中有多个支付组件，则第二次支付是要约响应块中包含StartAfter属性（参见第7.9节）的支付组件，该属性标识第一次支付的支付组件
o the Payment Handler to include is identified by the Brand Selection Component (see section 7.8) for the payment. Also see section 6.3.1 Check Request Block sent Correct Organisation for an explanation on how Payment Handlers are identified
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 要从报价响应块中包括的品牌选择组件是包含BrandListRef属性（参见第3.5节）的组件，该属性标识第二次付款的品牌列表组件。
SIGNATURE BLOCK (PAYMENT REQUEST)
签名栏（付款请求）
If the either the preceding Offer Document Exchange included an Offer Response Signature (see section 9.1.2.5 Offer Response IOTP Message), or a preceding Payment Exchange included a Payment Response Signature
如果先前的要约文件交换包含要约响应签名（见第9.1.2.5节要约响应IOTP消息），或先前的支付交换包含支付响应签名
(see section 9.1.3.4 Payment Response IOTP Message) then they should both be copied to the Signature Block in the Payment Request IOTP Message.
（参见第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 一个支付方案组件（见第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 一个付款收据组件（见第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 一个包含付款方式特定数据的付款方案组件（见第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:
如果提供了已签名的付款收据（由付款组件的SignedPayReceipt属性设置为True表示），则签名块应包含一个签名组件，该签名组件包含以下内容的摘要元素：
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 事务参考块内全局唯一标识IOTP事务的事务Id组件（见第3.3.1节），
o the Payment Receipt Component from the Payment Response Block,
o 付款响应块中的付款收据组件，
o the Payment Note Component from the Payment Response Block,
o 付款响应块中的付款通知单组件，
o the other Components referenced by the PayReceiptNameRefs attribute (if present) of the Payment Receipt Component,
o 付款收据组件的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 传递处理程序向消费者发送传递响应IOTP消息，其中包含处理程序对请求的响应的详细信息以及可选签名。
The message flow is illustrated by the diagram below.
消息流如下图所示。
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
Consumer
| Delivery
| Handler
STEP | |
1. Consumer generates Delivery Request Block and sends it to
the Delivery Handler with the Signature Block if present
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
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
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 通过将取消块发送回包含状态组件（状态类型为Delivery、ProcessState为Failed且CompletionCode（参见第7.16.4节）设置为DeliverCancelled或Unspecified）的消费者，指示未能继续交付。
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
- 组织组成部分（见第7.6节），其角色为：商户、送货员和送货员
- the Delivery Component (see section 7.13)
- the Delivery Component (see section 7.13)translate error, please retry
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 一个交货通知单组件（见第7.15节），其中包含有关货物或服务交付的交付说明
in3 SIGNATURE BLOCK (DELIVERY RESPONSE)
in3签名块（交付响应）
The Signature Block should contain one Signature Component that contains Digest elements that refer to
签名块应该包含一个签名组件，其中包含引用
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 支付处理程序在一条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
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
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
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. 消费者和支付处理程序继续交换支付交换块，直到最终支付协议消息完成，因此支付处理程序在支付响应块内创建支付收据组件，在签名块内创建可选签名组件，然后使用来自Offer-Response-Bock的信息创建交付响应块，并将其发送给消费者和站点。
C <-- P PAYMENT RESPONSE & DELIVERY RESPONSE. IotpMsg: Trans Ref
Block; Signature Block; Pay Response Block; Delivery
Response Block
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.
报价响应块（见第8.3节）中包含的交货组件（见第7.13节）的DeliverandPayrep属性如果交付响应块和支付响应块组合到同一IOTP消息中，则设置为True；如果交付响应块和支付响应块在单独的IOTP消息中发送，则设置为False。
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
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
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
o 商户（金融机构）可能能够接受几种不同类型的电子现金的存款，但由于存款电子现金的消费者角色通常知道他们想要存款的类型，因此通常受到限制
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 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
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 商户通过以下两个交易交易所向消费者支付退款：
- 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
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 例如，当通过某些其他方式实现了对消费者的认证时，消费者输入了一些以前提供的代码，以便识别自己以及代码适用的退款。代码可以通过网页或电子邮件等方式提供。
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
START -----------------------------------------------------
| v
| ----------------
| | AUTHENTICATION |
| ----------------
-------------------------------------- |
| | |
| -------------- | -------------
v v v v
------------------- -----------------
| BRAND INDEPENDENT | | BRAND DEPENDENT |
| OFFER | | OFFER |
------------------- -----------------
| |
| |
| |
| -------------------
v v
--------- --------------
| PAYMENT | | PAYMENT WITH |
| (first) | | DELIVERY |
--------- --------------
|
----------------
|
---------- --------- |
| DELIVERY | | PAYMENT | |
| | | {second)| |
---------- --------- |
|
-----------------> STOP
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 28 Baseline Withdrawal IOTP Transaction
图28基线提取IOTP交易
Note that:
请注意：
o a Merchant (Financial Institution) may be able to offer withdrawal of several different types of electronic cash. In practice usually only one form of electronic cash may be offered. However, there may be several different protocols which may be used for the same "brand" of electronic cash.
o 商户（金融机构）可以提供几种不同类型的电子现金取款。实际上，通常只能提供一种形式的电子现金。然而，可能有几种不同的协议可用于同一“品牌”的电子现金。
o the Merchant (Financial Institution) may use the results of the authentication to identify not only the consumer but also the account from which the withdrawal is to be made. If no single account can be identified, then it must be obtained by other means. For example:
o 商户（金融机构）可以使用认证结果不仅识别消费者，还可以识别要进行取款的账户。如果无法确定单一账户，则必须通过其他方式获得。例如：
- the consumer could specify the account number prior to the Baseline Withdrawal IOTP Transaction starting, or
- 消费者可以在基准取款IOTP交易开始之前指定账号，或
- the consumer could have been identified earlier, for example using a Baseline Authentication IOTP Transaction, and an account selected from a list provided by the Financial Institution.
- 例如，可以使用基准认证IOTP交易和从金融机构提供的列表中选择的账户更早地识别消费者。
o a Baseline Withdrawal without an authentication might be used:
o 可以使用未经身份验证的基线撤回：
- if a previous IOTP transaction, for example a Baseline Deposit or a Baseline Authentication, authenticated the consumer, and a secure channel has been maintained, therefore the authenticity of the consumer is known
- 如果先前的IOTP交易（例如基线存款或基线身份验证）对消费者进行了身份验证，并且维护了安全通道，则消费者的真实性是已知的
- if authentication is achieved as part of a proprietary payment protocol and is therefore included in the Payment Document Exchange
- 如果认证是作为专有支付协议的一部分实现的，因此包含在支付凭证交换中
- if authentication of the consumer has been achieved by some other means, for example, by using a pass phrase, or a proprietary banking software solution.
- 如果消费者的身份验证是通过其他方式实现的，例如，通过使用密码或专有银行软件解决方案。
The Baseline Value Exchange Transaction uses Payment Document Exchanges to support the exchange of value in one currency obtained using one payment method with value in the same or another currency using the same or another payment method. Examples of its use include:
基准价值交换交易使用支付凭证交换，以支持使用一种支付方法获得的一种货币的价值与使用相同或另一种支付方法获得的相同或另一种货币的价值的交换。其使用示例包括：
o electronic cash advance on a credit card. For example the first payment could be a "dollar SET Payment" using a credit card with the second payment being a download of Visa Cash e-cash in dollars.
o 信用卡上的电子现金预付款。例如，第一次付款可以是使用信用卡的“美元固定付款”，第二次付款是下载Visa现金电子现金（美元）。
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 外汇使用相同的支付方式。例如，付款可以是上传以英镑表示的Mondex值，第二次是下载以欧元表示的Mondex值
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 外汇使用不同的支付方式。例如，第一次付款可以是以加元进行的固定付款，然后以德国马克下载GeldKarte。
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 两个支付文件交换（见第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
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事务以两种基本形式发生：
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
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
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
| ---------------------- 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:
i) 如果Delivery组件的DeliverandPayResp属性设置为True，则：
(1) the IOTP Transaction consists of a Payment And Delivery Document Exchange (see section 9.1.5) (Note 4)
(1) IOTP交易包括支付和交付文件交换（见第9.1.5节）（注4）
ii) otherwise (the DelivAndPayResp attribute of the Delivery Component is set to False)
ii）否则（交付组件的deliverandpayresp属性设置为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节）和交付凭证交换（见第9.1.4节）（注4）
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) the IOTP Transaction contains just one Payment Document Exchange (Note 5)
(1) IOTP交易仅包含一次付款凭证交换（注5）
ii) if the Offer Response Block contains two Payment Components, then:
ii）如果报价响应块包含两个付款组件，则：
(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交易包含两个付款凭证交换。付款组件的StartAfter属性用于指示哪个付款最先发生（注6）
iii) if the Offer Response Block contains no or more than two Payment Components, then there is an error
iii）如果报价响应块不包含或包含两个以上的支付组件，则存在错误
4) Otherwise (no Offer Response Block) there is an error.
4) 否则（无报价响应块）将出现错误。
The following table indicates the types of IOTP Transactions which can validly have the conditions indicated above.
下表列出了可有效满足上述条件的IOTP交易类型。
Note IOTP Transaction Validity
注意IOTP交易有效性
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
5. 基线购买、退款、存款或取款
6. Baseline Value Exchange only
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节）将其链接至原始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:
基础架构事务旨在支持有关事务是否成功或交易角色的服务器是否正常运行的查询。有两种类型的交易：
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 Ping事务，使一个IOTP感知应用程序能够确定另一个交易角色的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 要帮助恢复挂起的事务，以确定其他角色之一的当前处理状态，
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.
一个交易角色可以在任何时间点对任何其他交易角色进行查询。
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
对于正在进行的事务的事务状态查询，使用与正在进行的事务不同的传输会话。对于过去交易的交易状态查询，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的每个运输补充映射中定义。
TRANSACTION STATUS INQUIRY ERROR HANDLING
事务状态查询错误处理
Errors in a Transaction Status Inquiry can be categorised into one of the following three cases:
交易状态查询中的错误可分为以下三种情况之一：
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 原始IOTP（查询）消息中的技术错误（见第4.1节）-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.
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
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)
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
进行查询的交易角色必须使用交易Id组件（见第3.3.1节），其中IotpTransId和TransTimeStamp属性与正在查询的原始交易的交易Id组件中的属性相同。此组件中的iotpransid属性用作查询
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).
在交易角色的站点维护的交易日志。消息ID组件的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 一个查询类型组件（见第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 零或一个付款方案组成部分（见第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 一个签名组件（见第7.19节）
o one or more Certificate Components, if required.
o 一个或多个证书组件（如果需要）。
Inquiry Response Blocks should only be generated if the Transaction is authorised.
仅当交易获得授权时，才应生成查询响应块。
Note: Digital signatures on an Inquiry Request is only likely to occur if the recipient of the request expects the Inquiry Request to be signed. In this version of IOTP this will require some kind of pre-existing agreement. This means that:
注意：只有当请求的接收者希望对查询请求进行签名时，才可能对查询请求进行数字签名。在此版本的IOTP中，这需要某种预先存在的协议。这意味着：
o Consumers are unlikely to generate requests with signatures, although it is not an error if they do
o 消费者不太可能生成带有签名的请求，尽管这样做并不是错误
o the other trading roles may agree that digital signatures are required. For example a Payment Handler may require that an Inquiry Request is digitally signed by the Merchant so that they can check that the request is valid.
o 其他交易角色可能同意需要数字签名。例如，支付处理程序可能要求商户对查询请求进行数字签名，以便他们能够检查请求是否有效。
On the other hand if the original transaction to which the Inquiry relates was carried out over a secure channel (e.g., [SSL]) then it is probably reasonable to presume that if the sender of the Inquiry knows the Transaction Id component of the original message (including for example the timestamp) then the inquiry is likely to be genuine.
另一方面，如果查询所涉及的原始事务是通过安全通道（例如，[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 一个状态组件（见第7.16节）。此组件保存查询交易的状态信息，
o zero or one Payment Scheme Components. These contain encapsulated payment scheme specific inquiry messages for inquiries on payment.
o 零或一个支付方案组件。其中包含用于支付查询的特定于支付方案的封装查询消息。
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 一个签名组件（见第7.19节）
o one or more Certificate Components, if required.
o 一个或多个证书组件（如果需要）。
Note: Digital signatures on an Inquiry Response is only likely to occur if the recipient of the response expects the Inquiry Request to be signed. In this version of IOTP this will require some kind of pre-existing agreement. This means that:
注意：只有当响应的接收者希望对查询请求进行签名时，才可能对查询响应进行数字签名。在此版本的IOTP中，这需要某种预先存在的协议。这意味着：
o Consumers are unlikely to generate responses with signatures, although it is not an error if they do
o 消费者不太可能生成带有签名的响应，尽管这样做并不是错误
o the other trading roles may agree that digital signatures are required. For example a Merchant may require that an Inquiry Response is digitally signed by the Payment Handler so that they can check that the request response is valid.
o 其他交易角色可能同意需要数字签名。例如，商户可能要求支付处理程序对查询响应进行数字签名，以便他们可以检查请求响应是否有效。
The purpose of the Baseline IOTP Ping Transaction is to test basic connectivity between the Trading Roles that may take part in an IOTP Transaction.
基线IOTP Ping事务的目的是测试可能参与IOTP事务的交易角色之间的基本连接。
It enables IOTP aware application software to:
它使IOTP感知应用软件能够：
o determine if the IOTP aware application at another Trading Role is operating, and
o 确定另一交易角色的IOTP感知应用程序是否正在运行，以及
o verify whether or not the two trading roles signatures can be processed.
o 验证是否可以处理两个交易角色签名。
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.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
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请求块的第二个交易角色生成Ping响应块，并在需要时将其发送回原始Ping请求的发送方，同时发送一个签名块。
1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block
(Optional); Ping Response Block
1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block
(Optional); Ping Response Block
3. The first Trading Role checks the Ping Response Block and takes appropriate action, if necessary
3. 第一个交易角色检查Ping响应块，并在必要时采取适当的操作
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Figure 33 Baseline Ping Messages
图33基线Ping消息
The verification that signatures can be handled is indicated by the sender of the Ping Request Block including:
Ping请求块的发送方指示可以处理签名的验证，包括：
o Organisation Components that identify itself and the intended recipient of the Ping Request Block, and
o 识别自身和Ping请求块的预期接收者的组织组件，以及
o a Signature Block that signs data in the Ping Request.
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 不影响任何正在进行的交易
o does NOT initiate an IOTP transaction, unlike other IOTP transaction messages such as TPO or Transaction Status Inquiry.
o 与其他IOTP事务消息（如TPO或事务状态查询）不同，不会启动IOTP事务。
All IOTP aware applications must return a Ping Response message to the sender of a Ping Request message when it is received.
当收到Ping请求消息时，所有支持IOTP的应用程序必须将Ping响应消息返回给Ping请求消息的发送者。
A Baseline IOTP Ping request can also contain an optional Signature Block. IOTP aware applications can, for example, use the Signature Block to check the recipient of a Ping Request can successfully process and check signatures it has received.
基线IOTP Ping请求还可以包含可选的签名块。IOTP感知应用程序可以，例如，使用签名块来检查Ping请求的接收者是否能够成功地处理和检查其接收到的签名。
For each Baseline Ping IOTP Transaction, each IOTP role shall establish a different transport session from other IOTP transactions.
对于每个基线Ping IOTP事务，每个IOTP角色应建立不同于其他IOTP事务的传输会话。
Any IOTP Trading Role can send a Ping request to any other IOTP Trading Role at any time it wants. A Ping message has its own IotpTransId, which is different from other IOTP transactions.
任何IOTP交易角色都可以随时向任何其他IOTP交易角色发送Ping请求。Ping消息有自己的IotpTransId，这与其他IOTP事务不同。
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请求消息的发送方已生成签名块。签名块必须由接收Ping请求块的交易角色进行验证。
SIGNATURE BLOCK (PING REQUEST)
签名块（PING请求）
The Ping Request Signature Block (see section 8.16) contains the following components:
Ping请求签名块（见第8.16节）包含以下组件：
o one Signature Component (see section 7.19)
o 一个签名组件（见第7.19节）
o one or more Certificate Components, if required.
o 一个或多个证书组件（如果需要）。
PING RESPONSE BLOCK
PING响应块
The Ping Response Block (see section 8.15) contains the following component:
Ping响应块（见第8.15节）包含以下组件：
o the Organisation Component of the sender of the Ping Response message
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 一个签名组件（见第7.19节）
o one or more Certificate Components, if required.
o 一个或多个证书组件（如果需要）。
This section describes how to retrieve logos for display by IOTP aware software using the Logo Net Locations attribute contained in the Brand Element (see section 7.7.1) and the Organisation Component (see section 7.6).
本节描述了如何使用品牌元素（见第7.7.1节）和组织组件（见第7.6节）中包含的Logo Net Locations属性检索标识，以供IOTP感知软件显示。
The full address of a logo is defined as follows: Logo_address ::=
Logo_net_location "/" Logo_size Logo_color_depth ".gif"
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_位置从品牌元素（见第7.7.1节）或组织组件中的LogoNetLocn属性获取。请注意：
- the content of this attribute is dependent on the Transport Mechanism (such as HTTP) that is used. See the Transport Mechanism supplement,
- 此属性的内容取决于所使用的传输机制（如HTTP）。见《运输机制补编》，
- implementers should check that if the rightmost character of Logo Net Location is set to right-slash "/" then another, right slash should not be included when generating the Logo Address,
- 实施者应检查，如果Logo Net Location最右边的字符设置为右斜杠“/”，则在生成Logo地址时不应包括另一个右斜杠，
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标识Logo的颜色深度
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_大小和Logo_颜色_深度由IOTP软件的实施者指定，IOTP软件根据其想要使用的大小和颜色检索Logo。
There are five standard sizes for logos. The sizes in pixels and the corresponding values for Logo Size are given in the table below.
徽标有五种标准尺寸。下表给出了以像素为单位的大小以及徽标大小的相应值。
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特大型
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.
有三种标准颜色深度。下表给出了颜色深度（包括每像素位）和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" would retrieve a medium size
256 colour logo
o "http://logos.xzpay.com/small4.gif" would retrieve a small size 16
colour logo
o "http://logos.xzpay.com/small4.gif" would retrieve a small size 16
colour logo
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的一个关键功能是商家能够提供一份品牌列表，消费者可以从中进行选择。本节概述了所涉及的内容，并就消费者如何选择品牌和相关支付工具提供了指导。它包括：
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 支付工具和品牌的定义-在物联网环境下，什么是支付工具和品牌。进一步将品牌分类为可选的“双品牌”或“促销品牌”，
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元素的定义，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 信用卡，如万事达卡或Visa卡；
o a debit card such as MasterCard's Maestro;
o 借记卡，如万事达卡的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卡、Geldkart卡或Visa现金卡
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 支付协会和专有品牌，如万事达卡、Visa卡、美国运通卡、Diners Club、Mondex、Geldkart、CyberCash等。
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)
- 商店品牌，由特定商户向消费者发放支付工具，例如沃尔玛、西尔斯或玛莎百货（英国）
- 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:
双品牌意味着可以像使用两个独立品牌一样使用单个支付工具。例如，可能有一张日本“UC”万事达卡，可以用作UC卡或普通万事达卡。UC卡品牌和万事达卡品牌可以各自拥有各自独立的支付处理程序。这意味着：
o the merchant treats, for example "UC" and "MasterCard" as two separate Brands when offering a list of Brands to the Consumer,
o 商户在向消费者提供品牌列表时，将“UC”和“万事达卡”视为两个单独的品牌，
o the consumer chooses a Brand, for example either "UC" or "MasterCard,
o 消费者选择一个品牌，例如“UC”或“万事达卡，
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 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.translate error, please retry
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:
促销品牌意味着，如果消费者使用该品牌付款，那么消费者将通过两种方式获得额外的利益：
o at the time of purchase. For example if a Consumer pays with a "Walmart MasterCard" at a Walmart web site, then a 5% discount might apply, which means the consumer actually pays less,
o 在购买时。例如，如果消费者在沃尔玛网站上使用“沃尔玛万事达卡”付款，那么可能会有5%的折扣，这意味着消费者实际支付的费用更少，
o from their Payment Instrument (card) issuer when the payment appears on their statement. For example loyalty points in a frequent flyer scheme could be awarded based on the total payments made with the Payment Instrument since the last statement was issued.
o 当付款出现在他们的对账单上时，从他们的支付工具（卡）发行人处。例如，常客计划中的忠诚度积分可根据自上次报表发布以来使用支付工具支付的总金额授予。
Note that:
请注意：
o the first example (obtaining the benefit at the time of purchase), requires that:
o 第一个例子（购买时获得利益）要求：
- the Consumer is informed of the benefits which arise if that Brand is selected
- 消费者被告知如果选择该品牌会带来哪些好处
- if the Brand is selected, the Merchant changes the relevant IOTP Components in the Offer Response to reflect the correct amount to be paid
- 如果选择了品牌，商户将更改报价响应中的相关IOTP组件，以反映要支付的正确金额
o the second (obtaining a benefit through the Payment Instrument issuer) does not require that the Offer Response is changed
o 第二种（通过支付工具发行人获得利益）不要求更改要约响应
o each Promotional Brand should be identified as a separate Brand in the list of Brands offered by the Merchant. For example: "Walmart", "Sears", "Marks and Spencer" and "American Advantage Visa", would each be a separate Brand.
o 在商户提供的品牌列表中，每个促销品牌应被确定为一个单独的品牌。例如：“沃尔玛”、“西尔斯”、“玛莎百货”和“美国优势签证”都将是一个单独的品牌。
There are two problems which need to handled in identifying Promotional Brands:
在确定促销品牌时，需要处理两个问题：
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:
两种方法似乎是可行的：
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 使用支付工具或支付方法的某些特征来积极识别所使用的品牌。例如，可以使用该品牌的SET证书（如果有），或者
o use the Payment Instrument (card) number to look up information about the Payment Instrument on a Payment Instrument issuer database to determine if the Payment Instrument is a promotional brand.
o 使用支付工具（卡）号码在支付工具发行人数据库中查找有关支付工具的信息，以确定支付工具是否为促销品牌。
Note that:
请注意：
o the first assumes that SET is available.
o 第一个假设集合可用。
o the second is only possible if the Merchant, or alternatively the Payment Handler, has access to card issuer information.
o 第二种方法只有在商户或支付处理人能够访问发卡机构信息的情况下才可行。
IOTP does not provide the Merchant with Payment Instrument information (e.g., a card or account number). This is only sent as part of the encapsulated payment protocol to a Payment Handler. This means that:
IOTP不向商户提供支付工具信息（如卡或账号）。这仅作为封装支付协议的一部分发送给支付处理程序。这意味着：
o the Merchant would have to assume that the Payment Instrument selected was a valid Promotional Brand, or
o 商户必须假设选择的支付工具是有效的促销品牌，或
o the Payment Handler would have to check that the Payment Instrument was for the valid Promotional Brand and fail the payment if it was not.
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:
消费者可以通过以下两种方式正确选择促销品牌：
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,
- 支付软件提供的用于处理特定支付方式的代码，可应用于Geldkart、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感知应用程序将“记住”促销品牌的代码，以供将来购买时使用。
New Brand Ids are allocated under IANA procedures (see section 12 IANA Considerations). Which also contains an initial list of Brand Identifiers.
根据IANA程序分配新品牌ID（参见第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预加载其软件，并提供更新方法。例如，通过访问软件开发人员的网站。
This example contains three examples of the XML for a Brand List Component. It covers:
此示例包含三个品牌列表组件的XML示例。它包括：
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 本附录中描述的所有示例技术都可以包含在一个品牌列表中。
This is a simple example involving:
这是一个简单的例子，涉及：
o only major credit card payment brands
o 仅主要信用卡支付品牌
o a single price in a single currency
o 单一货币的单一价格
o a single Payment Handler, and
o 一个单一的支付处理程序，以及
o a single payment protocol
o 单一支付协议
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Purchase book including s&h'
PayDirection='Debit' >
<Brand ID ='M1.30'
BrandId='MasterCard'
BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com/mastercardcredit'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M.31'
BrandId='Visa'
BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com/visacredit'
ProtocolAmountRefs='M1.33'>
</Brand>
<Brand ID ='M1.32'
BrandId='AmericanExpress'
BrandName='American Express'
BrandLogoNetLocn='ftp://otplogos.amex.com'
ProtocolAmountRefs ='M1.33' >
</Brand >
<ProtocolAmount ID ='M1.33'
PayProtocolRef='M1.35'
CurrencyAmountRefs='M1.34'>
</ProtocolAmount>
<CurrencyAmount ID ='M1.34'
Amount='10.95'
CurrCode='USD'/>
<PayProtocol ID ='M1.35'
ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
</PayProtocol>
</BrandList>
<BrandList ID='M1.2'
XML: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 两个普通信用卡协会品牌和两个推广信用卡品牌。促销品牌包括一个以忠诚度为基础的（英国航空万事达卡），提供额外的忠诚度积分；一个以商店为基础的（沃尔玛），提供一定数量的折扣
o two payment protocols:
o 两种支付协议：
- SET (Secure Electronic Transactions) see [SET], and
- SET（安全电子交易）见[SET]，以及
- SCCD (Secure Channel Credit Debit) see [SCCD].
- SCCD（安全通道贷记借记）见[SCCD]。
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Purchase ladies coat'
PayDirection='Debit' >
<Brand ID ='M1.3'
BrandId='MasterCard'
BrandName='MasterCard Credit'
BrandLogoNetLocn='ftp://otplogos.mastercard.com'
ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.4'
BrandId='Visa'
BrandName='Visa Credit'
BrandLogoNetLocn='ftp://otplogos.visa.com'
ProtocolAmountRefs='M1.7 M1.8'>
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
</ProtocolBrand>
</Brand>
<Brand ID ='M1.5'
BrandId='BritishAirwaysMC'
BrandName='British Airways MasterCard'
BrandLogoNetLocn='ftp://otplogos.britishairways.co.uk'
BrandNarrative='Double air miles with British Airways MasterCard'
ProtocolAmountRefs ='M1.7 M1.8' >
<ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
</ProtocolBrand>
</Brand >
<Brand ID ='M1.6'
BrandId='Walmart'
BrandName='Walmart Store Card'
<BrandList ID='M1.2'
XML: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'
BrandLogoNetLocn='ftp://otplogos.walmart.com'
BrandNarrative='5% off with your Walmart Card
on purchases over $150'
ProtocolAmountRefs='M1.8'>
</Brand>
<ProtocolAmount ID ='M1.7'
PayProtocolRef='M1.10'
CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<ProtocolAmount ID ='M1.8'
PayProtocolRef='M1.11'
CurrencyAmountRefs='M1.9' >
<PackagedContent Transform="BASE64">
238djqw1298erh18dhoire
</PackagedContent>
</ProtocolAmount>
<CurrencyAmount ID ='M1.9'
Amount='157.53'
CurrCode='USD'/>
<PayProtocol ID ='M1.10'
ProtocolId='SET1.0'
ProtocolName='Secure Electronic Transaction Version 1.0'
PayReqNetLocn='http://www.example.com/etill/set1' >
<PackagedContent Transform="BASE64">
8ueu26e482hd82he82
</PackagedContent>
</PayProtocol>
<PayProtocol ID ='M1.11'
ProtocolId='SCCD1.0'
ProtocolName='Secure Channel Credit/Debit'
PayReqNetLocn='http://www.example.com/etill/sccd1' >
<PackagedContent Transform="BASE64">
82hd82he8226e48ueu
</PackagedContent>
</PayProtocol>
</BrandList>
BrandNarrative='5% 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:
为了使用“英国航空公司”万事达卡使用上述示例使用SET支付，从而获得双倍航空里程，品牌选择应为：
<BrandSelection ID='C1.2'
<BrandSelection ID='C1.2'
BrandListRef='M1.3'
BrandRef='M1.5'
ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>
BrandListRef='M1.3'
BrandRef='M1.5'
ProtocolAmountRef='M1.7'
CurrencyAmountRef='M1.9' >
</BrandSelection>
The following is an fairly complex example which includes:
以下是一个相当复杂的示例，包括：
o payments using either Mondex, GeldKarte, CyberCash or DigiCash
o 使用Mondex、Geldkart、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 如果使用英镑或美元以Mondex支付，则价格折扣，以及
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 支持多个版本的CyberCash CyberCoin支付协议。
<BrandList ID='M1.2'
XML:Lang='us-en'
ShortDesc='Company report on XYZ Co'
PayDirection='Debit' >
<Brand ID ='M1.13'
BrandId='Mondex'
BrandName='Mondex Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.mondex.com'
ProtocolAmountRefs='M1.17 M1.18'>
</Brand>
<Brand ID ='M1.14'
BrandId='GeldKarte'
BrandName='GeldKarte Electronic Cash'
BrandLogoNetLocn='ftp://otplogos.geldkarte.co.de'
ProtocolAmountRefs='M1.19'>
</Brand>
<Brand ID ='M1.15'
BrandId='CyberCoin'
BrandName='CyberCoin Eletronic Cash'
BrandLogoNetLocn='http://otplogos.cybercash.com'
ProtocolAmountRefs ='M1.20' >
</Brand >
<Brand ID ='M1.16'
BrandId='DigiCash'
<BrandList ID='M1.2'
XML: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'
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>
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)
算法/“sha1”-表示将应用[sha1]身份验证名称（当算法是“签名”的子项时）-表示身份验证AuthReq包括生成数字签名。组件）“支付：ppp”，其中“ppp”可设置为“IoTPrand”的任何有效值（见下文）
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:
Brand/BrandId以下为截至1999年6月1日已申请SET证书的组织的初始BrandId列表：
"Amex" - American Express
“美国运通”-美国运通
"Dankort" - Dankort
“丹科特”-丹科特
"JCB" - JCB
“JCB”-JCB
"Maestro" - Maestro
“大师”-大师
"MasterCard" - MasterCard
“万事达卡”-万事达卡
"NICOS" - NICOS
“尼科斯”-尼科斯
"VISA" - Visa
“签证”-签证
In addition the following Brand Id values are defined:
此外，还定义了以下品牌Id值：
"Mondex"
“Mondex”
"GeldKarte"
“盖尔德卡特”
New values of BrandId must be announced to the IETF Trade mailing list and, if there are no objections within three weeks, are allocated on a "first come first served" basis.
BrandId的新价值必须向IETF贸易邮件列表公布，如果三周内没有异议，则按照“先到先得”的原则分配。
CurrencyAmount/ Currency codes are dependent on CurrCodeType (see CurrCode below).
CurrencyAmount/货币代码取决于CurrencCodeType（参见下面的CurrencCode）。
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交易邮件列表公布新值，如果三周内没有异议，则按照“先到先得”的原则分配。
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"
货币金额/“ISO4217-A”货币代码类型“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”交付方法
"Web"
“网络”
"Email"
“电子邮件”
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”（其中mimetype必须与[MIME]定义的内容类型相同）
"XML"
“XML”
If the Content attribute is of the form "MIME"mimetype", then control of new values for "mimetype" is as defined in [MIME].
如果内容属性的形式为“MIME”mimetype，则“mimetype”的新值控制如[MIME]中所定义。
Otherwise, new values of the Content attribute are allocated following review on the IETF Trade mailing list and by the Designated Expert. This may require the publication of additional documentation to describe how the new attribute is used within a Packaged Content element.
否则，内容属性的新值将在IETF交易邮件列表审查后由指定专家分配。这可能需要发布其他文档来描述如何在打包的内容元素中使用新属性。
RelatedTo/ "IotpTransaction" RelationshipType "Reference"
RelatedTo/“物联网交易”关系类型“参考”
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
RelationshipType属性的新值在IETF贸易工作组邮件列表审查后由指定专家分配。这可能需要发布额外的文档来描述
Element Type/ Attribute Values Attribute Name delivery method is used.
使用元素类型/属性值属性名称传递方法。
Status/ Offer StatusType Payment
状态/报价状态类型付款
Delivery
传送
Authentication
认证
Unidentified
不明身份
New values of the Status Type attribute are allocated following: o publication to the IETF Trade Working Group, of an RFC describing the Trading Exchange, Trading Roles and associated components that relate to the Status, and o review of the document on the IETF Trade mailing list and by the Designated Expert.
状态类型属性的新值分配如下：o向IETF贸易工作组发布RFC，描述交易交易所、交易角色和与状态相关的相关组件，o审查IETF贸易邮件列表上的文件和指定专家。
Note: The document describing new values for the Status Type attribute may be combined with documents that describe new Trading Roles and types of signatures (see below).
注意：描述Status Type属性新值的文档可以与描述新交易角色和签名类型的文档结合使用（见下文）。
TradingRole/ "Consumer" TradingRole "Merchant"
TradingRole/“消费者”TradingRole“商人”
"PaymentHandler"
“PaymentHandler”
"DeliveryHandler"
“DeliveryHandler”
"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.
交易角色属性的新值分配如下：o向IETF交易工作组发布RFC，描述交易交易所、交易角色和与交易角色相关的相关组件；o审查IETF交易邮件列表上的文件，并由指定专家进行审查。
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/“BaselineAuthentication”IotpTransType“BaselineDeposit”
"BaselinePurchase"
“基线购买”
"BaselineRefund"
“基线退款”
"BaselineWithdrawal"
“基线撤回”
"BaselineValueExchange"
“BaselineValueExchange”
"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属性的新值分配如下：o发布到IETF贸易邮件列表，发布描述新IOTP交易的RFC，以及o审查IETF贸易工作组邮件列表上的文件和指定专家。
Attribute/ Content (see Signature "OfferResponse" Component) "PaymentResponse"
属性/内容（参见签名“报价响应”组件）“PaymentResponse”
"DeliveryResponse"
“交付响应”
"AuthenticationRequest"
“身份验证请求”
"AuthenticationResponse"
“AuthenticationResponse”
"PingRequest"
“ping请求”
"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.
定义签名类型的新代码值分配如下：o向IETF贸易工作组发布，描述使用签名的交易交易所的RFC，以及o审查IETF贸易邮件列表上的文件和指定专家。
Element Type/ Attribute Values Attribute Name
元素类型/属性值属性名称
Note: The document describing new values for the types of signatures may be combined with documents that describe new Status Types and Trading Roles (see above).
注：描述签名类型新值的文档可以与描述新状态类型和交易角色的文档结合使用（见上文）。
In addition to the formal development and registration of codes as described above, there is still a need for developers to experiment using new IOTP codes. For this reason, "user defined codes" may be used to identify additional values for the codes contained within this specification without the need for them to be registered with IANA.
除了上述代码的正式开发和注册外，开发人员还需要尝试使用新的IOTP代码。因此，“用户定义代码”可用于识别本规范中包含的代码的附加值，而无需向IANA注册。
The definition of a user defined code is as follows:
用户定义代码的定义如下：
user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*
NameChar NameChar has the same definition as the [XML] definition of NameChar
NameChar NameChar的定义与NameChar的[XML]定义相同
Use of domain names (see [DNS]) to make user defined codes unique is recommended although this method cannot be relied upon.
建议使用域名（参见[DNS]）使用户定义的代码唯一，尽管这种方法不可靠。
This section contains the XML DTD for the Internet Open Trading Protocols.
本节包含互联网开放交易协议的XML DTD。
<!--
******************************************************
* *
* INTERNET OPEN TRADING PROTOCOL VERSION 1.0 DTD *
* Filename: ietf.org/rfc/rfc2801.dtd *
* *
* Changes from version 07 (iotp-v1.0-protocol-07.dtd)*
* - NO CHANGES *
* *
* *
* *
* *
* Copyright Internet Engineering Task Force 1998-2000*
* *
******************************************************
<!--
******************************************************
* *
* INTERNET OPEN TRADING 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 *
******************************************************
-->
******************************************************
* 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 | AuthRespBlk | AuthStatusBlk | CancelBlk | DeliveryReqBlk | DeliveryReqBlk | InquiryReqBlk | InquiryRespBlk | OfferSpblk | PayXchblk | PayReqBlk | PayRespBlk | PayRespBlk！ATTLIST IotpMessage xmlns CDATA“iotp:ietf.org/iotp-v1.0”>
<!--
******************************************************
* TRANSACTION REFERENCE BLOCK DEFINITION *
******************************************************
-->
<!--
******************************************************
* TRANSACTION REFERENCE BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
<!ATTLIST TransRefBlk
ID ID #REQUIRED >
<!ELEMENT TransId EMPTY >
<!ATTLIST TransId
ID ID #REQUIRED
Version NMTOKEN #FIXED '1.0'
IotpTransId CDATA #REQUIRED
IotpTransType CDATA #REQUIRED
TransTimeStamp CDATA #REQUIRED >
<!ELEMENT TransId EMPTY >
<!ATTLIST TransId
ID ID #REQUIRED
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 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 >
<!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 *
******************************************************
-->
<!--
******************************************************
* Packaged Content Common Element *
******************************************************
-->
<!ELEMENT PackagedContent (#PCDATA) >
<!ATTLIST PackagedContent
Name CDATA #IMPLIED
Content NMTOKEN "PCDATA"
Transform (NONE|BASE64) "NONE" >
<!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 >
<!--
******************************************************
* 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 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 >
<!-- 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 >
<!-- 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
<!-- 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 >
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 >
<!-- 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 TradingRole EMPTY >
<!ATTLIST TradingRole
ID ID#REQUIRED
TradingRole NMTOKEN #REQUIRED
IotpMsgIdPrefix NMTOKEN #REQUIRED
CancelNetLocn CDATA #IMPLIED
ErrorNetLocn CDATA #IMPLIED
ErrorLogNetLocn CDATA #IMPLIED >
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
Tel CDATA #IMPLIED
Fax CDATA #IMPLIED
Email CDATA #IMPLIED
NetLocn CDATA #IMPLIED >
<!ELEMENT ContactInfo EMPTY >
<!ATTLIST ContactInfo
xml:lang NMTOKEN #IMPLIED
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 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' >
<!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 >
<!-- 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 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 ProtocolBrand (PackagedContent*) >
<!ATTLIST ProtocolBrand
ProtocolId CDATA #REQUIRED
ProtocolBrandId CDATA #REQUIRED >
<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount
ID ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT ProtocolAmount (PackagedContent*) >
<!ATTLIST ProtocolAmount
ID ID #REQUIRED
PayProtocolRef IDREF #REQUIRED
CurrencyAmountRefs IDREFS #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount CDATA #REQUIRED
<!ELEMENT CurrencyAmount EMPTY >
<!ATTLIST CurrencyAmount
ID ID #REQUIRED
Amount CDATA #REQUIRED
CurrCodeType NMTOKEN 'ISO4217-A' CurrCode CDATA #REQUIRED >
CurrCodeType NMTOKEN“ISO4217-A”CurrCode CDATA#必需>
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT PayProtocol (PackagedContent*) >
<!ATTLIST PayProtocol
ID ID #REQUIRED
xml:lang NMTOKEN #IMPLIED
ProtocolId NMTOKEN #REQUIRED
ProtocolName CDATA #REQUIRED
ActionOrgRef NMTOKEN #REQUIRED
PayReqNetLocn CDATA #IMPLIED
SecPayReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
<!-- BRAND SELECTION COMPONENT -->
<!ELEMENT BrandSelection (BrandSelBrandInfo?,
BrandSelProtocolAmountInfo?,
BrandSelCurrencyAmountInfo?) >
<!ATTLIST BrandSelection
ID ID #REQUIRED
BrandListRef NMTOKEN #REQUIRED
BrandRef NMTOKEN #REQUIRED
ProtocolAmountRef NMTOKEN #REQUIRED
CurrencyAmountRef NMTOKEN #REQUIRED >
<!-- BRAND 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 BrandSelBrandInfo (PackagedContent+) >
<!ATTLIST BrandSelBrandInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelProtocolAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) >
<!ATTLIST BrandSelCurrencyAmountInfo
ID ID #REQUIRED
ContentSoftwareId CDATA #IMPLIED >
<!-- PAYMENT COMPONENT -->
<!ELEMENT Payment EMPTY >
<!ATTLIST Payment
ID ID #REQUIRED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
BrandListRef NMTOKEN #REQUIRED
<!-- 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 >
签名工资收据（真|假）#所需StartAfterRefs NMTOKENS#暗示>
<!-- PAYMENT SCHEME COMPONENT -->
<!ELEMENT PaySchemeData (PackagedContent+) >
<!ATTLIST PaySchemeData
ID ID #REQUIRED
PaymentRef NMTOKEN #IMPLIED
ConsumerPaymentId CDATA #IMPLIED
PaymentHandlerPayId CDATA #IMPLIED
ContentSoftwareId CDATA #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 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 >
<!-- 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 >
<!-- 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
<!ELEMENT DeliveryData (PackagedContent*) >
<!ATTLIST DeliveryData
xml:lang NMTOKEN #IMPLIED
OkFrom CDATA #REQUIRED
OkTo CDATA #REQUIRED
DelivMethod NMTOKEN #REQUIRED
DelivToRef NMTOKEN #REQUIRED
DelivReqNetLocn CDATA #IMPLIED
SecDelivReqNetLocn CDATA #IMPLIED
ContentSoftwareId CDATA #IMPLIED >
ContentSoftwareId CDATA#隐含>
<!-- CONSUMER DELIVERY DATA COMPONENT -->
<!ELEMENT ConsumerDeliveryData EMPTY >
<!ATTLIST ConsumerDeliveryData
ID ID #REQUIRED
ConsumerDeliveryId CDATA #REQUIRED >
<!-- 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 >
<!-- 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 >
<!-- 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 >
<!-- 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 >
<!-- 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 >
<!-- 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 >
<!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 BLOCKS *
******************************************************
-->
<!-- TRADING PROTOCOL OPTIONS BLOCK -->
<!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
<!ATTLIST TpoBlk
ID ID #REQUIRED >
<!-- 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 >
<!-- 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 >
<!-- 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 REQUEST BLOCK -->
<!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
<!ATTLIST AuthReqBlk
ID ID #REQUIRED >
<!-- AUTHENTICATION RESPONSE BLOCK -->
<!ELEMENT AuthRespBlk (AuthResp?, Org*) >
<!ATTLIST AuthRespBlk
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 >
<!-- 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 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 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 >
<!-- 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 >
<!-- 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 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 >
<!-- 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 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>
<!-- 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 >
<!-- ERROR BLOCK -->
<!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
<!ATTLIST ErrorBlk
ID ID #REQUIRED >
<!-- CANCEL BLOCK -->
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk
ID ID #REQUIRED >
<!-- CANCEL BLOCK -->
<!ELEMENT CancelBlk (Status) >
<!ATTLIST CancelBlk
ID ID #REQUIRED >
<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION *
******************************************************
-->
<!--
******************************************************
* IOTP SIGNATURES BLOCK DEFINITION *
******************************************************
-->
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED
>
<!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
<!ATTLIST IotpSignatures
ID ID #IMPLIED
>
<!--
******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION *
******************************************************
-->
<!--
******************************************************
* IOTP SIGNATURE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED
>
<!ELEMENT Signature (Manifest, Value+) >
<!ATTLIST Signature
ID ID #IMPLIED
>
<!ELEMENT Manifest ( Algorithm+, Digest+, Attribute*, OriginatorInfo, RecipientInfo+ ) >
<!元素清单（算法+、摘要+、属性*、原始信息、接收方信息+）>
<!ATTLIST Manifest LocatorHRefBase CDATA #IMPLIED >
<!ATTLIST清单定位器HREFBASE CDATA#隐含>
<!ELEMENT Algorithm (Parameter*) >
<!ATTLIST Algorithm
ID ID #REQUIRED
type (digest|signature) #IMPLIED
name NMTOKEN #REQUIRED
>
<!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 Digest (Locator, Value) >
<!ATTLIST Digest
DigestAlgorithmRef IDREF #REQUIRED
>
<!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!ELEMENT Attribute ( ANY ) >
<!ATTLIST Attribute
type NMTOKEN #REQUIRED
critical ( true | false ) #REQUIRED
>
<!ELEMENT OriginatorInfo ANY >
<!ELEMENT OriginatorInfo ANY >
<!ATTLIST OriginatorInfo OriginatorRef NMTOKEN #IMPLIED >
<!ATTLIST OriginatorInfo OriginatorRef NMTOKEN#隐含>
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>
<!ELEMENT RecipientInfo ANY >
<!ATTLIST RecipientInfo
SignatureAlgorithmRef IDREF #REQUIRED
SignatureValueRef IDREF #IMPLIED
SignatureCertRef IDREF #IMPLIED
RecipientRefs NMTOKENS #IMPLIED
>
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT KeyIdentifier EMPTY>
<!ATTLIST KeyIdentifier
value CDATA #REQUIRED
>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>
<!ELEMENT Parameter ANY >
<!ATTLIST Parameter
type CDATA #REQUIRED
>
<!--
******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION *
******************************************************
-->
<!--
******************************************************
* IOTP CERTIFICATE COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Certificate ( IssuerAndSerialNumber, ( Value | Locator ) ) >
<!元素证书（颁发者序列号，（值|定位器））>
<!ATTLIST Certificate ID ID #IMPLIED type NMTOKEN #REQUIRED >
<!ATTLIST证书ID#隐含类型NMTOKEN#必需>
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED
>
<!ELEMENT IssuerAndSerialNumber EMPTY >
<!ATTLIST IssuerAndSerialNumber
issuer CDATA #REQUIRED
number CDATA #REQUIRED
>
<!--
******************************************************
* IOTP SHARED COMPONENT DEFINITION *
******************************************************
<!--
******************************************************
* IOTP SHARED COMPONENT DEFINITION *
******************************************************
-->
<!ELEMENT Value ( #PCDATA ) >
<!ATTLIST Value
ID ID #IMPLIED
encoding (base64|none) 'base64'
>
-->
<!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
>
<!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.
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
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组件上的SoftwareId属性识别生成内容的软件时，建议包含此属性（参见第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消息组成，同时执行部分或全部两个交易交换，以尽量减少必须通过互联网发送的实际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
双品牌双品牌意味着可以像使用两个独立品牌一样使用单个支付工具。例如，可能有一张日本“UC”万事达卡，可以用作
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.
UC卡或普通万事达卡。UC卡品牌和万事达卡品牌可以各自拥有各自独立的支付处理程序。这意味着：o商户在向消费者提供品牌列表时，将例如“UC”和“万事达卡”视为两个单独的品牌；o消费者选择一个品牌，例如“UC”或“万事达卡”；o消费者IOTP感知应用程序确定哪种支付工具匹配所选品牌，并选择正确的支付工具（可能需要用户帮助）。
Error Block An Error Block reports that a Technical Error was found in an IOTP Message that was previously received. Typically Technical Errors are caused by errors in the XML which has been received or some technical failure of the processing of the IOTP Message. Frequently the generation or receipt of an Error Block will result in failure of the IOTP Transaction. They are distinct from Business Errors, reported in a Status Component, which can also cause failure of an IOTP Transaction.
错误块错误块报告在先前收到的IOTP消息中发现技术错误。通常，技术错误是由接收到的XML中的错误或IOTP消息处理的某些技术故障引起的。生成或接收错误块通常会导致IOTP事务失败。它们不同于状态组件中报告的业务错误，后者也可能导致IOTP事务失败。
Exchange Block An Exchange Block is sent between the two Trading Roles involved in a Trading Exchange. It contains one or more Trading Components. Exchange Blocks are always sent after a Request Block and before a Response Block in a Trading Exchange. The content of an Exchange Block is dependent on the type of Trading Exchange being carried out.
交易所区块在交易交易所中涉及的两个交易角色之间发送交易所区块。它包含一个或多个交易组件。在交易交易所中，交换块总是在请求块之后和响应块之前发送。交易所区块的内容取决于正在进行的交易类型。
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交易相关的交易块或交易组件进行数字签名o可选错误块，用于报告先前收到的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.
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
组织作为贸易角色参与贸易的公司或个人。这些组织可以担任行业中涉及的一个或多个角色
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
Payment A Payment Instrument is the means by which
Instrument Consumer pays for goods or services offered by a
Merchant. It can be, for example:
o a credit card such as MasterCard or Visa;
o a debit card such as MasterCard's Maestro;
o a smart card based electronic cash Payment
Instrument such as a Mondex Card, a GeldKarte card or a Visa Cash card o a software based electronic payment account such as a CyberCash's CyberCoin or DigiCash account.
工具，如Mondex卡、Geldkart卡或Visa现金卡，或基于软件的电子支付账户，如CyberCash的CyberCoin或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.
促销品牌促销品牌是指，如果消费者使用该品牌付款，那么消费者将获得一些额外的好处，这些好处可以通过两种方式获得：在购买时获得。例如，如果消费者在沃尔玛网站上使用“沃尔玛万事达卡”付款，那么可能会有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.
收据组件收据组件是交易交易所成功完成的记录。收据组件的示例包括：付款收据和交货通知单。它的内容可能取决于用于执行交易交换的技术。例如，安全电子交易（SET）付款收据由记录付款结果的SET付款消息组成。
Request Block A Request Block is Trading Block that contains a request for a Trading Exchange to start. The Trading Components in a Request Block may be signed by a Signature Block so that their authenticity may be checked and to determine that the Trading Exchange being requested is authorised. Authorisation for a Trading Exchange to start can be provided by the signatures contained on Receipt Components contained in
请求块请求块是包含交易交易所启动请求的交易块。请求块中的交易组件可由签名块签名，以便检查其真实性，并确定所请求的交易交易所已获得授权。交易交易所启动的授权可通过以下文件中收据组件上的签名提供：
Response Blocks resulting from previously completed Trading Exchanges. Examples of Request Blocks are Payment Request and Delivery Request
以前完成的交易交易所产生的响应块。请求块的示例包括付款请求和交货请求
Response Block A Response Block is a Trading Block that indicates that a Trading Exchange is complete. It is sent by the Trading Role that received a Request Block to the Trading Role that sent the Request Block. The Response Block contains a Status Component that contains information about the completion of the Trading Exchange, for example it indicates whether or not the Trading Exchange completed successfully. For some Trading Exchanges the Response Block contains a Receipt Component that forms a record of the Trading Exchange. Receipt Components may be digitally signed using a Signature Block to make completion non-refutable. Examples of Response Blocks include Offer Response, Payment Response and Delivery Response.
响应块响应块是指示交易交易所已完成的交易块。它由接收请求块的交易角色发送给发送请求块的交易角色。响应块包含一个状态组件，其中包含有关交易交易所完成的信息，例如，它指示交易交易所是否成功完成。对于某些交易交易所，响应块包含一个收据组件，该组件构成交易交易所的记录。可以使用签名块对收据组件进行数字签名，以使完成不可反驳。响应块的示例包括报价响应、付款响应和交货响应。
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.
签名块签名块是包含一个或多个签名组件形式的数字签名的交易块。签名组件可以对同一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
交易区块交易区块由一个或多个交易组件组成。一个或多个交易区块可包含在IOTP消息中，IOTP消息以[XML]文档的形式在参与交易的不同交易角色之间物理发送。交易区块有三种主要类型：请求区块、交易区块或响应区块
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.
交易交易所交易交易所由两个交易角色之间的一系列文件的交换组成。这些文件可以是交易区块的形式，也可以通过一些其他方式进行传输，例如通过将数据输入网页。每个交易交易所由三个主要部分组成：o一个交易角色（发起人）向另一个交易角色（接收方）发送请求块；o接收方和发起人之间选择性交换一个或多个交易块，直至最终，o收到请求块的交易角色向发起方发送响应块。
A Trading Exchange is designed to implement a
useful service of some kind. Examples of Trading
Exchanges/services are:
o Offer, which results in a Consumer receiving
an offer from a Merchant to carry out a
business transaction of some kind,
o Payment, where a Consumer makes a payment to a
Payment Handler,
o Delivery, where a Consumer requests, and
optionally obtains, delivery of goods or
services from a Delivery Handler, and
o Authentication, where any Trading Role may
request and receive information about another
Trading Role.
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.
交易角色交易角色识别组织参与交易的不同方式。有五个交易角色：消费者、商户、支付处理人、交付处理人和商户客户服务提供商。
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事务，o IOTP事务中唯一的IOTP消息，通过消息标识符
The Transaction Reference Block may also contain references to other transactions which may or may not be IOTP Transactions
事务引用块还可以包含对其他事务的引用，这些事务可以是IOTP事务，也可以不是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，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年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.和N.Uramoto，“DOM的摘要值（DOMHASH）”，RFC 2803，2000年4月。
[DNS] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[DNS]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[DNS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[DSA] The Digital Signature Algorithm (DSA) published by the National Institute of Standards and Technology (NIST) in the Digital Signature Standard (DSS), which is a part of the US government's Capstone project.
[DSA]美国国家标准与技术研究所（NIST）在数字签名标准（DSS）中发布的数字签名算法（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.米勒。椭圆曲线在密码学中的应用。《密码学的进展——加密》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，“超文本标记语言-2.0”，RFC 18661995年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）是一种简单的标记语言，用于创建与平台无关的超文本文档。请访问万维网（W3C）联盟网站：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.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, T. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1.", RFC 2616, June 1999.
[HTTP]Fielding，R.，Gettys，J.，Mogul，J.，Frystyk，T.和T.Berners Lee，“超文本传输协议——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互联网开放交易协议（IOTP）的数字签名”，RFC 2802，2000年4月。
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[MD5]Rivest，R.，“MD5消息摘要算法”，RFC 13211992年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.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年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）第二部分：媒体类型”，RFC 20461996年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（多用途互联网邮件扩展）第三部分：非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.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，RFC 20481996年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.和N.Borenstein，“多用途互联网邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[OPS] Open Profiling Standard. A proposed standard which provides a framework with built-in privacy safeguards for the trusted exchange of profile information between individuals and web sites. Being developed by Netscape and Microsoft amongst others.
[OPS]开放式分析标准。一个提议的标准，为个人和网站之间的档案信息可信交换提供了一个内置隐私保护的框架。由Netscape和微软等公司开发。
[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，“统一资源定位器（URL）”，RFC 17381994年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", 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
[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。Unicode联盟，马萨诸塞州雷丁市。见ISO/IEC 10646 1拟议修正案草案1
[X.509] ITU Recommendation X.509 1993 | ISO/IEC 9594-8: 1995, Including Draft Amendment 1: Certificate Extensions (Version 3 Certificate)
[X.509]ITU建议X.509 1993 | 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 Recommendation for Namespaces in XML, World Wide Web
Namespace] Consortium, 14 January 1999, "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建议。看见http://www.w3.org/TR/1998/REC-xml-19980210 1998年2月10日的版本。
The author of this document is:
本文件的作者是：
David Burdett Commerce One 4440 Rosewood Drive, Bldg 4 Pleasanton California 94588 USA
David Burdett Commerce One美国加利福尼亚州普莱森顿红木大道4440号楼，邮编94588
Phone: +1 (925) 520 4422
EMail: david.burdett@commerceone.com
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，英国电信公司
- Andrew Marchewka, Canadian Imperial Bank of Commerce
- Andrew Marchewka，加拿大帝国商业银行
- Brian Boesch, CyberCash Inc.
- Brian Boesch，网络现金公司。
- Tom Arnold, CyberSource
- 汤姆·阿诺德，网络资源
- Terry Allen, Commerce One (formally Veo Systems)
- Terry Allen，商务一号（正式为Veo系统）
- Richard Brown, GlobeSet Inc.
- 理查德·布朗，全球教育公司。
- Peter Chang, Hewlett Packard
- 彼得·张，惠普公司
- Masaaki Hiroya, Hitachi Ltd
- 日立株式会社Masaaki Hiroya
- Yoshiaki Kawatsura, Hitachi Ltd
- 日立株式会社川崎吉崎
- Mark Linehan, International Business Machines
- Mark Linehan，国际商用机器公司
- Jonathan Sowler, JCP Computer Services Ltd
- Jonathan Sowler，JCP计算机服务有限公司
- John Wankmueller, MasterCard International
- John Wankmueller，万事达卡国际
- Steve Fabes, Mondex International Ltd
- Steve Fabes，Mondex国际有限公司
- Donald Eastlake 3rd, Motorola Inc (formerly International Business Machines Inc)
- Donald Eastlake 3rd，摩托罗拉公司（前身为国际商业机器公司）
- Surendra Reddy, Oracle Corporation
- 苏伦德拉·雷迪，甲骨文公司
- Akihiro Nakano, Plat Home, Inc. (ex Hitachi Ltd)
- 中野昭弘，Plat Home，Inc.（前日立有限公司）
- Chris Smith, Royal Bank of Canada
- Chris Smith，加拿大皇家银行
- 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（前花旗银行通用卡服务，正式为AT&T通用卡服务）
- Efrem Lipkin, Sun Microsystems
- 太阳微系统公司Efrem Lipkin
- Tony Lewis, Visa International
- 托尼·刘易斯，维萨国际
The author would also like to thank the following organisations for their support:
作者还要感谢以下组织的支持：
- Amino Communications
- 氨基通信
- DigiCash
- 迪吉卡斯
- Fujitsu
- 富士通
- General Information Systems
- 一般信息系统
- Globe Id Software
- 环球Id软件
- Hyperion
- 海伯龙
- InterTrader
- 交互器
- Nobil I T Corp
- 诺比尔IT公司
- Mercantec
- 商业的
- Netscape
- 网景
- Nippon Telegraph and Telephone Corporation
- 日本电报电话公司
- Oracle Corporation
- 甲骨文公司
- Smart Card Integrations Ltd.
- 智能卡集成有限公司。
- Spyrus
- 斯皮罗斯
- Verifone
- 终端控制语言
- Unisource nv
- Unisource内华达州
- Wells Fargo Bank
- 富国银行
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。