tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2801


Internet Open Trading Protocol - IOTP Version 1.0

Part 8 of 9, p. 241 to 277
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 241 
9.2.2 Baseline Ping IOTP Transaction

   The purpose of the Baseline IOTP Ping Transaction is to test basic
   connectivity between the Trading Roles that may take part in an IOTP

   It enables IOTP aware application software to:

   o  determine if the IOTP aware application at another Trading Role is
      operating, and

   o  verify whether or not the two trading roles signatures can be

   For example it can be used by a Merchant to determine if a Payment
   Handler or Delivery Handler is up and running prior to starting a
   Purchase transaction that uses those trading roles.

   The Trading Blocks used by the Baseline Ping IOTP Transaction are:

   o a Ping Request Block (see section 8.14)

   o a Ping Response Block (see section 8.15), and

   o a Signature Block (see section 8.16).


   The following figure outlines the message flows in the Baseline IOTP
   Ping Transaction.

Top      Up      ToC       Page 242 
    1st Role
     |  2nd Role
STEP |     |
 1.          The IOTP Aware Application in the first Trading Role
             decides to check whether the counterparty IOTP
             application is up and running. It generates a Ping
             Request Block and optional Signature Block and sends them
             to the second trading role.

     1 --> 2 PING REQUEST. IotpMsg: Trans Ref Block; Signature Block
             (Optional); Ping Request Block

 2.          The second Trading Role which receives the Ping Request
             Block generates a Ping Response Block and sends it back
             to the sender of the original Ping Request with a
             signature block if required.

     1 <-- 2 PING Response. IotpMsg: Trans Ref Block; Signature Block
             (Optional); Ping Response Block

 3.          The first Trading Role checks the Ping Response Block and
             takes appropriate action, if necessary


                      Figure 33 Baseline Ping Messages

   The verification that signatures can be handled is indicated by the
   sender of the Ping Request Block including:

   o  Organisation Components that identify itself and the intended
      recipient of the Ping Request Block, and

   o  a Signature Block that signs data in the Ping Request.

   In this way the receiver of the Ping Request:

   o  knows who is sending the Ping Request and can therefore verify the
      Signature on the Request, and

   o  knows who to generate a signature for on the Ping Response.

   Note that a Ping Request:

   o  does not affect any on-going transaction

Top      Up      ToC       Page 243 
   o  does NOT initiate an IOTP transaction, unlike other IOTP
      transaction messages such as TPO or Transaction Status Inquiry.

   All IOTP aware applications must return a Ping Response message to
   the sender of a Ping Request message when it is received.

   A Baseline IOTP Ping request can also contain an optional Signature
   Block. IOTP aware applications can, for example, use the Signature
   Block to check the recipient of a Ping Request can successfully
   process and check signatures it has received.

   For each Baseline Ping IOTP Transaction, each IOTP role shall
   establish a different transport session from other IOTP transactions.

   Any IOTP Trading Role can send a Ping request to any other IOTP
   Trading Role at any time it wants. A Ping message has its own
   IotpTransId, which is different from other IOTP transactions.

   The remainder of this sub-section on the Baseline Ping IOTP
   Transaction defines the contents of each Trading Block.


   The IotpTransId of a Ping transaction should be different from any
   other IOTP transaction.


   If the Ping Transaction is anonymous then no Organisation Components
   are included in the Ping Request Block (see section 8.7).

   If the Ping Transaction is not anonymous then the Ping Request Block
   contains Organisation Components for:

   o  the sender of the Ping Request Block, and

   o  the verifier of the Signature Component

   If Organisation Components are present, then it indicates that the
   sender of the Ping Request message has generated a Signature Block.
   The signature block must be verified by the Trading Role that
   receives the Ping Request Block.


   The Ping Request Signature Block (see section 8.16) contains the
   following components:

Top      Up      ToC       Page 244 
   o  one Signature Component (see section 7.19)

   o  one or more Certificate Components, if required.


   The Ping Response Block (see section 8.15) contains the following

   o  the Organisation Component of the sender of the Ping Response

   If the Ping Transaction is not anonymous then the Ping Response
   additionally contains:

   o  copies of the Organisation Components contained in the Ping
      Request Block.


   The Ping Response Signature Block (see section 8.16) contains the
   following components:

   o  one Signature Component (see section 7.19)

   o  one or more Certificate Components, if required.

10. Retrieving Logos

   This section describes how to retrieve logos for display by IOTP
   aware software using the Logo Net Locations attribute contained in
   the Brand Element (see section 7.7.1) and the Organisation Component
   (see section 7.6).

   The full address of a logo is defined as follows:  Logo_address ::=
   Logo_net_location "/" Logo_size Logo_color_depth ".gif"


   o  Logo_net_location is obtained from the LogoNetLocn attribute in
      the Brand Element (see section 7.7.1) or the Organisation
      Component. Note that:

      -  the content of this attribute is dependent on the Transport
         Mechanism (such as HTTP) that is used. See the Transport
         Mechanism supplement,

Top      Up      ToC       Page 245 
      -  implementers should check that if the rightmost character of
         Logo Net Location is set to right-slash "/" then another, right
         slash should not be included when generating the Logo Address,

   o  Logo_size identifies the size of the logo,

   o  Logo_color_depth identifies the colour depth of the logo

   o  "gif" indicates that the logos are in "gif" format

   Logo_size and Logo_color_depth are specified by the implementer of
   the IOTP software that is retrieving the logo depending on the size
   and colour that they want to use.

10.1 Logo Size

   There are five standard sizes for logos. The sizes in pixels and the
   corresponding values for Logo Size are given in the table below.

           Size in     Logo Size
           Pixels        Value

        32 x 32 or   exsmall
        32 x 20

        53 x 33      small

        103 x 65     medium

        180 x 114    large

        263 x 166    exlarge

