Subject: RE: My Comments of IOTP Spec Release4

From: David Burdett <[email-masked]>
Date: Mon, 2 Aug 1999 08:55:21 -0700

Yoshiaki

You asked "Do the descriptions of "the request" above mean "external request
from another system"?

I do ... but what I really meant is a request from another system **running
at the same trading role**. For example, suppose there are two systems
running at a trading role:
- an IOTP system which conforms to the IOTP spec, and
- anothter system which does *not* understand IOTP *but* communicates with
the IOTP system by sending it messages.

What I'm trying to provide by this part of the specification is a method for
the second non-IOTP-aware system to cancel a transaction in process on the
IOTP system. This could be, for example:
- a consumer "cancelling" a transaction by "clicking" on a cancel button
- an operator or another system at the server deciding to close down an IOTP
server and terminate any current transactions

I hope this is clearer.

If this makes sense, then let me know and I'll have another go at clarifying
the spec.

David

-----Original Message-----
From: Yoshiaki KAWATSURA [mailto:[email-masked]]
Sent: Wednesday, July 28, 1999 12:54 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: My Comments of IOTP Spec Release4

David,
I will send some comments for your mails in this week because I have to
discuss with my coleagues except for Cancelling a Transaction.

--
For 4.5.3
> *	if the IotpTransId of the transaction to be cancelled is not
> recognised, or complete then fail the request, otherwise
> *	if the IotpTransId refers to an Inquiry Transaction or a Ping
I wanna make sure.
Do the descriptions of "the request" above mean "external request from
another system"?

If so, I do not understand why you disagreed.
In the current IOTP, the Consumer generates new IotpTransId 
whenever the Consumer generates the Ping Message. 
But the Consumer uses the IotpTransId corresponding with the Purchase
Transaction which Consumer wants to inquire, so the Consumer does not
create new IotpTransId.

After all, the IotpTransId also refers to an Purchase Transaction if
IotpTransId refers to an Inquiry Transaction.

--
Yoshiaki Kawatsura Hitachi, Ltd.

>>>>> Wed, 28 Jul 1999 03:40:12 +0100,
	[email-masked] said:

> > 4.5.3 Cancelling a Transaction
> > In 4.5.3,
> > --Start
> >       o if the IotpTransId refers to Inquiry Transaction or a Ping
> >         Transaction then fail the request, otherwise
> > --End
> > 
> > We use the same IotpTransId, which is used in the Payment
> > Transaction, whenever the Inquiry Transaction is processed. So we
> > should revise the above description as follows:
> > 
> >       o if the IotpTransId refers to a Ping
> >         Transaction then fail the request, otherwise
> ##Disagree. What I intended, but perhaps didn't make clear, was that that
> this process is used to generate a cancel block to be sent to the other
> party. For example, if a Payment Handler decides to cancel a transaction
for
> some business reason, then there needs to be a way for the cancellation to
> be communicated to the IOTP Server for the Payment Handler so that it can
> generate the Cancel Block. So if clarified this section as follows.
> 
> This process is used to cancel a transaction running on an IOTP server. It
> is initiated by some other process as a result of an external request from
> another system or server that is being run by the same Trading Role. The
> processing required is as follows:
> *	if the IotpTransId of the transaction to be cancelled is not
> recognised, or complete then fail the request, otherwise
> *	if the IotpTransId refers to an Inquiry Transaction or a Ping
> Transaction then fail the request, otherwise
> *	determine which Document Exchange to cancel and generate a Cancel
> Block and send it to the other party
> 	[Note]	Cancelling a transaction on an IOTP server typically arises
> for a business reason. For example a merchant may have attempted
> authentication several times without success and as a result decides to
> cancel the transaction. Therefore the process that decides to take this
> action needs to send a message from the process/server that made the
> business decision to the IOTP server with the instruction that the IOTP
> transaction should be cancelled.
> 	[Note End]	 
> ##

-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]

---

From: Masaaki Hiroya <[email-masked]>
Date: Tue, 03 Aug 1999 12:47:11 +0900

David,

I think Yoshiaki just wanted to remove "Inquiry Transaction" from the
following sentence because the IotpTransId of an Inquiry Transaction is
the same as the IotpTransId of a Purchase Transaction, a Withdrawal 
Transaction or a Deposit Transaction.

> > Transaction then fail the request, otherwise

Is there any case that the request of a cancellation is not allowed 
(should be failed) when the IotpTransId of an Inquiry Transaction is used?

Masaaki

> discuss with my coleagues except for Cancelling a Transaction.
-----
Masaaki Hiroya
Systems Development Laboratory
Hitachi, Ltd.
email: [email-masked]
tel: +81-44-549-1531
fax: +81-44-549-1640
-----------------------------------------------------------------------
Message addressed to: [email-masked]
Archive available at: http://www.elistx.com/archives/ietf-trade/
To (un)subscribe send a message with "subscribe" or "unsubscribe" in the
body to: [email-masked]