tech-invite   World Map     

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

RFC 2801

 
 
 

Internet Open Trading Protocol - IOTP Version 1.0

Part 5 of 9, p. 125 to 163
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 125 
7.10 Payment Scheme Component

   A Payment Scheme Component contains payment protocol information for
   a specific payment scheme which is transferred between the parties
   involved in a payment for example a [SET] message. Its definition is
   as follows.

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

   Attributes:

   ID                   An identifier which uniquely identifies the
                        Payment Scheme Component within the IOTP
                        Transaction.

   PaymentRef           An Element Reference (see section 3.5) to the
                        Payment Component (see section 7.9) to which
                        this Payment Scheme Component relates. It is
                        required unless the Payment Scheme Component is
                        part of an Transaction Inquiry Status
                        Transaction (see section 9.2.1).

   ConsumerPaymentId    An identifier specified by the Consumer which,
                        if returned by the Payment Handler in another
                        Payment Scheme Component or by other means, will
                        enable the Consumer to identify which payment is
                        being referred to.

   PaymentHandlerPayId  An identifier specified by the Payment Handler
                        which, if returned by the Consumer in another
                        Payment Scheme Component, or by other means,
                        will enable the Payment Handler to identify
                        which payment is being referred to. It is
                        required on every Payment Scheme Component apart
                        from the one contained in a Payment Request
                        Block.

   ContentSoftwareId    See section 14. Glossary.

Top      Up      ToC       Page 126 
   Content:

   PackagedContent    Contains payment scheme protocol information as
                      Packaged Content elements (see section 3.7). See
                      the payment scheme supplement for the definition
                      of its content.

                      Note that:
                       o the values of the Name attribute of each
                         packaged content element are defined by the
                         Payment Protocol Supplement
                       o the value of each Name must be unique within a
                         Payment where a Payment is defined as all
                         Payment Scheme or Payment Receipt Components
                         with the same value of the PaymentRef attribute

7.11 Payment Receipt Component

   A Payment Receipt is a record of a payment which demonstrates how
   much money has been paid or received. It is distinct from a purchase
   receipt in that it contains no record of what was being purchased.

   Typically the content of a Payment Receipt Component will contain
   data which describes:

   o  the amount paid and its currency

   o  the date and time of the payment

   o  internal reference numbers which identify the payment to the
      payment system

   o  potentially digital signatures generated by the payment method
      which can be used to prove after the event that the payment
      occurred.

   If the Payment Method being used provides the facility then the
   Payment Receipt Component should contain payment protocol messages,
   or references to messages, which prove the payment occurred.

   The precise definition of the content is Payment Method dependent.
   Refer to the supplement for the payment method being used to
   determine the rules that apply.

   Information contained in the Payment Receipt Component should be
   displayed or otherwise made available to the Consumer.

Top      Up      ToC       Page 127 
   Note: If the Payment Receipt Component contains Payment Protocol
   Messages, then the Messages will need to be processed by Payment
   Method software to convert it into a format which can be understood
   by the Consumer

    The definition of a Payment Receipt Component is as follows.

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

   Attributes:

   ID                  An identifier which uniquely identifies the
                       Payment Receipt Component within the IOTP
                       Transaction.

   PaymentRef          Contains an Element Reference (see section 3.5)
                       to the Payment Component (see section 7.9) to
                       which this payment receipt applies

   PayReceiptNameRefs  Optionally contains a list of the values of the
                       Name attributes of Packaged Content elements that
                       together make up the receipt. The Packaged
                       Content elements are contained either within:
                        o Payment Scheme Data components exchanged
                          between the Payment Handler and the Consumer
                          roles during the Payment, and/or
                        o the Payment Receipt component itself.
                       Note that:
                        o each payment scheme defines in its supplement
                          the Names of the Packaged Content elements
                          that must be listed in this attribute (if
                          any).
                        o if a Payment Scheme Component contains
                          Packaged Content elements with a name that
                          matches a name within PayReceiptNameRefs, then
                          those Payment Scheme Components must be
                          referenced by Digests in the Payment Response
                          signature component (if such a signature is
                          being used)

                       The client software should save all the
                       components referenced so that the payment receipt
                       can be reconstructed when required.

Top      Up      ToC       Page 128 
   ContentSoftwareId   See section 14. Glossary.

   Content:

   PackagedContent    Optionally contains payment scheme payment receipt
                      information as Packaged Content elements (see
                      section 3.7). See the payment scheme supplement
                      for the definition of its content.

                      Note that:
                       o the values of the Name attribute of each
                         packaged content element are defined by the
                         Payment Protocol Supplement
                       o the value of each Name must be unique within a
                         Payment where a Payment is defined as all
                         Payment Scheme or Payment Receipt Components,
                         with the same value of the PaymentRef attribute

   Note that either the PayReceiptNameRefs attribute, the
   PackagedContent element, or both must be present.

7.12 Payment Note Component

   The Payment Note Component contains additional, non payment related,
   information which the Payment Handler wants to provide to the
   Consumer.  For example, if a withdrawal or deposit were being made
   then it could contain information on the remaining balance on the
   account after the transfer was complete. The information should
   duplicate information contained within the Payment Receipt Component.

   Information contained in the Payment Note Component should be
   displayed or otherwise made available to the Consumer. For
   interoperability, the Payment Note Component should support, as a
   minimum, the content types of "Plain Text", HTML and XML. Its
   definition is as follows.

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

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Payment Receipt Component within the IOTP
                      Transaction.

   ContentSoftwareId  See section 14. Glossary.

Top      Up      ToC       Page 129 
   Content:

   PackagedContent    Contains additional, non payment related,
                      information which the Payment Handler wants to
                      provide to the Consumer as one or more Packaged
                      Content elements (see section 3.7).

7.13 Delivery Component

   The Delivery Element contains information required to deliver goods
   or services. Its definition is as follows.

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

   Attributes:

   ID                  An identifier which uniquely identifies the
                       Delivery Component within the IOTP Transaction.

   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.

   DelivExch           Indicates if this IOTP Transaction includes the
                       messages associated with a Delivery Exchange.
                       Valid values are:
                        o True indicates it does include a Delivery
                          Exchange
                        o False indicates it does not include a
                          Delivery Exchange

                       If set to true then a DeliveryData element must
                       be present. If set to false it may be absent.

   DelivAndPayResp     Indicates if the Delivery Response Block (see
                       section 8.11) and the Payment Response Block (see
                       section 8.9 ) are combined into one IOTP Message.
                       Valid values are:
                        o True indicates both blocks will be in the
                          same IOTP Message, and

