draft-ietf-trade-iotp-http-04.txt   draft-ietf-trade-iotp-http-05.txt 
INTERNET-DRAFT IOTP HTTP Supplement INTERNET-DRAFT IOTP HTTP Supplement
March 2000 April 2000
Expires September 2000 Expires October 2000
Internet Open Trading Protocol (IOTP) HTTP Supplement Internet Open Trading Protocol (IOTP) HTTP Supplement
-------- ---- ------- -------- ------ ---- ---------- -------- ---- ------- -------- ------ ---- ----------
<draft-ietf-trade-iotp-http-04.txt> <draft-ietf-trade-iotp-http-05.txt>
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Chris J. Smith Chris J. Smith
Status of This Document Status of This Document
This draft is intended to become a Proposed Standard RFC. This draft is intended to become a Proposed Standard RFC.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the TRADE WG mailing list <ietf-trade@eListX.com> or to the to the TRADE WG mailing list <ietf-trade@eListX.com> or to the
authors. authors.
skipping to change at page 4, line 48 skipping to change at page 4, line 48
avoid having its responses cached. In HTTP V1.0, the "nocache" avoid having its responses cached. In HTTP V1.0, the "nocache"
pragma can be used. This can be neglected on SSL/TLS secured pragma can be used. This can be neglected on SSL/TLS secured
connections which are not cached and on HTTP POST requests in HTTP connections which are not cached and on HTTP POST requests in HTTP
v1.1 as in v1.1 POST responses are not cached. v1.1 as in v1.1 POST responses are not cached.
4.2 Ongoing IOTP Messages 4.2 Ongoing IOTP Messages
Data from earlier IOTP Messages in a transaction must be retained by Data from earlier IOTP Messages in a transaction must be retained by
the IOTP Client so that it may (1) be copied to make up part of later the IOTP Client so that it may (1) be copied to make up part of later
IOTP messages, (2) used in calculations to verify signatures in later IOTP messages, (2) used in calculations to verify signatures in later
IOTP message, (3) be resent in some cases where a request has times IOTP message, (3) be resent in some cases where a request has timed
out without response, (4) used as input to the Customer Care role in out without response, (4) used as input to the Customer Care role in
later versions of IOTP, etc. The way in which the data is copied later versions of IOTP, etc. The way in which the data is copied
depends on the IOTP Transaction. depends on the IOTP Transaction.
The IOTP messages contain Net Locations (e.g. the PayReqNetLocn) The IOTP messages contain Net Locations (e.g. the PayReqNetLocn)
which for HTTP will contain the URIs to which the IOTP client must which for HTTP will contain the URIs to which the IOTP client must
ship IOTP messages. ship IOTP messages.
Subsequent IOTP messages (XML documents) will be sent using the POST Subsequent IOTP messages (XML documents) will be sent using the POST
function of HTTP. The HTTP client has to perform full HTTP POST function of HTTP. The HTTP client has to perform full HTTP POST
skipping to change at page 6, line 36 skipping to change at page 6, line 36
-- for a Payment handler, a Payment Request Block, and -- for a Payment handler, a Payment Request Block, and
-- for a Delivery Handler, a Delivery Request Block -- for a Delivery Handler, a Delivery Request Block
6. Security Considerations 6. Security Considerations
Security of Internet Open Trade Protocol messages is primarily Security of Internet Open Trade Protocol messages is primarily
dependent on signatures within IOTP as described in [draft-ietf- dependent on signatures within IOTP as described in [draft-ietf-
trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-iotp-v1.0- trade-iotp-v1.0-protocol-*.txt] and [draft-ietf-trade-iotp-v1.0-
dsig-*.txt]. Privacy protection for IOTP interactions should be dsig-*.txt]. Privacy protection for IOTP interactions should be
obtained by using a secure channle for IOTP messages, such as SSL/TLS obtained by using a secure channel for IOTP messages, such as SSL/TLS
[RFC 2246]. [RFC 2246].
Note that the security of payment protocols transported by IOTP is Note that the security of payment protocols transported by IOTP is
the responsibility of those payment protocols, NOT of IOTP. the responsibility of those payment protocols, NOT of IOTP.
7. IANA Considerations 7. IANA Considerations
This specification defines the application/iotp mime type. The This specification defines the application/iotp mime type. The
registration template is as follows [RFC 2048]: registration template is as follows [RFC 2048]:
To: ietf-types@iana.org To: ietf-types@iana.org
Subject: Registration of MIME media type APPLICATION/IOTP Subject: Registration of MIME media type APPLICATION/IOTP
MIME media type name: APPLICATION MIME media type name: APPLICATION
MIME subtype name: IOTP MIME subtype name: IOTP
Required parameters: (none) Required parameters: (none)
Optional parameters: (none) Optional parameters: charset - see RFC 2376
Encoding considerations: Content is XML and may in some cases Encoding considerations: Content is XML and may in some cases
require quoted printable or base64 encoding. However, no encoding require quoted printable or base64 encoding. However, no encoding
is required for HTTP transport which is expected to be common. is required for HTTP transport which is expected to be common.
Security considerations: IOTP includes provisions for digital Security considerations: IOTP includes provisions for digital
authentication but for confidentiality, other mechanisms such as authentication but for confidentiality, other mechanisms such as
TLS should be used. See draft-ietf-trade-iotp-v1.0-protocol- TLS should be used. See draft-ietf-trade-iotp-v1.0-protocol-
07.txt in RFC Editor's queue. 07.txt and draft-ietf-trade-iotp-v1.0-dsig-*.txt in RFC Editor's
queue.
Interoperability considerations: See draft-ietf-trade-iotp-v1.0- Interoperability considerations: See draft-ietf-trade-iotp-v1.0-
protocol-07.txt in RFC Editor's queue. protocol-07.txt in RFC Editor's queue.
Published specification: See draft-ietf-trade-iotp-v1.0-protocol- Published specification: See draft-ietf-trade-iotp-v1.0-protocol-
07.txt in RFC Editor's queue. 07.txt and draft-ietf-trade-iotp-v1.0-dsig-*.txt in RFC Editor's
queue.
Applications which use this media type: Internet Open Trading Applications which use this media type: Internet Open Trading
Protocol applications. Protocol applications.
Additional information: (none) Additional information: (none)
Person & email address to contact for further information: Person & email address to contact for further information:
Name: Donald E. Eastlake 3rd Name: Donald E. Eastlake 3rd
Email: Donald.Eastlake@motorola.com Email: Donald.Eastlake@motorola.com
skipping to change at page 9, line 28 skipping to change at page 9, line 28
Royal Bank of Canada Royal Bank of Canada
277 Front Street West 277 Front Street West
Toronto, Ontario M5V 3A4 CANADA Toronto, Ontario M5V 3A4 CANADA
Telephone: +1 416-348-6090 Telephone: +1 416-348-6090
FAX: +1 416-348-2210 FAX: +1 416-348-2210
email: chris.smith@royalbank.com email: chris.smith@royalbank.com
Expiration and File Name Expiration and File Name
This draft expires September 2000. This draft expires October 2000.
Its file name is draft-ietf-trade-iotp-http-04.txt. Its file name is draft-ietf-trade-iotp-http-05.txt.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/