rfc2801.txt

RFC 的详细文档！

      services to the Consumer on behalf of the Merchant.

   o  Merchant Customer Care Provider. The entity that is involved with
      customer dispute negotiation and resolution on behalf of the
      Merchant

   Roles may be carried out by the same organisation or different
   organisations. For example:

   o  in the simplest case one physical organisation (e.g., a merchant)
      could handle the purchase, accept the payment, deliver the goods
      and provide merchant customer care

   o  at the other extreme, a merchant could handle the purchase but
      instruct the consumer to pay a bank or financial institution,
      request that delivery be made by an overnight courier firm and to
      contact an organisation which provides 24x7 service if problems
      arise.

   Note that in this specification, unless stated to the contrary, when
   the words Consumer, Merchant, Payment Handler, Delivery Handler or
   Customer Care Provider are used, they refer to the Trading Role
   rather than an actual organisation.

   An individual organisation may take multiple roles. For example a
   company which is selling goods and services on the Internet could
   take the role of Merchant when selling goods or services and the role
   of Consumer when the company is buying goods or services itself.

   As roles occur in different places there is a need for the
   organisations involved in the trade to exchange data, i.e. to carry
   out Trading Exchanges, so that the trade can be completed.






Burdett                      Informational                     [Page 17]

RFC 2801                       IOTP/1.0                       April 2000


2.2 Trading Exchanges

   The Internet Open Trading Protocols identify four Trading Exchanges
   which involve the exchange of data between the Trading Roles. The
   Trading Exchanges are:

   o  Offer. The Offer Exchange results in the Merchant providing the
      Consumer with the reason why the trade is taking place. It is
      called an Offer since the Consumer must accept the Offer if a
      trade is to continue

   o  Payment. The Payment Exchange results in a payment of some kind
      between the Consumer and the Payment Handler. This may occur in
      either direction

   o  Delivery. The Delivery Exchange transmits either the on-line
      goods, or delivery information about physical goods from the
      Delivery Handler to the Consumer, and

   o  Authentication. The Authentication Exchange can be used by any
      Trading Role to authenticate another Trading Role to check that
      they are who they appear to be.

   IOTP Transactions are composed of various combinations of these
   Trading Exchanges.  For example, an IOTP Purchase transaction
   includes Offer, Payment, and Delivery Trading Exchanges.  As another
   example, an IOTP Value Exchange transaction is composed of an Offer
   Trading Exchange and two Payment Trading Exchanges.

   Trading Exchanges consist of Trading Components that are transmitted
   between the various Trading Roles.  Where possible, the number of
   round-trip delays in an IOTP Transaction is minimised by packing the
   Components from several Trading Exchanges into combination IOTP
   Messages.  For example, the IOTP Purchase transaction combines a
   Delivery Organisation Component with an Offer Response Component in
   order to avoid an extra Consumer request and response.

   Each of the IOTP Trading Exchanges is described in more detail below.
   For clarity of description, these describe the Trading Exchanges as
   though they were standalone operations.  For performance reasons, the
   Trading Exchanges are intermingled in the actual IOTP Transaction
   definitions.









Burdett                      Informational                     [Page 18]

RFC 2801                       IOTP/1.0                       April 2000


2.2.1 Offer Exchange

   The goal of the Offer Exchange is for the Merchant to provide the
   Consumer with information about the trade so that the Consumer can
   decide whether to continue with the trade. This is illustrated in the
   figure below.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
   Consumer
     |  Merchant
STEP |     |
 1.          Consumer decides to trade and sends information about the
             transaction (requests an offer) to the Merchant e.g.,
             using HTML.

     C --> M Data: Information on what is being purchased (Offer Request)
             - outside scope of IOTP

 2.          Merchant checks the information provided by the Consumer,
             creates an Offer optionally signs it and sends it to the
             Consumer.

     C <-- M OFFER RESPONSE. Components: Status; Organisation(s)
             (Consumer, DelivTo, Merchant, Payment Handler, Customer
             Care); Order; Payment; Delivery; TradingRoleData (optional)
             Offer Response Signature (optional) that signs other
             components

 3.          Consumer checks the information from the Merchant and
             decides whether to continue.

 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

                           Figure 2 Offer Exchange

   An Offer Exchange uses the following Trading Components that are
   passed between the Consumer and the Merchant:

   o  the Status component is used to indicate to other parties that a
      valid Offer Response has been generated

   o  the Organisation Component contains information which describes
      the Organisations which are taking a role in the trade:

      -  the consumer provides information, about who the consumer is
         and, if goods or services are being delivered, where the goods
         or services are to be delivered to