Top      Up      ToC       Page 130 
                        o False indicates each block will be in a
                          different IOTP Message

                       DelivAndPayResp should not be true if DelivExch
                       is False.

                       In practice combining the Delivery Response Block
                       and Payment Response Block is only likely to be
                       practical if the Merchant, the Payment Handler
                       and the Delivery Handler are the same
                       Organisation since:
                        o the Payment Handler must have access to Order
                          Component information so that they know what
                          to deliver, and
                        o the Payment Handler must be able to carry out
                          the delivery

   ActionOrgRef        An Element Reference to the Organisation
                       Component of the Delivery Handler for this
                       delivery.

   Content:

   DeliveryData       Contains details about how the delivery will be
                      carried out. See 7.13.1 Delivery Data Element
                      below.

   PackagedContent    Contains "user" data defined for the Merchant
                      which is required by the Delivery Handler as one
                      or more Packaged Content Elements see section 3.7.

7.13.1 Delivery Data Element

   The DeliveryData element contains information about where and how
   goods are to be delivered. Its definition is as follows.

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

Top      Up      ToC       Page 131 
   Attributes:

   xml:lang            Defines the language used by attributes within
                       this component. See section 3.8 Identifying
                       Languages.

   OkFrom              The date and time in [UTC] format after which the
                       Delivery Handler may accept for processing a
                       Delivery Request Block (see section 8.10).

   OkTo                The date and time in [UTC] format before which
                       the Delivery Handler may accept for processing a
                       Delivery Request Block.

   DelivMethod         Indicates the method by which goods or services
                       may be delivered. Valid values are:
                        o Post the goods will be delivered by post or
                          courier
                        o Web the goods will be delivered
                          electronically in the Delivery Note Component
                        o Email the goods will be delivered
                          electronically by e-mail

                       Values of DelivMethod are managed under the
                       procedure described in section 12 IANA
                       Considerations which allows user defined codes to
                       be defined.

   DelivToRef          The Element Reference (see section 3.4) of an
                       Organisation Component within the IOTP
                       Transaction which has a role of DelivTo. The
                       information in this block is used to determine
                       where delivery is to be made. It must be
                       compatible with DelivMethod. Specifically if the
                       DelivMethod is:
                        o Post, then the there must be a Postal Address
                          Element containing sufficient information for
                          a postal delivery,
                        o Web, then there are no specific requirements.
                          The information will be sent in a web page
                          back to the Consumer
                        o Email, then there must be Contact Information
                          Element with a valid e-mail address

   DelivReqNetLocn     This contains the Net Location to which an
                       unsecured Delivery Request Block (see section
                       8.10) which contains the Delivery Component
                       should be sent.

Top      Up      ToC       Page 132 
                       The content of this attribute is dependent on the
                       Transport Mechanism and must conform to
                       [RFC1738].

   SecDelivReqNetLocn  This contains the Net Location to which a secured
                       Delivery Request Block (see section 8.10) which
                       contains the Delivery Component should be sent.

                       A secured delivery request involves the use of a
                       secure channel such as [SSL/TLS] in order to
                       communicate with the Payment Handler.

                       The content of this attribute is dependent on the
                       Transport Mechanism must conform to [RFC1738].

                       See also Section 3.9 Secure and Insecure Net
                       Locations.

   ContentSoftwareId   See section 14. Glossary.

   Content:

   PackagedContent    Additional information about the delivery as one
                      or more Packaged Content elements (see section
                      3.7) provided to the Delivery Handler by the
                      merchant.

7.14 Consumer Delivery Data Component

   A Consumer Delivery Data Component is used by a Consumer to specify
   an identifier that can be used by the Consumer to identify the
   Delivery.

   Its definition is as follows:

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

   Attributes:

   ID                  An identifier which uniquely identifies the
                       Consumer Delivery Data Component within the IOTP
                       Transaction.

Top      Up      ToC       Page 133 
   ConsumerDeliveryId  An identifier specified by the Consumer which, if
                       returned by the Delivery Handler will enable the
                       Consumer to identify which Delivery is being
                       referred to.

7.15 Delivery Note Component

   A Delivery Note contains delivery instructions about the delivery of
   goods or services or potentially the actual Delivery Information
   itself.  It is information which the person or Organisation receiving
   the Delivery Note can use when delivery occurs.

   For interoperability, the Delivery Note Component Packaged Content
   should support both Plain Text, HTML and XML.

   It's definition is as follows.

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

   Attributes:

   ID                   An identifier which uniquely identifies the
                        Delivery Note Component within the IOTP
                        Transaction.

   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.

   DelivHandlerDelivId  An optional identifier specified by the Delivery
                        Handler which, if returned by the Consumer in
                        another Delivery Component, or by other means,
                        will enable the Delivery Handler to identify
                        which Delivery is being referred to. It is
                        required on every Delivery Component apart from
                        the one contained in a Delivery Request Block.

                        An example use of this attribute is to contain a
                        delivery tracking number.

   ContentSoftwareId    See section 14. Glossary.

Top      Up      ToC       Page 134 
   Content:

   PackagedContent    Contains actual delivery note information as one
                      or more Packaged Content elements (see section
                      3.7).

   Note: If the content of the Delivery Message is a Mime message then
   the Delivery Note may trigger an application which causes the actual
   delivery to occur.

7.16 Status Component

   A Status Component contains status information about the business
   success or failure (see section 4.2) of a process.

   Its definition is as follows.

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

   Attributes:

   ID                 An identifier which uniquely identifies the Status
                      Component within the IOTP Transaction.

   xml:lang           Defines the language used by attributes within
                      this component. See section 3.8 Identifying
                      Languages.

   StatusType         Indicates the type of Document Exchange which the
                      Status is reporting on. It may be set to either
                      Offer, Payment, Delivery, Authentication or
                      Undefined.

                      Undefined means that the type of document exchange
                      could not be identified. This is caused by an
                      error in the initial input message of the
                      exchange.

Top      Up      ToC       Page 135 
                      Values of StatusType are managed under the
                      procedure described in section 12 IANA
                      Considerations which also allows user defined
                      values of StatusType to be defined.

   ElRef              If the StatusType is not set to Undefined then
                      ElRef contains an Element Reference (see section
                      3.5) to the Component for which the Status is
                      being described. It must refer to either:
                       o an Order Component (see section 7.5), if the
                         StatusType is Offer,
                       o a Payment Component (see section 7.9), if the
                         StatusType is Payment, or
                       o a Delivery Component (see section 7.13), if
                         the StatusType is Delivery
                       o an Authentication Request Component (see
                         section 7.2) if the StatusType is
                         Authentication.

   ProcessState       Contains a State Code which indicates the current
                      state of the process being carried out. Valid
                      values for ProcessState are:
                       o NotYetStarted. A Request Block has been
                         received but the process has not yet started
                       o InProgress. Processing of the Request Block
                         has started but it is not yet complete
                       o CompletedOk. The processing of the Request
                         Block has completed successfully without any
                         errors
                       o Failed. The processing of the Request Block
                         has failed because of a Business Error (see
                         section 4.2)
                       o ProcessError. This value is only used when the
                         Status Component is being used in connection
                         with an Inquiry Request Trading Block (see
                         section 8.12). It indicates there was a
                         Technical Error (see section 4.1) in the
                         Request Block which is being processed or some
                         internal processing error.

                      Note that this code reports on the processing of a
                      Request Block. Further, asynchronous processing
                      may occur after the Response Block associated with
                      the Process has been sent.

