Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2801

Internet Open Trading Protocol - IOTP Version 1.0

Pages: 290
Informational
Part 6 of 9 – Pages 163 to 200
First   Prev   Next

Top   ToC   RFC2801 - Page 163   prevText

8. Trading Blocks

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. Each Trading Blocks consist of one or more Trading Components (see section 7). This is illustrated in the diagram below.
Top   ToC   RFC2801 - Page 164
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

             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
Top   ToC   RFC2801 - Page 165
   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:

   <!ELEMENT IotpMessage
      ( TransRefBlk,
        SigBlk?,
        ErrorBlk?,
        ( AuthReqBlk |
          AuthRespBlk |
          AuthStatusBlk |
          CancelBlk |
          DeliveryReqBlk |
          DeliveryRespBlk |
          InquiryReqBlk |
          InquiryRespBlk |
          OfferRespBlk |
          PayExchBlk |
          PayReqBlk |
          PayRespBlk |
          PingReqBlk |
          PingRespBlk |
          TpoBlk |
          TpoSelectionBlk
        )*
      ) >

   The remainder of this section defines the Trading Blocks in this
   version of IOTP. They are:

   o  Authentication Request Block

   o  Authentication Response Block

   o  Authentication Status Block

   o  Cancel Block

   o  Delivery Request Block

   o  Delivery Response Block

   o  Error Block

   o  Inquiry Request Block

   o  Inquiry Response Block
Top   ToC   RFC2801 - Page 166
   o  Offer Response Block

   o  Payment Exchange Block

   o  Payment Request Block

   o  Payment Response Block

   o  Signature Block

   o  Trading Protocol Options Block

   o  TPO Selection Block

   The Transaction Reference Block is described in section 3.3.

8.1 Trading Protocol Options Block

The TPO Trading Block contains options which apply to the IOTP Transaction. The definition of a TPO Trading Block is as follows. <!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). Content: ProtocolOptions The Protocol Options Component (see section 7.1)defines the options which apply to the whole IOTP Transaction (see section 9). BrandList This Brand List Component contains one or more payment brands and protocols which may be selected (see section 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.
Top   ToC   RFC2801 - Page 167
   The TPO Block should contain:

   o  the Protocol Options Component

   o  the Organisation Component with the Trading Role of Merchant

   o  the Organisation Component with the Trading Role of Consumer

   o  optionally, the Organisation Component with the Trading Role of
      DeliverTo, if there is a Delivery included in the IOTP Transaction

   o  Brand List Components for each payment in the IOTP Transaction

   o  Organisation Components for all the Payment Handlers involved

   o  optionally, Organisation Components for the Delivery Handler (if
      any) for the transaction

   o  additional Organisation Components that the Merchant may want to
      include. For example

      -  a Customer Care Provider

      -  an Certificate Authority that offers Merchant "Credentials" or
         some other warranty on the goods or services being offered.

8.2 TPO Selection Block

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. <!ELEMENT TpoSelectionBlk (BrandSelection+) > <!ATTLIST TpoSelectionBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the TPO Selection Block within the IOTP Transaction. 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.
Top   ToC   RFC2801 - Page 168
   The TPO Selection Block should contain one Brand Selection Component
   for each Brand List in the TPO Block.

8.3 Offer Response Block

The Offer Response Block contains details of the goods, services, amount, delivery instructions or financial transaction which is to take place. Its definition is as follows. <!ELEMENT OfferRespBlk (Status, Order?, Payment*, Delivery?, TradingRoleData*) > <!ATTLIST OfferRespBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Offer Response Block within the IOTP Transaction. 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. Order The Order Component contains details about the goods, services or financial transaction which is taking place see section 7.5. The Order Component must be present unless the ProcessState attribute of the Status Component is set to Failed. Payment The Payment Components contain information about the payments which are to be made see section 7.9. Delivery The Delivery Component contains details of the delivery to be made (see section 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). The Offer Response Block should contain:
Top   ToC   RFC2801 - Page 169
   o  the Order Component for the IOTP Transaction

   o  Payment Components for each Payment in the IOTP Transaction

   o  the Delivery Component the IOTP Transaction requires (if any).

8.4 Authentication Request Block

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 a request for additional information about the Organisation being authenticated. Its definition is as follows. <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) > <!ATTLIST AuthReqBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Authentication Request Block within the IOTP Transaction. 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). If one Authentication Request Component is present then that Authentication Request Component should be used.
Top   ToC   RFC2801 - Page 170
                       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

   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.

