rfc2935.txt

中、英文RFC文档大全打包下载完全版 .


RFC 2935                  IOTP HTTP Supplement            September 2000


      IOTP Transaction, and hand control to the browser so that it will
      do a GET from the Error Net Location specified for the role from
      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 may
      automatically retry.  On failure due to time out, treat as an
      error above.

   Each implementation of an IOTP client may decide whether or not to
   terminate the IOTP Client application immediately upon completing an
   IOTP Transaction or whether to wait until it is closed down as a
   result of, for example, user shut down or browser shut down.

5. Starting the Payment handler and Deliverer IOTP Servers

   Payment Handler and Deliverer IOTP Servers are started by receiving
   an IOTP Message which contains:

   -- for a Payment handler, a Payment Request Block, and

   -- for a Delivery Handler, a Delivery Request Block

6. Security Considerations

   Security of Internet Open Trade Protocol messages is primarily
   dependent on signatures within IOTP as described in [RFC 2801] and
   [RFC 2802].  Privacy protection for IOTP interactions can be obtained
   by using a secure channel for IOTP messages, such as SSL/TLS [RFC
   2246].

   Note that the security of payment protocols transported by IOTP is
   the responsibility of those payment protocols, NOT of IOTP.

7. IANA Considerations

   This specification defines the APPLICATION/IOTP MIME type.  The
   registration template is as follows [RFC 2048]:

      To: [e-mail]

      Subject: Registration of MIME media type APPLICATION/IOTP

      MIME media type name: APPLICATION

      MIME subtype name: IOTP

      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 cases
      require quoted printable or base64 encoding.  However, no encoding
      is required for HTTP transport which is expected to be common.

      Security considerations: IOTP includes provisions for digital
      authentication but for confidentiality, other mechanisms such as
      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 Trading
      Protocol applications.

      Additional information: (none)

      Person & email address to contact for further information:
         Name: Donald E. Eastlake 3rd
         Email: [e-mail]

      Intended usage: COMMON

      Author/Change controller: IETF

8. References

   [RFC 1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
              Internet Mail Extensions (MIME) Part Four: Registration
              Procedure", RFC 2048, November 1996.

   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
              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, "Uniform
              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, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC 2801] Burdett, D., "Internet Open Trading Protocol - IOTP
              Version 1.0", RFC 2801, April 2000.

   [RFC 2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the
              v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802,
              April 2000

   [XML]      Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible
              Markup Language (XML) 1.0" <http://www.w3.org/TR/REC-xml>,
              February 1998.

9. Authors' Addresses

   Donald E. Eastlake 3rd
   Motorola
   140 Forest Avenue
   Hudson, MA 01749 USA

   Phone: [phone](h)
          [phone](w)
   Fax:   [phone](w)
   EMail: [e-mail]


   Chris J. Smith
   Royal Bank of Canada
   277 Front Street West
   Toronto, Ontario M5V 3A4 CANADA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]















Eastlake & Smith            Standards Track                     [Page 7]

RFC 2935                  IOTP HTTP Supplement            September 2000


10.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Eastlake & Smith            Standards Track                     [Page 8]