Top      Up      ToC       Page 136 
   CompletionCode     Indicates how the process completed. Valid values
                      for the CompletionCode are given below together
                      with the conditions when it must be present and
                      indications on when recovery from failures are
                      possible.

                      A CompletionCode is a maximum of 14 characters
                      long.

   ProcessReference   This optional attribute holds a reference for the
                      process whose status is being reported. It may
                      hold the following values:
                       o when StatusType is set to Offer, it should
                         contain the OrderIdentifier from the Order
                         Component
                       o when StatusType is set to Payment, it should
                         contain the PaymentHandlerPayId from the
                         Payment Scheme Data Component
                       o when StatusType is set to Delivery, it should
                         contain the DelivHandlerDelivId from the
                         Delivery Note Component
                       o when StatusType is set to Authentication, it
                         should contain the AuthenticationId from the
                         Authentication Request Component

                      This attribute should be absent in the Inquiry
                      Request message when the Consumer has not been
                      given such a reference number by the IOTP Service
                      Provider.

                      This attribute can be used inside an Inquiry
                      Response Block (see section 8.13) to give the
                      reference number for a transaction which has
                      previously been unavailable.

                      For example, the package tracking number might not
                      be assigned at the time a delivery response was
                      received. However, if the Consumer issues a
                      Baseline Transaction Status Inquiry later, the
                      Delivery Handler can put the package tracking
                      number into this attribute in the Inquiry Response
                      message and send it back to the Consumer.

   StatusDesc         An optional textual description of the current
                      status of the process in the language identified
                      by xml:lang.

Top      Up      ToC       Page 137 
7.16.1 Offer Completion Codes

   The Completion Code is only required if the ProcessState attribute is
   set to Failed. The following table contains the valid values for the
   CompletionCode that may be used and indicates whether or not recovery
   might be possible. It is recommended that the StatusDesc attribute is
   used to provide further explanation where appropriate.

       Value                            Description

   AuthError        Authentication Error. The check of the
                    Authentication Response which was carried out has
                    failed.

                    Recovery may be possible by the Consumer re-
                    submitting a new Authentication Response Block with
                    corrected information.

   ConsCancelled    Consumer Cancelled. The Consumer decides to cancel
                    the transaction for some reason. This code is only
                    valid in a Status Component contained in a Cancel
                    Block or an Inquiry Response Block.

                    No recovery possible.

   MerchCancelled   Offer Cancelled. The Merchant declines to generate
                    an offer for some reason and cancels the
                    transaction. This code is only valid in a Status
                    Component contained in a Cancel Block or an Inquiry
                    Response Block.

                    No recovery possible.

   Unspecified      Unspecified error. There is some unknown problem or
                    error which does not fall into one of the other
                    CompletionCodes.

                    No recovery possible.

   TimedOutRcvr     Recoverable Time Out. Messages were resent but no
                    response received. The document exchange has
                    therefore "Timed Out". This code is only valid on a
                    Transaction Inquiry.

                    Recovery is possible if the last message from the
                    other Trading Role is received again.

Top      Up      ToC       Page 138 
   TimedOutNoRcvr   Non Recoverable Time Out. Messages were resent but
                    no response received. The document exchange has
                    therefore "Timed Out". This code is only valid on a
                    Transaction Inquiry.

                    No recovery possible.

7.16.2 Payment Completion Codes

   The CompletionCode is only required if the ProcessState attribute is
   set to Failed. The following table contains the valid values for the
   CompletionCode that may be used and indicates where recovery may be
   possible. It is recommended that the StatusDesc attribute is used by
   individual payment schemes to provide further explanation where
   appropriate.

         Value                           Description

   BrandNotSupp       Brand not supported. The payment brand is not
                      supported by the Payment Handler.

                      See below for recovery options.

   CurrNotSupp        Currency not supported. The currency in which the
                      payment is to be made is not supported by either
                      the Payment Instrument or the Payment Handler.

                      If the payment is Brand Independent, then the
                      Consumer may recover by selecting a different
                      currency, if available, or a different brand. Note
                      that this may involve a different Payment Handler.

   ConsCancelled      Consumer Cancelled. The Consumer decides to cancel
                      the payment for some reason. This code is only
                      valid in a Status Component contained in a Cancel
                      Block or an Inquiry Response Block.

                      Recovery is not possible.

   PaymtCancelled     Payment Cancelled. The Payment Handler declines to
                      complete the payment for some reason and cancels
                      the transaction. This code is only valid in a
                      Status Component contained in a Cancel Block or an
                      Inquiry Response Block.

                      See below for recovery options.

Top      Up      ToC       Page 139 
   AuthError          Authentication Error. The Payment Scheme specific
                      authentication check which was carried out has
                      failed.

                      Recovery may be possible. See the payment scheme
                      supplement to determine what is allowed.

   InsuffFunds        Insufficient funds. There are insufficient funds
                      available for the payment to be made.

                      See below for recovery options.

   InstBrandInvalid   Payment Instrument not valid for Brand. A Payment
                      Instrument is being used which does not correspond
                      with the Brand selected. For example a Visa credit
                      card is being used when MasterCard was selected as
                      the Brand.

                      See below for recovery options.

   InstNotValid       Payment instrument not valid for trade. The
                      Payment Instrument cannot be used for the proposed
                      type of trade, for some reason.

                      See below for recovery options.

   BadInstrument      Bad instrument. There is a problem with the
                      Payment Instrument being used which means that it
                      is unable to be used for the payment.

                      See below for recovery options.

   Unspecified        Unspecified error. There is some unknown problem
                      or error which does not fall into one of the other
                      CompletionCodes. The StatusDesc attribute should
                      provide the explanation of the cause.

                      See below for recovery options.

   TimedOutRcvr       Recoverable Time Out. Messages were resent but no
                      response received. The document exchange has
                      therefore "Timed Out". This code is only valid on
                      a Transaction Inquiry.

                      Recovery is possible if the last message from the
                      other Trading Role is received again.

Top      Up      ToC       Page 140 
   TimedOutNoRcvr     Non Recoverable Time Out. Messages were resent but
                      no response received. The document exchange has
                      therefore "Timed Out". This code is only valid on
                      a Transaction Inquiry.

                      No recovery possible.

   If the Payment is Brand Independent, then recovery may be possible
   for some values of the Completion Code, by the Consumer selecting
   either a different payment brand or a different payment instrument
   for the same brand. Note that this might involve a different Payment
   Handler. The codes to which this applies are: BrandNotSupp,
   PaymtCancelled, InsuffFunds, InstBrandInvalid, InstNotValid,
   BadInstrument and Unspecified.

   Recovery from Payments associated with Brand Dependent purchases is
   only possible, if the Brand Selection component sent by the Merchant
   to the Consumer does not change. In practice this means that the same
   Brand, Protocol Amount and PayProtocol elements must be used. All
   that can change is the Payment Instrument. Any other change will
   invalidate the Merchant's Offer as a changed selection will
   invalidate the Offer Response.