8.5 Authentication Response Block

The Authentication Response Block contains the response which results from processing the Authentication Request Block. Its definition is as follows. <!ELEMENT AuthRespBlk (AuthResp?, Org*) > <!ATTLIST AuthRespBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Authentication Response Block within the IOTP Transaction. Content: AuthResp The optional Authentication Response Component which contains the results of processing the Authentication Request Component - see section 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.
Top   ToC   RFC2801 - Page 171
   The components present in the Authentication Response Block must
   match the requirement of the corresponding Authentication Request
   Block otherwise it is an error.

8.6 Authentication Status Block

The Authentication Status Block indicates the success or failure of the validation of an Authentication Response Block by an Authenticator. Its definition is as follows. <!ELEMENT AuthStatusBlk (Status) > <!ATTLIST AuthStatusBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Authentication Status Block within the IOTP Transaction. Content: Status Contains status information about the business success (see section 4.2) or failure of the authentication

8.7 Payment Request Block

The Payment Request Block contains information which requests that a payment is started. Its definition is as follows. <!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection, Payment, PaySchemeData?, Org*, TradingRoleData*) > <!ATTLIST PayReqBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Payment Request Block within the IOTP Transaction. 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
Top   ToC   RFC2801 - Page 172
                      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).

   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.

   Payment            The Payment Components contain information about
                      the payment which is being made see section 7.9.

   PaySchemeData      The Payment Scheme Component contains payment
                      scheme specific data see section 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.

   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).

   The Payment Request Block should contain:

   o  the Organisation Component with a Trading Role of Merchant

   o  the Organisation Component with the Trading Role of Consumer

   o  the Payment Component for the Payment

   o  the Brand List Component for the Payment

   o  the Brand Selection Component for the Brand List

   o  the Organisation Component for the Payment Handler of the Payment
Top   ToC   RFC2801 - Page 173
   o  the Organisation Component (if any) for the Organisation which
      carried out the previous step, for example another Payment Handler

   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  the Organisation Components for any additional Organisations that
      the Merchant has included in the Offer Response Block

   o  an Optional Payment Scheme Data Component, if required by the
      Payment Method as defined in the IOTP supplement for the payment
      method

   o  any Trading Role Data Components that may be required (see section
      7.17.1).

8.8 Payment Exchange Block

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 > Attributes: ID An identifier which uniquely identifies the Payment Exchange Block within the IOTP Transaction. Content: PaySchemeData This Trading Component contains payment scheme specific data see section 7.10 Payment Scheme Component.

8.9 Payment Response Block

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.
Top   ToC   RFC2801 - Page 174
   <!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.

   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.

   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.

   PaySchemeData      Contains payment scheme specific data see section,
                      for example a payment protocol message. See 7.10
                      Payment Scheme Component.

   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.

   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).
Top   ToC   RFC2801 - Page 175

8.10 Delivery Request Block

The Delivery Request Block contains details of the goods or services which are to be delivered together with a signature which can be used to check that delivery is authorised. Its definition is as follows. <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery, ConsumerDeliveryData?, TradingRoleData*) > <!ATTLIST DeliveryReqBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Delivery Request Block within the IOTP Transaction. 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. Order The Order Component contains details about the goods, services or financial transaction which is taking place see section 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. Delivery The Delivery Component contains details of the delivery to be made (see section 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.
Top   ToC   RFC2801 - Page 176
   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).

   The Delivery Request Block contains:

   o  the Organisation Component with a Trading Role of Merchant

   o  the Organisation Component for the Consumer and DeliverTo Trading
      Roles

   o  the Delivery Component for the Delivery

   o  the Organisation Component for the Delivery Handler. Specifically
      the Organisation Component identified by the ActionOrgRef
      attribute on the Delivery Component

   o  the Organisation Component (if any) for the Organisation which
      carried out the previous step, for example a Payment Handler

   o  the Organisation Components for any additional Organisations that
      the Merchant has included in the Offer Response Block

   o  any Trading Role Data Components that may be required (see section
      7.17.1).

