Subject: Two questions to IOTP spec

From: Johannes Lessmann <[email-masked]>
Date: Fri, 14 Jul 2000 12:16:08 +0200

Hi,

i intend to make a test implementation of IOTP.

I have two questions:

1) Imagine a consumer makes an order (step 1 in Offer Doc Exchange).
   How can a merchant directly tell him that the ordered goods are
   not available. As far as i see, the merchant would need to
   send back an Offer Resp Block with Status comp with CompletionCode
   "PermNotAvail" or "TempNotAvail". But in order to do this, the 
   StatusType must be "Delivery". Yet we are in an Offer Exchange, so
   the StatusType has to be "Offer" according to the spec.
   Where am i wrong?

2) As far as i see, the IOTP only deals with communication between
   a consumer and a non-consumer. Is that true? Would it not be
   sensefull if the Delivery Request were initiated by the merchant
   rather than the consumer (step 1 of Delivery Doc Exchange)?
   How does a merchant get to know that the payment was successfully
   performed? Or cancelled?
   
Please excuse me if the quesions were already discussed earlier.

Thanks,

Johannes
C-Lab, Germany

---

From: Chris Smith <[email-masked]>
Date: Fri, 14 Jul 2000 20:32:12 -0400 (Eastern Daylight Time)

>    the StatusType has to be "Offer" according to the spec.

IOTP is a purchase protocol, and as such, would not normally get invoked
until after 'shopping' is finished. A completely integrated merchant
would control the availability of goods to be placed in a virtual shopping
cart (for example).

When the consumer indicates "checkout", the merchant would already know
that only available items are in the cart and so everything that the
consumer wants is available.

Alternatively, if there is the possibility of unavailable items in the
cart, the merchant has three choices:

a) since the request to 'checkout' is not actually a request of
type application/iotp, the merchant is free to respond with text/html
and specify the goods that are not available. The consumer can then
be given controls to either remove the goods from the cart, accept
them as backordered, or any other option the merchant thinks is
worthwhile.

b) The merchant can proceed to produce an offer of type application/iotp,
and the invoice details can specify that items are included (and to
be paid for) or have been back-ordered, and can be paid for at a later
date.

c) If the merchant is confident that re-supply is coming soon, they can
simply create an offer for all requested goods, accept payment, and
ship goods as they arrive. In this case, the merchant should have some
contingency arrangements in the event that expected shipments do not
arrive.

>    How does a merchant get to know that the payment was successfully

If a merchant wishes, they can assign themselves all the roles of
Merchant, PaymentHandler, and DeliveryHandler. That way, they get
to see all the information you have indicated.

The trading roles are like actors in a play. Any given merchant is
free to set up a "one-man show" and play all the parts himself.

In many cases, though, merchants are already outsourcing their
logistics. In this case, the DeliveryHandler could even be (example!)
FedEx, who can read the DeliveryRequest, check the original OfferResponse
signature from the Merchant and the PaymentResponse signature from the
PaymentHandler, and move the goods from storage into the delivery channel.

In a best case scenario, you could order physical goods at 11:59 PM for
next day 9 AM delivery.

IOTP simply *allows* (but does not force) this capability.

----------------------------------------------------------------------
Chris Smith                                       <[email-masked]>