7.16.3 Delivery Completion Codes

   The following table contains the valid values for the CompletionCode
   attribute for a Delivery. It is recommended that the StatusDesc
   attribute is used to provide further explanation where appropriate.

        Value                           Description

   BackOrdered     Back Ordered. The goods to be delivered are on order
                   but they have not yet been received. Shipping will be
                   arranged when they are received. This is only valid
                   if ProcessState is CompletedOk.

                   Recovery is not possible.

   PermNotAvail    Permanently Not Available. The goods are permanently
                   unavailable and cannot be re-ordered. This is only
                   valid if ProcessState is Failed.

                   Recovery is not possible.

   TempNotAvail    Temporarily Not Available. The goods are temporarily
                   unavailable and may become available if they can be
                   ordered. This is only valid if ProcessState is
                   CompletedOk.

Top      Up      ToC       Page 141 
                   Recovery is not possible.

   ShipPending     Shipping Pending. The goods are available and are
                   scheduled for shipping but they have not yet been
                   shipped. This is only valid if ProcessState is
                   CompletedOk.

                   Recovery is not possible.

   Shipped         Goods Shipped. The goods have been shipped.
                   Confirmation of delivery is awaited. This is only
                   valid if ProcessState is CompletedOk.

                   Recovery is not possible.

   ShippedNoConf   Shipped - No Delivery Confirmation. The goods have
                   been shipped but it is not possible to confirm
                   delivery of the goods. This is only valid if
                   ProcessState is CompletedOk.

                   Recovery is not possible.

   ConsCancelled   Consumer Cancelled. The Consumer decides to cancel
                   the delivery for some reason. This code is only valid
                   in a Status Component contained in a Cancel Block or
                   an Inquiry Response Block.

                   Recovery is not possible.

   DelivCancelled  Delivery Cancelled. The Delivery Handler declines to
                   complete the Delivery for some reason and cancels the
                   transaction. This code is only valid in a Status
                   Component contained in a Cancel Block or an Inquiry
                   Response Block.

                   Recovery is not possible.

   Confirmed       Confirmed. All goods have been delivered and
                   confirmation of their delivery has been received.
                   This is only valid if ProcessState is CompletedOk.

                   Recovery is not possible.

   Unspecified     Unspecified error. There is some unknown problem or
                   error which does not fall into one of the other
                   CompletionCodes. The StatusDesc attribute should
                   provide the explanation of the cause.

Top      Up      ToC       Page 142 
                   Recovery is not possible.

   TimedOutRcvr    Recoverable Time Out. Messages were resent but no
                   response received. The document exchange has
                   therefore "Timed Out". This code is only valid on a
                   Transaction Inquiry.

                   Recovery is possible if the last message from the
                   other Trading Role is received again.

   TimedOutNoRcvr  Non Recoverable Time Out. Messages were resent but no
                   response received. The document exchange has
                   therefore "Timed Out". This code is only valid on a
                   Transaction Inquiry.

                   No recovery possible.

   Note: Recovery from failed, or partially completed deliveries is not
   possible. The Consumer should use the Transaction Status Inquiry
   Transaction (see section 9.2.1) to determine up-to- date information
   on the current state.

7.16.4 Authentication Completion Codes

   The Completion Code is only required if the ProcessState attribute is
   set to Failed. The following table contains the valid values for the
   CompletionCode that may be used. It is recommended that the
   StatusDesc attribute is used to provide further explanation where
   appropriate.

        Value                           Description

   AutEeCancel     Authenticatee Cancel. The Organisation being
                   authenticated declines to be authenticated for some
                   reason. This could be, for example because the
                   signature on an Authentication Request was invalid or
                   the Authenticator was not known or acceptable to the
                   Authenticatee.

                   Recovery is not possible.

   AutOrCancel     Authenticator Cancel. The Organisation requesting
                   authentication declines to validate the
                   Authentication Response received for some reason and
                   cancels the transaction.

                   Recovery is not possible.

Top      Up      ToC       Page 143 
   NoAuthReq       Authentication Request Not Available. The
                   Authenticatee does not have the data that must be
                   provided so that they may be successfully
                   authenticated. For example a password may have been
                   forgotten, the Authenticatee has not yet become a
                   member, or a smart card token is not present.

                   Recovery is not possible

   AuthFailed      Authentication Failed. The Authenticator checked the
                   Authentication Response but the authentication failed
                   for some reason. For example a password may have been
                   incorrect.

                   Recovery may be possible by the Authenticatee re-
                   sending a revised Authentication Response with
                   corrected data.

   TradRolesIncon  Trading Roles Inconsistent. The Trading Roles
                   contained within the TradingRoleList attribute of the
                   Trading Role Information Request Component (see
                   section 7.4) are inconsistent with the Trading Role
                   which the Authenticatee is taking in the IOTP
                   Transaction or is able to take. Examples of
                   inconsistencies include:
                    o asking a PaymentHandler for DeliveryHandler
                     information
                    o asking a Consumer for Merchant information

                   Recovery may be possible by the Authenticator re-
                   sending a revised Authentication Request Block with
                   corrected information.

   Unspecified     Unspecified error. There is some unknown problem or
                   error which does not fall into one of the other
                   CompletionCodes.

                   Recovery is not possible.

   TimedOutRcvr    Recoverable Time Out. Messages were resent but no
                   response received. The document exchange has
                   therefore "Timed Out". This code is only valid on a
                   Transaction Inquiry.

                   Recovery is possible if the last message from the
                   other Trading Role is received again.

Top      Up      ToC       Page 144 
   TimedOutNoRcvr  Non Recoverable Time Out. Messages were resent but no
                   response received. The document exchange has
                   therefore "Timed Out". This code is only valid on a
                   Transaction Inquiry.

                   No recovery possible.

7.16.5 Undefined Completion Codes

   The Completion Code is only required if the ProcessState attribute is
   set to Failed. The following table contains the valid values for the
   CompletionCode that may be used. It is recommended that the
   StatusDesc attribute is used to provide further explanation where
   appropriate.

        Value                           Description

   InMsgHardError  Input Message Hard Error. The type of Request Block
                   could not be identified or was inconsistent.
                   Therefore no single Document Exchange could be
                   identified. This will cause a Hard Error in the
                   transaction

