RFC 2801
Internet Open Trading Protocol - IOTP Version 1.0
Pages: 290
Informational
Informational
Part 2 of 9 – Pages 28 to 56
2.3 Scope of Baseline IOTP
This specification describes the IOTP Transactions which make up Baseline IOTP. As described in the preface, IOTP will evolve over time. This section defines the initial conformance criteria for implementations that claim to "support IOTP." 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. 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 those who accept value as part of a deposit transaction, or o those that issue value a withdrawal transaction The following table defines, for each role, the IOTP Transactions and Trading Blocks which must be supported for that role.
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
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 Selection Must Must Must Must
Auth-Request a) a) a)
Depends Depends Depends
Auth-Reply a) a) a)
Depends Depends Depends
Offer Response Must Must Must Must
Payment Must Must
Request
Payment Must Must
Exchange
Payment Must Must
Response
Delivery Must Must
Request
Delivery Must Must
Response
Merchants
ECash ECash
Store Value Value Consumer Payment Delivery
Issuer Acquirer Handler Handler
Inquiry Must Must Must Must Must Must
Request
Inquiry Must Must Must Must Must Must
Response
Ping Request Must Must Must Must Must Must
Ping Response Must Must Must Must Must Must
Signature Must Must Must Limited Must Must
Error Must Must Must Must Must Must
In the above table:
o "Must" means that a Trading Role must support the Transaction or
Trading Block.
o "May" means that an implementation may support the Transaction or
Trading Block at the option of the developer.
o "Depends" means implementation of the Transaction or Trading Block
depends on one of the following conditions:
- if Baseline Authentication IOTP Transaction is supported;
- if required by a Payment Method as defined in its IOTP
Supplement document.
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.
An IOTP solution must support all the IOTP Transactions and Trading
Blocks required by at least one role (column) as described in the
above table for that solution to be described as "supporting IOTP".
3. Protocol Structure
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 Trading Exchanges where each Trading Exchange involves the
exchange of data, between Trading Roles, in the form of a set of
Trading Components.
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 how IOTP Messages are exchanged between Trading Roles to create an
IOTP Transaction
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 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 how extra XML Elements and new user defined values for existing
IOTP codes can be used when Extending IOTP,
o how IOTP uses the Packaged Content Element to embed data such as
payment protocol messages or detailed order definitions within an
IOTP Message
o how IOTP Identifies Languages so that different languages can be
used within IOTP Messages
o how IOTP handles both Secure and Insecure Net Locations when
sending messages
o how an IOTP Transaction can be cancelled.
3.1 Overview
3.1.1 IOTP Message Structure
The structure of an IOTP Message and its relationship with Trading
Blocks and Trading Components is illustrated in the diagram below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
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
The diagram also introduces the concept of a Transaction Reference
Block. This block contains, amongst other things, a globally unique
identifier for the IOTP Transaction. Also each block and component is
given an ID Attribute (see section 3.4) which is unique within an
IOTP Transaction. Therefore the combination of the ID attribute and
the globally unique identifier in the Transaction Reference Block is sufficient to uniquely identify any Trading Block or Trading Component.3.1.2 IOTP Transactions
A predefined set of IOTP Messages exchanged between the Trading Roles constitute an IOTP Transaction. This is illustrated in the diagram below. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 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
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. The IOTP Transactions (see section 9) in this version of IOTP are specifically: o Purchase. This supports a purchase involving an offer, a payment and optionally a delivery o Refund. This supports the refund of a payment as a result of, typically, an earlier purchase 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 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 Withdrawal. This supports the withdrawal of electronic cash from a financial institution o Deposit. This supports the deposit of electronic cash at a financial institution o Inquiry This supports inquiries on the status of an IOTP transaction which is either in progress or is complete 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.3.2 IOTP Message
As described earlier, IOTP Messages are [XML] documents which are physically sent between the different Trading Roles that are taking part in a trade. The XML definition of an IOTP Message is as follows. <!ELEMENT IotpMessage ( TransRefBlk, SigBlk?, ErrorBlk?,
( AuthReqBlk |
AuthRespBlk |
AuthStatusBlk |
CancelBlk |
DeliveryReqBlk |
DeliveryRespBlk |
InquiryReqBlk |
InquiryRespBlk |
OfferRespBlk |
PayExchBlk |
PayReqBlk |
PayRespBlk |
PingReqBlk |
PingRespBlk |
TpoBlk |
TpoSelectionBlk
)*
) >
<!ATTLIST IotpMessage
xmlns CDATA
'iotp:ietf.org/iotp-v1.0'
Content:
TransRefBlk This contains information which describes an IOTP
Message within an IOTP Transaction (see section
3.3 immediately below)
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
Attributes:
xmlns The [XML-Namespace] definition for IOTP messages.
3.2.1 XML Document Prolog
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: <?XML Version='1.0'?> <!DOCTYPE IotpMessage > <IotpMessage> ... </IotpMessage>3.3 Transaction Reference Block
A Transaction Reference Block contains information which identifies the IOTP Transaction and IOTP Message. The Transaction Reference Block contains: 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 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 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. The definition of a Transaction Reference Block is as follows: <!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) > <!ATTLIST TransRefBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Transaction Reference Block within the IOTP Transaction (see section 3.4 ID Attributes). Content: TransId See 3.3.1 Transaction Id Component immediately below. MsgId See 3.3.2 Message Id Component immediately below.
RelatedTo See 3.3.3 Related To Component immediately below.3.3.1 Transaction Id Component
This contains information which globally uniquely identifies the IOTP Transaction. Its definition is as follows: <!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. Version This identifies the version of IOTP, and therefore the structure of the IOTP Messages, which the IOTP Transaction is using. IotpTransId Contains data which uniquely identifies the IOTP Transaction. It must conform to the rules for Message Ids in [RFC 822]. 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.
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.
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.
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.
3.3.2 Message Id Component
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.
<!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.
RespIotpMsg This contains the ID attribute of the Message
Id Component of the IOTP Message to which this
IOTP Message is a response. In this way all
the IOTP Messages in an IOTP Transaction are
unambiguously linked together. This field is
required on every IOTP Message except the
first IOTP Message in an IOTP Transaction.
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.
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.
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.
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.
SoftwareId This contains information which identifies the
software which generated the IOTP Message. Its
purpose is to help resolve interoperability
problems that might occur as a result of
incompatibilities between messages produced by
different software. It is a single text string
in the language defined by xml:lang. It must
contain, as a minimum:
o the name of the software manufacturer
o the name of the software
o the version of the software, and
o the build of the software
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.
3.3.3 Related To Component
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.
<!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.
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.
RelationshipType Defines the type of the relationship. Valid values
are:
o IotpTransaction. in which case the Packaged
Content Element contains an IotpTransId of
another IOTP Transaction
o Reference in which case the Packaged Content
Element contains the reference of some other,
non-IOTP document.
Values of RelationshipType are controlled under
the procedures defined in section 12 IANA
Considerations which also allows user defined
values to be defined.
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.
The purpose of the attribute is to provide the
Trading Roles involved in an IOTP Transaction with
an explanation of the nature of the relationship
between the transactions.
Care should be taken that the words used to in the
Relation attribute indicate the "direction" of the
relationship correctly. For example: one
transaction might be a refund for another earlier
transaction. In this case the transaction which is
a refund should contain in the Relation attribute
words such as "refund for" rather than "refund to"
or just "refund".
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.
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.4 ID Attributes
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.
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. 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). This section defines the rules for setting the values for the ID attributes of IOTP Messages, Blocks and Components.3.4.1 IOTP Message ID Attribute Definition
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: 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: o "M" - Merchant o "C" - Consumer For messages which contain an Inquiry Request Trading Block or a Ping Request Trading Block, the prefix is set to "I" for Inquiry. For messages which contain an Inquiry Response Trading Block or a Ping Response Trading Block, the prefix is set to "Q". The prefix for the other roles in a trade is contained within the Organisation Component for the role and are typically set by the Merchant. The following is recommended as a guideline and must not be relied upon:
o "P" - First (only) Payment Handler
o "R" - Second Payment Handler
o "D" - Delivery Handler
o "C" - Deliver To
As a guideline, prefixes should be limited to one
character.
NameChar has the same definition as the [XML]
definition of NameChar.
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:
o the first IOTP Message sent by a trading role
is given the suffix "1"
o the second and subsequent IOTP Messages sent
by the same trading role are incremented by one
for each message
o no leading zeroes are included in the suffix
Put more simply the Message Id Component of the
first IOTP Message sent by a Consumer would have
an ID attribute of, "C1", the second "C2", the
third "C3" etc.
Digit has the same definition as the [XML]
definition of Digit.
3.4.2 Block and Component ID Attribute Definitions
The ID Attribute of Blocks and Components must also be unique within
an IOTP Transaction. Their definition is as follows:
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.
In IOTP, Trading Components and Trading Blocks are
copied from one IOTP Message to another. The ID
attribute does not change when an existing Trading
Block or Component is copied to another IOTP
Message.
IdSuffix The suffix consists of one or more digits. The
suffix must be unique within the ID attribute of
the Message ID Component used to generate the ID
attribute. The following is recommended as a
guideline and must not be relied upon:
o the first Block or Component sent by a trading
role is given the suffix "1"
o the ID attributes of the second and subsequent
Blocks or Components are incremented by one for
each new Block or Component added to an IOTP
Message
o no leading zeroes are included in the suffix
Put more simply, the first new Block or Component
added to the second IOTP Message sent, for
example, by a consumer would have a an ID
attribute of "C2.1", the second "C2.2", the third
"C2.3" etc.
Digit has the same definition as the [XML]
definition of Digit.
3.4.3 Example of use of ID Attributes
The diagram below illustrates how ID attribute values are used. *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* 1st IOTP MESSAGE 2nd IOTP MESSAGE (e.g., from Merchant to (e.g., from Consumer to Consumer Payment Handler) IOTP MESSAGE IOTP MESSAGE * |-Trans Ref Block. ID=M1.1 |-Trans Ref Block.ID=C1.1* | |-Trans Id Comp. ID = M1.2 ------------>| |-Trans Id Comp. | | Copy Element | | ID=M1.2 | |-Msg Id Comp. ID = M1 | |-Msg Id Comp. ID=C1 * | | |-Signature Block. ID=M1.8 |-Signature Block.ID=C1.5* | |-Sig Comp. ID=M1.15 ------------------>| |-Comp. ID=M1.15 | Copy Element | |-Trading Block. ID=M1.3 |-Trading Block.ID=C1.2 * | |-Comp. ID=M1.4 -------------------------->|-Comp. ID=M1.4 | | Copy Element | | |-Comp. ID=M1.5 -------------------------->|-Comp. ID=M1.5 | | Copy Element | | |-Comp. ID=M1.6 |-Comp. ID=C1.3 * | |-Comp. ID=M1.7 |-Comp. ID=C1.4 * | |-Trading Block. ID=M1.9 |-Comp. ID=M1.10 * = new elements |-Comp. ID=M1.11 |-Comp. ID=M1.12 |-Comp. ID=M1.13 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- Figure 8 Example use of ID attributes3.5 Element References
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: o identifying an XML element whose Digest is included in a Signature Component,
o referring to the Payment Handler Organisation Component which is
used when making a Payment
An Element Reference always contains the value of an ID attribute of
a Block or Component.
Identifying the IOTP Message, Trading Block or Trading Component
which is referred to by an Element Reference, involves finding the
XML element which:
o belongs to the same IOTP Transaction (i.e. the Transaction Id
Components of the IOTP Messages match), and
o where the value of the ID attribute of the element matches the
value of the Element Reference.
Note: The term "match" in this specification has the same definition
as the [XML] definition of match.
An example of "matching" an Element Reference is illustrated in the
example below.
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
1st IOTP MESSAGE 2nd IOTP MESSAGE
(e.g., from Merchant to (e.g., from Consumer to
Consumer Payment Handler)
IOTP MESSAGE IOTP MESSAGE
|-Trans Ref Block. ID=M1.1 Trans ID |-Trans RefBlock. ID=C1.1
| |-Trans Id Comp. ID = M1.2 <-Components-|->|-TransId Comp.ID=M1.2
| | must be | |
| |-Msg Id Comp. ID = M1 Identical | |-Msg Id Comp. ID=C1
| ^ |
|-Signature Block. ID=M1.8 | |-Signature Block.ID=C1.5
| |-Sig Comp. ID=M1.15 | | |-Comp. ID=M1.15
| AND |
|-Trading Block. ID=M1.3 | |-Trading Block. ID=C1.2
| |-Comp. ID=M1.4 | |-Comp. ID=M1.4
| | v |
| |-Comp. ID=M1.5 <-------- -ID Attribute |-Comp. ID=M1.5
| | and El Ref |
| |-Comp. ID=M1.6 values must |-Comp. ID=C1.3
| | match--------|--> El Ref=M1.5
| |-Comp. ID=M1.7 |-Comp. ID=C1.4
|
|-Trading Block. ID=M1.9
|-Comp. ID=M1.10
|-Comp. ID=M1.11
|-Comp. ID=M1.12
|-Comp. ID=M1.13
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Figure 9 Element References
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.
3.6 Extending IOTP
Baseline IOTP defines a minimum protocol which systems supporting
IOTP must be able to accept. As new versions of IOTP are developed,
additional types of IOTP Transactions will be defined. In addition to
this, Baseline and future versions of IOTP will support user
extensions to IOTP through two mechanisms:
o extra XML elements, and o new values for existing IOTP codes.3.6.1 Extra XML Elements
The XML element and attribute names used within IOTP constitute an [XML-Namespace] as identified by the xmlns attribute on the IotpMessage element. This allows IOTP to support the inclusion of additional XML elements within IOTP messages through the use of [XML Namespaces]. Using XML Namespaces, extra XML elements may be included at any level within an IOTP message including: o new Trading Blocks o new Trading Components o new XML elements within a Trading Component. The following rules apply: o any new XML element must be declared according to the rules for [XML-Namespace] o new XML elements which are either Trading Blocks or Trading Components must contain an ID attributes with an attribute name of 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. The purpose of this attribute is to allow an IOTP aware application to determine if the IOTP transaction can safely continue. Specifically: 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 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:
- 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
- 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 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
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 (True | False ) 'True'
3.6.2 Opaque Embedded Data
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.
3.7 Packaged Content Element
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:
o to encapsulate payment scheme messages, such as SET messages,
o to encapsulate a description of an order, a payment note, or a
delivery note.
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" >
Attributes:
Name Optional. Distinguishes between multiple
occurrences of Packaged Content Elements at the
same point in IOTP. For example:
<ABCD>
<PackagedContent Name='FirstPiece'>
snroasdfnas934k
</PackagedContent>
<PackagedContent Name='SecondPiece'>
dvdsjnl5poidsdsflkjnw45
</PackagedContent>
</ABCD>
The name attribute may be omitted, for example if
there is only one Packaged Content element.
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.
o XML. The content of the Packaged Content
Element can be treated as an XML document.
Entities and CDATA sections, or Transform set
to BASE64, must be used to ensure that the
Packaged Content Element contents are
legitimate PCDATA.
Values of the Content attribute are controlled
under the procedures defined in section 12 IANA
Considerations which also allows user defined
values to be defined.
Transform This identifies the transformation that has been
done to the data before it was placed in the
content. Valid values are:
o NONE. The PCDATA content of the Packaged
Content Element is the correct representation
of the data. Note that entity expansion must
occur first (i.e. replacement of & and
	) before the data is examined. CDATA
sections may legitimately occur in a Packaged
Content Element where the Transform attribute
is set to NONE.
o BASE64. The PCDATA content of the Packaged
Content Element represents a BASE64 encoding of
the actual content.
Content:
PCDATA This is the actual data which has been embedded.
The format of the data and rules on how to decode
it are contained in the Content and the Transform
attributes
Note that any special details, especially custom attributes, must be
represented at a higher level.
3.7.1 Packaging HTML
The packaged content may contain HTML. In this case the following
conventions are followed:
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 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 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 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 [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.
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.
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
3.7.2 Packaging XML
Support for XML is recommended. When XML needs to be displayed, for
example to display the content of an Order Description to a Consumer,
then implementers should follow the latest recommendations of the
World Wide Web Consortium.
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:
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.
Once these standards become W3C "Recommendations", then it is anticipated that this specification will be amended if practical.3.8 Identifying Languages
IOTP uses [XML] Language Identification to specify which languages are used within the content and attributes of IOTP Messages. The following principles have been used in order to determine which XML elements contain an xml:lang Attributes: o a mandatory xml:lang attribute is contained on every Trading Component which contains attributes or content which may need to be displayed or printed in a particular language o 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. xml:lang attributes which follow these principles are included in the Trading Components and their child XML elements defined in section 7. 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.3.9 Secure and Insecure Net Locations
IOTP contains several "Net Locations" which identify places where, typically, IOTP Messages may be sent. Net Locations come in two types: 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 "Insecure" Net Locations where privacy of data is not assured. 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.3.10 Cancelled Transactions
Any Trading Role involved in an IOTP transaction may cancel that transaction at any time.3.10.1 Cancelling Transactions
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. 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 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. 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. 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. 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. A non-Consumer Trading Role should only cancel a transaction: o after a request block has been received and
o before the response block has been sent If a non-Consumer Trading Role cancels a transaction at any other time it should be treated by the recipient as an error.3.10.2 Handling Cancelled Transactions
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. 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.
(page 56 continued on part 3)