8.11 Delivery Response Block

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. <!ELEMENT DeliveryRespBlk (Status, DeliveryNote) > <!ATTLIST DeliveryRespBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Delivery Response Block within the IOTP Transaction. Content:
Top   ToC   RFC2801 - Page 177
   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.

   DeliveryNote       The Delivery Note Component contains details about
                      how the goods or services will be delivered (see
                      section 7.15).

8.12 Inquiry Request Trading Block

The Inquiry Request Trading Block contains an Inquiry Type Component and an optional Payment Scheme Component to contain payment scheme specific inquiry messages. <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) > <!ATTLIST InquiryReqBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Inquiry Request Trading Block within the IOTP Transaction. Content: InquiryType Inquiry Type Component (see section 7.18) that contains the type of inquiry. 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.

8.13 Inquiry Response Trading Block

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.
Top   ToC   RFC2801 - Page 178
   <!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.

   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.

   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.

   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).

   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.
Top   ToC   RFC2801 - Page 179

8.14 Ping Request Block

The Ping Request Block is used to determine if a Server is operating and whether or not cryptography is compatible. The definition of a Ping Request Block is as follows. <!ELEMENT PingReqBlk (Org*)> <!ATTLIST PingReqBlk ID ID #REQUIRED> Attributes: ID An identifier which uniquely identifies the Ping Request Trading Block within the IOTP Transaction. Content: Org Optional Organisation Components (see section 7.6). If no Organisation Component is present then the Ping Request is anonymous and simply determines if the server is operating. However if Organisation Components are present, then it indicates that the sender of the Ping Request wants to verify that digital signatures can be handled. 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. These are then used to generate a signature over the Ping Response Block.

8.15 Ping Response Block

The Ping Response Trading Block provides the result of a Ping Request. It contains an Organisation Component that identifies the sender of the Ping Response.
Top   ToC   RFC2801 - Page 180
   If the Ping Request to which this block is a response contained
   Organisation Components, then it also contains those Organisation
   Components.

   <!ELEMENT PingRespBlk (Org+)>
   <!ATTLIST PingRespBlk
    ID                 ID      #REQUIRED
    PingStatusCode (Ok | Busy | Down) #REQUIRED
    SigVerifyStatusCode (Ok | NotSupported | Fail) #IMPLIED
    xml:lang           NMTOKEN #IMPLIED
    PingStatusDesc     CDATA   #IMPLIED>

   Attributes:

   ID                   An identifier which uniquely identifies the Ping
                        Request Trading Block within the IOTP
                        Transaction.

   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.

   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.

   Xml:lang             Defines the language used in PingStatusDesc.
                        This is present when PingStatusDesc is present.

   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
Top   ToC   RFC2801 - Page 181
                        attribute to send more refined status
                        information than PingStatusCode which can be
                        used for debugging purposes, for example.

   Content:

   Org                These are Organisation Components (see section
                      7.6).

                      The Organisation Components of the sender of the
                      Ping Response is always included in addition to
                      the Organisation Components sent in the Ping
                      Request.

   Note: Ping Status Code values do not include a value such as Fail,
   since, when the software receiving the Ping Request message is not
   working at all, no Ping Response message will be sent back.

8.16 Signature Block

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. The definition of a Signature Block is as follows: <!ELEMENT IotpSignatures (Signature+, Certificate*) > <!ATTLIST IotpSignatures ID ID #IMPLIED > Attributes: ID An identifier which uniquely identifies the Signature Block within the IOTP Transaction. Content: Signature A Signature Component. See section 7.19. Certificate A Certificate Component. See section 7.20.
Top   ToC   RFC2801 - Page 182
   The contents of a Signature Block depends on the Trading Block that
   is contained in the same IOTP Message as the Signature Block.

