- From: <noah_mendelsohn@us.ibm.com>
- Date: Mon, 9 Sep 2002 17:55:48 -0400
- To: Mark Baker <distobj@acm.org>
- Cc: Elliotte Rusty Harold <elharo@metalab.unc.edu>, Tim Bray <tbray@textuality.com>, www-tag@w3.org
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