7.16.6 Transaction Inquiry Completion Codes

   The Completion Code is only required if the ProcessState attribute is
   set to Failed. The following table contains the valid values for the
   CompletionCode that may be used. It is recommended that the
   StatusDesc attribute is used to provide further explanation where
   appropriate.

        Value                           Description

   UnAuthReq       Unauthorised Request. The recipient of the
                   Transaction Status Request declines to respond to the
                   request.

7.17 Trading Role Data Component

   The Trading Role Data Component contains opaque data which needs to
   be communicated between the Trading Roles involved in an IOTP
   Transaction.

   Trading Role Components identify:

   o the Organisation that generated the component, and

   o the Organisation that is to receive it.

Top      Up      ToC       Page 145 
   They are first generated and included in a "Response" Block, and then
   copied to the appropriate "Request" Block. For example a Payment
   Handler might need to inform a Delivery Handler that a credit card
   payment had been authorised but not captured. There may also be other
   information that the Payment Handler has generated where the format
   is privately agreed with the Delivery Handler which needs to be
   communicated. In another example a Merchant might need to provide a
   Payment Handler with some specific information about a Consumer so
   that consumer can acquire double loyalty points with the payment.

   Its definition is as follows.

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

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Trading Role Data Component within the IOTP
                      Transaction.

   OrginatorElRef     Contains an element reference to the Organisation
                      Component of the Organisation that created the
                      Trading Role Data Component and included it in a
                      "Response" Block (e.g., an Offer Response or a
                      Payment Response Block).

   DestinationElRefs  Contains element references to the Organisation
                      Components of the Organisations that are to
                      receive the Trading Role Data Component in a
                      "Request" Block (e.g., either a Payment Request or
                      a Delivery Request Block).

   Content:

   PackagedContent    This contains the data which is to be sent between
                      the various Trading Roles as one or more
                      PackagedContent elements see section 3.7.

7.17.1 Who Receives a Trading Role Data Component

   The rules for deciding what to do with Trading Role Data Components
   are described below.

Top      Up      ToC       Page 146 
   o  whenever a Trading Role Data Component is received in a "Response"
      block identify the Organisation Components of the Organisations
      that are to receive it as identified by the DestinationElRefs
      attribute.

   o  whenever a "Request" Block is being sent, check to see if it is
      being sent to one of the Organisations identified by the
      DestinationElRefs attribute. If it is then include in the
      "Request" block:

      -  the Trading Role Data Component as well as,

      -  the Organisation Component of the Organisation identified by
         the OriginatorElRef attribute (if not already present)

7.18 Inquiry Type Component

   The Inquiry Type Component contains the information which indicates
   the type of process that is being inquired upon. Its definition is as
   follows.

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

   Attributes:

   ID                 An identifier which uniquely identifies the
                      Inquiry Type Component within the IOTP
                      Transaction.

   Type               Contains the type of inquiry. Valid values for
                      Type are:
                       o Offer. The inquiry is about the status of an
                         offer and is addressed to the Merchant.
                       o Payment. The inquiry is about the status of a
                         payment and is addressed to the Payment
                         Handler.
                       o Delivery. The inquiry is about the status of a
                         delivery and addressed to the Delivery Handler.

   ElRef              Contains an Element Reference (see section 3.5) to
                      the component to which this Inquiry Type Component
                      applies. That is,
                       o TPO Block when Type is Offer

Top      Up      ToC       Page 147 
                       o Payment Component when Type is Payment
                       o Delivery Component when Type is Delivery

   ProcessReference   Optionally contains a reference to the process
                      being inquired upon. It should be set if the
                      information is available. For the definition of
                      the values it may contain, see the
                      ProcessReference attribute of the Status Component
                      (see section 7.16).

7.19 Signature Component

   Note: Definitions of the XML structures for signatures and
   certificates are described in the document titled "Digital Signatures
   for the Internet Open Trading Protocol" by Kent Davidson and Yoshiaki
   Kawatsura published at the same time as this document - see
   [IOTPDSIG].

   In the future it is anticipated that future versions of IOTP will
   adopt a whatever method for digitally signing XML becomes the
   standard.

   Each Signature Component digitally signs one or more Blocks or
   Components including other Signature Components.

   The Signature Component:

   o  contains digests of one or more Blocks or Components in one or
      more IOTP Messages within the same IOTP Transaction and places the
      result in a Digest Element

   o  concatenates these Digest elements with other information on the
      type of signature, the originator and potential recipients of the
      signature and details of the signature algorithms being used and
      places them in a Manifest element, and

   o  signs the Manifest element using the optional certificate
      identified in the Certificate element within the Signature Block
      placing the result in a Value element within a Signature Component

   Note that there may be multiple Value elements that contain
   signatures of a Manifest Element.

   A Signature Component can be one of four types either:

   o an Offer Response Signature,

   o a Payment Response Signature,

Top      Up      ToC       Page 148 
   o a Delivery Response Signature, or

   o an Authentication Response Signature.

   For a general explanation of signatures see section 6 Digital
   Signatures.

7.19.1 IOTP usage of signature elements and attributes

   Definitions of the elements and attributes are contained in
   [IOTPDSIG].  The following contains additional information that
   describes how these elements and attributes are used by IOTP.

   SIGNATURE ELEMENT

   The ID attribute is mandatory.

   MANIFEST ELEMENT

   The optional LocatorHrefBase attribute contains text which should be
   concatenated before the text contained in the LocatorHREF attribute
   of all Digest elements within the Manifest.

   Its purpose is to reduce the size of LocatorHREF attribute values
   since the first part of the LocatorHREF attributes in the same
   signature are likely to be the same.

   Typically, within IOTP, it will contain all the characters in a
   LocatorHref attribute up to the sharp ("#") character (see
   immediately below).

   ALGORITHM AND PARAMETER ELEMENTS

   The algorithm element identifies the algorithms used in generating
   the signature. The type of the algorithm is defined by the value of
   the Type attribute which indicates if it is to be used as a Digest
   algorithm, a Signature algorithm or a Key Agreement algorithm.

   The following Digest algorithms must be implemented:

   o  a [DOM-HASH] algorithm. This is identified by setting the Name
      attribute of the Algorithm element to "urn:ibm:dom-hash"

   o  a [SHA1] algorithm. This is identified by setting the Name
      attribute of the Algorithm element to "urn:fips:sha1", and

   o  a [MD5] algorithm. This is identified by setting the Name
      attribute of the Algorithm element to "urn:rsa:md5"

