Subject: RE: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

From: David Burdett <[email-masked]>
Date: Fri, 10 Sep 1999 08:23:53 -0700

Andras

See a few minor comments below marked with @@

David

-----Original Message-----
From: Andras Varga [mailto:[email-masked]]
Sent: Friday, September 10, 1999 4:10 AM
To: [email-masked]
Subject: RE: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt

Please see comments inlined...

>  PaymtPending    Payment Pending. The payment is a longer process and
cannot
>                  be completed while the Consumer is online. (For example,
>                  Direct Debit or Bank Transfer is used for the payment
which
>                  takes several hours or days to complete.) 
>                  This is only valid if ProcessState is CompletedOk.
>                  No recovery possible.
> 
>  Paid            Payment finished successfully (as opposed to being
pending).
>                  This is only valid if ProcessState is CompletedOk.
>                  No recovery possible.
> ##IMOH I think this distinction, whilst technically correct, could be
> confusing to a Consumer. Once they've completed a Payment 
> Exchange, they will think, for all intents and purposes, that they've 
> "paid". A message that says "payment pending" could cause confusion 
> and they might think that something has gone wrong and the payment 
> perhaps won't work. I prefer to leave it as it is. OTOH, if the developer
> of a payment supplement wants to make the distinction then they can 
> include text in the StatusDesc attribute to distinguish between the two 
> states. Propose no change.## 

I accept.

----
> If the payment completion code is PaymtPending, it might be 
> useful NOT to return the PayReceipt component immediately in the 
> Payment Response Block. In this case, the Consumer could retrieve 
> the PayReceipt later with an Inquiry when the payment finished. I believe 
> this is not possible in the current version of IOTP. Opinions?
> ##Correct. It's not possible to do what you suggest in the 
> current version of IOTP. The behaviour you suggest also does not 
> represent what happens in the real world. For example, if you pay 
> by check you get a receipt at the time you hand over the check. 
> The fact the check might "bounce" is handled separately. I think it 
> is a good idea, at least initially, to mirror real world behaviour. 
> Propose no change.##

I accept this. Practice will show if any change is needed in IOTP.

> Again 7.16.2 Payment Completion Codes:
> IOTP> BadInstrument      Bad instrument. There is a problem with the
> IOTP>                    Payment Instrument being used which 
> IOTP>                    means that it is unable to be used for the
payment.
> 
> A potential error situation is that the payment amount is too small 
> (or too big) for the given brand/protocol. For example, credit cards 
> cannot be used for micropayments. Since this is not a problem with the
> Payment Instrument itself, I recommend the error description 
> be changed to: 
>   "The Payment Instrument cannot be used for the payment for 
>   some reason (e.g. the credit card is invalid, or payment amount is too 
>   small/too big for the Payment Instrument)."
> An alternative would be to introduce AmountTooLarge and AmountTooSmall
> error codes.
> ## You can use the ValueTooSmall and ValueTooLarge error 
> codes for this. The Error Description can be used to fine tune the 
> meaning.##

I accept that no change is required, with the comment that this is
rather a business error (recovery is possible) and it can be covered
by one of BadInstrument, InstNotValid or Unspecified.
@@ ... except that what *sane* Merchant would include credit cards in a
Brand List when the goods being purchased are for only a few pence. The
Merchant should know in advance that it wouldn't work. IMOH I think if this
problem occurs then it is an error in the way the Merchant has set up his
IOTP system.@@
----
> Comment:
> Authentication Exchange can be used to communicate trading role info 
> between trading roles. For example, the Delivery Handler can 
> authenticate the Consumer to obtain the shipping address. A potential 
> problem is that Authentication is initiated by the Delivery Handler 
> not the Consumer, so I believe currently there is no way for the 
> Consumer to tell a changed shipping address to the Delivery Handler 
> unless the Delivery Handler explicitly asks for it in an Authentication 
> Reqeuest. Opinions?
> ## This has been already discussed. See
> http://www.elistx.com/archives/ietf-trade/199908/msg00035.html##

FYI, we figured out another way to request shipping to a different address 
from the Delivery Handler (by means of a new critial element). If someone
is interested please write.
&& Yes. But changing the shipping address MUST be treated with care as it
can mean that the wrong tax is being collected. For example in the US goods
bought and shipped within the same state must include sales tax. Goods that
are shipped out of state do not (although technically the purchases should
report and pay the tax due). So, if the Delivery Handler changes the address
then it could result in the Merchant being liable for additional tax that he
has not received payment for.@@
Andras

------------------------------
Andras Varga

-----------------------------------------------------------------------
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]
-----------------------------------------------------------------------
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: Andras Varga <[email-masked]>
Date: Mon, 13 Sep 1999 13:11:43 +0200

David,
Thanks for your comments. I added some more details and problems we see...

> > Comment:
> > Authentication Exchange can be used to communicate trading 
> > role info between trading roles. For example, the Delivery 
> > Handler can authenticate the Consumer to obtain the shipping 
> > address. A potential problem is that Authentication is initiated 
> > by the Delivery Handler not the Consumer, so I believe 
> > currently there is no way for the 
> > unless the Delivery Handler explicitly asks for it in an 
> > Authentication Reqeuest. Opinions?
> FYI, we figured out another way to request shipping to a 
> different address from the Delivery Handler (by means of a new critial 
> element). If someone is interested please write.
>
> && Yes. But changing the shipping address MUST be treated 
> with care as it can mean that the wrong tax is being collected. 
> For example in the US goods bought and shipped within the same 
> state must include sales tax. Goods that are shipped out of state 
> do not (although technically the purchases should report and 
> pay the tax due). So, if the Delivery Handler changes the address
> then it could result in the Merchant being liable for additional 
> tax that he has not received payment for.@@

Good point. According to our idea, the Delivery Hander would examine 
if the address change can be carried out without violating the original 
offer (i.e. the taxing and the shipping cost is the same, etc.). 
If the address change cannot be carried out (or the Delivery Handler
does not support/is not authorized to change the address), 
the Delivery Handler would send back a status with business error 
and an appropriate status description. The Consumer could then retry
the Delivery Request with another address or with keeping the original
address.

There are minor problems with this however. All Delivery Competion 
Codes [7.16.3] say that "Recovery is not possible.", so with the 
current IOTP implementation the Consumer could not retry.

Another problem is if the Delivery Handler does not recognize
the extension to the Delivery Request. Because the element is critical,
this is a technical [4.1] error and the Consumer cannot retry with
another, "plain" Delivery Request. 
OTOH if the extension is non-critical, the Consumer won't know
where the goods are going to be shipped eventually.

[I feel this a sign of a more general problem with extensions.
If the extension is critical it causes technical error and the 
transaction must fail, ie. the trading role sending the message
in error has no possibility to fix the problem by sending a
revised message. OTOH if the extension is non-critical, the 
sender trading role won't know whether the info carried in the
extensions was taken into account. But maybe I'm missing some
point. 
Probably this has been discussed before, so I apologize
for consuming the bandwidth.]

David, do you think this whole issue is important enough?

I apologize for consuming the bandwidth to those who are not 
interested...

Andras