Burdett                      Informational                     [Page 19]

RFC 2801                       IOTP/1.0                       April 2000


      -  the merchant augments this information by providing information
         about the merchant, the Payment Handler, the customer care
         provider and, if goods or services are being delivered, the
         Delivery Handler

   o  the Order Component contains descriptions of the goods or services
      which will result from the trade if the consumer agrees to the
      offer.  This information is sent by the Merchant to the consumer
      who should verify it

   o  the Payment Component generated by the Merchant, contains details
      of how much to pay, the currency and the payment direction, for
      example the consumer could be asking for a refund. Note that there
      may be more than one payment in a trade

   o  the Delivery Component, also generated by the Merchant, is used if
      goods or services are being delivered. This contains information
      about how delivery will occur, for example by post or using e-mail

   o  the Trading Role Data component contains data the Merchant wants
      to forward to another Trading Role such as a Payment Handler or
      Delivery Handler

   o  the "Offer Response" Signature Component, if present, digitally
      signs all of the above components to ensure their integrity.

   The exact content of the information provided by the Merchant to the
   Consumer will vary depending on the type of IOTP Transaction. For
   example:

   o  low value purchases may not need a signature

   o  the amount to be paid may vary depending on the payment brand and
      payment protocol used

   o  some offers may not involve the delivery of any goods

   o  a value exchange will involve two payments

   o  a merchant may not offer customer care.

   Information provided by the consumer to the merchant is provided
   using a variety of methods, for example, it could be provided:

   o  using [HTML] pages as part of the "shopping experience" of the
      consumer.





Burdett                      Informational                     [Page 20]

RFC 2801                       IOTP/1.0                       April 2000


   o  Using the Open Profiling Standard [OPS] which has recently been
      proposed,

   o  in the form of Organisation Components associated with an
      authentication of a Consumer by a Merchant

   o  as Order Components in a later version of IOTP.

2.2.2 Payment Exchange

   The goal of the Payment Exchange is for a payment to be made from the
   Consumer to a Payment Handler or vice versa using a payment brand and
   payment protocol selected by the Consumer. A secondary goal is to
   optionally provide the Consumer with a digitally signed Payment
   Receipt which can be used to link the payment to the reason for the
   payment as described in the Offer Exchange.

   Payment Exchanges can work in a variety of ways. The most general
   case where the trade is dependent on the payment brand and protocol
   used is illustrated in the diagram below. Simpler payment exchanges
   are possible.

 *+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*
  Consumer  Pay Handler
     |  Merchant |
STEP |     |     |
 1.                 Consumer decides to trade and sends information
                    about the transaction (requests an offer) to the
                    Merchant e.g., using HTML.

     C --> M        Information on what is being paid for (outside
                    scope of IOTP

 2.                 Merchant decides which payment brand, payment
                    protocols and currencies/amounts to offer,
                    places then in a Brand List Component and sends
                    them to the Consumer

     C <-- M        Components: Brand List

 3.                 Consumer selects the payment brand, protocol and
                    currency/amount to use, creates a Brand Selection
                    component and sends it to the Merchant

     C --> M        Component: Brand List Selection






Burdett                      Informational                     [Page 21]

RFC 2801                       IOTP/1.0                       April 2000


 4.                 Merchant checks Brand Selection, creates a Payment
                    Amount information, optionally signs it to
                    authorise payment and sends it to the Consumer

     C <-- M        Component: Payment; Organisation(s) (Merchant and
                    Payment Handler); Optional Offer Response Signature
                    that signs other components

 5.                 Consumer checks the Payment Amount information and
                    if OK requests that the payment starts by sending
                    information to the Payment Handler

     C --------> P  PAYMENT REQUEST. Components: Status, Payment;
                    Organisations (Merchant and Payment Handler);
                    Trading Role Data (optional); Optional Offer
                    Response Signature that signs other components;
                    Pay Scheme Data

 6.                 Payment Handler checks information including
                    optional signature and if OK starts exchanging Pay
                    Scheme Data components for selected payment brand
                    and payment protocol

     C <-------> P  PAYMENT EXCHANGE. Component: Pay Scheme Data

 7.                 Eventually payment protocol messages finish so
                    Payment Handler sends Pay Receipt and optional
                    signature to the Consumer as proof of payment

     C <-------> P  PAYMENT RESPONSE. Components: Status, Pay Receipt;
                    Payment Note; Trading Role Data (optional);
                    Optional Offer Response Signature; Optional
                    Payment Receipt Signature that binds the payment
                    to the Offer

 8.                 Consumer checks Payment Receipt is OK

 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*