10.2 Logo Color Depth

   There are three standard colour depths. The colour depth (including
   bits per pixel) and the corresponding value for Logo_Color_Depth are
   given in the table below.

                Color Depth          Logo Color
             (bits per pixel)        Depth Value

         4 (16 colors)            4

         8 (256 colors)           nothing

         24 (16 million colors)   24

Top      Up      ToC       Page 246 
   Note that if Logo Color Depth is omitted then a logo with the default
   colour depth of 256 colours will be retrieved.

10.3 Logo Net Location Examples

   If Logo Net Location was set to "", then:

   o  "" would retrieve a medium size
      256 colour logo

   o  "" would retrieve a small size 16
      colour logo

   Note: Organisations which make logos available for use with IOTP
   should always make available "small" and "medium" size logos and use
   the "gif" format.

11. Brands

   This section contains:

   o  a definition of Brands and an outline of Brand Selection using
      Brand Lists, and

   o  some XML examples of Brand Lists

11.1 Brand Definitions and Brand Selection

   One of the key features of IOTP is the ability for a merchant to
   offer a list of Brands from which a consumer may make a selection.
   This section provides an overview of what is involved and provides
   guidance on how selection of a brand and associated payment
   instrument can be carried out by a Consumer. It covers:

   o  definitions of Payment Instruments and Brands - what are Payment
      Instruments and Brands in an IOTP context. Further categorises
      Brands as optionally a "Dual Brand" or a "Promotional Brand",

   o  identification and selection of Promotional Brands - Promotional
      Brands offer a Consumer some additional benefit, for example
      loyalty points or a discount. This means that both Consumers and
      Merchant must be able to correctly identify that a valid
      Promotional Brand is being used.

   Also see the following sections:

Top      Up      ToC       Page 247 
   o  Brand List Component (section 7.7) which contains definitions of
      the XML elements which contain the list of Brands offered by a
      Merchant to a Consumer, and

   o  Brand Selection Component (section 7.8) for details of how a
      Consumer records the Brand, currency, amount and payment protocol
      that was selected.

11.1.1 Definition of Payment Instrument

   A Payment Instrument is the means by which a Consumer pays for goods
   or services offered by a Merchant. It can be, for example:

   o  a credit card such as MasterCard or Visa;

   o  a debit card such as MasterCard's Maestro;

   o  a smart card based electronic cash payment instrument such as a
      Mondex Card, a GeldKarte card or a Visa Cash card

   o  a software based electronic payment account such as a CyberCash or
      DigiCash account.

   Most Payment Instruments have a number, typically an account number,
   by which the Payment Instrument can be identified.

11.1.2 Definition of Brand

   A Brand is the mark which identifies a particular type of Payment
   Instrument. A list of Brands are the payment options which are
   presented by the Merchant to the Consumer and from which the Consumer
   makes a selection. Each Brand may have a different Payment Handler.
   Examples of Brands include:

   o  payment association and proprietary Brands, for example
      MasterCard, Visa, American Express, Diners Club, Mondex,
      GeldKarte, CyberCash, etc.

   o  promotional brands (see below). These include:

      -  store brands, where the Payment Instrument is issued to a
         Consumer by a particular Merchant, for example Walmart, Sears,
         or Marks and Spencer (UK)

      -  cobrands, for example American Advantage Visa, where an
         Organisation uses their own brand in conjunction with,
         typically, a payment association Brand.

Top      Up      ToC       Page 248 
11.1.3 Definition of Dual Brand

   A Dual Brand means that a single payment instrument may be used as if
   it were two separate Brands. For example there could be a single
   Japanese "UC" MasterCard which can be used as either a UC card or a
   regular MasterCard. The UC card Brand and the MasterCard Brand could
   each have their own separate Payment Handlers. This means that:

   o  the merchant treats, for example "UC" and "MasterCard" as two
      separate Brands when offering a list of Brands to the Consumer,

   o  the consumer chooses a Brand, for example either "UC" or

   o  the consumer IOTP aware application determines which Payment
      Instrument(s) match the chosen Brand, and selects, perhaps with
      user assistance, the correct Payment Instrument to use.

   Note: Dual Brands need no special treatment by the Merchant and
   therefore no explicit reference is made to Dual Brands in the DTD.
   This is because, as far as the Merchant is concerned, each Brand in a
   Dual Brand is treated as a separate Brand. It is at the Consumer,
   that the matching of a Brand to a Dual Brand Payment Instrument needs
   to be done.

11.1.4 Definition of Promotional Brand

   A Promotional Brand means that, if the Consumer pays with that Brand,
   then the Consumer will receive some additional benefit which can be
   received in two ways:

   o  at the time of purchase. For example if a Consumer pays with a
      "Walmart MasterCard" at a Walmart web site, then a 5% discount
      might apply, which means the consumer actually pays less,

   o  from their Payment Instrument (card) issuer when the payment
      appears on their statement. For example loyalty points in a
      frequent flyer scheme could be awarded based on the total payments
      made with the Payment Instrument since the last statement was

   Note that:

   o  the first example (obtaining the benefit at the time of purchase),
      requires that:

      -  the Consumer is informed of the benefits which arise if that
         Brand is selected

Top      Up      ToC       Page 249 
      -  if the Brand is selected, the Merchant changes the relevant
         IOTP Components in the Offer Response to reflect the correct
         amount to be paid

   o  the second (obtaining a benefit through the Payment Instrument
      issuer) does not require that the Offer Response is changed

   o  each Promotional Brand should be identified as a separate Brand in
      the list of Brands offered by the Merchant. For example:
      "Walmart", "Sears", "Marks and Spencer" and "American Advantage
      Visa", would each be a separate Brand.

