Internet Open Trading Protocol (IOTP) HTTP Supplement
Extracted elements (20)
Consumer agents are expected to initially be HTML browsers, which lack native IOTP capability. The design relies on the browser's MIME type dispatch mechanism to launch a separate IOTP client application when the server returns an APPLICATION/IOTP response, cleanly separating IOTP client lifecycle from the browser.
IOTP messages are described as short-lived, motivating the requirement that servers avoid caching responses. This ensures that each transaction step always involves a fresh exchange rather than a stale cached response.
The experimental MIME type APPLICATION/X-IOTP was used for development prior to standardization and SHOULD be recognized alongside the official APPLICATION/IOTP type for backward compatibility with deployed implementations.
Data from earlier IOTP messages in a transaction MUST be retained by the IOTP client for use in later messages, signature verification, retransmission, and customer care. Data MUST be retained until the end of the transaction and as long thereafter as any party may inquire.
If a Cancel Block is received, the IOTP client MUST stop the transaction and hand control to the browser to perform a GET on the Cancel Net Location specified for the role that sent the Cancel Block.
If a secure connection is required or desired, a secure channel that both the HTTP server and client support MUST be used. Examples include SSL version 3 or TLS (RFC 2246).
If an Error Trading Block is received, the IOTP client MUST display the error information, stop the transaction, and pass control to the browser to perform an HTTP GET on the Error Net Location for the role that sent the error.
If an IOTP message does not conform to the specification, the client MUST send an IOTP Error Trading Block to the offending role and to the ErrorLogNetLoc for that role, stop the transaction, and hand control to the browser to GET the Error Net Location.
On successful IOTP transaction completion (no HardError or Cancel Block received), the IOTP client MUST direct the browser to the Net Location specified in SuccessNetLocn via HTTP GET.
On transaction timeout, the IOTP client MUST display a message describing the timeout. It MAY offer the user the option to cancel or retry, and/or may automatically retry. On timeout failure, the situation is treated as an error.
Subsequent IOTP messages (XML documents) MUST be sent using the HTTP POST method. The HTTP client MUST perform full HTTP POST requests to the URIs specified in the Net Locations of IOTP messages.
The HTTP server SHOULD avoid having its IOTP responses cached. In HTTP/1.0 the 'nocache' pragma can be used; POST responses in HTTP/1.1 are not cached; SSL/TLS connections are also not cached.
XML documents carrying IOTP messages MUST be sent in a manner compatible with the external encodings allowed by the XML specification.
IOTP roles map to HTTP roles as follows: merchant, payment handler, delivery handler, and customer care are all HTTP servers; the consumer role is represented by an HTTP client. Multiple roles may be combined on a single server.
Net Locations in the IOTP specification are all URIs (RFC 2396). For HTTP transport, these URIs indicate the endpoints to which IOTP messages are sent.
Payment Handler IOTP servers are started upon receiving an IOTP message containing a Payment Request Block; Delivery Handler IOTP servers are started upon receiving a Delivery Request Block.
The MIME type for all IOTP messages is APPLICATION/IOTP. The experimental type APPLICATION/X-IOTP has been used for development and SHOULD also be recognized. No content-transfer-encoding is required for HTTP transport.
This document registers the APPLICATION/IOTP MIME media type with IANA. Optional parameter: charset (see RFC 2376). Encoding: XML content; no encoding required for HTTP transport. Security: IOTP includes digital authentication; confidentiality requires TLS.
Security of IOTP messages depends primarily on digital signatures within IOTP as described in RFC 2801 and RFC 2802. Confidentiality protection requires a separate secure channel such as SSL/TLS (RFC 2246). Security of payment protocols transported by IOTP is the responsibility of those payment protocols, not of IOTP.
An IOTP transaction ends in one of four terminal states: (1) successful completion — client directs browser to SuccessNetLocn via HTTP GET; (2) error block received — display error, stop transaction, GET ErrorNetLocn; (3) cancel block received — stop transaction, GET CancelNetLocn; (4) non-conforming message — send Error Trading Block, stop, GET ErrorNetLocn.