Subject: PINT service charging

From: "������" <[email-masked]>
Date: Thu, 15 Apr 1999 21:00:45 +0900

I hope your comment.

In an electronic-commerce case,
an e-commerce provider(A) may sell their products through web pages
which was hosted by an ISP(B).
On that web-page, a Click-To-Dial-Back service link is connected to an
Intelligent Network Provider(C), who provides PINT server facilities in
their (PSTN/IN)network.

I am a IN service provider with PINT features(CTD, in this example).

To whom should I charge for the PINT service provision ?

(1) to A, for the CTD services embedded on their content.
(2) to B, for the CTD feature link on the web pages they established.
(3) No charge. because I earn money by eventual PSTN call by CTD user.

Any answer would be very appreciated.
Thank you.

Jinkyung Hwang
Korea Telecom

---------
This message came from the IETF PINT Working Group Mailing List.

---

From: [email-masked] (Lawrence Conroy)
Date: Thu, 15 Apr 1999 14:53:05 +0100

>Any answer would be very appreciated.
To which I reply:

Right Now, I'd lean towards charging the "B1 party" in the
Click-To-Dial-Back (CTD) request.
I guess that's what you mean by the third option (No charge).

This scenario is similar to a normal "IN/PSTN" Free Phone service:
If I'm surfing the Web and I click on a link to have a Call Center agent
call me back by phone, then the Call Center phone number is a good choice
to charge for the CTD service. When I fill in my phone number to get a
callback, I am not going to be happy if I get charged for the CTD service
without very LARGE WARNINGS on the web site that this will happen. Thus I'd
expect the B1 party to be charged for the service, not the B2.

Another variant on the CTD service involves a separate subscription ID
being encoded into the request using something like the opaque reference
attribute (opr:). In this case neither party to the eventual service call
is charged
- as such it's similar to a Calling Card service.

Beware that there are serious security concerns with sending this kind of
information over the Internet, so that all such requests MUST be encrypted
to ensure that someone doesn't steal the subscription ID and use it for
their own service requests.

There is another view, however...
Our esteemed co-chair, Steve Bellovin, pointed out in an earlier draft that
there is likely to be some prior relationship between the operator of the
PINT Client (in your example, ISP "B") and the PINT Gateway/Executive
System that carries out the service requests (the IN/PSTN Operator "C").

His argument was that the PINT Client is held responsible for any service
requests it sends. Thus, "C" would expect "B" to be responsible for the
service request, and it is a private matter between "B" and "A" to agree on
back-charging the costs of these requests.

In this case, the B1 and B2 numbers are not important, and "C" will only
accept requests from an entity run by one of their customers, and will
charge that customer (in this case, "B") for making the requests.

How that customer defrays the costs is his problem, not that of the IN/PSTN
Operator.

I think I've summarised the different options that have been discussed in
PINT, and in the earlier work for the PINT Informational RFC. If anyone
disagrees, I'm sure they'll complain.

All the best, Lawrence
-----------------------------------------------------------------------
| Lawrence Conroy,    | "These Opinions must be mine, 'cos if they    |
| Roke Manor Research |  were my Company's they'd charge you for them"|
|- [email-masked]  ---+- Tel: +44 1794 833666  Fax: +44 1794 833434 --|

---------

---

From: [email-masked] (Igor Faynberg)
Date: Thu, 15 Apr 1999 11:38:50 -0400

PINT, and in the earlier work for the PINT Informational RFC. If anyone        
disagrees, I'm sure they'll complain.                                          >

With due respect, charging is NOT subject to PINT standardization, and
Steve and I have made it clear that charging is not to be standardized
and even discussed. Personally, I am unaware of any such discussion on
the PINT mailing list.

I am aware of a dozen business models in which PINT service features are
used in different scenarios, but, again the PINT mailing list is not
the place to discuss them.

Respectfully,

Igor Faynberg

---------

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 15 Apr 1999 14:57:19 -0400

> and even discussed. Personally, I am unaware of any such discussion on

Igor is quite correct -- charging is completely out of scope for PINT.
(If nothing else, discussing that could open us up to legal liability.)
What is within the scope of PINT is the authorization model, upon which
the various parties can build their own business and charging models.

In the case you describe, the ISP would be the party requesting that the
IN make a call; thus, the IN must verify that the request did indeed come
from the ISP.  Whether the IN provider bills the ISP, the merchant, or
none of the above is entirely up to those parties.

---------