11.1.5 Identifying Promotional Brands

   There are two problems which need to handled in identifying
   Promotional Brands:

   o  how does the Merchant or their Payment Handler positively identify
      the promotional brand being used at the time of purchase

   o  how does the Consumer reliably identify the correct promotional
      brand from the Brand List presented by the Merchant

   The following is a description of how this could be achieved.

   Note: Please note that the approach described here is a model
   approach that solves the problem. Other equivalent methods may be
   used. Merchant/Payment Handler Identification of Promotional Brands

   Correct identification that the Consumer is paying using a
   Promotional Brand is important since a Consumer might fraudulently
   claim to have a Promotional Brand that offers a reduced payment
   amount when in reality they do not.

   Two approaches seem possible:

   o  use some feature of the Payment Instrument or the payment method
      to positively identify the Brand being used. For example, the SET
      certificate for the Brand could be used, if one is available, or

   o  use the Payment Instrument (card) number to look up information
      about the Payment Instrument on a Payment Instrument issuer
      database to determine if the Payment Instrument is a promotional

Top      Up      ToC       Page 250 
   Note that:

   o  the first assumes that SET is available.

   o  the second is only possible if the Merchant, or alternatively the
      Payment Handler, has access to card issuer information.

   IOTP does not provide the Merchant with Payment Instrument
   information (e.g., a card or account number). This is only sent as
   part of the encapsulated payment protocol to a Payment Handler. This
   means that:

   o  the Merchant would have to assume that the Payment Instrument
      selected was a valid Promotional Brand, or

   o  the Payment Handler would have to check that the Payment
      Instrument was for the valid Promotional Brand and fail the
      payment if it was not.

   A Payment Handler checking that a brand is a valid Promotional Brand
   is most likely if the Payment Handler is also the Card Issuer. Consumer Selection of Promotional Brands

   Two ways by which a Consumer can correctly select a Promotional Brand

   o  the Consumer visually matching a logo for the Promotional Brand
      which has been provided to the Consumer by the Merchant,

   o  the Consumer's IOTP aware application matching a code for the
      Promotional Brand which the application has registered against a
      similar code contained in the list of Brands offered by the

   In the latter case, the code contained in the Consumer wallet must
   match exactly the code in the list offered by the Merchant otherwise
   no match will be found. Ways in which the Consumer's IOTP Aware
   Application could obtain such a code include:

   o  the Consumer types the code in directly. This is error prone and
      not user friendly, also the consumer needs to be provided with the
      code.  This approach is not recommended,

   o  using one of the Brand Identifiers defined by IOTP and pre-loaded
      into the Consumers IOTP Aware application or wallet by the
      developer of the Wallet,

Top      Up      ToC       Page 251 
   o  using some information contained in the software or other data
      associated with the Payment Instrument. This could be:

      -  a SET certificate for Brands which use this payment method

      -  a code provided by the payment software which handles the
         particular payment method, this could apply to, for example,
         GeldKarte, Mondex, CyberCash and DigiCash,

   o  the consumer making an initial "manual" link between a Promotional
      Brand in the list of Brands offered by the Merchant and an
      individual Payment Instrument, the first time the promotional
      brand is used. The IOTP Aware application would then "remember"
      the code for the Promotional Brand for use in future purchases. Consumer Software Brand Id recommendation

   New Brand Ids are allocated under IANA procedures (see section 12
   IANA Considerations). Which also contains an initial list of Brand

   It is recommended that implementers of consumer IOTP aware
   applications (e.g., software wallets) pre-load their software with
   the then current set of Brand Ids and provide a method by which they
   can be updated. For example, by going to the software developer's web

11.2 Brand List Examples

   This example contains three examples of the XML for a Brand List
   Component. It covers:

   o  a simple credit card based example

   o  a credit card based brand list including promotional credit card
      brands, and

   o  a complex electronic cash based brand list

   Note that:

   o  brand lists can be as complex or as simple as required

   o  all example techniques described in this appendix can be included
      in one brand list.

Top      Up      ToC       Page 252 
11.2.1 Simple Credit Card Based Example

   This is a simple example involving:

   o  only major credit card payment brands

   o  a single price in a single currency

   o  a single Payment Handler, and

   o  a single payment protocol

   <BrandList ID='M1.2'
     ShortDesc='Purchase book including s&h'
     PayDirection='Debit' >
     <Brand ID ='M1.30'
       BrandName='MasterCard Credit'
     <Brand ID ='M.31'
       BrandName='Visa Credit'
     <Brand ID ='M1.32'
       BrandName='American Express'
       ProtocolAmountRefs ='M1.33' >
     </Brand >
     <ProtocolAmount ID ='M1.33'
     <CurrencyAmount ID ='M1.34'
     <PayProtocol ID ='M1.35'
       ProtocolName='Secure Channel Credit/Debit'
       PayReqNetLocn='' >

Top      Up      ToC       Page 253 
11.2.2 Credit Card Brand List Including Promotional Brands

   An example of a Credit Card based Brand List follows. It includes:

   o  two ordinary card association brands and two promotional credit
      card brands. The promotional brands consist of one loyalty based
      (British Airways MasterCard) which offers additional loyalty
      points and one store based (Walmart) which offers a discount on
      purchases over a certain amount

   o  two payment protocols:

      -  SET (Secure Electronic Transactions) see [SET], and

      -  SCCD (Secure Channel Credit Debit) see [SCCD].

 <BrandList ID='M1.2'
   ShortDesc='Purchase ladies coat'
   PayDirection='Debit' >
   <Brand ID ='M1.3'
     BrandName='MasterCard Credit'
     ProtocolAmountRefs='M1.7 M1.8'>
     <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:'>
   <Brand ID ='M1.4'
     BrandName='Visa Credit'
     ProtocolAmountRefs='M1.7 M1.8'>
     <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='Visa:'>
   <Brand ID ='M1.5'
     BrandName='British Airways MasterCard'
     BrandNarrative='Double air miles with British Airways MasterCard'
     ProtocolAmountRefs ='M1.7 M1.8' >
     <ProtocolBrand ProtocolId='SET1.0' ProtocolBrandId='MasterCard:BA'>
   </Brand >
   <Brand ID ='M1.6'
     BrandName='Walmart Store Card'