8.16.1 Signature Block with Offer Response

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).

8.16.2 Signature Block with Payment Request

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 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

8.16.3 Signature Block with Payment Response

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.

8.16.4 Signature Block with Delivery Request

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 the Payment Receipt Signature Component (see section 7.19.3) generated by the previous step.

8.16.5 Signature Block with Delivery Response

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.
Top   ToC   RFC2801 - Page 183

8.17 Error Block

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. 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 message reporting the error. An IOTP message that contains an Error Trading Block that describes the error found in a message in error. 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. The structure of an Error Trading Block is as follows. <!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) > <!ATTLIST ErrorBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Error Trading Block within the IOTP Transaction. Content: ErrorComp An Error Components (see section 7.21) that contains information about an individual Technical Error. PaySchemeData An optional Payment Scheme Component (see section 7.10) which contains a Payment Scheme Message. See the appropriate payment scheme supplement to
Top   ToC   RFC2801 - Page 184
                      determine whether or not this component needs to
                      be present and for the definition of what it must
                      contain.

8.18 Cancel Block

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 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. Its definition is as follows. <!ELEMENT CancelBlk (Status) > <!ATTLIST CancelBlk ID ID #REQUIRED > Attributes: ID An identifier which uniquely identifies the Cancel Block within the IOTP Transaction. Content: Status Contains status information indicating that the IOTP transaction has been cancelled.

9. Internet Open Trading Protocol Transactions

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
Top   ToC   RFC2801 - Page 185
   o  IOTP Transactions that involve one or more payments. Specifically:

      -  Deposit

      -  Purchase

      -  Refund

      -  Withdrawal, and

      -  Value Exchange

   o  IOTP Transactions designed to check the correct function of the
      IOTP infrastructure. Specifically:

      -  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:

   o  Authentication and Payment transactions (Authentication, Deposit,
      Purchase, Refund, Withdrawal and Value Exchange)

   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

9.1 Authentication and Payment Related IOTP Transactions

The Authentication and Payment related IOTP Transactions consist of six Document Exchanges which are then combined in sequence to implement a specific transaction. Generally, there is a close, but not exact, correspondence between a Document Exchange and a Trading Exchange. The main difference is that some Document Exchanges implement part or all of two Trading Exchanges simultaneously in order to minimise the number of actual IOTP Messages which must be sent over the Internet. The six Document Exchanges are: o Authentication. This is a direct implementation of the Authentication Trading Exchange
Top   ToC   RFC2801 - Page 186
   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  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  Payment. This is a direct implementation of the Payment part of a
      Payment Trading Exchange

   o  Delivery. This is a direct implementation of the Delivery Exchange

   o  Delivery with Payment. This is an implementation of combined
      Payment and Delivery Trading Exchanges

   These Document Exchanges are combined together in different sequences
   to implement each IOTP Transaction. The way in which they may be
   combined is illustrated by the diagram below.
Top   ToC   RFC2801 - Page 187
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

     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

   The combinations of Document Exchanges that are valid depend on the
   particular IOTP transaction.

   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  descriptions of how each IOTP Transaction uses the Document
      Exchanges to effect the desired result.
Top   ToC   RFC2801 - Page 188
   Note: The descriptions of the Document Exchanges which follow
   describe the ways in which various Business Errors (see section 4.2)
   are handled. No reference is made however to the handling of
   Technical Errors (see section 4.1) in any of the messages since these
   are handled the same way irrespective of the context in which the
   message is being sent. See section 4 for more details.

9.1.1 Authentication Document Exchange

