Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00M013ROQC@eListX.com>; Thu, 30 Nov 2000 05:57:24 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00M033RNQA@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Thu, 30 Nov 2000 05:57:24 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00M013RMQ4@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Thu, 30 Nov 2000 05:57:23 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00M013RLQ3@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Thu, 30 Nov 2000 05:57:21 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4U00KHV3RLCO@eListX.com> for ietf-trade@lists.elistx.com; Thu, 30 Nov 2000 05:57:21 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27759; Thu, 30 Nov 2000 05:56:48 -0500 (EST) Date: Thu, 30 Nov 2000 05:56:48 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-drt-requirements-01.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.elistx.com Reply-to: Internet-Drafts@ietf.org Message-id: <200011301056.FAA27759@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_XtHEVSjBR+e5mjdi26Wl/g)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , --Boundary_(ID_XtHEVSjBR+e5mjdi26Wl/g) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Requirements for Digital-Right Trading Author(s) : K. Fujimura Filename : draft-ietf-trade-drt-requirements-01.txt Pages : 11 Date : 29-Nov-00 In purchase and other trading transactions, it is often required to credit loyalty points, collect digital coupons or gift certificates, and so on. The IETF Trade Working Group is investigating how these activities can be generalized using the concept of a 'digital-right', which is a digital representation of the right to claim goods or services. This document contains the requirements in the following areas: - The digital rights trading model - The language to describe diverse types of digital rights A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-drt-requirements-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-drt-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-drt-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_XtHEVSjBR+e5mjdi26Wl/g) Content-type: multipart/alternative; boundary="Boundary_(ID_gN68WLZHO2UDNgL6yBdFBg)" --Boundary_(ID_gN68WLZHO2UDNgL6yBdFBg) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <20001129114459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-drt-requirements-01.txt --Boundary_(ID_gN68WLZHO2UDNgL6yBdFBg) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-drt-requirements-01.txt Content-Type: text/plain Content-ID: <20001129114459.I-D@ietf.org> --Boundary_(ID_gN68WLZHO2UDNgL6yBdFBg)-- --Boundary_(ID_XtHEVSjBR+e5mjdi26Wl/g)-- Return-path: Received: from PIPE-ELISTX-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U0040DLPXYS@eListX.com> (original mail from ietf-trade-errors@lists.elistx.com); Thu, 30 Nov 2000 12:25:09 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00401LOMX0@eListX.com>; Thu, 30 Nov 2000 12:24:23 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00403LOMWY@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 30 Nov 2000 12:24:22 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00401LOKWV@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 30 Nov 2000 12:24:21 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00401LOKWU@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 30 Nov 2000 12:24:20 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4U00382LOHZ7@eListX.com> for ietf-trade@lists.elistx.com; Thu, 30 Nov 2000 12:24:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id MAA05295; Thu, 30 Nov 2000 12:28:22 -0500 (EST) Date: Thu, 30 Nov 2000 12:28:22 -0500 From: "Donald E. Eastlake 3rd" Subject: Working Group Last Call for Payment API and SET Supplement To: ietf-trade@lists.elistx.com Cc: lde008@dma.isg.mot.com Message-id: <200011301728.MAA05295@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp This is a working group last call for Payment API for v1.0 Internet Open Trading Protocol (IOTP) ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt and SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt Both of these documents are currently intended to become Informational RFCs. If you believe they should have a different status, such as Experimental or Proposed Standard, you should indicate why. I expect that these documents will be on the agenda of the TRADE WG meeting in San Diego (). This working group last call is through December 22nd 2000 to decide if there is a consensus to advance these documents. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1 508-634-2066(h) Milford, MA 01757 USA +1 508-261-5434(w) Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00J01ZOLNE@eListX.com>; Tue, 28 Nov 2000 13:36:21 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00J03ZOKNC@eListX.com> (original mail from roth@visa.com); Tue, 28 Nov 2000 13:36:20 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00J01ZOJN8@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 13:36:20 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00J01ZOJN7@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 13:36:19 -0500 (EST) Received: from portal1.visa.com (portal1.visa.com [198.80.42.2]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G4Q00GNNZOIYH@eListX.com> for ietf-trade@lists.elistx.com; Tue, 28 Nov 2000 13:36:19 -0500 (EST) Received: by portal1.visa.com id KAA23305 (InterLock SMTP Gateway 4.2 for ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 10:35:26 -0800 Received: by portal1.visa.com (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 2000 10:35:26 -0800 Date: Tue, 28 Nov 2000 10:34:03 -0800 From: "Roth, Janet" Subject: RE: Ongoing payments - IOTP Version 2 extension To: "'ietf-trade@lists.eListX.com'" Cc: "Lewis, Tony" , "Howell, Phil" Message-id: <95288CC7E7F7D111883B0001FAF85C0303E5A2C8@sw720x014.visa.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: multipart/alternative; boundary="Boundary_(ID_DgIOW46rYG/euCTbuaE5tQ)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_DgIOW46rYG/euCTbuaE5tQ) Content-type: text/plain The issues Chris raises are interesting ones, but IOTP in and of itself can't resolve them. Those have to be addressed by the overall payment protocol. Firstly, because of these issues (and others not mentioned) a payment protocol designed to accomodate ongoing payments needs to ensure that the customer system is present and "approves" each incremental payment. (There are of course a variety of methods of implementing the customer approval. Just as an example, continuing to play a game after a signal of some sort indicating that more money is required might indicate approval of the next increment). As Chris points out, it must be possible to "close" the transaction, even if the customer is no longer present. The protocol should ensure that the merchant/acquirer cannot get paid without doing this. If the customer is still connected, there can also be an (informational) message to the customer system that indicates the closure and gives the status. Otherwise, the customer may go to her issuer site (later, when reconnected) to determine the transaction status. A payment product's business rules must determine how disputes are handled. Depending on the business model, you may allow "chargebacks", or may not. (if you do, those are back-end issues, and are not part of the customer system interface to the merchant system). If not, then the payment protocol must certainly provide a refund mechanism. In the event a particular merchant is mischarging or otherwise mis-behaving, and not providing refunds or other customer satisfaction, then the recourse would be defined by the owner, or guarantor, of the payment acceptance mark under which the payments were made. What is done (such as sanctions on the merchant) seem to be primarily business questions (or possible legal questions), rather than technical or protocol issues. -Janet Roth -----Original Message----- From: Smith, Chris [mailto:CHRIS.SMITH@ROYALBANK.COM] Sent: Monday, November 27, 2000 3:42 PM To: 'ietf-trade@lists.eListX.com' Subject: RE: Ongoing payments - IOTP Version 2 extension > -----Original Message----- > From: Roth, Janet [ mailto:roth@visa.com ] > > Using game playing as an example: > > Before starting the game, the merchant and customer systems > negotiate the payment brand and protocol, and agree that the > customer will be charged $3 for an initial 30 minutes of > playing time, $.50 for each subsequent 10 minute period, > and will be credited $.10 for each game level achieved. > This can be expressed as agreeing to an immediate payment > of $3 and to maximum incremental payments of $.50. I like the idea, but even more, I like your example. Hopefully it will allow for resolution of some of the issues that arise around such payments. In particular - given that the negotiation is only done up front, how does the customer know that the merchant is using a "valid clock"? As I understand your example, there is no guaranteed closing step where the customer is informed of the total amount. There is good reason for NOT having such a step, because this may be impossible if the customer is accidentally disconnected. But - in the event the customer is disconnected, how do they complain about overcharging? The merchant appears to be able to continue charging you for several more 'units'. This may be even more subtle when you reconnect two hours later, and you really reconnect to the same game and position - and the merchant then charges you for the two hours, arguing that he had to expend resources to maintain your game, whether you were actively playing, or 'just thinking' while disconnected. If the customer is using a chipcard payment system, then a disconnect will also prevent future payments. But a 'virtual card' system, or even a credit card system, allows the merchant to continue charging without further communication with the customer. ------------------------------------------------------------ Chris Smith Royal Bank Senior Technical Consultant Smart Card Systems 277 Front Street West, 2nd Floor Toronto, Ontario M5V 2X4 Tel: (416) 348-6090 Fax: (416) 348-2210 > -----Original Message----- > From: Roth, Janet [ mailto:roth@visa.com ] > Sent: November 27, 2000 06:09 PM > To: 'ietf-trade@lists.eListX.com' > Subject: Ongoing payments - IOTP Version 2 extension > > > > Visa is interested in seeing a small extension to IOTP for > Version 2 that > will support what we call "incremental" or "ongoing" > payments. A familiar > example of such an ongoing payment from the mundane, > pre-internet world is a > pay-telephone call. Internet based examples of such payments > might include > not only payment for connection time, but also payment for ongoing > activities such as game playing. While this can be implemented under > Version 1, it is somewhat awkward. > > Specifically, we would like to see added to the standard IOTP element > definitions the following: > > 1) an optional data element indicating that this transaction > is one of three > possibilities: a stand-alone single payment (the default), > the initial > payment of an ongoing payment transaction set, and an > incremental payment. > (in the last case, the initial payment is referenced using > the Related To > component). > > 2) an data element, used only for the initial payment of an ongoing > transaction set, giving the maximum permitted incremental > payment amount in > each offered currency. > > The authentication of the customer/cardholder, and the > negotiation of the > price and means of payment is performed once only, during the > processing of > the initial payment for the transaction set. This > negotiation includes both > the agreement of an initial payment amount, and the maximum > amount for the > subsequent incremental payments. The subsequent incremental payment > transactions would be for any amount not greater than the > agreed maximum. > > Using game playing as an example: > > Before starting the game, the merchant and customer systems > negotiate the > payment brand and protocol, and agree that the customer will > be charged $3 > for an initial 30 minutes of playing time, $.50 for each subsequent 10 > minute period, and will be credited $.10 for each game level > achieved. This > can be expressed as agreeing to an immediate payment of $3 > and to maximum > incremental payments of $.50. > > In other words, the initial payment of the set indicates $3 > in the "amount" > attribute in the currency amount element and $.50 in the new maximum > incremental amount. The subsequent incremental payments may > contain any > value up to $.50 in the "amount" attribute. In this example, > if the game > player had achieved a new game level, then the next payment > would be $.40. > > > Janet Roth > __________________________________________________ > roth@visa.com > Chief Systems Architect > Emerging Technologies - Application Architecture & Standards > Visa International > Ph. +1 (650) 432-1758; FAX +1 (650) 432-3199 > Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA, > 94404-2775, USA > > --Boundary_(ID_DgIOW46rYG/euCTbuaE5tQ) Content-type: text/html; charset=iso-8859-1 RE: Ongoing payments - IOTP Version 2 extension
The issues Chris raises are interesting ones, but IOTP in and of itself can't resolve them.  Those have to be addressed by the overall payment protocol. 
 
Firstly, because of these issues (and others not mentioned) a payment protocol designed to accomodate ongoing payments needs to ensure that the customer system is present and "approves" each incremental payment.  (There are of course a variety of methods of implementing the customer approval.  Just as an example, continuing to play a game after a signal of some sort indicating that more money is required might indicate approval of the next increment).  
 
As Chris points out, it must be possible to "close" the transaction, even if the customer is no longer present.  The protocol should ensure that the merchant/acquirer cannot get paid without doing this.
 
If the customer is still connected, there can also be an (informational) message to the customer system that indicates the closure and gives the status.  Otherwise, the customer may go to her issuer site (later, when reconnected) to determine the transaction status.
 
A payment product's business rules must determine how disputes are handled.  Depending on the business model, you may allow "chargebacks", or may not.  (if you do, those are back-end issues, and are not part of the customer system interface to the merchant system).  If not, then the payment protocol must certainly provide a refund mechanism. 
 
In the event a particular merchant is mischarging or otherwise mis-behaving, and not providing refunds or other customer satisfaction, then the recourse would be defined by the owner, or guarantor, of the payment acceptance mark under which the payments were made.  What is done (such as sanctions on the merchant) seem to be primarily business questions (or possible legal questions), rather than technical or protocol issues. 
 
    -Janet Roth
 

 -----Original Message-----
From: Smith, Chris [mailto:CHRIS.SMITH@ROYALBANK.COM]
Sent: Monday, November 27, 2000 3:42 PM
To: 'ietf-trade@lists.eListX.com'
Subject: RE: Ongoing payments - IOTP Version 2 extension

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
>
> Using game playing as an example:
>
> Before starting the game, the merchant and customer systems
> negotiate the payment brand and protocol, and agree that the
> customer will be charged $3 for an initial 30 minutes of
> playing time, $.50 for each subsequent 10 minute period,
> and will be credited $.10 for each game level achieved.
> This can be expressed as agreeing to an immediate payment
> of $3 and to maximum incremental payments of $.50.

I like the idea, but even more, I like your example. Hopefully
it will allow for resolution of some of the issues that arise
around such payments.

In particular - given that the negotiation is only done up
front, how does the customer know that the merchant is using
a "valid clock"? As I understand your example, there is no
guaranteed closing step where the customer is informed of the
total amount. There is good reason for NOT having such a step,
because this may be impossible if the customer is accidentally
disconnected.

But - in the event the customer is disconnected, how do they
complain about overcharging? The merchant appears to be able
to continue charging you for several more 'units'. This may
be even more subtle when you reconnect two hours later, and
you really reconnect to the same game and position - and the
merchant then charges you for the two hours, arguing that he
had to expend resources to maintain your game, whether you
were actively playing, or 'just thinking' while
disconnected.

If the customer is using a chipcard payment system, then a
disconnect will also prevent future payments. But a 'virtual
card' system, or even a credit card system, allows the merchant
to continue charging without further communication with the
customer.

------------------------------------------------------------
 Chris Smith                                     Royal Bank
 Senior Technical Consultant
 Smart Card Systems
 277 Front Street West, 2nd Floor
 Toronto, Ontario M5V 2X4
 Tel: (416) 348-6090
 Fax: (416) 348-2210

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
> Sent: November 27, 2000 06:09 PM
> To: 'ietf-trade@lists.eListX.com'
> Subject: Ongoing payments - IOTP Version 2 extension
>
>
>
> Visa is interested in seeing a small extension to IOTP for
> Version 2 that
> will support what we call "incremental" or "ongoing"
> payments.  A familiar
> example of such an ongoing payment from the mundane,
> pre-internet world is a
> pay-telephone call.  Internet based examples of such payments
> might include
> not only payment for connection time, but also payment for ongoing
> activities such as game playing.  While this can be implemented under
> Version 1, it is somewhat awkward.
>
> Specifically, we would like to see added to the standard IOTP element
> definitions the following:
>
> 1) an optional data element indicating that this transaction
> is one of three
> possibilities:  a stand-alone single payment (the default),
> the initial
> payment of an ongoing payment transaction set, and an
> incremental payment.
> (in the last case, the initial payment is referenced using
> the Related To
> component).
>
> 2) an data element, used only for the initial payment of an ongoing
> transaction set, giving the maximum permitted incremental
> payment amount in
> each offered currency.
>
> The authentication of the customer/cardholder, and the
> negotiation of the
> price and means of payment is performed once only, during the
> processing of
> the initial payment for the transaction set.  This
> negotiation includes both
> the agreement of an initial payment amount, and the maximum
> amount for the
> subsequent incremental payments.  The subsequent incremental payment
> transactions would be for any amount not greater than the
> agreed maximum.
>
> Using game playing as an example:
>
> Before starting the game, the merchant and customer systems
> negotiate the
> payment brand and protocol, and agree that the customer will
> be charged $3
> for an initial 30 minutes of playing time, $.50 for each subsequent 10
> minute period, and will be credited $.10 for each game level
> achieved.  This
> can be expressed as agreeing to an immediate payment of $3
> and to maximum
> incremental payments of $.50. 
>
> In other words, the initial payment of the set indicates $3
> in the "amount"
> attribute in the currency amount element and $.50 in the new maximum
> incremental amount.  The subsequent incremental payments may
> contain any
> value up to $.50 in the "amount" attribute.  In this example,
> if the game
> player had achieved a new game level, then the next payment
> would be $.40.
>
>
> Janet Roth
> __________________________________________________
> roth@visa.com
> Chief Systems Architect
> Emerging Technologies - Application Architecture & Standards
> Visa International
> Ph. +1 (650) 432-1758;  FAX +1 (650) 432-3199
> Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA,
> 94404-2775, USA
>
>

--Boundary_(ID_DgIOW46rYG/euCTbuaE5tQ)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELZTM@eListX.com>; Tue, 28 Nov 2000 06:01:11 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D03ELYTK@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Tue, 28 Nov 2000 06:01:10 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELVTC@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 06:01:10 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELVTA@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 06:01:07 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4Q00ANJELUEE@eListX.com> for ietf-trade@lists.elistx.com; Tue, 28 Nov 2000 06:01:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04199; Tue, 28 Nov 2000 06:00:35 -0500 (EST) Date: Tue, 28 Nov 2000 06:00:34 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-set-02.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.elistx.com Reply-to: Internet-Drafts@ietf.org Message-id: <200011281100.GAA04199@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_XLH1XM75sSnaV9eKi34Y6A)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , --Boundary_(ID_XLH1XM75sSnaV9eKi34Y6A) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) Author(s) : Y. Kawatsura Filename : draft-ietf-trade-iotp-v1.0-set-02.txt Pages : 58 Date : 27-Nov-00 This document describes detailed Input/Output parameter for the IOTP Payment API and a procedure in the Payment Bridge for use SET as the payment protocol within Version 1.0 of the Internet Open Trading Protocol (IOTP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-v1.0-set-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_XLH1XM75sSnaV9eKi34Y6A) Content-type: multipart/alternative; boundary="Boundary_(ID_nnTvSYgVgTgXJxf10u9FmA)" --Boundary_(ID_nnTvSYgVgTgXJxf10u9FmA) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <20001127133133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt --Boundary_(ID_nnTvSYgVgTgXJxf10u9FmA) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-iotp-v1.0-set-02.txt Content-Type: text/plain Content-ID: <20001127133133.I-D@ietf.org> --Boundary_(ID_nnTvSYgVgTgXJxf10u9FmA)-- --Boundary_(ID_XLH1XM75sSnaV9eKi34Y6A)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELQSU@eListX.com>; Tue, 28 Nov 2000 06:01:02 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D03ELQSS@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Tue, 28 Nov 2000 06:01:02 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELNRM@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 06:01:01 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELNRL@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 06:00:59 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4Q00ANGELNEE@eListX.com> for ietf-trade@lists.elistx.com; Tue, 28 Nov 2000 06:00:59 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04159; Tue, 28 Nov 2000 06:00:28 -0500 (EST) Date: Tue, 28 Nov 2000 06:00:27 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-papi-03.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.elistx.com Reply-to: Internet-Drafts@ietf.org Message-id: <200011281100.GAA04159@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_1/xXY2Ty1cMp++Zxt0Z7ag)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , --Boundary_(ID_1/xXY2Ty1cMp++Zxt0Z7ag) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Payment API for v1.0 Internet Open Trading Protocol (IOTP) Author(s) : W. Hans, H. Beykirch, M. Hiroya, Y. Kawatsura Filename : draft-ietf-trade-iotp-v1.0-papi-03.txt Pages : 103 Date : 27-Nov-00 The Internet Open Trading Protocol provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-v1.0-papi-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_1/xXY2Ty1cMp++Zxt0Z7ag) Content-type: multipart/alternative; boundary="Boundary_(ID_5z0G9r2acLzhTKjr3ulRFQ)" --Boundary_(ID_5z0G9r2acLzhTKjr3ulRFQ) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <20001127133123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt --Boundary_(ID_5z0G9r2acLzhTKjr3ulRFQ) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-iotp-v1.0-papi-03.txt Content-Type: text/plain Content-ID: <20001127133123.I-D@ietf.org> --Boundary_(ID_5z0G9r2acLzhTKjr3ulRFQ)-- --Boundary_(ID_1/xXY2Ty1cMp++Zxt0Z7ag)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7NIO@eListX.com>; Mon, 27 Nov 2000 18:42:59 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00903J7NIM@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Mon, 27 Nov 2000 18:42:59 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7MII@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Mon, 27 Nov 2000 18:42:59 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7MIH@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Mon, 27 Nov 2000 18:42:58 -0500 (EST) Received: from uhrbc1p1.royalbank.com (uhrbc1p1.royalbank.com [198.96.131.220]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G4P005J5J7HD2@eListX.com> for ietf-trade@lists.elistx.com; Mon, 27 Nov 2000 18:42:58 -0500 (EST) Received: from wsecure3.royalbank.com by uhrbc1p1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Mon, 27 Nov 2000 23:39:08 +0000 (UT) Received: from 10.224.0.79 by se001021.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 27 Nov 2000 18:41:34 -0500 Received: by se001025.rbc1.royalbank.com with Internet Mail Service ( 5.5.2650.21) id ; Mon, 27 Nov 2000 18:42:22 -0500 Date: Mon, 27 Nov 2000 18:42:19 -0500 From: "Smith, Chris " Subject: RE: Ongoing payments - IOTP Version 2 extension To: "'ietf-trade@lists.eListX.com'" Message-id: <55D770EEA49FD4118FDE00D0B7692F91243083@se001035.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 163C2EA4137363-02-01 List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ) Content-type: text/plain Content-transfer-encoding: QUOTED-PRINTABLE > -----Original Message----- > From: Roth, Janet [mailto:roth@visa.com] > > Using game playing as an example: >=20 > Before starting the game, the merchant and customer systems > negotiate the payment brand and protocol, and agree that the > customer will be charged $3 for an initial 30 minutes of > playing time, $.50 for each subsequent 10 minute period, > and will be credited $.10 for each game level achieved. > This can be expressed as agreeing to an immediate payment > of $3 and to maximum incremental payments of $.50. I like the idea, but even more, I like your example. Hopefully it will allow for resolution of some of the issues that arise around such payments. In particular - given that the negotiation is only done up front, how does the customer know that the merchant is using a "valid clock"? As I understand your example, there is no guaranteed closing step where the customer is informed of the total amount. There is good reason for NOT having such a step, because this may be impossible if the customer is accidentally disconnected. But - in the event the customer is disconnected, how do they complain about overcharging? The merchant appears to be able to continue charging you for several more 'units'. This may be even more subtle when you reconnect two hours later, and you really reconnect to the same game and position - and the merchant then charges you for the two hours, arguing that he had to expend resources to maintain your game, whether you were actively playing, or 'just thinking' while=20 disconnected. If the customer is using a chipcard payment system, then a disconnect will also prevent future payments. But a 'virtual card' system, or even a credit card system, allows the merchant to continue charging without further communication with the customer. ------------------------------------------------------------ =A0Chris Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 Royal Bank =A0Senior Technical Consultant =A0Smart Card Systems =A0277 Front Street West, 2nd Floor =A0Toronto, Ontario M5V 2X4 =A0Tel: (416) 348-6090 =A0Fax: (416) 348-2210 > -----Original Message----- > From: Roth, Janet [mailto:roth@visa.com] > Sent: November 27, 2000 06:09 PM > To: 'ietf-trade@lists.eListX.com' > Subject: Ongoing payments - IOTP Version 2 extension >=20 >=20 >=20 > Visa is interested in seeing a small extension to IOTP for=20 > Version 2 that > will support what we call "incremental" or "ongoing"=20 > payments. A familiar > example of such an ongoing payment from the mundane,=20 > pre-internet world is a > pay-telephone call. Internet based examples of such payments=20 > might include > not only payment for connection time, but also payment for ongoing > activities such as game playing. While this can be implemented und= er > Version 1, it is somewhat awkward. >=20 > Specifically, we would like to see added to the standard IOTP eleme= nt > definitions the following: >=20 > 1) an optional data element indicating that this transaction=20 > is one of three > possibilities: a stand-alone single payment (the default),=20 > the initial > payment of an ongoing payment transaction set, and an=20 > incremental payment. > (in the last case, the initial payment is referenced using=20 > the Related To > component).=20 >=20 > 2) an data element, used only for the initial payment of an ongoing > transaction set, giving the maximum permitted incremental=20 > payment amount in > each offered currency. >=20 > The authentication of the customer/cardholder, and the=20 > negotiation of the > price and means of payment is performed once only, during the=20 > processing of > the initial payment for the transaction set. This=20 > negotiation includes both > the agreement of an initial payment amount, and the maximum=20 > amount for the > subsequent incremental payments. The subsequent incremental paymen= t > transactions would be for any amount not greater than the=20 > agreed maximum. >=20 > Using game playing as an example: >=20 > Before starting the game, the merchant and customer systems=20 > negotiate the > payment brand and protocol, and agree that the customer will=20 > be charged $3 > for an initial 30 minutes of playing time, $.50 for each subsequent= 10 > minute period, and will be credited $.10 for each game level=20 > achieved. This > can be expressed as agreeing to an immediate payment of $3=20 > and to maximum > incremental payments of $.50. =20 >=20 > In other words, the initial payment of the set indicates $3=20 > in the "amount" > attribute in the currency amount element and $.50 in the new maximu= m > incremental amount. The subsequent incremental payments may=20 > contain any > value up to $.50 in the "amount" attribute. In this example,=20 > if the game > player had achieved a new game level, then the next payment=20 > would be $.40. >=20 >=20 > Janet Roth > __________________________________________________ > roth@visa.com > Chief Systems Architect > Emerging Technologies - Application Architecture & Standards > Visa International > Ph. +1 (650) 432-1758; FAX +1 (650) 432-3199 > Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA,=20 > 94404-2775, USA >=20 >=20 --Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE RE: Ongoing payments - IOTP Version 2 extension

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
>
> Using game playing as an example:
>
> Before starting the game, the merchant and cu= stomer systems
> negotiate the payment brand and protocol, and= agree that the
> customer will be charged $3 for an initial 30= minutes of
> playing time, $.50 for each subsequent 10 min= ute period,
> and will be credited $.10 for each game level= achieved.
> This can be expressed as agreeing to an immed= iate payment
> of $3 and to maximum incremental payments of = $.50.