Top      Up      ToC       Page 254 

     BrandNarrative='5% off with your Walmart Card
                   on purchases over $150'
   <ProtocolAmount ID ='M1.7'
     CurrencyAmountRefs='M1.9' >
     <PackagedContent Transform="BASE64">
   <ProtocolAmount ID ='M1.8'
     CurrencyAmountRefs='M1.9' >
     <PackagedContent Transform="BASE64">
   <CurrencyAmount ID ='M1.9'
   <PayProtocol ID ='M1.10'
     ProtocolName='Secure Electronic Transaction Version 1.0'
     PayReqNetLocn='' >
     <PackagedContent Transform="BASE64">
   <PayProtocol ID ='M1.11'
     ProtocolName='Secure Channel Credit/Debit'
     PayReqNetLocn='' >
     <PackagedContent Transform="BASE64">

11.2.3 Brand Selection Example

   In order to pay by 'British Airways' MasterCard using the example
   above using SET and therefore getting double air miles, the Brand
   Selection would be:

   <BrandSelection ID='C1.2'

Top      Up      ToC       Page 255 
     CurrencyAmountRef='M1.9' >

11.2.4 Complex Electronic Cash Based Brand List

   The following is an fairly complex example which includes:

   o  payments using either Mondex, GeldKarte, CyberCash or DigiCash

   o  in currencies including US dollars, British Pounds, Italian Lira,
      German Marks and Canadian Dollars

   o  a discount on the price if the payment is made in Mondex using
      British pounds or US dollars, and

   o  more than one Payment Handler is used for payments involving
      Mondex or CyberCash

   o  support for more than one version of a CyberCash CyberCoin payment

   <BrandList ID='M1.2'
     ShortDesc='Company report on XYZ Co'
     PayDirection='Debit' >
     <Brand ID ='M1.13'
       BrandName='Mondex Electronic Cash'
       ProtocolAmountRefs='M1.17 M1.18'>
     <Brand ID ='M1.14'
       BrandName='GeldKarte Electronic Cash'
     <Brand ID ='M1.15'
       BrandName='CyberCoin Eletronic Cash'
       ProtocolAmountRefs ='M1.20' >
     </Brand >
     <Brand ID ='M1.16'

Top      Up      ToC       Page 256 
       BrandName='DigiCash Electronic Cash'
       BrandNarrative='5% off with your Walmart Card
                     on purchases over $150'
     <ProtocolAmount ID ='M1.17'
       CurrencyAmountRefs='M1.25 M1.29'>
     <ProtocolAmount ID ='M1.18'
       CurrencyAmountRefs='M1.26 M1.27 M1.28 M1.30'>
     <ProtocolAmount ID ='M1.19'
     <ProtocolAmount ID ='M1.20'
       PayProtocolRef='M1.34 M1.33'
       CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
     <ProtocolAmount ID ='M1.21'
       CurrencyAmountRefs='M1.23 M1.24 M1.27 M1.28 M1.29 M1.30'>
     <CurrencyAmount ID ='M1.23'
     <CurrencyAmount ID ='M1.24'
     <CurrencyAmount ID ='M1.25'
     <CurrencyAmount ID ='M1.26'
     <CurrencyAmount ID ='M1.27'
     <CurrencyAmount ID ='M1.28'
     <CurrencyAmount ID ='M1.29'
     <CurrencyAmount ID ='M1.30'

Top      Up      ToC       Page 257 
     <PayProtocol ID ='M1.31'
       ProtocolName='Mondex IOTP Protocol Version 1.0'
       PayReqNetLocn='' >
     <PayProtocol ID ='M1.32'
       ProtocolName='Mondex IOTP Protocol Version 1.0'
       PayReqNetLocn='' >
     <PayProtocol ID ='M1.33'
       ProtocolName='CyberCoin Version 1.0'
       PayReqNetLocn='' >
     <PayProtocol ID ='M1.34'
       ProtocolName='CyberCoin Version 2.0'
       PayReqNetLocn='' >
     <PayProtocol ID ='M1.35'
       ProtocolName='GeldKarte Version 1.0'
       PayReqNetLocn='' >
     <PayProtocol ID ='M1.36'
       ProtocolName='DigiCash Protocol Version 1.0'
       PayReqNetLocn='' >

12. IANA Considerations

   This section describes the codes that are controlled by IANA, and
   also how new codes can be created for testing purposes that are not
   controlled by IANA.

12.1 Codes Controlled by IANA

   To help ensure interoperability, there is a need for codes used by
   IOTP to be maintained in a controlled environment so that their
   meaning and usage are well defined and duplicate codes avoided.
   [IANA] is the mechanism to be used for this purpose as described in
   RFC 2434.

