- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 31 Dec 2014 14:15:12 -0500
- To: public-webpayments@w3.org
- Message-ID: <54A44B40.3050409@openlinksw.com>
On 12/31/14 1:10 PM, Anders Rundgren wrote: > On 2014-12-31 18:59, Randall Leeds wrote: >> >> You're taking past one another. Let me clear a few things, having >> read this whole back and forth. >> >> - This would be more than a couple lines of js. >> >> - The code would need to intercept navigation and present a payment >> screen. That could be done by a proxy or a browser extension or as >> built in browser behavior. For a proof of concept, any would be >> acceptable. >> >> - A Chrome extension is a working demonstration of something which >> could be built into a browser, and is more reasonable for many people >> to test an idea than installing a fork of a browser. It's closer to >> the right separation of entities than having a proxy. No one should >> be concerned that a proof of concept starts this way. Everyone should >> understand that whatever UI and interaction is written into such an >> extension is a stand in for a future built in feature. >> >> - 402 is the clear choice for the status code of the initial response >> exactly because it has largely been ignored. There are no >> *conflicting* semantics already defined, and that's what really matters. >> >> - 402 is only sufficient to say that payment is required, whereas >> accessing paid content involves also making the payment and then >> requesting the content with proof of payment. Melvin described this >> proof as given by certificates, but didn't describe the payment or >> the mechanism by which that payment changes the balance associated >> with the certificate. All that needs to be specified still, but that >> doesn't mean 402 is wrong. >> >> Interface guidelines are needed for the agent, as well as the >> protocol for making the payment and making the authenticated access >> thereafter. >> >> But let that come later. >> >> >> Anyway, this idea won't go anywhere (in this context NB...) until >> a proper >> specification is presented. Based on two years experience with >> this forum >> I don't think there will be such a thing but nobody would be more >> happy >> than I if I was proven wrong :-) >> >> >> I would encourage people to follow through with demonstrations and >> implementations and worry about spec writing later. >> > > Currently the specification is: "HTTP 402 was defined for payments, > let's put it to work" > That's apparently enough for this forum, for me it is not. He meant: 402 is an error code for payment oriented communications over HTTP. That's it. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Wednesday, 31 December 2014 19:15:35 UTC