I like the idea, but even more, I like your example= . Hopefully
it will allow for resolution of some of the issues= that arise
around such payments.

In particular - given that the negotiation is only = done up
front, how does the customer know that the merchan= t is using
a "valid clock"? As I understand your ex= ample, there is no
guaranteed closing step where the customer is info= rmed of the
total amount. There is good reason for NOT having = such a step,
because this may be impossible if the customer is = accidentally
disconnected.

But - in the event the customer is disconnected, ho= w do they
complain about overcharging? The merchant appears = to be able
to continue charging you for several more 'units'.= This may
be even more subtle when you reconnect two hours l= ater, and
you really reconnect to the same game and position= - and the
merchant then charges you for the two hours, argui= ng that he
had to expend resources to maintain your game, whe= ther you
were actively playing, or 'just thinking' while
disconnected.

If the customer is using a chipcard payment system,= then a
disconnect will also prevent future payments. But = a 'virtual
card' system, or even a credit card system, allows= the merchant
to continue charging without further communication= with the
customer.

---------------------------------------------------= ---------
=A0Chris Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0      =    =A0=A0=A0=A0=A0 Royal Bank
=A0Senior Technical Consultant
=A0Smart Card Systems
=A0277 Front Street West, 2nd Floor
=A0Toronto, Ontario M5V 2X4
=A0Tel: (416) 348-6090
=A0Fax: (416) 348-2210

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
> Sent: November 27, 2000 06:09 PM
> To: 'ietf-trade@lists.eListX.com'
> Subject: Ongoing payments - IOTP Version 2 ex= tension
>
>
>
> Visa is interested in seeing a small extensio= n to IOTP for
> Version 2 that
> will support what we call "incremental&q= uot; or "ongoing"
> payments.  A familiar
> example of such an ongoing payment from the m= undane,
> pre-internet world is a
> pay-telephone call.  Internet based exam= ples of such payments
> might include
> not only payment for connection time, but als= o payment for ongoing
> activities such as game playing.  While = this can be implemented under
> Version 1, it is somewhat awkward.
>
> Specifically, we would like to see added to t= he standard IOTP element
> definitions the following:
>
> 1) an optional data element indicating that t= his transaction
> is one of three
> possibilities:  a stand-alone single pay= ment (the default),
> the initial
> payment of an ongoing payment transaction set= , and an
> incremental payment.
> (in the last case, the initial payment is ref= erenced using
> the Related To
> component).
>
> 2) an data element, used only for the initial= payment of an ongoing
> transaction set, giving the maximum permitted= incremental
> payment amount in
> each offered currency.
>
> The authentication of the customer/cardholder= , and the
> negotiation of the
> price and means of payment is performed once = only, during the
> processing of
> the initial payment for the transaction set.&= nbsp; This
> negotiation includes both
> the agreement of an initial payment amount, a= nd the maximum
> amount for the
> subsequent incremental payments.  The su= bsequent incremental payment
> transactions would be for any amount not grea= ter than the
> agreed maximum.
>
> Using game playing as an example:
>
> Before starting the game, the merchant and cu= stomer systems
> negotiate the
> payment brand and protocol, and agree that th= e customer will
> be charged $3
> for an initial 30 minutes of playing time, $.= 50 for each subsequent 10
> minute period, and will be credited $.10 for = each game level
> achieved.  This
> can be expressed as agreeing to an immediate = payment of $3
> and to maximum
> incremental payments of $.50. 
>
> In other words, the initial payment of the se= t indicates $3
> in the "amount"
> attribute in the currency amount element and = $.50 in the new maximum
> incremental amount.  The subsequent incr= emental payments may
> contain any
> value up to $.50 in the "amount" at= tribute.  In this example,
> if the game
> player had achieved a new game level, then th= e next payment
> would be $.40.
>
>
> Janet Roth
> _____________________________________________= _____
> roth@visa.com
> Chief Systems Architect
> Emerging Technologies - Application Architect= ure & Standards
> Visa International
> Ph. +1 (650) 432-1758;  FAX +1 (650) 432= -3199
> Mailstop M1-8H, 900 Metro Center Blvd., Foste= r City CA,
> 94404-2775, USA
>
>

--Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901HQG80@eListX.com>; Mon, 27 Nov 2000 18:11:04 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00903HQG7Y@eListX.com> (original mail from roth@visa.com); Mon, 27 Nov 2000 18:11:04 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901HQF7W@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Mon, 27 Nov 2000 18:11:03 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901HQF7V@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Mon, 27 Nov 2000 18:11:03 -0500 (EST) Received: from portal1.visa.com (portal1.visa.com [198.80.42.2]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G4P005GGHQED2@eListX.com> for ietf-trade@lists.elistx.com; Mon, 27 Nov 2000 18:11:03 -0500 (EST) Received: by portal1.visa.com id PAA10554 (InterLock SMTP Gateway 4.2 for ietf-trade@lists.eListX.com); Mon, 27 Nov 2000 15:10:29 -0800 Received: by portal1.visa.com (Protected-side Proxy Mail Agent-1); Mon, 27 Nov 2000 15:10:29 -0800 Date: Mon, 27 Nov 2000 15:09:11 -0800 From: "Roth, Janet" Subject: Ongoing payments - IOTP Version 2 extension To: "'ietf-trade@lists.eListX.com'" Message-id: <95288CC7E7F7D111883B0001FAF85C0303E5A2B9@sw720x014.visa.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Visa is interested in seeing a small extension to IOTP for Version 2 that will support what we call "incremental" or "ongoing" payments. A familiar example of such an ongoing payment from the mundane, pre-internet world is a pay-telephone call. Internet based examples of such payments might include not only payment for connection time, but also payment for ongoing activities such as game playing. While this can be implemented under Version 1, it is somewhat awkward. Specifically, we would like to see added to the standard IOTP element definitions the following: 1) an optional data element indicating that this transaction is one of three possibilities: a stand-alone single payment (the default), the initial payment of an ongoing payment transaction set, and an incremental payment. (in the last case, the initial payment is referenced using the Related To component). 2) an data element, used only for the initial payment of an ongoing transaction set, giving the maximum permitted incremental payment amount in each offered currency. The authentication of the customer/cardholder, and the negotiation of the price and means of payment is performed once only, during the processing of the initial payment for the transaction set. This negotiation includes both the agreement of an initial payment amount, and the maximum amount for the subsequent incremental payments. The subsequent incremental payment transactions would be for any amount not greater than the agreed maximum. Using game playing as an example: Before starting the game, the merchant and customer systems negotiate the payment brand and protocol, and agree that the customer will be charged $3 for an initial 30 minutes of playing time, $.50 for each subsequent 10 minute period, and will be credited $.10 for each game level achieved. This can be expressed as agreeing to an immediate payment of $3 and to maximum incremental payments of $.50. In other words, the initial payment of the set indicates $3 in the "amount" attribute in the currency amount element and $.50 in the new maximum incremental amount. The subsequent incremental payments may contain any value up to $.50 in the "amount" attribute. In this example, if the game player had achieved a new game level, then the next payment would be $.40. Janet Roth __________________________________________________ roth@visa.com Chief Systems Architect Emerging Technologies - Application Architecture & Standards Visa International Ph. +1 (650) 432-1758; FAX +1 (650) 432-3199 Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA, 94404-2775, USA Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4J00301XB3VE@eListX.com>; Fri, 24 Nov 2000 18:01:51 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4J00303XB2VB@eListX.com> (original mail from scoya@cnri.reston.va.us) ; Fri, 24 Nov 2000 18:01:51 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4J00301XAVV1@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.eListX.com); Fri, 24 Nov 2000 18:01:49 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4J00301XAVUY@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.eListX.com); Fri, 24 Nov 2000 18:01:43 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4J002CGXAT2U@eListX.com> for ietf-trade@lists.eListX.com; Fri, 24 Nov 2000 18:01:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19022; Fri, 24 Nov 2000 18:01:07 -0500 (EST) Date: Fri, 24 Nov 2000 18:01:07 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-ecmlv2-req-00.txt Sender: scoya@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200011242301.SAA19022@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_RH0VKhDZpdkQPg6WtpaCRg)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , --Boundary_(ID_RH0VKhDZpdkQPg6WtpaCRg) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Electronic Commerce Modeling Language (ECML)Version 2 Requirements Author(s) : J. Parsons, D. Shepherd Filename : draft-ietf-trade-ecmlv2-req-00.txt Pages : 7 Date : 22-Nov-00 This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to the html and XML syntax, data model, format, payment processing, and external requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-ecmlv2-req-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-ecmlv2-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-ecmlv2-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_RH0VKhDZpdkQPg6WtpaCRg) Content-type: multipart/alternative; boundary="Boundary_(ID_4Fhkb5lgbjBqNH2iffUmVA)" --Boundary_(ID_4Fhkb5lgbjBqNH2iffUmVA) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <20001122145944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-ecmlv2-req-00.txt --Boundary_(ID_4Fhkb5lgbjBqNH2iffUmVA) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-ecmlv2-req-00.txt Content-Type: text/plain Content-ID: <20001122145944.I-D@ietf.org> --Boundary_(ID_4Fhkb5lgbjBqNH2iffUmVA)-- --Boundary_(ID_RH0VKhDZpdkQPg6WtpaCRg)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4I00L01QNPEP@eListX.com>; Fri, 24 Nov 2000 02:40:37 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4I00L03QNOEN@eListX.com> (original mail from fujimura@isl.ntt.co.jp) ; Fri, 24 Nov 2000 02:40:36 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4I00L01QNOEL@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.eListX.com); Fri, 24 Nov 2000 02:40:36 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4I00L01QNOEK@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.eListX.com); Fri, 24 Nov 2000 02:40:36 -0500 (EST) Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4I00INNQNM42@eListX.com> for ietf-trade@lists.eListX.com; Fri, 24 Nov 2000 02:40:35 -0500 (EST) Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id QAA07382 for ; Fri, 24 Nov 2000 16:39:59 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from alsace.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id QAA18644 for ; Fri, 24 Nov 2000 16:39:58 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from isl.ntt.co.jp (degas.isl.ntt.co.jp [129.60.104.56]) by alsace.isl.ntt.co.jp (8.8.8/3.7W) with ESMTP id QAA25769 for ; Fri, 24 Nov 2000 16:39:57 +0900 (JST) Date: Fri, 24 Nov 2000 16:43:52 +0900 From: Ko Fujimura Subject: New draft for Rights Trading To: ietf-trade@lists.eListX.com Message-id: <3A1E1C38.E278B82A@isl.ntt.co.jp> MIME-version: 1.0 X-Mailer: Mozilla 4.75 [ja] (Win98; U) Content-type: text/plain Content-transfer-encoding: 7BIT X-Accept-Language: ja List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Hi, I posted a new draft for rights trading to the internet directory. My apologies for taking such a long time to update the draft. You can see the draft from the following location until it will be officially announced: ftp://torque.pothole.com/pub/ietf-trade/draft-ietf-trade-drt-requirements-01.txt Major changes from the previous version are as follows: (1) Naming for "digitalized rights" The name for "digitalized rights" are changed from "digital-rights" to "electronic-rights", and "Generic" is added to the document title, etc. to avoid confusion with "Digital Property Rights". (2) Application examples A new section that describes application examples are added (Section 6) to clarify the objectives and benefit of rights trading. It may be helpful to consider the relationship between the IOTP model. (3) Improvement of readability A several editorial changes are made over the document, especially in Section 2.2 and 2.3, to improve the correctness and readability. Any comments or suggestions on this document are welcome. Regards, Ko ---------------------------------------------------------- Ko Fujimura, NTT Information Sharing Platform Laboratories 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241 Email: fujimura@isl.ntt.co.jp Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4F00301T4V11@eListX.com>; Wed, 22 Nov 2000 12:41:19 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4F00303T4U0Z@eListX.com> (original mail from lde008@dma.isg.mot.com) ; Wed, 22 Nov 2000 12:41:18 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4F00301T4U0X@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Wed, 22 Nov 2000 12:41:18 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4F00301T4T0W@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Wed, 22 Nov 2000 12:41:17 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4F001CLT4TP1@eListX.com> for ietf-trade@lists.eListX.com; Wed, 22 Nov 2000 12:41:17 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA11694; Wed, 22 Nov 2000 10:40:22 -0700 (MST) Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA12583; Wed, 22 Nov 2000 10:40:21 -0700 (MST) Received: from dma.isg.mot.com (nrlab-10.dma.isg.mot.com [150.21.50.48]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id MAA27947; Wed, 22 Nov 2000 12:40:20 -0500 (EST) Date: Wed, 22 Nov 2000 12:40:20 -0500 From: Donald Eastlake 3rd Subject: revised Payment API and SET Supplements available Sender: lde008@dma.isg.mot.com To: ietf-trade@lists.eListX.com Cc: dee3@torque.pothole.com, lde008@dma.isg.mot.com Message-id: <200011221740.MAA27947@noah.dma.isg.mot.com> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Revised drafts should be posted to the IETF internet drafts directory and officially announced shortly. In the mean time they are available from ftp://torque.pothole.com/pub/ietf-trade/draft-ietf-trade-iotp-v1.0-papi-03.txt and ftp://torque.pothole.com/pub/ietf-trade/draft-ietf-trade-iotp-v1.0-set-02.txt Thanks, Donald ================================================================== Donald Eastlake 3rd +1 508-634-2066(h) dee3@torque.pothole.com 155 Beaver Street +1 508-261-5434(w) lde008@dma.isg.mot.com Milford, MA 01757 USA Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4B007011GG7V@eListX.com>; Sun, 19 Nov 2000 22:53:04 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4B007031GG7T@eListX.com> (original mail from dee3@torque.pothole.com) ; Sun, 19 Nov 2000 22:53:04 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4B007011GF7R@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Sun, 19 Nov 2000 22:53:03 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4B007011GF7Q@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Sun, 19 Nov 2000 22:53:03 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4B0070T1GD52@eListX.com> for ietf-trade@lists.eListX.com; Sun, 19 Nov 2000 22:53:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id WAA21820; Sun, 19 Nov 2000 22:56:55 -0500 (EST) Date: Sun, 19 Nov 2000 22:56:55 -0500 From: "Donald E. Eastlake 3rd" Subject: preliminary ECML v2 requriements draft To: ietf-trade@lists.eListX.com Cc: lde008@dma.isg.mot.com Message-id: <200011200356.WAA21820@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp Hi, A preliminary draft to get things started on ECML v2 requirement has been submitted as an internet draft. The official announcement should appear on the mailing list shortly. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1 508-634-2066(h) Milford, MA 01757 USA +1 508-261-5434(w) Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G3Q00201Q04AT@eListX.com>; Wed, 08 Nov 2000 23:33:40 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G3Q00203Q04AR@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 08 Nov 2000 23:33:40 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G3Q00201Q03AP@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Wed, 08 Nov 2000 23:33:39 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G3Q00201Q03AO@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Wed, 08 Nov 2000 23:33:39 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G3Q0008DQ008I@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Nov 2000 23:33:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA09585; Wed, 08 Nov 2000 23:37:21 -0500 (EST) Date: Wed, 08 Nov 2000 23:37:21 -0500 From: "Donald E. Eastlake 3rd" Subject: Further revised draft new CHARTER To: ietf-trade@lists.eListX.com Cc: lde008@dma.isg.mot.com Message-id: <200011090437.XAA09585@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp My apologies for taking so long to get this out. I have incorporarted freedback from comments on the list to my previous draft new charter and produced the following. I have also adjusted dates and dropped the specific date milestones for the IOTP V2 Specification. The IOTP V2 Requirement document still has milestones. This is because of comments that the Specification should be more modular and my feeling that we will need to understand the requirements better before we can schedule the specification document or documents. Please post any further comments as I'd like to replace our way out of date charter very soon. Thanks, Donald Applications Area Advisor: Patrik Faltstrom Mailing Lists: General Discussion:ietf-trade@lists.eListX.com To Subscribe: ietf-trade-request@lists.eListX.com In Body: (un)subscribe Archive: http://www.eListX.com/archives/ietf-trade The Internet Open Trading Protocol is an interoperable framework for Internet commerce. It is optimized for the case where the buyer and the merchant do not have a prior acquaintance and is payment system independent. It can encapsulate and support payment systems such as SET, Mondex, secure channel card payment, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the payment handler, the deliverer of goods or services, and the provider of customer support are performed by different Internet sites. 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.) - Ability to indicate and handle a payment protocol not tunnelled through IOTP - Support for wallet servers - Repeated/ongoing payments - Server to Server messages - The ability to add both fields and attributes to trading blocks - Standardized XML Digital Signatures based on output from the XMLDSIG working group - Collaboration with other protocols such as ECML. The following is out of scope for IOTP version 2: - legal or regulatory issues surrounding the implementation of the protocol or information systems using it. - design of an XML Messaging Layer The working group will specify requirements for Digitally Represented Rights Trading. The working group will specify requirements for and then a syntax and processing model of ECML (Electronic Commerce Modeling Language) V2. Milestones 00 Nov Internet Draft publication Secure Channel Credit/Debit 00 Nov Working Group Last Call SET Supplement Architecture and Payment API (December 2000 IETF Meeting) 00 Dec Submit to IESG SET Supplement (Informational) Architecture and Payment API (Informational) 00 Dec Internet Draft publication ECML V2.0 Requirements IOTP V2.0 Requirements 01 Jan Submit to IESG Secure Channel Credit/Debit (Proposed Standard?) "Digital Rights" Trading Requirements (Informational) ECML V2.0 Requirements (Informational) 01 Jan Internet Draft publication ECML V2.0 Specification (March 2001 IETF Meeting) 01 Mar Submit to IESG IOTP V2.0 Requirements (Informational) 01 Mar Submit to IESG ECML V2.0 Specification (Proposed Standard) Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00M013ROQC@eListX.com>; Thu, 30 Nov 2000 05:57:24 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00M033RNQA@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Thu, 30 Nov 2000 05:57:24 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00M013RMQ4@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Thu, 30 Nov 2000 05:57:23 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00M013RLQ3@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Thu, 30 Nov 2000 05:57:21 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4U00KHV3RLCO@eListX.com> for ietf-trade@lists.elistx.com; Thu, 30 Nov 2000 05:57:21 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27759; Thu, 30 Nov 2000 05:56:48 -0500 (EST) Date: Thu, 30 Nov 2000 05:56:48 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-drt-requirements-01.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.elistx.com Reply-to: Internet-Drafts@ietf.org Message-id: <200011301056.FAA27759@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_XtHEVSjBR+e5mjdi26Wl/g)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , --Boundary_(ID_XtHEVSjBR+e5mjdi26Wl/g) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Requirements for Digital-Right Trading Author(s) : K. Fujimura Filename : draft-ietf-trade-drt-requirements-01.txt Pages : 11 Date : 29-Nov-00 In purchase and other trading transactions, it is often required to credit loyalty points, collect digital coupons or gift certificates, and so on. The IETF Trade Working Group is investigating how these activities can be generalized using the concept of a 'digital-right', which is a digital representation of the right to claim goods or services. This document contains the requirements in the following areas: - The digital rights trading model - The language to describe diverse types of digital rights A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-drt-requirements-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-drt-requirements-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-drt-requirements-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_XtHEVSjBR+e5mjdi26Wl/g) Content-type: multipart/alternative; boundary="Boundary_(ID_gN68WLZHO2UDNgL6yBdFBg)" --Boundary_(ID_gN68WLZHO2UDNgL6yBdFBg) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <20001129114459.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-drt-requirements-01.txt --Boundary_(ID_gN68WLZHO2UDNgL6yBdFBg) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-drt-requirements-01.txt Content-Type: text/plain Content-ID: <20001129114459.I-D@ietf.org> --Boundary_(ID_gN68WLZHO2UDNgL6yBdFBg)-- --Boundary_(ID_XtHEVSjBR+e5mjdi26Wl/g)-- Return-path: Received: from PIPE-ELISTX-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U0040DLPXYS@eListX.com> (original mail from ietf-trade-errors@lists.elistx.com); Thu, 30 Nov 2000 12:25:09 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00401LOMX0@eListX.com>; Thu, 30 Nov 2000 12:24:23 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00403LOMWY@eListX.com> (original mail from dee3@torque.pothole.com) ; Thu, 30 Nov 2000 12:24:22 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00401LOKWV@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 30 Nov 2000 12:24:21 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4U00401LOKWU@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Thu, 30 Nov 2000 12:24:20 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4U00382LOHZ7@eListX.com> for ietf-trade@lists.elistx.com; Thu, 30 Nov 2000 12:24:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id MAA05295; Thu, 30 Nov 2000 12:28:22 -0500 (EST) Date: Thu, 30 Nov 2000 12:28:22 -0500 From: "Donald E. Eastlake 3rd" Subject: Working Group Last Call for Payment API and SET Supplement To: ietf-trade@lists.elistx.com Cc: lde008@dma.isg.mot.com Message-id: <200011301728.MAA05295@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp This is a working group last call for Payment API for v1.0 Internet Open Trading Protocol (IOTP) ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt and SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) ftp://ftp.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt Both of these documents are currently intended to become Informational RFCs. If you believe they should have a different status, such as Experimental or Proposed Standard, you should indicate why. I expect that these documents will be on the agenda of the TRADE WG meeting in San Diego (). This working group last call is through December 22nd 2000 to decide if there is a consensus to advance these documents. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1 508-634-2066(h) Milford, MA 01757 USA +1 508-261-5434(w) Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00J01ZOLNE@eListX.com>; Tue, 28 Nov 2000 13:36:21 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00J03ZOKNC@eListX.com> (original mail from roth@visa.com); Tue, 28 Nov 2000 13:36:20 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00J01ZOJN8@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 13:36:20 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00J01ZOJN7@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 13:36:19 -0500 (EST) Received: from portal1.visa.com (portal1.visa.com [198.80.42.2]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G4Q00GNNZOIYH@eListX.com> for ietf-trade@lists.elistx.com; Tue, 28 Nov 2000 13:36:19 -0500 (EST) Received: by portal1.visa.com id KAA23305 (InterLock SMTP Gateway 4.2 for ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 10:35:26 -0800 Received: by portal1.visa.com (Protected-side Proxy Mail Agent-1); Tue, 28 Nov 2000 10:35:26 -0800 Date: Tue, 28 Nov 2000 10:34:03 -0800 From: "Roth, Janet" Subject: RE: Ongoing payments - IOTP Version 2 extension To: "'ietf-trade@lists.eListX.com'" Cc: "Lewis, Tony" , "Howell, Phil" Message-id: <95288CC7E7F7D111883B0001FAF85C0303E5A2C8@sw720x014.visa.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: multipart/alternative; boundary="Boundary_(ID_DgIOW46rYG/euCTbuaE5tQ)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_DgIOW46rYG/euCTbuaE5tQ) Content-type: text/plain The issues Chris raises are interesting ones, but IOTP in and of itself can't resolve them. Those have to be addressed by the overall payment protocol. Firstly, because of these issues (and others not mentioned) a payment protocol designed to accomodate ongoing payments needs to ensure that the customer system is present and "approves" each incremental payment. (There are of course a variety of methods of implementing the customer approval. Just as an example, continuing to play a game after a signal of some sort indicating that more money is required might indicate approval of the next increment). As Chris points out, it must be possible to "close" the transaction, even if the customer is no longer present. The protocol should ensure that the merchant/acquirer cannot get paid without doing this. If the customer is still connected, there can also be an (informational) message to the customer system that indicates the closure and gives the status. Otherwise, the customer may go to her issuer site (later, when reconnected) to determine the transaction status. A payment product's business rules must determine how disputes are handled. Depending on the business model, you may allow "chargebacks", or may not. (if you do, those are back-end issues, and are not part of the customer system interface to the merchant system). If not, then the payment protocol must certainly provide a refund mechanism. In the event a particular merchant is mischarging or otherwise mis-behaving, and not providing refunds or other customer satisfaction, then the recourse would be defined by the owner, or guarantor, of the payment acceptance mark under which the payments were made. What is done (such as sanctions on the merchant) seem to be primarily business questions (or possible legal questions), rather than technical or protocol issues. -Janet Roth -----Original Message----- From: Smith, Chris [mailto:CHRIS.SMITH@ROYALBANK.COM] Sent: Monday, November 27, 2000 3:42 PM To: 'ietf-trade@lists.eListX.com' Subject: RE: Ongoing payments - IOTP Version 2 extension > -----Original Message----- > From: Roth, Janet [ mailto:roth@visa.com ] > > Using game playing as an example: > > Before starting the game, the merchant and customer systems > negotiate the payment brand and protocol, and agree that the > customer will be charged $3 for an initial 30 minutes of > playing time, $.50 for each subsequent 10 minute period, > and will be credited $.10 for each game level achieved. > This can be expressed as agreeing to an immediate payment > of $3 and to maximum incremental payments of $.50. I like the idea, but even more, I like your example. Hopefully it will allow for resolution of some of the issues that arise around such payments. In particular - given that the negotiation is only done up front, how does the customer know that the merchant is using a "valid clock"? As I understand your example, there is no guaranteed closing step where the customer is informed of the total amount. There is good reason for NOT having such a step, because this may be impossible if the customer is accidentally disconnected. But - in the event the customer is disconnected, how do they complain about overcharging? The merchant appears to be able to continue charging you for several more 'units'. This may be even more subtle when you reconnect two hours later, and you really reconnect to the same game and position - and the merchant then charges you for the two hours, arguing that he had to expend resources to maintain your game, whether you were actively playing, or 'just thinking' while disconnected. If the customer is using a chipcard payment system, then a disconnect will also prevent future payments. But a 'virtual card' system, or even a credit card system, allows the merchant to continue charging without further communication with the customer. ------------------------------------------------------------ Chris Smith Royal Bank Senior Technical Consultant Smart Card Systems 277 Front Street West, 2nd Floor Toronto, Ontario M5V 2X4 Tel: (416) 348-6090 Fax: (416) 348-2210 > -----Original Message----- > From: Roth, Janet [ mailto:roth@visa.com ] > Sent: November 27, 2000 06:09 PM > To: 'ietf-trade@lists.eListX.com' > Subject: Ongoing payments - IOTP Version 2 extension > > > > Visa is interested in seeing a small extension to IOTP for > Version 2 that > will support what we call "incremental" or "ongoing" > payments. A familiar > example of such an ongoing payment from the mundane, > pre-internet world is a > pay-telephone call. Internet based examples of such payments > might include > not only payment for connection time, but also payment for ongoing > activities such as game playing. While this can be implemented under > Version 1, it is somewhat awkward. > > Specifically, we would like to see added to the standard IOTP element > definitions the following: > > 1) an optional data element indicating that this transaction > is one of three > possibilities: a stand-alone single payment (the default), > the initial > payment of an ongoing payment transaction set, and an > incremental payment. > (in the last case, the initial payment is referenced using > the Related To > component). > > 2) an data element, used only for the initial payment of an ongoing > transaction set, giving the maximum permitted incremental > payment amount in > each offered currency. > > The authentication of the customer/cardholder, and the > negotiation of the > price and means of payment is performed once only, during the > processing of > the initial payment for the transaction set. This > negotiation includes both > the agreement of an initial payment amount, and the maximum > amount for the > subsequent incremental payments. The subsequent incremental payment > transactions would be for any amount not greater than the > agreed maximum. > > Using game playing as an example: > > Before starting the game, the merchant and customer systems > negotiate the > payment brand and protocol, and agree that the customer will > be charged $3 > for an initial 30 minutes of playing time, $.50 for each subsequent 10 > minute period, and will be credited $.10 for each game level > achieved. This > can be expressed as agreeing to an immediate payment of $3 > and to maximum > incremental payments of $.50. > > In other words, the initial payment of the set indicates $3 > in the "amount" > attribute in the currency amount element and $.50 in the new maximum > incremental amount. The subsequent incremental payments may > contain any > value up to $.50 in the "amount" attribute. In this example, > if the game > player had achieved a new game level, then the next payment > would be $.40. > > > Janet Roth > __________________________________________________ > roth@visa.com > Chief Systems Architect > Emerging Technologies - Application Architecture & Standards > Visa International > Ph. +1 (650) 432-1758; FAX +1 (650) 432-3199 > Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA, > 94404-2775, USA > > --Boundary_(ID_DgIOW46rYG/euCTbuaE5tQ) Content-type: text/html; charset=iso-8859-1 RE: Ongoing payments - IOTP Version 2 extension
The issues Chris raises are interesting ones, but IOTP in and of itself can't resolve them.  Those have to be addressed by the overall payment protocol. 
 