The Authentication Document Exchange is a direct implementation of the Authentication Trading Exchange (see section 2.2.4). It involves: o an Authenticator - the Organisation which is requesting the authentication, and o an Authenticatee - the Organisation being authenticated. The authentication consists of: o an Authentication Request being sent by the Authenticator to the Authenticatee, o an Authentication Response being sent in return by the Authenticatee to the Authenticator which is then checked, and o an Authentication Status being sent by the Authenticator to the Authenticatee to provide an indication of the success or failure of the authentication. An Authentication Document Exchange also: o provides an Authenticatee with an Organisation Component which describes the Authenticator, and o optionally provides the Authenticator with Organisation Components which describe the Authenticatee. 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.
Top   ToC   RFC2801 - Page 189
 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
 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)

 2.          The second Organisation generates: an Authentication
             Request Block containing one or more Authentication
             Request Components and/or a Trading Role Information
             Request Component, then sends it to the first
             Organisation

     1 <-- 2 TPO & AUTHENTICATION REQUEST. IotpMsg: Trans Ref Block;
             Signature Block (optional); TPO Block; Auth Request Block

 3.          IOTP aware application started. If a Signature Block is
             present, the first Organisation may use this to check the
             credentials of the second Organisation. If credentials are
             OK, the first Organisation selects an Authentication
             Request to use (if present and more than one), then uses
             the authentication algorithm selected to generate an
             Authentication Response Block. If present, the Trading
             Role Information Request Component is used to generate
             Organisation Components. Finally a Signature Component is
             created if required and all components are then sent back
             to the second Organisation for validation.

     1 --> 2 AUTHENTICATION RESPONSE. IotpMsg; Trans Ref Block;
             Signature Block (optional) ; Auth Response Block

 4.          The second Organisation checks the Authentication
             Response against the data in the Authentication Request
             Block to check that the first Organisation is who they
             appear to be, and sends an Authentication Status Block to
             the first Organisation to indicate the result then
             stops.

     1 <-- 2 AUTHENTICATION STATUS. IotpMsg: Trans Ref Block;
             Signature Block (optional); Auth Response Block
Top   ToC   RFC2801 - Page 190
 5.          The first Organisation checks the authentication Status
             Block and optionally keeps information on the IOTP
             transaction for record keeping purposes and stops.

 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                 Figure 18 Authentication Document Exchange

9.1.1.1 Message Processing Guidelines
On receiving a TPO & Authentication Request IOTP Message (see below), an Authenticatee may either: o generate and send an Authentication Response IOTP Message back to the Authenticator, or o indicate failure to comply with the Authentication Request by sending a Cancel Block back to the Authenticator containing a Status Component with a StatusType of Authentication a ProcessState of Failed and the CompletionCode (see section 7.16.4) set to either: AutEeCancel, NoAuthReq, TradRolesIncon or Unspecified. On receiving an Authentication Response IOTP Message (see below), an Authenticator should send in return, an Authentication Status IOTP Message (see below) containing a Status Block with a Status Component where the StatusType is set to Authentication, and: o the ProcessState attribute of the Status Component is set to CompletedOk which indicates a successful completion, or o the ProcessState attribute is set to Failed and the CompletionCode attribute is set to either: AutOrCancel, AuthFailed or Unspecified which indicates a failed authentication, On receiving an Authentication Status IOTP Message (see below), the Authenticatee should check the Status Component in the Status Block. If this indicates: o a successful authentication, then the Authenticatee should either: - continue with the next step in the IOTP Transaction of which the Authentication Document Exchange is part (if any), or
Top   ToC   RFC2801 - Page 191
      -  indicate a failure to continue with the rest of the IOTP
         Transaction, by sending back to the Authenticator a Cancel
         Block containing a Status Component with a StatusType of
         Authentication, a ProcessState of Failed and the CompletionCode
         (see section 7.16.4) set to AutEeCancel.

   o  a failed authentication, then the failure should be reported to
      the Authenticatee and any further processing stopped.

   If the Authenticator receives an IOTP Message containing a Cancel
   block from a Consumer, then the Authenticatee may go to the
   CancelNetLocn specified on the Trading Role Element in the
   Organisation Component for the Authenticator contained in the Trading
   Protocol Options Block.

