RFC 2801
Internet Open Trading Protocol - IOTP Version 1.0
Pages: 290
Informational
Informational
Part 5 of 9 – Pages 125 to 163
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.
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.
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.
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.
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
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 >
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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,
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"
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).
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
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
o the Brand Selection Component. o any Trading Role Data Components7.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 Component7.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)
- 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.
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
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
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.
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.
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.
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.
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.
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
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.
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)