csysmas@OAC.UCLA.EDU (Michael Stein) (04/21/88)
Instead of a "WILL/WONT PAY" protocol (which only works on
connections) how about something else:
Suppose that it was possible to send packets containing "money"?
This might be the IP level equivalent of "reverse charges" (since
IP packets aren't related like traffic on a connection).
The idea is that the "network" charges for packets sent (not
new), but will also allow a packet to transfer "money" from the
sender to the target This could show up as a charge on the bill
to the sender and a "refund" on the bill of the target.
Thus a UDP request to a name server should contain the money
for the reply (or else it's likely there won't be a reply).
It is clearly possible to build a "reverse charge" connection
level protocol on top of this by having one side request
(demand?) "money" to continue.
Note however that much more is possible:
o either side could pay the whole cost or they could
split it in any way
o this also works for 3 (or more) party traffic (it's possible
to receive "money" and send it out to someone else).
o this also works across time, I can send payment now for
something you will do later (time to renew your subscription
to TCP-IP?)
o since "money" is general, other net-wide resources could
also be handled
This can't be practical, can it?geoff@fernwood.mpk.ca.us (Geoff Goodfellow) (04/22/88)
i'd like to propose that methods of reverse charging or the negotiation thereof become known as The Internet Buck Passing Protocol. geoff
wbe@bbn.com (Winston B Edmond) (04/23/88)
Michael Stein writes: >Instead of a "WILL/WONT PAY" protocol (which only works on >connections) how about something else: > >Suppose that it was possible to send packets containing "money"? This sounds like a good, general solution. If I understand it right, billing by the network ALWAYS go to the sender of the packet, but the "money" transferred becomes a promise to pay from one host to another. Thus, at the end of the month, the host administrator will get a bill for network services, pays the bill, and has X dollars in Accounts Receivable from other hosts sending "money", and Y dollars in Accounts Payable the host has promised to send to other hosts. You will need to figure out how to say "I'll pay up to D dollars", since the cost of a message may well depend on the Internet path it takes between the hosts. It may also be difficult to "make change", since the price of the packets to return money may cost more than the amount to be refunded. However, if you want the end-of-the-month bill from the networks to directly reflect the "money" exchanged, then I caution again that the final exchange of money or billing charges should be between the billed client and the billing entity (the network) in order to prevent counterfeiting, empty promises, and even ordinary billing errors. This means the protocol for paying wouldn't a high level protocol like IP, but an enhancement to the network level protocols. The Automatic Teller networks have solved this kind of reliable money transfer, so perhaps we don't need to reinvent everything. -WBE
emv@starbarlounge (Edward Vielmetti) (04/23/88)
In article <8804220957.AA26052@ucbvax.Berkeley.EDU> csysmas@OAC.UCLA.EDU (Michael Stein) writes: >Instead of a "WILL/WONT PAY" protocol (which only works on >connections) how about something else: > >Suppose that it was possible to send packets containing "money"? > Fake "money" is too easy to "print". Me and my PC can decipher the money protocol and send out bogus cash at our leisure. Schemes like this violate the principle that hosts are not to be trusted. Edward Vielmetti, U of Michigan mail group.