Firstly, because of these issues (and others not mentioned) a payment protocol designed to accomodate ongoing payments needs to ensure that the customer system is present and "approves" each incremental payment.  (There are of course a variety of methods of implementing the customer approval.  Just as an example, continuing to play a game after a signal of some sort indicating that more money is required might indicate approval of the next increment).  
 
As Chris points out, it must be possible to "close" the transaction, even if the customer is no longer present.  The protocol should ensure that the merchant/acquirer cannot get paid without doing this.
 
If the customer is still connected, there can also be an (informational) message to the customer system that indicates the closure and gives the status.  Otherwise, the customer may go to her issuer site (later, when reconnected) to determine the transaction status.
 
A payment product's business rules must determine how disputes are handled.  Depending on the business model, you may allow "chargebacks", or may not.  (if you do, those are back-end issues, and are not part of the customer system interface to the merchant system).  If not, then the payment protocol must certainly provide a refund mechanism. 
 
In the event a particular merchant is mischarging or otherwise mis-behaving, and not providing refunds or other customer satisfaction, then the recourse would be defined by the owner, or guarantor, of the payment acceptance mark under which the payments were made.  What is done (such as sanctions on the merchant) seem to be primarily business questions (or possible legal questions), rather than technical or protocol issues. 
 
    -Janet Roth
 

 -----Original Message-----