9.1.1.2 TPO & Authentication Request IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this message consists of: o a Trading Protocol Options Block (see section 8.1) o an Authentication Request Block (see section 8.4), and o an optional Signature Block (see section 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: o one Protocol Options Component (see Section 7.1) which defines the options which apply to the whole Authentication Document Exchange. o one Organisation Component (see section 7.6) which describes the Authenticator. The Trading Role on the Organisation Component should indicate the role which the Authenticator is taking in the Trade, for example a Merchant or a Consumer. AUTHENTICATION REQUEST BLOCK The Authentication Request Block (see section 8.4) must contain the following Trading Components: o one Authentication Request Component (see section 7.2), and
Top   ToC   RFC2801 - Page 192
   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:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message that contains information that describes the IOTP Message
      and IOTP Transaction

   o  the Transaction Id Component (see section 3.3.1) which globally
      uniquely identifies the IOTP Transaction

   o  the following components of the TPO Block :

      -  the Protocol Options Component

      -  the Organisation Component

   o  the following components of the Authentication Request Block:

      -  the Authentication Request Component

      -  the Trading Role Information Request Component

9.1.1.3 Authentication Response IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this message consists of: o an Authentication Response Block (see section 8.5), and o an optional Signature Block (see section 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 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.
Top   ToC   RFC2801 - Page 193
   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:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message that contains information that describes the IOTP Message
      and IOTP Transaction

   o  the Transaction Id Component (see section 3.3.1) which globally
      uniquely identifies the IOTP Transaction

   o  the following components of the Authentication Request Block:

      -  the Authentication Request Component

      -  the Trading Role Information Request Component

   o  the Organisation Components contained in the Authentication
      Response Block

   Note: It should not be assumed that all trading roles can support the
   signing of data. Particularly it should not be assumed that Consumers
   support the signing of data.

9.1.1.4 Authentication Status IOTP Message
Apart from a Transaction Reference Block (see section 3.3), this message consists of: o an Authentication Status Block (see section 8.5), and o an optional Signature Block (see section 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: o one Status Component (see section 7.16) with a ProcessState attribute set to CompletedOk.
Top   ToC   RFC2801 - Page 194
      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:

   o  the Transaction Reference Block (see section 3.3) for the IOTP
      Message that contains information that describes the IOTP Message
      and IOTP Transaction

   o  the Transaction Id Component (see section 3.3.1) which globally
      uniquely identifies the IOTP Transaction

   o  the following components of the Authentication Status Block:

      -  the Status Component (see section 7.16).

   Note: If the Authentication Document Exchange is followed by an Offer
   Document Exchange (see section 9.1.2) then the Authentication Status
   Block and the Signature Block (Authentication Status) may be combined
   with either:

   o a TPO IOTP Message (see section 9.1.2.3), or

   o a TPO and Offer Response IOTP Message (see section 9.1.2.6)

9.1.2 Offer Document Exchange

The Offer Document Exchange occurs in two basic forms: o Brand Dependent Offer Exchange. Where the content of the offer, e.g., the order details, amount, delivery details, etc., are dependent on the payment brand and protocol selected by the consumer, and o Brand Independent Offer Exchange. Where the content of the offer is not dependent on the payment brand and protocol selected. Each of these types of Offer Document Exchange may be preceded by an Authentication Document Exchange (see section 9.1.1).
9.1.2.1 Brand Dependent Offer Document Exchange
In a Brand Dependent Offer Document Exchange the TPO Block and the Offer Response Block are sent separately by the Merchant to the Consumer, i.e.:
Top   ToC   RFC2801 - Page 195
   o  the Brand List Component is sent to the Consumer in a TPO Block,

   o  the Consumer selects a Payment Brand, Payment Protocol and
      optionally a Currency and amount from the Brand List Component

   o  the Consumer sends the selected brand, protocol and
      currency/amount back to the Merchant in a TPO Selection Block, and

   o  the Merchant uses the information received to define the content
      of and then send the Offer Response Block to the Consumer.
Top   ToC   RFC2801 - Page 196
 This is illustrated by the diagram below.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer
     |  Merchant
STEP |     |
 1.          Consumer decides to trade and sends to the Merchant
             information (e.g., using HTML) that enables the Merchant
             to create an offer,

     C --> M Offer information - outside scope of IOTP

 2.          Merchant decides which payment brand protocols,
             currencies and amounts apply, places then in a Brand List
             Component inside a TPO Block and sends to Consumer

     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.

     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

     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

     CONTINUED ...

 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

              Figure 19 Brand Dependent Offer Document Exchange
Top   ToC   RFC2801 - Page 197
   Note, a Consumer identifies a Brand Dependent Offer Document
   Exchange, by the absence of an Offer Response Block in the first IOTP
   Message.

   MESSAGE PROCESSING GUIDELINES

   On receiving a TPO IOTP Message (see below), the Consumer may either:

   o  generate and send a TPO Selection IOTP Message back to the
      Merchant, or

   o  indicate failure to continue with the IOTP Transaction by sending
      a Cancel Block back to the Merchant containing a Status Component
      with a StatusType of Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.4) set to either: ConsCancelled
      or Unspecified.

   On receiving a TPO Selection IOTP Message (see below) the Merchant
   may either:

   o  generate and send an Offer Response IOTP Message back to the
      Consumer, or

   o  indicate failure to continue with the IOTP Transaction by sending
      a Cancel Block back to the Consumer containing a Status Component
      with a StatusType of Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.4) set to either: MerchCancelled
      or Unspecified.

   On receiving an Offer Response IOTP Message (see below) the Consumer
   may either:

   o  generate and send the next IOTP Message in the IOTP transaction
      and send it to the required Trading Role. This is dependent on the
      IOTP Transaction, or

   o  indicate failure to continue with the IOTP Transaction by sending
      a Cancel Block back to the Merchant containing a Status Component
      with a StatusType of Offer, a ProcessState of Failed and the
      CompletionCode (see section 7.16.4) set to either: ConsCancelled
      or Unspecified.

   If the Merchant receives an IOTP Message containing a Cancel block,
   then the Consumer is likely to go to the CancelNetLocn specified on
   the Trading Role Element in the Organisation Component for the
   Merchant.
Top   ToC   RFC2801 - Page 198
   If the Consumer receives an IOTP Message containing a Cancel block,
   then the information contained in the IOTP Message should be reported
   to the Consumer but no further action taken.

9.1.2.2 Brand Independent Offer Document Exchange
In a Brand Independent Offer Document Exchange the TPO Block and the Offer Response Block are sent together by the Merchant to the Consumer, i.e. there is one IOTP Message that contains both a TPO Block, and an Offer Response Block. The message flow is illustrated by the diagram below: *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+* Consumer | Merchant STEP | | 1. Consumer decides to trade and sends to the Merchant information (e.g., using HTML) that enables the Merchant to create an offer, C --> M Offer information - outside scope of IOTP 2. Merchant decides which payment brand protocols, currencies and amounts apply, places then in a Brand List Component inside a TPO Block, creates an Offer Response containing details about the IOTP Transaction including price, etc., optionally signs it and sends to Consumer 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. CONTINUED ... *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Figure 20 Brand Independent Offer Exchange
Top   ToC   RFC2801 - Page 199
   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.

   IOTP aware applications supporting the Consumer Trading Role must
   check for the existence of an Offer Response Block in the first IOTP
   Message to determine whether the Offer Document Exchange is brand
   dependent or not.

   MESSAGE PROCESSING GUIDELINES

   On receiving a TPO and Offer Response IOTP Message (see below), the
   Consumer may either:

   o  generate and send the next IOTP Message in the IOTP transaction
      and send it to the required Trading Role. This is dependent on the
      IOTP Transaction, or

   o  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.

   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.

9.1.2.3 TPO IOTP Message
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.
Top   ToC   RFC2801 - Page 200
   TPO (TRADING PROTOCOL OPTIONS) BLOCK

   The Trading Protocol Options Block (see section 8.1) must contain the
   following Trading Components:

   o  one Protocol Options Component which defines the options which
      apply to the whole IOTP Transaction. See Section 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  Organisation Components (see section 7.6) with the following
      roles:

      -  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

   If the IOTP Transaction includes a Delivery then the TPO Block must
   also contain:

   o  Organisation Components with the following roles:

      -  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:

   o  an Authentication Status Block (see section 8.6), and

   o  an optional Signature Block (Authentication Status) Signature
      Block

   See section 9.1.1.4 Authentication Status IOTP Message for more
   details.


(next page on part 7)

Next Section