tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2801

 
 
 

Internet Open Trading Protocol - IOTP Version 1.0

Part 2 of 9, p. 28 to 56
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 28 
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.

Top      Up      ToC       Page 29 
                       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

Top      Up      ToC       Page 30 
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;

Top      Up      ToC       Page 31 
      -  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

Top      Up      ToC       Page 32 
   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.

Top      Up      ToC       Page 33 
*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

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

Top      Up      ToC       Page 34 
   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

Top      Up      ToC       Page 35 
   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?,

Top      Up      ToC       Page 36 
        ( 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.

Top      Up      ToC       Page 37 
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.

Top      Up      ToC       Page 38 
   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.

Top      Up      ToC       Page 39 
                      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

Top      Up      ToC       Page 40 
                          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:

Top      Up      ToC       Page 41 
                          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.

Top      Up      ToC       Page 42 
   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.

Top      Up      ToC       Page 43 
   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:

Top      Up      ToC       Page 44 
                       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.

Top      Up      ToC       Page 45 
   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.

Top      Up      ToC       Page 46 
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 attributes

3.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,

Top      Up      ToC       Page 47 
   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.

Top      Up      ToC       Page 48 
   *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*

         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:

Top      Up      ToC       Page 49 
   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:

Top      Up      ToC       Page 50 
      -  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.

Top      Up      ToC       Page 51 
   <!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.

Top      Up      ToC       Page 52 
                       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 &amp; and
                         &#9;) 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

Top      Up      ToC       Page 53 
   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.

Top      Up      ToC       Page 54 
   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.

Top      Up      ToC       Page 55 
   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

Top      Up      ToC       Page 56 
   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)

Next RFC Part