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

[David Burdett <[e-mail]>]

Andras

See comments marked with ##

David

-----Original Message-----
From: Andras Varga [mailto:[e-mail]]
Sent: Thursday, September 09, 1999 8:24 AM
To: [e-mail]
Subject: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt


Some comments to draft-ietf-trade-iotp-v1.0-protocol-05.txt:

----
>From 7.6.1.1 Organisation IDs:
IOTP> NonConsumerOrgId   If the Role is not Consumer then this contains the
IOTP>                    Canonical Name for the non-consumer organisation
IOTP>                    being described by the Organisation Component. See
IOTP>                    [DNS].
IOTP>
IOTP>                    Note that a NonConsumerOrgId may not start with
IOTP>                    the ConsumerOrgIdPrefix.
IOTP>
IOTP>                    Use of upper and lower case is not significant.

Occasionally it may happen that a Merchant does not have its own
domain name. For example, www.passage.hu offers e-commerce services
to merchants, so the URLs of the individual shops (merchants) are 
www.passage.hu/Caori, www.passage.hu/TicketExpress, etc. How should 
the NonConsumerOrgId be produced in such a case?
## Good point changed definition of NonConsumerOrgId as follows ...
"If the Role is not Consumer then this contains the Canonical Name for the
non-consumer Organisation being described by the Organisation Component. See
[DNS] optionally followed by additional characters, if required, to make the
NonConsumerOrgId unique"
##
----
Section 2.2.4 Authentication Exchange say that an Authentication Exchange
uses:
IOTP>  o A Trading Role Information Request Component that requests
information
IOTP>    about an Organisation, for example a ship to or billing address.

This is the only place where the words "billing address" occur in the
document.
I recommend it to be made more explicit that the billing address is the
Consumer role's postal address.
##Removed reference to "billing address"##
----
I suggest adding the following codes to 7.16.2 Payment Completion Codes:
 MerchNotSupp    The Merchant is not served by the Payment Handler.
                 No recovery possible.
##This is really an error caused by the merchant trying to use a Payment
handler that they should not or the Consumer sending the payment request to
the wrong URL. Therefore suggest handled by generating an error with an
error code of AttValNotRecog. The error description can say "The merchant is
not server by the Payment Handler". However this requires a minor change to
the defintion of AttValNotRecog by deleting the text ..." even though it
should have been able to. since the information had been provided in an
earlier IOTP message."##
 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.## 
----
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.##
----
Again 7.16.2 Payment Completion Codes:
IOTP> BadInstrument      Bad instrument. There is a problem with the
IOTP>                    Payment Instrument being used which means that it
IOTP>                    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.##
----
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##
Regards,
Andras

-----------------------------------------------------------------------
Andras Varga [[e-mail]], Project Manager
MeTechnology Ltd. Hungary - a Brokat Company
-----------------------------------------------------------------------


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