Top      Up      ToC       Page 258 
   The element types and attributes names to which this procedure
   applies is shown in the table below together with the initial values
   that are valid for these attributes.

   Note that:

   o  the IETF Trade mailing list's email address is ietf-

   o  "Designated Experts" (see [IANA]) are appointed by the IESG.

     Element Type/                     Attribute Values
     Attribute Name

   Algorithm/         "sha1" - indicates that a [SHA1] authentication
   Name               will apply
   (When Algorithm
   is a child of an   "signature" - indicates that authentication
   AuthReq            consists of the generation of a digital signature.
                      "Pay:ppp" where "ppp" may be set to any valid
                      value for "iotpbrand" (see below)

                      With the exception of Algorithms that begin with
                      "pay:", new values are allocated following review
                      on the IETF Trade mailing list and by the
                      Designated Expert.

   Note:     The Algorithm element is likely to be eventually defined
   within the [DSIG] name space. It is likely that the maintenance
   procedure defined here may need to vary over time, as the DSIG
   proposals become more widely adopted.

     Element Type/                     Attribute Values
     Attribute Name

   Brand/BrandId      The following list of initial BrandIds have been
                      taken from those Organisations that have applied
                      for SET certificates as at 1st June 1999:

                      "Amex" - American Express

                      "Dankort" - Dankort

                      "JCB" - JCB

                      "Maestro" - Maestro

Top      Up      ToC       Page 259 
                      "MasterCard" - MasterCard

                      "NICOS" - NICOS

                      "VISA" - Visa

                      In addition the following Brand Id values are



                      New values of BrandId must be announced to the
                      IETF Trade mailing list and, if there are no
                      objections within three weeks, are allocated on a
                      "first come first served" basis.

   CurrencyAmount/    Currency codes are dependent on CurrCodeType (see
   CurrCode           below).

                      If CurrCodeType is "ISO4217-A" then the currency
                      code is an alphabetic currency code as defined by

                      If CurrCodeType is "IOTP" then new values must be
                      announced to the IETF Trade mailing list and, if
                      there are no objections within three weeks, are
                      allocated on a "first come first served" basis.

   Note:     The Currency Code Type of IOTP, is designed to allow the
   support of "new" psuedo currencies such as loyalty or frequent flyer
   points. At the time of writing this specification, no currency codes
   of this type have been defined.

     Element Type/                     Attribute Values
     Attribute Name

   CurrencyAmount/    "ISO4217-A"

                      New values of CurrCodeType attribute are allocated
                      following review on the IETF Trade mailing list
                      and by the Designated Expert.

   DeliveryData/      "Post"

Top      Up      ToC       Page 260 


                      New values of Delivery Method attribute are
                      allocated following review on the IETF Trade
                      mailing list and by the Designated Expert. This
                      may require the publication of additional
                      documentation to describe how the delivery method
                      is used.

   PackagedContent/   "PCDATA"

                      "MIME:mimetype" (where mimetype must be the same
                      as content-type as defined by [MIME] )


                      If the Content attribute is of the form
                      "MIME"mimetype", then control of new values for
                      "mimetype" is as defined in [MIME].

                      Otherwise, new values of the Content attribute are
                      allocated following review on the IETF Trade
                      mailing list and by the Designated Expert. This
                      may require the publication of additional
                      documentation to describe how the new attribute is
                      used within a Packaged Content element.

   RelatedTo/         "IotpTransaction"

                      New values of the RelationshipType attribute are
                      allocated following review on the IETF Trade
                      Working Group mailing list and by the Designated
                      Expert. This may require the publication of
                      additional documentation to describe how the

     Element Type/                     Attribute Values
     Attribute Name
                      delivery method is used.

   Status/            Offer

Top      Up      ToC       Page 261 



                      New values of the Status Type attribute are
                      allocated following:
                       o publication to the IETF Trade Working Group,
                         of an RFC describing the Trading Exchange,
                         Trading Roles and associated components that
                         relate to the Status, and
                       o review of the document on the IETF Trade
                         mailing list and by the Designated Expert.

   Note: The document describing new values for the Status Type
   attribute may be combined with documents that describe new Trading
   Roles and types of signatures (see below).

   TradingRole/       "Consumer"





                      New values of the Trading Role attribute are
                      allocated following:
                       o publication to the IETF Trade Working Group,
                         of an RFC describing the Trading Exchange,
                         Trading Roles and associated components that
                         relate to the Trading Role, and
                       o review of the document on the IETF Trade
                         mailing list and by the Designated Expert.

   Note: The document describing new values for the Trading Role
   attribute may be

     Element Type/                     Attribute Values
     Attribute Name
                                   combined with documents that describe
                                   new Status Types (see above) and
                                   types of signatures (see below).

Top      Up      ToC       Page 262 
   TransId/           "BaselineAuthentication"







                      New values of the IotpTransType attribute are
                      allocated following:
                       o publication to the IETF Trade mailing list, of
                         an RFC describing the new IOTP Transaction, and
                       o review of the document on the IETF Trade
                         Working Group mailing list and by the
                         Designated Expert.

   Attribute/ Content
   (see Signature
   Component)         "PaymentResponse"






                      New values of the code that define the type of a
                      signature are allocated following:
                       o publication to the IETF Trade Working Group,
                         of an RFC describing the Trading Exchange where
                         the signature is being used, and
                       o review of the document on the IETF Trade
                         mailing list and by the Designated Expert.

Top      Up      ToC       Page 263 
     Element Type/                     Attribute Values
     Attribute Name

   Note: The document describing new values for the types of signatures
   may be combined with documents that describe new Status Types and
   Trading Roles (see above).

12.2 Codes not controlled by IANA

   In addition to the formal development and registration of codes as
   described above, there is still a need for developers to experiment
   using new IOTP codes. For this reason, "user defined codes" may be
   used to identify additional values for the codes contained within
   this specification without the need for them to be registered with

   The definition of a user defined code is as follows:

   user_defined_code ::= ( "x-" | "X-" ) NameChar (NameChar)*

     NameChar           NameChar has the same definition as the [XML]
                        definition of NameChar

   Use of domain names (see [DNS]) to make user defined codes unique is
   recommended although this method cannot be relied upon.

13. Internet Open Trading Protocol Data Type Definition

   This section contains the XML DTD for the Internet Open Trading

Top      Up      ToC       Page 264 
   *                                                    *
   * Filename:                 *
   *                                                    *
   * Changes from version 07 (iotp-v1.0-protocol-07.dtd)*
   *   - NO CHANGES                                     *
   *                                                    *
   *                                                    *
   *                                                    *
   *                                                    *
   * Copyright Internet Engineering Task Force 1998-2000*
   *                                                    *

   * IOTP MESSAGE DEFINITION                            *

   <!ELEMENT IotpMessage
      ( TransRefBlk,
        ( AuthReqBlk |
          AuthRespBlk |
          AuthStatusBlk |
          CancelBlk |
          DeliveryReqBlk |
          DeliveryRespBlk |
          InquiryReqBlk |
          InquiryRespBlk |
          OfferRespBlk |
          PayExchBlk |
          PayReqBlk |
          PayRespBlk |
          PingReqBlk |
          PingRespBlk |
          TpoBlk |
      ) >
   <!ATTLIST IotpMessage
     xmlns              CDATA
      '' >

Top      Up      ToC       Page 265 

   <!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) >
   <!ATTLIST TransRefBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT TransId EMPTY >
   <!ATTLIST TransId
    ID                 ID      #REQUIRED
    Version            NMTOKEN #FIXED '1.0'
    IotpTransId        CDATA   #REQUIRED
    IotpTransType      CDATA   #REQUIRED
    TransTimeStamp     CDATA   #REQUIRED >

   <!ATTLIST MsgId
    ID                 ID      #REQUIRED
    RespIotpMsg        NMTOKEN #IMPLIED
    xml:lang           NMTOKEN #REQUIRED
    LangPrefList       NMTOKENS #IMPLIED
    CharSetPrefList    NMTOKENS #IMPLIED
    SenderTradingRoleRef NMTOKEN #IMPLIED
    SoftwareId         CDATA   #REQUIRED
    TimeStamp          CDATA   #IMPLIED >

   <!ELEMENT RelatedTo (PackagedContent) >
   <!ATTLIST RelatedTo
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #REQUIRED
    RelationshipType   NMTOKEN #REQUIRED
    Relation           CDATA   #REQUIRED
    RelnKeyWords       NMTOKENS #IMPLIED >

   * Packaged Content Common Element                    *

Top      Up      ToC       Page 266 
   <!ELEMENT PackagedContent (#PCDATA) >
   <!ATTLIST PackagedContent
    Name             CDATA     #IMPLIED
    Content          NMTOKEN   "PCDATA"
    Transform (NONE|BASE64)    "NONE" >

   * TRADING COMPONENTS                                 *
   <!ELEMENT ProtocolOptions EMPTY >
   <!ATTLIST ProtocolOptions
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #REQUIRED
    ShortDesc          CDATA   #REQUIRED
    SenderNetLocn      CDATA   #IMPLIED
    SecureSenderNetLocn CDATA  #IMPLIED
    SuccessNetLocn     CDATA   #REQUIRED >

   <!ELEMENT AuthReq (Algorithm, PackagedContent*)>
   <!ATTLIST AuthReq
    ID                 ID      #REQUIRED
    AuthenticationId   CDATA   #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT AuthResp (PackagedContent*) >
   <!ATTLIST AuthResp
    ID                 ID      #REQUIRED
    AuthenticationId   CDATA   #REQUIRED
    SelectedAlgorithmRef NMTOKEN #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT TradingRoleInfoReq EMPTY>
   <!ATTLIST TradingRoleInfoReq
    ID                 ID      #REQUIRED
    TradingRoleList    NMTOKENS #REQUIRED >

   <!ELEMENT Order (PackagedContent*) >
   <!ATTLIST Order
    ID                 ID      #REQUIRED

Top      Up      ToC       Page 267 
    xml:lang           NMTOKEN #REQUIRED
    OrderIdentifier    CDATA   #REQUIRED
    ShortDesc          CDATA   #REQUIRED
    OkFrom             CDATA   #REQUIRED
    OkTo               CDATA   #REQUIRED
    ApplicableLaw      CDATA   #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT Org (TradingRole+, ContactInfo?,
        PersonName?, PostalAddress?)>
   <!ATTLIST Org
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #REQUIRED
    OrgId              CDATA   #REQUIRED
    LegalName          CDATA   #IMPLIED
    ShortDesc          CDATA   #IMPLIED
    LogoNetLocn        CDATA   #IMPLIED >

   <!ELEMENT TradingRole EMPTY >
   <!ATTLIST TradingRole
    TradingRole        NMTOKEN #REQUIRED
    IotpMsgIdPrefix    NMTOKEN #REQUIRED
    CancelNetLocn      CDATA   #IMPLIED
    ErrorNetLocn       CDATA   #IMPLIED
    ErrorLogNetLocn  CDATA           #IMPLIED >

   <!ELEMENT ContactInfo EMPTY >
   <!ATTLIST ContactInfo
    xml:lang           NMTOKEN #IMPLIED
    Tel                CDATA   #IMPLIED
    Fax                CDATA   #IMPLIED
    Email              CDATA   #IMPLIED
    NetLocn            CDATA   #IMPLIED >

   <!ELEMENT PersonName EMPTY >
   <!ATTLIST PersonName
    xml:lang           NMTOKEN #IMPLIED
    Title              CDATA   #IMPLIED
    GivenName          CDATA   #IMPLIED
    Initials           CDATA   #IMPLIED
    FamilyName         CDATA   #IMPLIED >

Top      Up      ToC       Page 268 
   <!ELEMENT PostalAddress EMPTY >
   <!ATTLIST PostalAddress
    xml:lang           NMTOKEN #IMPLIED
    AddressLine1       CDATA   #IMPLIED
    AddressLine2       CDATA   #IMPLIED
    CityOrTown         CDATA   #IMPLIED
    StateOrRegion      CDATA   #IMPLIED
    PostalCode         CDATA   #IMPLIED
    Country            CDATA   #IMPLIED
    LegalLocation (True | False) 'False' >

   <!ELEMENT BrandList (Brand+, ProtocolAmount+,
    CurrencyAmount+, PayProtocol+) >
   <!ATTLIST BrandList
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #REQUIRED
    ShortDesc          CDATA   #REQUIRED
    PayDirection (Debit | Credit) #REQUIRED >

   <!ELEMENT Brand (ProtocolBrand*, PackagedContent*) >
   <!ATTLIST Brand
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #IMPLIED
    BrandId            CDATA   #REQUIRED
    BrandName          CDATA   #REQUIRED
    BrandLogoNetLocn   CDATA   #REQUIRED
    BrandNarrative     CDATA   #IMPLIED
    ProtocolAmountRefs IDREFS  #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT ProtocolBrand (PackagedContent*) >
   <!ATTLIST ProtocolBrand
    ProtocolId         CDATA   #REQUIRED
    ProtocolBrandId    CDATA   #REQUIRED >

   <!ELEMENT ProtocolAmount (PackagedContent*) >
   <!ATTLIST ProtocolAmount
    ID                 ID      #REQUIRED
    PayProtocolRef     IDREF   #REQUIRED
    CurrencyAmountRefs IDREFS  #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT CurrencyAmount EMPTY >
   <!ATTLIST CurrencyAmount
    ID                 ID      #REQUIRED
    Amount             CDATA   #REQUIRED

Top      Up      ToC       Page 269 
    CurrCodeType       NMTOKEN 'ISO4217-A'
    CurrCode           CDATA   #REQUIRED >

   <!ELEMENT PayProtocol (PackagedContent*) >
   <!ATTLIST PayProtocol
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #IMPLIED
    ProtocolId         NMTOKEN #REQUIRED
    ProtocolName       CDATA   #REQUIRED
    ActionOrgRef       NMTOKEN #REQUIRED
    PayReqNetLocn      CDATA   #IMPLIED
    SecPayReqNetLocn   CDATA   #IMPLIED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT BrandSelection (BrandSelBrandInfo?,
        BrandSelCurrencyAmountInfo?) >
   <!ATTLIST BrandSelection
    ID                 ID      #REQUIRED
    BrandListRef       NMTOKEN #REQUIRED
    BrandRef           NMTOKEN #REQUIRED
    ProtocolAmountRef  NMTOKEN #REQUIRED
    CurrencyAmountRef  NMTOKEN #REQUIRED >

   <!ELEMENT BrandSelBrandInfo (PackagedContent+) >
   <!ATTLIST BrandSelBrandInfo
    ID                 ID      #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT BrandSelProtocolAmountInfo (PackagedContent+) >
   <!ATTLIST BrandSelProtocolAmountInfo
    ID                 ID      #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT BrandSelCurrencyAmountInfo (PackagedContent+) >
   <!ATTLIST BrandSelCurrencyAmountInfo
    ID                 ID      #REQUIRED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT Payment EMPTY >
   <!ATTLIST Payment
    ID                 ID      #REQUIRED
    OkFrom             CDATA   #REQUIRED
    OkTo               CDATA   #REQUIRED
    BrandListRef       NMTOKEN #REQUIRED

