more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Andras Varga <andras@metechnology.com> Thu, 09 September 1999 15:53 UTC
Received: from one.eListX.com (one.elistx.com [209.116.252.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04029 for <trade-archive@lists.ietf.org>; Thu, 9 Sep 1999 11:53:52 -0400 (EDT)
Received: from one.elistx.com by one.eListX.com id aa18745; 9 Sep 99 11:29 EDT
Received: from matavnet.hu by one.eListX.com id aa18731; 9 Sep 99 11:28 EDT
Received: (qmail 28176 invoked from network); 9 Sep 1999 17:30:41 +0200
Received: from line-211-163.dial.matav.net (HELO apps) (145.236.211.163) by mail.matav.hu with SMTP; 9 Sep 1999 17:30:41 +0200
Received: from 10.0.0.11 by apps ([10.0.0.1] running VPOP3) with SMTP for <ietf-trade@lists.elistx.com>; Thu, 9 Sep 1999 17:21:20 +0200
Reply-To: andras@metechnology.com
MMDF-Warning: Parse error in original version of preceding line at one.eListX.com
From: Andras Varga <andras@metechnology.com>
To: ietf-trade@lists.eListX.com
MMDF-Warning: Parse error in original version of preceding line at one.eListX.com
Subject: more comments on draft-ietf-trade-iotp-v1.0-protocol-05.txt
Date: Thu, 09 Sep 1999 17:24:13 +0200
Message-ID: <000801befad7$5fbfa3a0$0b00000a@andras>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Server: VPOP3 V1.3.0b - Registered to: Me Technology
Sender: ietf-trade-owner@lists.eListX.com
Precedence: bulk
X-elistx: ietf-trade
Source-Info: From (or Sender) name not authenticated.
Content-Transfer-Encoding: 7bit
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? ---- 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. ---- 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. 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. ---- 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? ---- 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. ---- 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? Regards, Andras ----------------------------------------------------------------------- Andras Varga [andras@metechnology.com], Project Manager MeTechnology Ltd. Hungary - a Brokat Company ----------------------------------------------------------------------- ----------------------------------------------------------------------- Message addressed to: ietf-trade@lists.elistx.com Archive available at: http://www.elistx.com/archives/ietf-trade/ To (un)subscribe send a message with "subscribe" or "unsubscribe" in the body to: ietf-trade-request@lists.elistx.com
- changing the shipping address (was RE: more comme… Andras Varga
- RE: more comments on draft-ietf-trade-iotp-v1.0-p… David Burdett
- RE: more comments on draft-ietf-trade-iotp-v1.0-p… Andras Varga
- RE: more comments on draft-ietf-trade-iotp-v1.0-p… David Burdett
- more comments on draft-ietf-trade-iotp-v1.0-proto… Andras Varga