Top      Up      ToC       Page 149 
   o  The following Signature algorithms must be implemented:

   o  a [DSA] algorithm. This is identified by setting the Name
      attribute of the Algorithm element to "urn:us.gov:dsa"

   o  a [HMAC] algorithm. This is identified by setting the Name
      attribute of the Algorithm element to "urn:ibm:hmac"

   It is recommended that the following Signature algorithm is also
   implemented:

   o  a [RSA] algorithm. This is identified by setting the Name
      attribute of the Algorithm element to "urn:rsa:rsa"

   In addition other payment scheme specific algorithms may be used. In
   this case the value of the name attribute to use is specified in the
   payment scheme supplement for that algorithm.

   One algorithm may make use of other algorithms by use of the
   Parameter element, for example:

   <Algorithm ID=A1 type="digest" name="urn:ibm:dom-hash">
     <Parameter type='AlgorithmRef'>A2</Parameter>
   </Algorithm>
   <Algorithm ID=A2 type="digest" name="urn:fips:sha1">
   </Algorithm>
   <Algorithm ID=A3 type="signature" name="urn:ibm:hmac">
       <Parameter type='AlgorithmRef'>A1</Parameter>
   </Algorithm>

   DIGEST ELEMENT

   The LocatorHREF attribute identifies the IOTP element which is being
   digitally signed. Specifically it consists of:

   o  the value of the IotpTransId attribute of the Transaction ID
      Component, followed by:

   o  a sharp character, i.e. "#", followed by

   o  an Element Reference (see section 3.5) to the element within the
      IOTP Transaction which is the subject of the digest.

   Before analysing the structure of the LocatorHREF attribute, it must
   be concatenated with the value of the LocatorHrefBase attribute of
   the Manifest element (see immediately above).

Top      Up      ToC       Page 150 
   ATTRIBUTE ELEMENT

   There must be one and only one Attribute Element that contains a Type
   attribute with a value of IOTP Signature Type and with content set to
   either: OfferResponse, PaymentResponse, DeliveryResponse,

   AuthenticationRequest, AuthenticationResponse, PingRequest or
   PingResponse; depending on the type of the signature.

   Values of the content of the Attribute element are controlled under
   the procedures defined in section 12 IANA Considerations which also
   allows user defined values to be defined.

   The Critical attribute must be set to true.

   ORIGINATORINFO ELEMENT

   The OriginatorRef attribute of the OriginatorInfo element must always
   be present and contain an Element Reference (see section 3.5) to the
   Organisation Component of the Organisation that generated the
   Signature Component.

   RECIPIENTINFO ELEMENT

   The RecipientRefs attribute contains a list of Element References
   (see section 3.5), that point to the Organisations that might need to
   validate the signature. For details see below.

7.19.2 Offer Response Signature Component

   The Manifest Element of a signature which has a type of OfferResponse
   should contain Digest elements for the following Components:

   o  the Transaction Id Component (see section 3.3.1) of the IOTP
      message that contains the Offer Response Signature

   o  the Transaction Reference Block (see section 3.3) of the IOTP
      Message that contains the Offer Response Signature

   o  from the TPO Block:

      -  the Protocol Options Component

      -  each of the Organisation Components

      -  each of the Brand List Components

Top      Up      ToC       Page 151 
   o  optionally, all the Brand Selection Components if they were sent
      to the Merchant in a TPO Selection Block

   o  from the Offer Response Block:

      - the Order Component

      - each of the Payment Components

      - the Delivery Component

      - each of the Authentication Request Components

      - any Trading Role Data Components

   The Offer Response Signature should also contain Digest elements for
   the components that describe each of the Organisations that may or
   will need to verify the signature. This involves:

   o  if the Merchant has received a TPO Selection Block containing
      Brand Selection Components, then generate a Digest element for the
      Payment Handler identified by the Brand Selection Component and
      the Delivery Handler identified by the Delivery Component. See
      section 6.3.1 Check Request Block sent Correct Organisation for a
      description of how this can be done.

   o  if the Merchant is not expecting to receive a TPO Selection Block
      then generate a Digest element for the Delivery Handler and all
      the Payment Handlers that are involved.

7.19.3 Payment Receipt Signature Component

   The Manifest Element of the Payment Receipt Signature Component
   should contain Digest Elements for the following Components:

   o  the Transaction Id Component (see section 3.3.1) of the IOTP
      message that contains the Payment Receipt Signature

   o  the Transaction Reference Block (see section 3.3) of the IOTP
      Message that contains the Payment Receipt Signature

   o  the Offer Response Signature Component

   o  the Payment Receipt Component

   o  the Payment Note Component

   o  the Status Component

Top      Up      ToC       Page 152 
   o  the Brand Selection Component.

   o  any Trading Role Data Components

7.19.4 Delivery Response Signature Component

   The Manifest Element of the Delivery Response Signature Component
   should contain Digest Elements for the following Components:

   o  the Transaction Id Component (see section 3.3.1) of the IOTP
      message that contains the Delivery  Response Signature

   o  the Transaction Reference Block (see section 3.3) of the IOTP
      Message that contains the Delivery Response Signature

   o  the Consumer Delivery Data component contained in the preceding
      Delivery Request (if any)

   o  the Signature Components contained in the preceding Delivery
      Request (if any)

   o  the Status Component

   o  the Delivery Note Component

7.19.5 Authentication Request Signature Component

   The Manifest Element of the Authentication Request Signature
   Component should contain Digest Elements for the following
   Components:

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

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

   o  the following components of the TPO Block :

      -  the Protocol Options Component

      -  the Organisation Component

   o  the following components of the Authentication Request Block:

      -  the Authentication Request Component(s) (if present)

Top      Up      ToC       Page 153 
      -  the Trading Role Information Request Component (if present)

7.19.6 Authentication Response Signature Component

   The Manifest Element of the Authentication Response Signature
   Component should contain Digest Elements for the following
   Components:

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

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

   o  the following components of the Authentication Request Block:

      -  the Authentication Request Component that was used in the
         Authentication (if present)

      -  the Trading Role Information Request Component (if present)

   o  the Organisation Components contained in the Authentication
      Response Block

7.19.7 Inquiry Request Signature Component

   If the Inquiry Request is being signed (see section 9.2.1) the
   Manifest Element of the Inquiry Request Signature Component should
   contain Digest elements of the Inquiry Type Component, and if
   present, the Payment Scheme Component.

7.19.8 Inquiry Response Signature Component

   If the Inquiry Response is being signed (see section 9.2.1) the
   Manifest Element of the Inquiry Response Signature Component should
   contain Digest elements of the Trading Response Block and the Status
   Component.

7.19.9 Ping Request Signature Component

   If the Ping Request is being singed (see section 9.2.2), the Manifest
   Element of the Ping Request Signature Component should contain Digest
   elements for all the Organisation Components.

Top      Up      ToC       Page 154 
7.19.10 Ping Response Signature Component

   If the Ping Response is being singed (see section 9.2.2), the
   Manifest Element of the Ping Response Signature Component should
   contain Digest elements fir all the Organisation Components.

7.20 Certificate Component

   Note: Definitions of the XML structures for signatures and
   certificates are described in the paper "Digital Signatures for the
   Internet Open Trading Protocol", see [IOTPDSIG].

   See note at the start of section 7.19 Signature Component for more
   details.

   A Certificate Component contains a Digital Certificate. They are used
   only when required, for example, when asymmetric cryptography is
   being used and the recipient of the signature that needs to check has
   not already received the Public Key.

   The structure of a Certificate Component is defined in [IOTPDSIG].