Top      Up      ToC       Page 270 
    SignedPayReceipt (True | False) #REQUIRED
    StartAfterRefs     NMTOKENS #IMPLIED >

   <!ELEMENT PaySchemeData (PackagedContent+) >
   <!ATTLIST PaySchemeData
    ID                 ID      #REQUIRED
    PaymentRef         NMTOKEN #IMPLIED
    ConsumerPaymentId  CDATA   #IMPLIED
    PaymentHandlerPayId CDATA  #IMPLIED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT PayReceipt (PackagedContent*) >
   <!ATTLIST PayReceipt
    ID                 ID      #REQUIRED
    PaymentRef         NMTOKEN #REQUIRED
    PayReceiptNameRefs NMTOKENS #IMPLIED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT PaymentNote (PackagedContent+) >
   <!ATTLIST PaymentNote
     ID                ID      #REQUIRED
     ContentSoftwareId CDATA   #IMPLIED >

   <!ELEMENT Delivery (DeliveryData?, PackagedContent*) >
   <!ATTLIST Delivery
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #REQUIRED
    DelivExch          (True | False) #REQUIRED
    DelivAndPayResp    (True | False) #REQUIRED
    ActionOrgRef       NMTOKEN #IMPLIED >

   <!ELEMENT DeliveryData (PackagedContent*) >
   <!ATTLIST DeliveryData
    xml:lang           NMTOKEN #IMPLIED
    OkFrom             CDATA   #REQUIRED
    OkTo               CDATA   #REQUIRED
    DelivMethod        NMTOKEN #REQUIRED
    DelivToRef         NMTOKEN #REQUIRED
    DelivReqNetLocn    CDATA   #IMPLIED
    SecDelivReqNetLocn CDATA   #IMPLIED

