Re: Micropayments and principle 4 (retrieval is safe)

I agree with Mark, or at least I'm fairly sure I do.  The drift of the 
current discussion is:  "GET can incur obligations if you've pre-arranged 
for it to do so."  Mark correctly points out (or strongly implies) that 
the reason for a uniform no-obligation rule is that so many components of 
a distributed web system can take advantage of that lattitude. Prefetching 
is possible, and so on.    The problem is, we haven't provided a reliable 
way to tell all those layers which gets are safe and which are not.  We 
certainly haven't done it in a way that does the right thing with existing 
deployed software.

Maybe one could turn the situation around and look at it this way:  Let's 
say I do buy into (pun intended) some micropayment scheme, and pre-arrange 
that some or all of my page accesses result in a charge.  Since I know 
this, the system infrastructure will be much better able to respond if I 
label each such access in a way that distinguishes it from an ordinary, 
no-obligations GET.  With this knowledge, the system can treat my safe 
GET's one way, but be very careful not to access "for fee" pages unless 
necessary, not to reaccess them unnecessarily, perhaps not to share the 
copy I paid for with others, etc. 

How to distinguish for-fee retrievals from safe GETs?  Well, we could (to 
name 3 options that come to mind) invent an HTTP Header, we could invent a 
new HTPP Method, or we could as Mark suggests use POST.  The problem with 
just adding a header to the GET seems to be evolution from today's 
deployed software -- the new header needs to be what SOAP calls 
"mustUnderstand".  If you have old HTTP software that doesn't recognize 
the header, it's not safe to go ahead and do that prefetch.   So that 
doesn't work well. Between a new verb and POST, I leave the choice to you 
all.  I suspect that requirements to run with existing deployed software 
will lead us to POST, at least on current versions of HTTP.  So, I think 
Mark has it right, at least for now.

(Not to unnecessarily introduce my own project work into the discussion, 
but it occurs to me that a SOAP envelope (non-RPC, most likely) would be 
something to consider as the body of that POST.  It has a nice header 
structure WITH mustUnderstand capability, and that seems like just the 
sort of flexibility you might want in managing a micropayment schema.  So, 
you POST a SOAP envelope with a body that says:  "get my page with URI 
XXX", the SOAP headers give additional info about your micropayment 
credentials...in a way that can be understood by knowledgeable 
intermediaries...and the response can be a page of arbitrary media type, 
with content-location.   I should point out that someone would have to set 
down a new SOAP MEP to cover this case, as the response is not necessarily 
a SOAP message.  It's easy to write the spec for such an MEP, and that 
does not require re-publishing the SOAP specs that have gone last call. Of 
course, one would have to suitably enable various SOAP engines and/or Web 
servers, but it's all quite doable, and very extensible.  Also:  any 
control information that usefully belongs in an HTTP headercan go there, 
instead of or inaddition to putting it in the SOAP envelope;  the SOAP 
feature architecture allows for such flexibility.) 

If we can't distinguish an access that incurs obligations from one that 
does not, I fear that no access can be viewed as completely safe.  So, +1 
to what Mark has written.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------







Mark Baker <distobj@acm.org>
Sent by: www-tag-request@w3.org
09/09/2002 03:28 PM

 
        To:     Tim Bray <tbray@textuality.com>
        cc:     Elliotte Rusty Harold <elharo@metalab.unc.edu>, www-tag@w3.org, (bcc: Noah 
Mendelsohn/Cambridge/IBM)
        Subject:        Re: Micropayments and principle 4 (retrieval is safe)



On Mon, Sep 09, 2002 at 11:29:08AM -0700, Tim Bray wrote:
> Why not?  This is my reading.  I do *not* want to make payments, even 
> micropayments, as a result of doing a GET, without have done an explicit 

> prior authorization.

And even then ...

I don't want to be charged per GET, period.  If I'm going to be charged
per-page, it better be via POST, because I may be using a personal proxy
that does things like invoking GETs on my behalf to keep my cache fresh.

I think #4 is fine as is, but perhaps an additional example to cover
the pay-per-page case would be worthwhile?

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Monday, 9 September 2002 17:57:20 UTC