7.20.1 IOTP usage of signature elements and attributes

   Detailed definitions of the above elements and attributes are
   contained in [IOTPDSIG]. The following contains additional
   information that describes how these elements and attributes are used
   by IOTP.

   CERTIFICATE COMPONENT

   The ID attribute is mandatory.

   VALUE ELEMENT

   The ID attribute is mandatory.

7.21 Error Component

   The Error Component contains information about Technical Errors (see
   section 4.1) in an IOTP Message which has been received by one of the
   Trading Roles involved in the trade.

   For clarity two phrases are defined which are used in the description
   of an Error Component:

   o  message in error. An IOTP message which contains or causes an
      error of some kind

Top      Up      ToC       Page 155 
   o  message reporting the error. An IOTP message that contains an
      Error Component that describes the error found in a message in
      error.

   The definition of the Error Component is as follows.

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

   Attributes:

   ID                 An identifier which uniquely identifies the Error
                      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.

   ErrorCode          Contains an error code which indicates the nature
                      of the error in the message in error. Valid values
                      for the ErrorCode are given in section 7.21.2
                      Error Codes.

   ErrorDesc          Contains a narrative description of the error in
                      the language defined by xml:lang. The content of
                      this attribute is defined by the vendor/developer
                      of the software which generated the Error
                      Component

   Severity           Indicates the severity of the error.  Valid values
                      are:
                       o Warning. This indicates that although there is
                         a message in error the IOTP Transaction can
                         still continue.
                       o TransientError. This indicates that the error
                         in the message in error may be recovered if the
                         message in error  that is referred to by the
                         ErrorLocation element is resent

Top      Up      ToC       Page 156 
                       o HardError. This indicates that there is an
                         unrecoverable error in the message in error and
                         the IOTP Transaction must stop.

   MinRetrySecs       This attribute should be present if Severity is
                      set to TransientError. It is the minimum number of
                      whole seconds which the IOTP aware application
                      which received the message reporting the error
                      should wait before re-sending the message in error
                      identified by the ErrorLocation element.

                      If Severity is not set to TransientError then the
                      value of this attribute is ignored.

   SwVendorErrorRef   This attribute is a reference whose value is set
                      by the vendor/developer of the software which
                      generated the Error Component. It should contain
                      data which enables the vendor to identify the
                      precise location in their software and the set of
                      circumstances which caused the software to
                      generate a message reporting the error. See also
                      the SoftwareId attribute of the Message Id element
                      in the Transaction Reference Block (section 3.3).

   Content:

   ErrorLocation      This identifies the IOTP Transaction Id of the
                      message in error  and, where possible, the element
                      and attribute in the message in error that caused
                      the Error Component to be generated.

                      If the Severity of the error is not
                      TransientError, more than one ErrorLocation may be
                      specified as appropriate depending on the nature
                      of the error (see section 7.21.2 Error Codes) and
                      at the discretion of  the vendor/developer of the
                      IOTP Aware Application.

   PackagedContent    This contains additional data which can be used to
                      understand the error. Its content may vary as
                      appropriate depending on the nature of the error
                      (see section 7.21.2 Error Codes) and at the
                      discretion of the vendor/developer of the IOTP
                      Aware Application. For a definition of
                      PackagedContent see section 3.7.

Top      Up      ToC       Page 157 
7.21.1 Error Processing Guidelines

   If there is more than one Error Component in a message reporting the
   error, carry out the actions appropriate for the Error Component with
   the highest severity. In this context, HardError has a higher
   severity than TransientError, which has a higher severity than
   Warning.

7.21.1.1 Severity - Warning

   If an IOTP aware application is generating a message reporting the
   error with an Error Component where the Severity attribute is set to
   Warning, then if the message reporting the error does not contain
   another Error Component with a severity higher than Warning, the IOTP
   Message must also include the Trading Blocks and Trading Components
   that would have been included if no error was being reported.

   If a message reporting the error is received with an Error Component
   where Severity is set to Warning, then:

   o  it is recommended that information about the error is either
      logged, or otherwise reported to the user,

   o  the implementer of the IOTP aware application must either, at
      their or the user's discretion:

      -  continue the IOTP transaction as normal, or

      -  fail the IOTP transaction by generating a message reporting the
         error with an Error Component with Severity set to HardError
         (see section 7.21.1.3).

   If the intention is to continue the IOTP transaction then, if there
   are no other Error Components with a higher severity, check that the
   necessary Trading Blocks and Trading Components for normal processing
   of the transaction to continue are present. If they are not then
   generate a message reporting the error with an Error Component with
   Severity set to HardError.

7.21.1.2 Severity - Transient Error

   If an IOTP Aware Application is generating a message reporting the
   error with an Error Component where the Severity attribute is set to
   TransientError, then there should be only one Error Component in the
   message reporting the error. In addition, the MinRetrySecs attribute
   should be present.

Top      Up      ToC       Page 158 
   If a message reporting the error is received with an Error Component
   where Severity is set to TransientError then:

   o  if the MinRetrySecs attribute is present and a valid number, then
      use the MinRetrySecs value given. Otherwise if MinRetrySecs is
      missing or is invalid, then:

      -  generate a message reporting the error containing an Error
         Component with a Severity of Warning and send it on the next
         IOTP message (if any) to be sent to the Trading Role which sent
         the message reporting the error with the invalid MinRetrySecs,
         and

      -  use a value for MinRetrySecs which is set by the
         vendor/developer of the IOTP Aware Application.

   o  check that only one ErrorLocation element is contained within the
      Error Component and that it refers to an IOTP Message which was
      sent by the recipient of the Error Component with a Severity of
      TransientError. If more than one ErrorLocation is present then
      generate a message reporting the error with a Severity of
      HardError.

7.21.1.3 Severity - Hard Error

   If an IOTP Aware Application is generating a message reporting the
   error with an Error Component where the Severity attribute set to
   HardError, then there should be only one Error Component in the
   message reporting the error.

   If a message reporting the error is received with an Error Component
   where Severity is set to HardError then terminate the IOTP
   Transaction.

7.21.2 Error Codes

   The following table contains the valid values for the ErrorCode
   attribute of the Error Component. The first sentence of the
   description contains the text that should be used to describe the
   error when displayed or otherwise reported. Individual
   implementations may translate this into alternative languages at
   their discretion.

   An Error Code must not be more that 14 characters long.