From: Smith, Chris [mailto:CHRIS.SMITH@ROYALBANK.COM]
Sent: Monday, November 27, 2000 3:42 PM
To: 'ietf-trade@lists.eListX.com'
Subject: RE: Ongoing payments - IOTP Version 2 extension

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
>
> Using game playing as an example:
>
> Before starting the game, the merchant and customer systems
> negotiate the payment brand and protocol, and agree that the
> customer will be charged $3 for an initial 30 minutes of
> playing time, $.50 for each subsequent 10 minute period,
> and will be credited $.10 for each game level achieved.
> This can be expressed as agreeing to an immediate payment
> of $3 and to maximum incremental payments of $.50.

I like the idea, but even more, I like your example. Hopefully
it will allow for resolution of some of the issues that arise
around such payments.

In particular - given that the negotiation is only done up
front, how does the customer know that the merchant is using
a "valid clock"? As I understand your example, there is no
guaranteed closing step where the customer is informed of the
total amount. There is good reason for NOT having such a step,
because this may be impossible if the customer is accidentally
disconnected.

But - in the event the customer is disconnected, how do they
complain about overcharging? The merchant appears to be able
to continue charging you for several more 'units'. This may
be even more subtle when you reconnect two hours later, and
you really reconnect to the same game and position - and the
merchant then charges you for the two hours, arguing that he
had to expend resources to maintain your game, whether you
were actively playing, or 'just thinking' while
disconnected.