Top      Up      ToC       Page 271 
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT ConsumerDeliveryData EMPTY >
   <!ATTLIST ConsumerDeliveryData
    ID                 ID      #REQUIRED
    ConsumerDeliveryId CDATA   #REQUIRED >

   <!ELEMENT DeliveryNote (PackagedContent+) >
   <!ATTLIST DeliveryNote
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #REQUIRED
    DelivHandlerDelivId CDATA  #IMPLIED
    ContentSoftwareId  CDATA   #IMPLIED >

   <!ELEMENT Status EMPTY >
   <!ATTLIST Status
    ID                 ID      #REQUIRED
    xml:lang           NMTOKEN #REQUIRED
    StatusType         NMTOKEN #REQUIRED
    ElRef              NMTOKEN #IMPLIED
    ProcessState (NotYetStarted | InProgress |
        CompletedOk | Failed | ProcessError) #REQUIRED
    CompletionCode     NMTOKEN #IMPLIED
    ProcessReference   CDATA   #IMPLIED
    StatusDesc         CDATA   #IMPLIED >

   <!ELEMENT TradingRoleData (PackagedContent+) >
   <!ATTLIST TradingRoleData
     ID                ID      #REQUIRED
     OriginatorElRef   NMTOKEN #REQUIRED
     DestinationElRefs NMTOKENS #REQUIRED >

   <!ELEMENT InquiryType EMPTY >
   <!ATTLIST InquiryType
    ID                 ID      #REQUIRED
    Type               NMTOKEN #REQUIRED
    ElRef              NMTOKEN #IMPLIED
    ProcessReference   CDATA   #IMPLIED >

