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

[Andras Varga <[e-mail]>]

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.

----
> 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.

Andras

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

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