If the customer is using a chipcard payment system, then a
disconnect will also prevent future payments. But a 'virtual
card' system, or even a credit card system, allows the merchant
to continue charging without further communication with the
customer.

------------------------------------------------------------
 Chris Smith                                     Royal Bank
 Senior Technical Consultant
 Smart Card Systems
 277 Front Street West, 2nd Floor
 Toronto, Ontario M5V 2X4
 Tel: (416) 348-6090
 Fax: (416) 348-2210

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
> Sent: November 27, 2000 06:09 PM
> To: 'ietf-trade@lists.eListX.com'
> Subject: Ongoing payments - IOTP Version 2 extension
>
>
>
> Visa is interested in seeing a small extension to IOTP for
> Version 2 that
> will support what we call "incremental" or "ongoing"
> payments.  A familiar
> example of such an ongoing payment from the mundane,
> pre-internet world is a
> pay-telephone call.  Internet based examples of such payments
> might include
> not only payment for connection time, but also payment for ongoing
> activities such as game playing.  While this can be implemented under
> Version 1, it is somewhat awkward.
>
> Specifically, we would like to see added to the standard IOTP element
> definitions the following:
>
> 1) an optional data element indicating that this transaction
> is one of three
> possibilities:  a stand-alone single payment (the default),
> the initial
> payment of an ongoing payment transaction set, and an
> incremental payment.
> (in the last case, the initial payment is referenced using
> the Related To
> component).
>
> 2) an data element, used only for the initial payment of an ongoing
> transaction set, giving the maximum permitted incremental
> payment amount in
> each offered currency.
>
> The authentication of the customer/cardholder, and the
> negotiation of the
> price and means of payment is performed once only, during the
> processing of
> the initial payment for the transaction set.  This
> negotiation includes both
> the agreement of an initial payment amount, and the maximum
> amount for the
> subsequent incremental payments.  The subsequent incremental payment
> transactions would be for any amount not greater than the
> agreed maximum.
>
> Using game playing as an example:
>
> Before starting the game, the merchant and customer systems
> negotiate the
> payment brand and protocol, and agree that the customer will
> be charged $3
> for an initial 30 minutes of playing time, $.50 for each subsequent 10
> minute period, and will be credited $.10 for each game level
> achieved.  This
> can be expressed as agreeing to an immediate payment of $3
> and to maximum
> incremental payments of $.50. 
>
> In other words, the initial payment of the set indicates $3
> in the "amount"
> attribute in the currency amount element and $.50 in the new maximum
> incremental amount.  The subsequent incremental payments may
> contain any
> value up to $.50 in the "amount" attribute.  In this example,
> if the game
> player had achieved a new game level, then the next payment
> would be $.40.
>
>
> Janet Roth
> __________________________________________________
> roth@visa.com
> Chief Systems Architect
> Emerging Technologies - Application Architecture & Standards
> Visa International
> Ph. +1 (650) 432-1758;  FAX +1 (650) 432-3199
> Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA,
> 94404-2775, USA
>
>

--Boundary_(ID_DgIOW46rYG/euCTbuaE5tQ)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELZTM@eListX.com>; Tue, 28 Nov 2000 06:01:11 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D03ELYTK@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Tue, 28 Nov 2000 06:01:10 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELVTC@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 06:01:10 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELVTA@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 06:01:07 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4Q00ANJELUEE@eListX.com> for ietf-trade@lists.elistx.com; Tue, 28 Nov 2000 06:01:06 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04199; Tue, 28 Nov 2000 06:00:35 -0500 (EST) Date: Tue, 28 Nov 2000 06:00:34 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-set-02.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.elistx.com Reply-to: Internet-Drafts@ietf.org Message-id: <200011281100.GAA04199@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_XLH1XM75sSnaV9eKi34Y6A)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , --Boundary_(ID_XLH1XM75sSnaV9eKi34Y6A) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : SET Supplement for the v1.0 Internet Open Trading Protocol (IOTP) Author(s) : Y. Kawatsura Filename : draft-ietf-trade-iotp-v1.0-set-02.txt Pages : 58 Date : 27-Nov-00 This document describes detailed Input/Output parameter for the IOTP Payment API and a procedure in the Payment Bridge for use SET as the payment protocol within Version 1.0 of the Internet Open Trading Protocol (IOTP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-v1.0-set-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_XLH1XM75sSnaV9eKi34Y6A) Content-type: multipart/alternative; boundary="Boundary_(ID_nnTvSYgVgTgXJxf10u9FmA)" --Boundary_(ID_nnTvSYgVgTgXJxf10u9FmA) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <20001127133133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-set-02.txt --Boundary_(ID_nnTvSYgVgTgXJxf10u9FmA) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-iotp-v1.0-set-02.txt Content-Type: text/plain Content-ID: <20001127133133.I-D@ietf.org> --Boundary_(ID_nnTvSYgVgTgXJxf10u9FmA)-- --Boundary_(ID_XLH1XM75sSnaV9eKi34Y6A)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELQSU@eListX.com>; Tue, 28 Nov 2000 06:01:02 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D03ELQSS@eListX.com> (original mail from nsyracus@cnri.reston.va.us) ; Tue, 28 Nov 2000 06:01:02 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELNRM@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 06:01:01 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4Q00D01ELNRL@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Tue, 28 Nov 2000 06:00:59 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4Q00ANGELNEE@eListX.com> for ietf-trade@lists.elistx.com; Tue, 28 Nov 2000 06:00:59 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04159; Tue, 28 Nov 2000 06:00:28 -0500 (EST) Date: Tue, 28 Nov 2000 06:00:27 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-iotp-v1.0-papi-03.txt Sender: nsyracus@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.elistx.com Reply-to: Internet-Drafts@ietf.org Message-id: <200011281100.GAA04159@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_1/xXY2Ty1cMp++Zxt0Z7ag)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , --Boundary_(ID_1/xXY2Ty1cMp++Zxt0Z7ag) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Payment API for v1.0 Internet Open Trading Protocol (IOTP) Author(s) : W. Hans, H. Beykirch, M. Hiroya, Y. Kawatsura Filename : draft-ietf-trade-iotp-v1.0-papi-03.txt Pages : 103 Date : 27-Nov-00 The Internet Open Trading Protocol provides a data exchange format for trading purposes while integrating existing pure payment protocols seamlessly. This motivates the multiple layered system architecture which consists of at least some generic IOTP application core and multiple specific payment modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-iotp-v1.0-papi-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_1/xXY2Ty1cMp++Zxt0Z7ag) Content-type: multipart/alternative; boundary="Boundary_(ID_5z0G9r2acLzhTKjr3ulRFQ)" --Boundary_(ID_5z0G9r2acLzhTKjr3ulRFQ) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <20001127133123.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-iotp-v1.0-papi-03.txt --Boundary_(ID_5z0G9r2acLzhTKjr3ulRFQ) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-iotp-v1.0-papi-03.txt Content-Type: text/plain Content-ID: <20001127133123.I-D@ietf.org> --Boundary_(ID_5z0G9r2acLzhTKjr3ulRFQ)-- --Boundary_(ID_1/xXY2Ty1cMp++Zxt0Z7ag)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7NIO@eListX.com>; Mon, 27 Nov 2000 18:42:59 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00903J7NIM@eListX.com> (original mail from CHRIS.SMITH@ROYALBANK.COM) ; Mon, 27 Nov 2000 18:42:59 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7MII@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Mon, 27 Nov 2000 18:42:59 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901J7MIH@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.elistx.com); Mon, 27 Nov 2000 18:42:58 -0500 (EST) Received: from uhrbc1p1.royalbank.com (uhrbc1p1.royalbank.com [198.96.131.220]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G4P005J5J7HD2@eListX.com> for ietf-trade@lists.elistx.com; Mon, 27 Nov 2000 18:42:58 -0500 (EST) Received: from wsecure3.royalbank.com by uhrbc1p1.royalbank.com via smtpd (for one.elistx.com [209.116.252.130]) with SMTP; Mon, 27 Nov 2000 23:39:08 +0000 (UT) Received: from 10.224.0.79 by se001021.royalbank.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.5); Mon, 27 Nov 2000 18:41:34 -0500 Received: by se001025.rbc1.royalbank.com with Internet Mail Service ( 5.5.2650.21) id ; Mon, 27 Nov 2000 18:42:22 -0500 Date: Mon, 27 Nov 2000 18:42:19 -0500 From: "Smith, Chris " Subject: RE: Ongoing payments - IOTP Version 2 extension To: "'ietf-trade@lists.eListX.com'" Message-id: <55D770EEA49FD4118FDE00D0B7692F91243083@se001035.rbc1.royalbank.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ)" X-Server-Uuid: 69f58f12-9d1a-11d3-825a-00609455ee28 X-WSS-ID: 163C2EA4137363-02-01 List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ) Content-type: text/plain Content-transfer-encoding: QUOTED-PRINTABLE > -----Original Message----- > From: Roth, Janet [mailto:roth@visa.com] > > Using game playing as an example: >=20 > Before starting the game, the merchant and customer systems > negotiate the payment brand and protocol, and agree that the > customer will be charged $3 for an initial 30 minutes of > playing time, $.50 for each subsequent 10 minute period, > and will be credited $.10 for each game level achieved. > This can be expressed as agreeing to an immediate payment > of $3 and to maximum incremental payments of $.50. I like the idea, but even more, I like your example. Hopefully it will allow for resolution of some of the issues that arise around such payments. In particular - given that the negotiation is only done up front, how does the customer know that the merchant is using a "valid clock"? As I understand your example, there is no guaranteed closing step where the customer is informed of the total amount. There is good reason for NOT having such a step, because this may be impossible if the customer is accidentally disconnected. But - in the event the customer is disconnected, how do they complain about overcharging? The merchant appears to be able to continue charging you for several more 'units'. This may be even more subtle when you reconnect two hours later, and you really reconnect to the same game and position - and the merchant then charges you for the two hours, arguing that he had to expend resources to maintain your game, whether you were actively playing, or 'just thinking' while=20 disconnected. If the customer is using a chipcard payment system, then a disconnect will also prevent future payments. But a 'virtual card' system, or even a credit card system, allows the merchant to continue charging without further communication with the customer. ------------------------------------------------------------ =A0Chris Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0 Royal Bank =A0Senior Technical Consultant =A0Smart Card Systems =A0277 Front Street West, 2nd Floor =A0Toronto, Ontario M5V 2X4 =A0Tel: (416) 348-6090 =A0Fax: (416) 348-2210 > -----Original Message----- > From: Roth, Janet [mailto:roth@visa.com] > Sent: November 27, 2000 06:09 PM > To: 'ietf-trade@lists.eListX.com' > Subject: Ongoing payments - IOTP Version 2 extension >=20 >=20 >=20 > Visa is interested in seeing a small extension to IOTP for=20 > Version 2 that > will support what we call "incremental" or "ongoing"=20 > payments. A familiar > example of such an ongoing payment from the mundane,=20 > pre-internet world is a > pay-telephone call. Internet based examples of such payments=20 > might include > not only payment for connection time, but also payment for ongoing > activities such as game playing. While this can be implemented und= er > Version 1, it is somewhat awkward. >=20 > Specifically, we would like to see added to the standard IOTP eleme= nt > definitions the following: >=20 > 1) an optional data element indicating that this transaction=20 > is one of three > possibilities: a stand-alone single payment (the default),=20 > the initial > payment of an ongoing payment transaction set, and an=20 > incremental payment. > (in the last case, the initial payment is referenced using=20 > the Related To > component).=20 >=20 > 2) an data element, used only for the initial payment of an ongoing > transaction set, giving the maximum permitted incremental=20 > payment amount in > each offered currency. >=20 > The authentication of the customer/cardholder, and the=20 > negotiation of the > price and means of payment is performed once only, during the=20 > processing of > the initial payment for the transaction set. This=20 > negotiation includes both > the agreement of an initial payment amount, and the maximum=20 > amount for the > subsequent incremental payments. The subsequent incremental paymen= t > transactions would be for any amount not greater than the=20 > agreed maximum. >=20 > Using game playing as an example: >=20 > Before starting the game, the merchant and customer systems=20 > negotiate the > payment brand and protocol, and agree that the customer will=20 > be charged $3 > for an initial 30 minutes of playing time, $.50 for each subsequent= 10 > minute period, and will be credited $.10 for each game level=20 > achieved. This > can be expressed as agreeing to an immediate payment of $3=20 > and to maximum > incremental payments of $.50. =20 >=20 > In other words, the initial payment of the set indicates $3=20 > in the "amount" > attribute in the currency amount element and $.50 in the new maximu= m > incremental amount. The subsequent incremental payments may=20 > contain any > value up to $.50 in the "amount" attribute. In this example,=20 > if the game > player had achieved a new game level, then the next payment=20 > would be $.40. >=20 >=20 > Janet Roth > __________________________________________________ > roth@visa.com > Chief Systems Architect > Emerging Technologies - Application Architecture & Standards > Visa International > Ph. +1 (650) 432-1758; FAX +1 (650) 432-3199 > Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA,=20 > 94404-2775, USA >=20 >=20 --Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE RE: Ongoing payments - IOTP Version 2 extension

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
>
> Using game playing as an example:
>
> Before starting the game, the merchant and cu= stomer systems
> negotiate the payment brand and protocol, and= agree that the
> customer will be charged $3 for an initial 30= minutes of
> playing time, $.50 for each subsequent 10 min= ute period,
> and will be credited $.10 for each game level= achieved.
> This can be expressed as agreeing to an immed= iate payment
> of $3 and to maximum incremental payments of = $.50.