Top      Up      ToC       Page 272 
   <!ELEMENT ErrorComp (ErrorLocation+, PackagedContent*) >
   <!ATTLIST ErrorComp
    ID                 NMTOKEN #REQUIRED
    xml:lang           NMTOKEN #REQUIRED
    ErrorCode          NMTOKEN #REQUIRED
    ErrorDesc          CDATA   #REQUIRED
    Severity (Warning|TransientError|HardError) #REQUIRED
    MinRetrySecs       CDATA   #IMPLIED
    SwVendorErrorRef   CDATA   #IMPLIED >

   <!ELEMENT ErrorLocation EMPTY >
   <!ATTLIST ErrorLocation
    ElementType        NMTOKEN #REQUIRED
    IotpMsgRef         NMTOKEN #IMPLIED
    BlkRef             NMTOKEN #IMPLIED
    CompRef            NMTOKEN #IMPLIED
    ElementRef         NMTOKEN #IMPLIED
    AttName            NMTOKEN #IMPLIED >

   * TRADING BLOCKS                                     *

   <!ELEMENT TpoBlk ( ProtocolOptions, BrandList*, Org* ) >
   <!ATTLIST TpoBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT TpoSelectionBlk (BrandSelection+) >
   <!ATTLIST TpoSelectionBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT OfferRespBlk (Status, Order?, Payment*,
                Delivery?, TradingRoleData*) >
   <!ATTLIST OfferRespBlk
    ID                 ID      #REQUIRED >

Top      Up      ToC       Page 273 
   <!ELEMENT AuthReqBlk (AuthReq*, TradingRoleInfoReq?) >
   <!ATTLIST AuthReqBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT AuthRespBlk (AuthResp?, Org*) >
   <!ATTLIST AuthRespBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT AuthStatusBlk (Status) >
   <!ATTLIST AuthStatusBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT PayReqBlk (Status+, BrandList, BrandSelection,
        Payment, PaySchemeData?, Org*, TradingRoleData*) >
   <!ATTLIST PayReqBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT PayExchBlk (PaySchemeData) >
   <!ATTLIST PayExchBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT PayRespBlk (Status, PayReceipt?, PaySchemeData?,
        PaymentNote?, TradingRoleData*) >
   <!ATTLIST PayRespBlk
    ID                 ID      #REQUIRED >
   <!ELEMENT DeliveryReqBlk (Status+, Order, Org*, Delivery,
        ConsumerDeliveryData?, TradingRoleData*) >
   <!ATTLIST DeliveryReqBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT DeliveryRespBlk (Status, DeliveryNote) >
   <!ATTLIST DeliveryRespBlk
    ID                 ID      #REQUIRED >

Top      Up      ToC       Page 274 
   <!ELEMENT InquiryReqBlk ( InquiryType, PaySchemeData? ) >
   <!ATTLIST InquiryReqBlk
    ID                 ID      #REQUIRED >

   <!ELEMENT InquiryRespBlk (Status, PaySchemeData?) >
   <!ATTLIST InquiryRespBlk
    ID                 ID      #REQUIRED
    LastReceivedIotpMsgRef NMTOKEN #IMPLIED
    LastSentIotpMsgRef NMTOKEN #IMPLIED >

   <!ELEMENT PingReqBlk (Org*)>
   <!ATTLIST PingReqBlk
    ID                 ID      #REQUIRED>

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

   <!-- ERROR BLOCK -->
   <!ELEMENT ErrorBlk (ErrorComp+, PaySchemeData*) >
   <!ATTLIST ErrorBlk
    ID                 ID      #REQUIRED >

   <!-- CANCEL BLOCK -->
   <!ELEMENT CancelBlk (Status) >
   <!ATTLIST CancelBlk
    ID                 ID      #REQUIRED >


Top      Up      ToC       Page 275 
   <!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
   <!ATTLIST IotpSignatures
       ID        ID        #IMPLIED


   <!ELEMENT Signature (Manifest, Value+) >
   <!ATTLIST Signature
       ID         ID        #IMPLIED

   <!ELEMENT Manifest
       (       Algorithm+,

   <!ATTLIST Manifest
       LocatorHRefBase       CDATA             #IMPLIED

   <!ELEMENT Algorithm (Parameter*) >
   <!ATTLIST Algorithm
       ID                     ID                #REQUIRED
       type            (digest|signature)      #IMPLIED
       name                  NMTOKEN           #REQUIRED

   <!ELEMENT Digest (Locator, Value) >
   <!ATTLIST Digest
       DigestAlgorithmRef    IDREF             #REQUIRED

   <!ELEMENT Attribute ( ANY ) >
   <!ATTLIST Attribute
       type                   NMTOKEN           #REQUIRED
       critical            ( true | false )     #REQUIRED

   <!ELEMENT OriginatorInfo ANY >

Top      Up      ToC       Page 276 
   <!ATTLIST OriginatorInfo
       OriginatorRef           NMTOKEN          #IMPLIED

   <!ELEMENT RecipientInfo ANY >
   <!ATTLIST RecipientInfo
       SignatureAlgorithmRef   IDREF            #REQUIRED
       SignatureValueRef       IDREF            #IMPLIED
       SignatureCertRef        IDREF            #IMPLIED
       RecipientRefs           NMTOKENS         #IMPLIED

   <!ELEMENT KeyIdentifier EMPTY>
   <!ATTLIST KeyIdentifier
       value                    CDATA           #REQUIRED

   <!ELEMENT Parameter ANY >
   <!ATTLIST Parameter
       type                     CDATA           #REQUIRED


   <!ELEMENT Certificate
    (  IssuerAndSerialNumber,  ( Value | Locator ) )

   <!ATTLIST Certificate
       ID                        ID                #IMPLIED
       type                      NMTOKEN           #REQUIRED

   <!ELEMENT IssuerAndSerialNumber EMPTY >
   <!ATTLIST IssuerAndSerialNumber
       issuer                     CDATA            #REQUIRED
       number                     CDATA            #REQUIRED


Top      Up      ToC       Page 277 
   <!ELEMENT Value ( #PCDATA ) >
   <!ATTLIST Value
       ID               ID           #IMPLIED
       encoding    (base64|none)    'base64'

   <!ELEMENT Locator EMPTY>
   <!ATTLIST Locator
       xml:link        CDATA         #FIXED        'simple'
       href            CDATA         #REQUIRED

(page 277 continued on part 9)

Next RFC Part