RE: Draft new TRADE WG Charter, two week comment period
Andras Varga <andras@metechnology.com> Wed, 16 August 2000 16:23 UTC
Return-Path: <ietf-trade-errors@lists.eListX.com>
Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-33 #43584) id <0FZE00G0187U0D@eListX.com>; Wed, 16 Aug 2000 12:23:54 -0400 (EDT)
Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-33 #43584) id <0FZE00G0187U0C@eListX.com> (original mail from andras@metechnology.com) ; Wed, 16 Aug 2000 12:23:54 -0400 (EDT)
Received: from ELISTS-DAEMON by eListX.com (PMDF V5.2-33 #43584) id <0FZE00G0387T0A@eListX.com> for ietf-trade-1104-outbound@reprocess.eListX.com (ORCPT rfc822; ietf-trade@lists.elistx.com); Wed, 16 Aug 2000 12:23:53 -0400 (EDT)
Received: from DIRECTORY-DAEMON by eListX.com (PMDF V5.2-33 #43584) id <0FZE00G0187S09@eListX.com> for ietf-trade@elists.eListX.com (ORCPT rfc822; ietf-trade@lists.elistx.com); Wed, 16 Aug 2000 12:23:52 -0400 (EDT)
Received: from mail.elender.hu (bendeguz.elender.hu [212.108.200.75]) by eListX.com (PMDF V5.2-33 #43584) with ESMTP id <0FZE00F1S87RTS@eListX.com> for ietf-trade@lists.eListX.com; Wed, 16 Aug 2000 12:23:52 -0400 (EDT)
Received: from apps (mail.metechnology.hu [212.108.229.233]) by mail.elender.hu with ESMTP id SAA24901 for <ietf-trade@lists.elistx.com>; Wed, 16 Aug 2000 18:21:16 +0200 (MET DST)
Received: from 10.0.0.11 by apps ([10.0.0.1] running VPOP3) with SMTP for <ietf-trade@lists.elistx.com>; Wed, 16 Aug 2000 17:43:34 +0200
Date: Wed, 16 Aug 2000 17:48:29 +0200
From: Andras Varga <andras@metechnology.com>
Subject: RE: Draft new TRADE WG Charter, two week comment period
In-reply-to: <642F9A357902D411BA5F0008C79197562591AE@ma07exm1.corp.isg.mot.com>
To: ietf-trade@lists.eListX.com
Reply-to: andras@metechnology.com
Message-id: <000901c00799$6cefcee0$0b00000a@andras>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 8bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Server: VPOP3 V1.3.0b - Registered to: Me Technology
List-Owner: <mailto:ietf-trade-help@lists.elistx.com>
List-Post: <mailto:ietf-trade@lists.elistx.com>
List-Subscribe: <mailto:ietf-trade-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <mailto:ietf-trade-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-trade>
List-Help: <http://lists.elistx.com/doc/email-manage.html>, <mailto:ietf-trade-request@lists.elistx.com?body=help>
Donald Eastlake wrote: [...] > The working group will document interoperability experience with > IOTP version 1 (which has been published as an Informational RFC) > and develop the requirements for IOTP version 2. Selection of > items for inclusion in version requirements 2 is to be from the > following: > - Separation of a content independent Messaging Layer > - Dynamic Definition of Trading Sequences > - Offer Request Block > - Improved Problem Resolution (extend to cover presentation of > signed receipt to customer support party, etc.) > - Server to Server messages > - Standardized XML Digital Signatures based on output from > the XMLDSIG working group I'd like to suggest two more items for inclusion: 1) issues concerning server-side IOTP wallets (or IOTP-enabled WalletServers). When using server-side wallets which reside in a WalletServer, a typical scenario is this: 1. consumer browses in the Merchant's shop and decides to check out 2. consumer clicks on the "Pay" link in the shop. The URL points to the WalletServer and contains additional parameters like e.g. merchant address and order number 3. consumer logs into the WalletServer 4. the WalletServer retrieves the Offer from the Merchant; data for this (e.g. OfferRequest URL) come from parameters from the URL used to invoke the WalletServer 5. now payment & delivery goes on like the Consumer had a locally installed IOTP wallet An item which would be worth standardizing is the URL used to invoke the WalletServer. (Using such an URL to get to the WalletServer has certain advantages over using e.g. a mime-type sent down from the shop.) This URL should include parameters which -at minimum- tell the WalletServer where to send the OfferRequest. 2) mixing IOTP with other payment protocols. Some existing payment protocols like SET or Geldkarte are pretty difficult to tunnel through IOTP (bridges require significant implementation effort). At the same time it would be nice to be able to use IOTP e.g. for retrieving offer or requesting delivery, which is not (properly) covered by other protocols. Such a feature would probably increase the usefulness and thus the acceptance of the IOTP standard. The IOTP specification should explicitly allow for payment protocols that are not tunnelled through IOTP. There should be a way to specify protocols in the IOTP OfferResponse that are to be used standalone with Merchant's Payment Handler (ie. not tunnelled through IOTP). Other modifications might also be necessary on the IOTP protocol to accomodate such a feature, for example signed PayReceipt is not possible if the payment was not done via IOTP. Best regards, Andras Varga ---------------------------------------------------------- Andras Varga | Brokat Ag. E-mail: andras.varga@brokat.com | Commerce Division Phone: +36-1 437-0413 | Research & Development Fax: +36-1 387-3798 | Kunigunda útja 58. http://www.brokat.com | 1037 Budapest, Hungary
- RE: Draft new TRADE WG Charter, two week comment … David Burdett
- Re: Draft new TRADE WG Charter, two week comment … Yoshiaki KAWATSURA
- RE: Draft new TRADE WG Charter, two week comment … Lewis, Tony
- Re: Draft new TRADE WG Charter, two week comment … Donald E. Eastlake 3rd
- RE: Draft new TRADE WG Charter, two week comment … David Burdett
- RE: Draft new TRADE WG Charter, two week comment … Andras Varga
- Re: Draft new TRADE WG Charter, two week comment … Ko Fujimura
- Draft new TRADE WG Charter, two week comment peri… Eastlake Donald-LDE008