I like the idea, but even more, I like your example= . Hopefully
it will allow for resolution of some of the issues= that arise
around such payments.

In particular - given that the negotiation is only = done up
front, how does the customer know that the merchan= t is using
a "valid clock"? As I understand your ex= ample, there is no
guaranteed closing step where the customer is info= rmed of the
total amount. There is good reason for NOT having = such a step,
because this may be impossible if the customer is = accidentally
disconnected.

But - in the event the customer is disconnected, ho= w do they
complain about overcharging? The merchant appears = to be able
to continue charging you for several more 'units'.= This may
be even more subtle when you reconnect two hours l= ater, and
you really reconnect to the same game and position= - and the
merchant then charges you for the two hours, argui= ng that he
had to expend resources to maintain your game, whe= ther you
were actively playing, or 'just thinking' while
disconnected.

If the customer is using a chipcard payment system,= then a
disconnect will also prevent future payments. But = a 'virtual
card' system, or even a credit card system, allows= the merchant
to continue charging without further communication= with the
customer.

---------------------------------------------------= ---------
=A0Chris Smith=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0      =    =A0=A0=A0=A0=A0 Royal Bank
=A0Senior Technical Consultant
=A0Smart Card Systems
=A0277 Front Street West, 2nd Floor
=A0Toronto, Ontario M5V 2X4
=A0Tel: (416) 348-6090
=A0Fax: (416) 348-2210

> -----Original Message-----
> From: Roth, Janet [mailto:roth@visa.com]
> Sent: November 27, 2000 06:09 PM
> To: 'ietf-trade@lists.eListX.com'
> Subject: Ongoing payments - IOTP Version 2 ex= tension
>
>
>
> Visa is interested in seeing a small extensio= n to IOTP for
> Version 2 that
> will support what we call "incremental&q= uot; or "ongoing"
> payments.  A familiar
> example of such an ongoing payment from the m= undane,
> pre-internet world is a
> pay-telephone call.  Internet based exam= ples of such payments
> might include
> not only payment for connection time, but als= o payment for ongoing
> activities such as game playing.  While = this can be implemented under
> Version 1, it is somewhat awkward.
>
> Specifically, we would like to see added to t= he standard IOTP element
> definitions the following:
>
> 1) an optional data element indicating that t= his transaction
> is one of three
> possibilities:  a stand-alone single pay= ment (the default),
> the initial
> payment of an ongoing payment transaction set= , and an
> incremental payment.
> (in the last case, the initial payment is ref= erenced using
> the Related To
> component).
>
> 2) an data element, used only for the initial= payment of an ongoing
> transaction set, giving the maximum permitted= incremental
> payment amount in
> each offered currency.
>
> The authentication of the customer/cardholder= , and the
> negotiation of the
> price and means of payment is performed once = only, during the
> processing of
> the initial payment for the transaction set.&= nbsp; This
> negotiation includes both
> the agreement of an initial payment amount, a= nd the maximum
> amount for the
> subsequent incremental payments.  The su= bsequent incremental payment
> transactions would be for any amount not grea= ter than the
> agreed maximum.
>
> Using game playing as an example:
>
> Before starting the game, the merchant and cu= stomer systems
> negotiate the
> payment brand and protocol, and agree that th= e customer will
> be charged $3
> for an initial 30 minutes of playing time, $.= 50 for each subsequent 10
> minute period, and will be credited $.10 for = each game level
> achieved.  This
> can be expressed as agreeing to an immediate = payment of $3
> and to maximum
> incremental payments of $.50. 
>
> In other words, the initial payment of the se= t indicates $3
> in the "amount"
> attribute in the currency amount element and = $.50 in the new maximum
> incremental amount.  The subsequent incr= emental payments may
> contain any
> value up to $.50 in the "amount" at= tribute.  In this example,
> if the game
> player had achieved a new game level, then th= e next payment
> would be $.40.
>
>
> Janet Roth
> _____________________________________________= _____
> roth@visa.com
> Chief Systems Architect
> Emerging Technologies - Application Architect= ure & Standards
> Visa International
> Ph. +1 (650) 432-1758;  FAX +1 (650) 432= -3199
> Mailstop M1-8H, 900 Metro Center Blvd., Foste= r City CA,
> 94404-2775, USA
>
>

