As per Relevance of the word standards, we have this rfc below:
Network Working Group D.
Request for Comments: 2935
Category: Standards Track C.
Royal Bank of
September 2000
Internet Open Trading Protocol (IOTP) HTTP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
Internet Open Trading Protocol (IOTP) messages will be carried
Extensible Markup Language (XML) documents. As such, the goal
mapping to the transport layer is to ensure that the underlying
documents are carried successfully between the various parties
This document describes that mapping for the Hyper Text
Protocol (HTTP), Versions 1.0 and 1.1.
Table of
1. Introduction................................................... 2
2. HTTP Servers and Clients....................................... 2
3. HTTP Net Locations............................................. 2
4. Consumer Clients............................................... 2
4.1 Starting the IOTP Client and the Merchant IOTP Server.......... 3
4.2 Ongoing IOTP Messages.......................................... 3
4.3 Stopping an IOTP Transaction................................... 4
5. Starting the Payment handler and Deliverer IOTP Servers........ 5
6. Security Considerations........................................ 5
7. IANA Considerations............................................ 5
8. References..................................................... 6
9. Authors' Addresses............................................. 7
10. Full Copyright Statement....................................... 9
Eastlake & Smith Standards Track [Page 1]
RFC 2935 IOTP HTTP Supplement September 2000
1.
Internet Open Trading Protocol (IOTP) [RFC2801] messages will
carried as XML [XML] documents. As such, the goal of mapping to
transport layer is to ensure that the underlying XML documents
carried successfully between the various parties
This document describes that mapping for the Hyper Text
Protocol (HTTP), Versions 1.0 and 1.1 [RFCs 1945, 2616].
There may be future documents describing IOTP over email (SMTP), TCP
cable TV, or other transports
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
2. HTTP Servers and
The structure of IOTP maps on to the structure of HTTP in
following way
The merchant, payment handler, delivery handler, and customer
roles are all represented by HTTP servers. Each may
represented by a separate server, or they may be combined in
combination
The consumer role is represented by an HTTP client
Note: A Merchant, may act in the role of a consumer, for example
deposit electronic cash. In this case the Merchant, as
organization rather than as a role, would need to be supported by
HTTP client
3. HTTP Net
The Net Locations contained within the IOTP specification are
URIs [RFC 2396]. If a secure connection is required or desired
secure channel that both the HTTP Server and Client support MUST
used. Examples of such channels are SSL version 3 or TLS [RFC 2246].
4. Consumer
In most environments, the consumer agent will initially be an
browser. However, current browsers do not provide the
capability to act as an agent for the consumer for an
transaction. This leads to two requirements
Eastlake & Smith Standards Track [Page 2]
RFC 2935 IOTP HTTP Supplement September 2000
a method of starting and passing control to the IOTP client,
a method of closing down the IOTP client cleanly and passing
back to the HTML browser once the IOTP Transaction has finished
4.1 Starting the IOTP Client and the Merchant IOTP
At some point, the HTTP client at the consumer will send an
request that is interpreted as an "IOTP Startup Request" by
Merchant HTTP server. This might, for example, be the result
clicking on a "pay" button. This message is a stand-in for a
message of some form and the Merchant Server will respond with
first IOTP Message in the form of an XML document
The MIME type for all IOTP messages is: "APPLICATION/IOTP";
"APPLICATION/X-IOTP" has been in use for experimentation
development and SHOULD also be recognized. See section 7 below
the MIME type registration template for APPLICATION/IOTP.
HTTP is binary clean, no content-transfer-encoding is required. (
[RFC 2376] re the application/xml type which has some
considerations.)
This HTTP response will be interpreted by the HTML browser as
request to start the application associated with MIME
"APPLICATION/IOTP", and to pass the content of this message to
application
At this point, the IOTP client will be started and have the
message
IOTP messages are short-lived. Therefore, the HTTP server
avoid having its responses cached. In HTTP V1.0, the "nocache
pragma can be used. This can be neglected on SSL/TLS
connections which are not cached and on HTTP POST requests in
v1.1 as in v1.1 POST responses are not cached
4.2 Ongoing IOTP
Data from earlier IOTP Messages in a transaction MUST be retained
the IOTP Client so that it may (1) be copied to make up part of
IOTP messages, (2) used in calculations to verify signatures in
IOTP message, (3) be resent in some cases where a request has
out without response, (4) used as input to the Customer Care role
later versions of IOTP, etc. The way in which the data is
depends on the IOTP Transaction. The data MUST be retained until
end of the transaction, whether by success, failure, or cancelation
and as long thereafter as it is desired for any of the parties
inquire into it
Eastlake & Smith Standards Track [Page 3]
RFC 2935 IOTP HTTP Supplement September 2000
The IOTP messages contain Net Locations (e.g. the PayReqNetLocn
which for HTTP will contain the URIs to which the IOTP client
send IOTP messages
Subsequent IOTP messages (XML documents) will be sent using the
function of HTTP. The HTTP client MUST perform full HTTP
requests
The XML documents MUST be sent in a manner compatible with
external encodings allowed by the XML [XML] specification
4.3 Stopping an IOTP
The following should be read in conjunction with [RFC 2801].
An IOTP Transaction is complete
-- the IOTP client decides to fail the IOTP Transaction for
reason either by canceling the transaction or as a result
discovering an error in an IOTP message received,
-- a "time out" occurs or a connection fails, e.g. a response to
IOTP Message, has not been received after some user-defined
of Time (including retransmissions).
An IOTP Client which processes an IOTP Transaction which
-- completes successfully (i.e. it has not received an Error
with a HardError or a Cancel Block) MUST direct the browser to
Net Location specified in SuccessNetLocn in the Protocol
Component, i.e., cause it to do an HTTP GET with that URL
-- does not complete successfully, because it has received some
Trading Block, MUST display the information in the Error Message
stop the transaction, and pass control to the browser so that
will do a GET on the Error Net Location specified for the
from which the error was received
-- is cancelled since a Cancel Block has been received, MUST stop
IOTP Transaction and hand control to the browser so that it
do a GET on the on the Cancel Net Location specified for the
from which the Cancel Block was received
-- is in error because an IOTP Message does not conform to
specification, MUST send an IOTP Message containing a
Trading Block to role from which the erroneous message
received and the ErrorLogNetLoc specified for that role, stop
Eastlake & Smith Standards Track [Page 4]
RFC 2935 IOTP HTTP Supplement September 2000
IOTP Transaction, and hand control to the browser so that it
do a GET from the Error Net Location specified for the role
which the bad message was received
-- has a "time out", MUST display a message describing the time out
May give the user the option of cancelling or retrying and/or
automatically retry. On failure due to time out, treat as
error above
Each implementation of an IOTP client may decide whether or not
terminate the IOTP Client application immediately upon completing
IOTP Transaction or whether to wait until it is closed down as
result of, for example, user shut down or browser shut down
5. Starting the Payment handler and Deliverer IOTP
Payment Handler and Deliverer IOTP Servers are started by
an IOTP Message which contains
-- for a Payment handler, a Payment Request Block,
-- for a Delivery Handler, a Delivery Request
6. Security
Security of Internet Open Trade Protocol messages is
dependent on signatures within IOTP as described in [RFC 2801]
[RFC 2802]. Privacy protection for IOTP interactions can be
by using a secure channel for IOTP messages, such as SSL/TLS [
2246].
Note that the security of payment protocols transported by IOTP
the responsibility of those payment protocols, NOT of IOTP
7. IANA
This specification defines the APPLICATION/IOTP MIME type.
registration template is as follows [RFC 2048]:
To: ietf-types@iana.
Subject: Registration of MIME media type APPLICATION/
MIME media type name:
MIME subtype name:
Required parameters: (none
Eastlake & Smith Standards Track [Page 5]
RFC 2935 IOTP HTTP Supplement September 2000
Optional parameters: charset - see RFC 2376
Encoding considerations: Content is XML and may in some
require quoted printable or base64 encoding. However, no
is required for HTTP transport which is expected to be common
Security considerations: IOTP includes provisions for
authentication but for confidentiality, other mechanisms such
TLS should be used. See RFC 2801 and RFC 2802.
Interoperability considerations: See RFC 2801.
Published specification: See RFC 2801 and RFC 2802.
Applications which use this media type: Internet Open
Protocol applications
Additional information: (none
Person & email address to contact for further information
Name: Donald E. Eastlake 3
Email: Donald.Eastlake@motorola.
Intended usage:
Author/Change controller:
8.
[RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC 2048] Freed, N., Klensin, J. and J. Postel, "
Internet Mail Extensions (MIME) Part Four:
Procedure", RFC 2048, November 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC 2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376,
July 1998.
[RFC 2396] Berners-Lee, T., Rielding, R. and L. Masinter, "
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
Eastlake & Smith Standards Track [Page 6]
RFC 2935 IOTP HTTP Supplement September 2000
[RFC 2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC 2801] Burdett, D., "Internet Open Trading Protocol -
Version 1.0", RFC 2801, April 2000.
[RFC 2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for
v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802,
April 2000
[XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "
Markup Language (XML) 1.0" ,
February 1998.
9. Authors'
Donald E. Eastlake 3
140 Forest
Hudson, MA 01749
Phone: +1 978-562-2827(h
+1 508-261-5434(w
Fax: +1 508-261-4447(w
EMail: Donald.Eastlake@motorola.
Chris J.
Royal Bank of
277 Front Street
Toronto, Ontario M5V 3A4
Phone: +1 416-348-6090
Fax: +1 416-348-2210
EMail: chris.smith@royalbank.
Eastlake & Smith Standards Track [Page 7]
RFC 2935 IOTP HTTP Supplement September 2000
10. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Eastlake & Smith Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