Top      Up      ToC       Page 159 
        Value                           Description

   Reserved        Reserved. This error is reserved by the
                   vendor/developer of the software. Contact the
                   vendor/developer of the software for more information
                   See the SoftwareId attribute of the Message Id
                   element in the Transaction Reference Block(section
                   3.3).

   XmlNotWellFrmd  XML not well formed. The XML document is not well
                   formed. See [XML] for the meaning of "well formed".
                   Even if the XML is not well formed, it should still
                   be scanned to find the Transaction Reference Block so
                   that a properly formed Error Response may be
                   generated.

   XmlNotValid     XML not valid. The XML document is well formed but
                   the document is not valid. See [XML] for the meaning
                   of "valid". Specifically:
                    o the XML document does not comply with the
                     constraints defined in the IOTP document type
                     declaration (DTD) (see section 13 Internet Open
                     Trading Protocol Data Type Definition), and
                    o the XML document does not comply with the
                     constraints defined in the document type
                     declaration of any additional [XML-Namespace] that
                     are declared.

                   As for XML not well formed, attempts should still be
                   made to extract the Transaction Reference Block so
                   that a properly formed Error Response may be
                   generated.

   ElUnexpected    Unexpected element. Although the XML document is well
                   formed and valid, an element is present that is not
                   expected in the particular context according to the
                   rules and constraints contained in this
                   specification.

   ElNotSupp       Element not supported. Although the document is well
                   formed and valid, an element is present that:
                    o is consistent with the rules and constraints
                     contained in this specification, but
                    o is not supported by the IOTP Aware Application
                     which is processing the IOTP Message.

Top      Up      ToC       Page 160 
   ElMissing       Element missing. Although the document is well formed
                   and valid, an element is missing that should have
                   been present if the rules and constraints contained
                   in this specification are followed.

                   In this case set the PackagedContent of the Error
                   Component to the type of the missing element.

   ElContIllegal   Element content illegal. Although the document is
                   well formed and valid, the element Content contains
                   values which do not conform to the rules and
                   constraints contained in this specification.

   EncapProtErr    Encapsulated protocol error. Although the document is
                   well formed and valid, the PackagedContent of an
                   element contains data from an encapsulated protocol
                   which contains errors.

   AttUnexpected   Unexpected attribute. Although the XML document is
                   well formed and valid, the presence of the attribute
                   is not expected in the particular context according
                   to the rules and constraints contained in this
                   specification.

   AttNotSupp      Attribute not supported. Although the XML document is
                   well formed and valid, and the presence of the
                   attribute in an element is consistent with the rules
                   and constraints contained in this specification, it
                   is not supported by the IOTP Aware Application which
                   is processing the IOTP Message.

   AttMissing      Attribute missing. Although the document is well
                   formed and valid, an attribute is missing that should
                   have been present if the rules and constraints
                   contained in this specification are followed.

                   In this case set the PackagedContent of the Error
                   Component to the type of the missing attribute.

   AttValIllegal   Attribute value illegal. The attribute contains a
                   value which does not conform to the rules and
                   constraints contained in this specification.

   AttValNotRecog  Attribute Value Not Recognised. The attribute
                   contains a value which the IOTP Aware Application
                   generating the message reporting the error could not
                   recognise.

Top      Up      ToC       Page 161 
   MsgTooLarge     Message too large. The message is too large to be
                   processed by the IOTP Aware Application.

   ElTooLarge      Element too large. The element is too large to be
                   processed by the IOTP Aware Application

   ValueTooSmall   Value too small or early. The value of all or part of
                   the Content of an element or an attribute, although
                   valid, is too small.

   ValueTooLarge   Value too large or in the future. The value of all or
                   part of the Content of an element or an attribute,
                   although valid, is too large.

   ElInconsistent  Element Inconsistent. Although the document is well
                   formed and valid, according to the rules and
                   constraints contained in this specification:
                    o the content of an element is inconsistent with the
                     content of other elements or their attributes, or
                    o the value of an attribute is inconsistent with the
                     value of one or more other attributes.

                   In this case create ErrorLocation elements which
                   identify all the attributes or elements which are
                   inconsistent.

   TransportError  Transport Error. This error code is used to indicate
                   that there is a problem with the Transport Mechanism
                   which is preventing the message from being received.
                   It is typically associated with a Transient Error.
                   Explanation of the Transport Error is contained
                   within the ErrorDesc attribute. The values which can
                   be used inside ErrorDesc with a TransportError is
                   specified in the IOTP supplement for the Transport
                   mechanism.

   MsgBeingProc    Message Being Processed. This error code is only used
                   with a Severity of Transient Error. It indicates that
                   the previous message, which may be an exchange
                   message or a request message, is being processed and,
                   if no response is received by the time indicated by
                   the MinRetrySecs attribute, then the original message
                   should be resent.

   SystemBusy      System Busy. This error code is only used with a
                   Severity of Transient Error. It indicates that the
                   server that received a message is currently too busy
                   to handle the message. If no response is received by

Top      Up      ToC       Page 162 
                   the time indicated by the MinRetrySecs attribute,
                   then the original message should be resent.

   Note: If the server/system handling the Transport Mechanism (e.g.,
   HTTP) is busy then a Transport Specific error message should be used
   instead of an IOTP Error message. This code should be used in
   association with IOTP servers/systems or other servers/systems to
   which the IOTP server is connected.

   UnknownError    Unknown Error. Indicates that the transaction cannot
                   complete for some reason that is not covered
                   explicitly by any of the other errors.  The ErrorDesc
                   attribute should be used to indicate the nature of
                   the problem.

                   This could be used to indicate, for example, an
                   internal error in a backend server or client process
                   of some kind.

7.21.3 Error Location Element

   An Error Location Element identifies an element and optionally an
   attribute in the message in error which is associated with the error.
   It contains a reference to the IOTP Message, Trading Block, Trading
   Component, element and attribute, which is in error.

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

   Attributes:

   ElementType        This is the name of the type of the element where
                      the error is located. For example if the element
                      was declared as <!ELEMENT Org ... then its name is
                      "Org".

   IotpMsgRef         This is the value of the ID attribute of the of
                      the Message Id Component (see section 3.3.2) of
                      the message in error to which this Error Component
                      applies.

Top      Up      ToC       Page 163 
   BlkRef             If the error is associated with a specific Trading
                      Block, then this is the value of the ID attribute
                      of the Trading Block where the error is located.

   CompRef            If the error is associated with a specific Trading
                      Component, then this is the value of the ID
                      attribute of the Trading Component where the error
                      is located.

   ElementRef         If the error is associated with a specific element
                      within a Trading Component then, if the element
                      has an attribute with an "attribute type" (see
                      [XML]) of "ID", then this is the value of that
                      attribute.

   AttName            If the error is associated with the value of an
                      attribute, then this is the name of that
                      attribute. In this case the PackagedContent of the
                      Error Component should contain the value of the
                      attribute.

   Note that as many as the attributes as possible should be included.
   For example if an attribute in a child element of a Trading Component
   contains an incorrect value, then all the attributes of ErrorLocation
   should be present.



(page 163 continued on part 6)

Next RFC Part