--Boundary_(ID_EglEGcl+hWH3EeXw4CJfhQ)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901HQG80@eListX.com>; Mon, 27 Nov 2000 18:11:04 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00903HQG7Y@eListX.com> (original mail from roth@visa.com); Mon, 27 Nov 2000 18:11:04 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901HQF7W@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Mon, 27 Nov 2000 18:11:03 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4P00901HQF7V@eListX.com> for ietf-trade@elists.elistx.com (ORCPT ietf-trade@lists.eListX.com); Mon, 27 Nov 2000 18:11:03 -0500 (EST) Received: from portal1.visa.com (portal1.visa.com [198.80.42.2]) by eListX.com (PMDF V6.0-24 #44856) with SMTP id <0G4P005GGHQED2@eListX.com> for ietf-trade@lists.elistx.com; Mon, 27 Nov 2000 18:11:03 -0500 (EST) Received: by portal1.visa.com id PAA10554 (InterLock SMTP Gateway 4.2 for ietf-trade@lists.eListX.com); Mon, 27 Nov 2000 15:10:29 -0800 Received: by portal1.visa.com (Protected-side Proxy Mail Agent-1); Mon, 27 Nov 2000 15:10:29 -0800 Date: Mon, 27 Nov 2000 15:09:11 -0800 From: "Roth, Janet" Subject: Ongoing payments - IOTP Version 2 extension To: "'ietf-trade@lists.eListX.com'" Message-id: <95288CC7E7F7D111883B0001FAF85C0303E5A2B9@sw720x014.visa.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Visa is interested in seeing a small extension to IOTP for Version 2 that will support what we call "incremental" or "ongoing" payments. A familiar example of such an ongoing payment from the mundane, pre-internet world is a pay-telephone call. Internet based examples of such payments might include not only payment for connection time, but also payment for ongoing activities such as game playing. While this can be implemented under Version 1, it is somewhat awkward. Specifically, we would like to see added to the standard IOTP element definitions the following: 1) an optional data element indicating that this transaction is one of three possibilities: a stand-alone single payment (the default), the initial payment of an ongoing payment transaction set, and an incremental payment. (in the last case, the initial payment is referenced using the Related To component). 2) an data element, used only for the initial payment of an ongoing transaction set, giving the maximum permitted incremental payment amount in each offered currency. The authentication of the customer/cardholder, and the negotiation of the price and means of payment is performed once only, during the processing of the initial payment for the transaction set. This negotiation includes both the agreement of an initial payment amount, and the maximum amount for the subsequent incremental payments. The subsequent incremental payment transactions would be for any amount not greater than the agreed maximum. Using game playing as an example: Before starting the game, the merchant and customer systems negotiate the payment brand and protocol, and agree that the customer will be charged $3 for an initial 30 minutes of playing time, $.50 for each subsequent 10 minute period, and will be credited $.10 for each game level achieved. This can be expressed as agreeing to an immediate payment of $3 and to maximum incremental payments of $.50. In other words, the initial payment of the set indicates $3 in the "amount" attribute in the currency amount element and $.50 in the new maximum incremental amount. The subsequent incremental payments may contain any value up to $.50 in the "amount" attribute. In this example, if the game player had achieved a new game level, then the next payment would be $.40. Janet Roth __________________________________________________ roth@visa.com Chief Systems Architect Emerging Technologies - Application Architecture & Standards Visa International Ph. +1 (650) 432-1758; FAX +1 (650) 432-3199 Mailstop M1-8H, 900 Metro Center Blvd., Foster City CA, 94404-2775, USA Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4J00301XB3VE@eListX.com>; Fri, 24 Nov 2000 18:01:51 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4J00303XB2VB@eListX.com> (original mail from scoya@cnri.reston.va.us) ; Fri, 24 Nov 2000 18:01:51 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4J00301XAVV1@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.eListX.com); Fri, 24 Nov 2000 18:01:49 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4J00301XAVUY@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.eListX.com); Fri, 24 Nov 2000 18:01:43 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4J002CGXAT2U@eListX.com> for ietf-trade@lists.eListX.com; Fri, 24 Nov 2000 18:01:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19022; Fri, 24 Nov 2000 18:01:07 -0500 (EST) Date: Fri, 24 Nov 2000 18:01:07 -0500 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-trade-ecmlv2-req-00.txt Sender: scoya@cnri.reston.va.us To: IETF-Announce: ; Cc: ietf-trade@lists.eListX.com Reply-to: Internet-Drafts@ietf.org Message-id: <200011242301.SAA19022@ietf.org> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_RH0VKhDZpdkQPg6WtpaCRg)" List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , --Boundary_(ID_RH0VKhDZpdkQPg6WtpaCRg) Content-type: TEXT/PLAIN A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Internet Open Trading Protocol Working Group of the IETF. Title : Electronic Commerce Modeling Language (ECML)Version 2 Requirements Author(s) : J. Parsons, D. Shepherd Filename : draft-ietf-trade-ecmlv2-req-00.txt Pages : 7 Date : 22-Nov-00 This document lists the design principles, scope, and requirements for the Electronic Commerce Modeling Language (ECML) version 2 specification. It includes requirements as they relate to the html and XML syntax, data model, format, payment processing, and external requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-trade-ecmlv2-req-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-trade-ecmlv2-req-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-trade-ecmlv2-req-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_RH0VKhDZpdkQPg6WtpaCRg) Content-type: multipart/alternative; boundary="Boundary_(ID_4Fhkb5lgbjBqNH2iffUmVA)" --Boundary_(ID_4Fhkb5lgbjBqNH2iffUmVA) Content-type: Message/External-body; server="mailserv@ietf.org"; access-type=mail-server Content-Type: text/plain Content-ID: <20001122145944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-trade-ecmlv2-req-00.txt --Boundary_(ID_4Fhkb5lgbjBqNH2iffUmVA) Content-type: Message/External-body; directory=internet-drafts; access-type=anon-ftp; site=ftp.ietf.org; name=draft-ietf-trade-ecmlv2-req-00.txt Content-Type: text/plain Content-ID: <20001122145944.I-D@ietf.org> --Boundary_(ID_4Fhkb5lgbjBqNH2iffUmVA)-- --Boundary_(ID_RH0VKhDZpdkQPg6WtpaCRg)-- Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4I00L01QNPEP@eListX.com>; Fri, 24 Nov 2000 02:40:37 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4I00L03QNOEN@eListX.com> (original mail from fujimura@isl.ntt.co.jp) ; Fri, 24 Nov 2000 02:40:36 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4I00L01QNOEL@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.eListX.com); Fri, 24 Nov 2000 02:40:36 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4I00L01QNOEK@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.eListX.com); Fri, 24 Nov 2000 02:40:36 -0500 (EST) Received: from tama3.tas.ntt.co.jp (tama3.tas.ntt.co.jp [192.68.248.40]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4I00INNQNM42@eListX.com> for ietf-trade@lists.eListX.com; Fri, 24 Nov 2000 02:40:35 -0500 (EST) Received: from nttmail.ecl.ntt.co.jp (nttmail.tas.ntt.co.jp [192.68.248.11]) by tama3.tas.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id QAA07382 for ; Fri, 24 Nov 2000 16:39:59 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from alsace.isl.ntt.co.jp by nttmail.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id QAA18644 for ; Fri, 24 Nov 2000 16:39:58 +0900 (JST envelope-from fujimura@isl.ntt.co.jp) Received: from isl.ntt.co.jp (degas.isl.ntt.co.jp [129.60.104.56]) by alsace.isl.ntt.co.jp (8.8.8/3.7W) with ESMTP id QAA25769 for ; Fri, 24 Nov 2000 16:39:57 +0900 (JST) Date: Fri, 24 Nov 2000 16:43:52 +0900 From: Ko Fujimura Subject: New draft for Rights Trading To: ietf-trade@lists.eListX.com Message-id: <3A1E1C38.E278B82A@isl.ntt.co.jp> MIME-version: 1.0 X-Mailer: Mozilla 4.75 [ja] (Win98; U) Content-type: text/plain Content-transfer-encoding: 7BIT X-Accept-Language: ja List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Hi, I posted a new draft for rights trading to the internet directory. My apologies for taking such a long time to update the draft. You can see the draft from the following location until it will be officially announced: ftp://torque.pothole.com/pub/ietf-trade/draft-ietf-trade-drt-requirements-01.txt Major changes from the previous version are as follows: (1) Naming for "digitalized rights" The name for "digitalized rights" are changed from "digital-rights" to "electronic-rights", and "Generic" is added to the document title, etc. to avoid confusion with "Digital Property Rights". (2) Application examples A new section that describes application examples are added (Section 6) to clarify the objectives and benefit of rights trading. It may be helpful to consider the relationship between the IOTP model. (3) Improvement of readability A several editorial changes are made over the document, especially in Section 2.2 and 2.3, to improve the correctness and readability. Any comments or suggestions on this document are welcome. Regards, Ko ---------------------------------------------------------- Ko Fujimura, NTT Information Sharing Platform Laboratories 1-1 Hikarinooka, Yokosuka-shi, Kanagawa 239-0847, JAPAN Tel: +81-(0)468-59-3814, Fax: +81-(0)468-59-2241 Email: fujimura@isl.ntt.co.jp Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4F00301T4V11@eListX.com>; Wed, 22 Nov 2000 12:41:19 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4F00303T4U0Z@eListX.com> (original mail from lde008@dma.isg.mot.com) ; Wed, 22 Nov 2000 12:41:18 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4F00301T4U0X@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Wed, 22 Nov 2000 12:41:18 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4F00301T4T0W@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Wed, 22 Nov 2000 12:41:17 -0500 (EST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4F001CLT4TP1@eListX.com> for ietf-trade@lists.eListX.com; Wed, 22 Nov 2000 12:41:17 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA11694; Wed, 22 Nov 2000 10:40:22 -0700 (MST) Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA12583; Wed, 22 Nov 2000 10:40:21 -0700 (MST) Received: from dma.isg.mot.com (nrlab-10.dma.isg.mot.com [150.21.50.48]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id MAA27947; Wed, 22 Nov 2000 12:40:20 -0500 (EST) Date: Wed, 22 Nov 2000 12:40:20 -0500 From: Donald Eastlake 3rd Subject: revised Payment API and SET Supplements available Sender: lde008@dma.isg.mot.com To: ietf-trade@lists.eListX.com Cc: dee3@torque.pothole.com, lde008@dma.isg.mot.com Message-id: <200011221740.MAA27947@noah.dma.isg.mot.com> Content-type: TEXT/PLAIN List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , Revised drafts should be posted to the IETF internet drafts directory and officially announced shortly. In the mean time they are available from ftp://torque.pothole.com/pub/ietf-trade/draft-ietf-trade-iotp-v1.0-papi-03.txt and ftp://torque.pothole.com/pub/ietf-trade/draft-ietf-trade-iotp-v1.0-set-02.txt Thanks, Donald ================================================================== Donald Eastlake 3rd +1 508-634-2066(h) dee3@torque.pothole.com 155 Beaver Street +1 508-261-5434(w) lde008@dma.isg.mot.com Milford, MA 01757 USA Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4B007011GG7V@eListX.com>; Sun, 19 Nov 2000 22:53:04 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4B007031GG7T@eListX.com> (original mail from dee3@torque.pothole.com) ; Sun, 19 Nov 2000 22:53:04 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4B007011GF7R@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Sun, 19 Nov 2000 22:53:03 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G4B007011GF7Q@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Sun, 19 Nov 2000 22:53:03 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G4B0070T1GD52@eListX.com> for ietf-trade@lists.eListX.com; Sun, 19 Nov 2000 22:53:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id WAA21820; Sun, 19 Nov 2000 22:56:55 -0500 (EST) Date: Sun, 19 Nov 2000 22:56:55 -0500 From: "Donald E. Eastlake 3rd" Subject: preliminary ECML v2 requriements draft To: ietf-trade@lists.eListX.com Cc: lde008@dma.isg.mot.com Message-id: <200011200356.WAA21820@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp Hi, A preliminary draft to get things started on ECML v2 requirement has been submitted as an internet draft. The official announcement should appear on the mailing list shortly. Thanks, Donald ===================================================================== Donald E. Eastlake 3rd dee3@torque.pothole.com 155 Beaver Street +1 508-634-2066(h) Milford, MA 01757 USA +1 508-261-5434(w) Return-Path: Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G3Q00201Q04AT@eListX.com>; Wed, 08 Nov 2000 23:33:40 -0500 (EST) Received: from ELISTS-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G3Q00203Q04AR@eListX.com> (original mail from dee3@torque.pothole.com) ; Wed, 08 Nov 2000 23:33:40 -0500 (EST) Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G3Q00201Q03AP@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Wed, 08 Nov 2000 23:33:39 -0500 (EST) Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-24 #44856) id <0G3Q00201Q03AO@eListX.com> for ietf-trade@elists.eListX.com (ORCPT ietf-trade@lists.elistx.com); Wed, 08 Nov 2000 23:33:39 -0500 (EST) Received: from torque.pothole.com ([38.138.52.132]) by eListX.com (PMDF V6.0-24 #44856) with ESMTP id <0G3Q0008DQ008I@eListX.com> for ietf-trade@lists.eListX.com; Wed, 08 Nov 2000 23:33:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by torque.pothole.com (8.8.2/8.8.8) with SMTP id XAA09585; Wed, 08 Nov 2000 23:37:21 -0500 (EST) Date: Wed, 08 Nov 2000 23:37:21 -0500 From: "Donald E. Eastlake 3rd" Subject: Further revised draft new CHARTER To: ietf-trade@lists.eListX.com Cc: lde008@dma.isg.mot.com Message-id: <200011090437.XAA09585@torque.pothole.com> Content-type: TEXT/PLAIN X-Authentication-warning: torque.pothole.com: localhost [127.0.0.1] didn't use HELO protocol List-Owner: List-Post: List-Subscribe: List-Unsubscribe: List-Archive: List-Help: , X-MTS: smtp My apologies for taking so long to get this out. I have incorporarted freedback from comments on the list to my previous draft new charter and produced the following. I have also adjusted dates and dropped the specific date milestones for the IOTP V2 Specification. The IOTP V2 Requirement document still has milestones. This is because of comments that the Specification should be more modular and my feeling that we will need to understand the requirements better before we can schedule the specification document or documents. Please post any further comments as I'd like to replace our way out of date charter very soon. Thanks, Donald Applications Area Advisor: Patrik Faltstrom Mailing Lists: General Discussion:ietf-trade@lists.eListX.com To Subscribe: ietf-trade-request@lists.eListX.com In Body: (un)subscribe Archive: http://www.eListX.com/archives/ietf-trade The Internet Open Trading Protocol is an interoperable framework for Internet commerce. It is optimized for the case where the buyer and the merchant do not have a prior acquaintance and is payment system independent. It can encapsulate and support payment systems such as SET, Mondex, secure channel card payment, GeldKarte, etc. IOTP is able to handle cases where such merchant roles as the shopping site, the payment handler, the deliverer of goods or services, and the provider of customer support are performed by different Internet sites. 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.) - Ability to indicate and handle a payment protocol not tunnelled through IOTP - Support for wallet servers - Repeated/ongoing payments - Server to Server messages - The ability to add both fields and attributes to trading blocks - Standardized XML Digital Signatures based on output from the XMLDSIG working group - Collaboration with other protocols such as ECML. The following is out of scope for IOTP version 2: - legal or regulatory issues surrounding the implementation of the protocol or information systems using it. - design of an XML Messaging Layer The working group will specify requirements for Digitally Represented Rights Trading. The working group will specify requirements for and then a syntax and processing model of ECML (Electronic Commerce Modeling Language) V2. Milestones 00 Nov Internet Draft publication Secure Channel Credit/Debit 00 Nov Working Group Last Call SET Supplement Architecture and Payment API (December 2000 IETF Meeting) 00 Dec Submit to IESG SET Supplement (Informational) Architecture and Payment API (Informational) 00 Dec Internet Draft publication ECML V2.0 Requirements IOTP V2.0 Requirements 01 Jan Submit to IESG Secure Channel Credit/Debit (Proposed Standard?) "Digital Rights" Trading Requirements (Informational) ECML V2.0 Requirements (Informational) 01 Jan Internet Draft publication ECML V2.0 Specification (March 2001 IETF Meeting) 01 Mar Submit to IESG IOTP V2.0 Requirements (Informational) 01 Mar Submit to IESG ECML V2.0 Specification (Proposed Standard)