- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 31 Dec 2014 15:39:19 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: Kingsley Idehen <kidehen@openlinksw.com>, Web Payments <public-webpayments@w3.org>
On 2014-12-31 12:11, Melvin Carvalho wrote: > <snip> > > Since it doesn't do anything that you can't equally well do with 200 + suitable message > > > How can 200 + message = 402? > > 4xx in HTTP indicates an error > > 200 in HTTP indicates success > > What message do you envisage here? Since HTTP 402 directed to the *browser window* doesn't apply, we are rather talking about a proxy that in the background does the communication. In your case through XHR. If I were to design such a scheme I would let the proxy call return two responses both having the response code 200. One message would be like "OK" which I understand should trigger the proxy to perform a URL access to the requested resource. The other response would be "Payment Required + associated information on what kind of payments that are accepted and how much money that is requested. So even if one could do the same thing with HTTP 402 the question remains: Why would this be better unless 402 got a built-in payment hook[*] in the browser? I would be interested hearing Manu's opinion on this since he and Digital Bazaar really are the only parties who have provided CG specifications. Anders *] I guess this is what the demo thing did by "hijacking" the browser communication. > > I didn't see the point with building on 402. > > > I think this is off topic. > > > Ok, I thought that HTTP 402 was the actual topic. > > > 402 is the topic, but it is already standardized. HTTP is one of the most widely deployed protocols on the planet. It means payment required. So the idea is that a page which is something like a paywall could return a 402 as part of the request / response process. > > But this more related to HTTP / AWWW than to the 402 demo above. > > Not understanding how the extension works or what it's doing, thats ok, youve said so already. > > I think your servlet demo is of topic because I dont know what you are trying to show other than how HTTP works. > > > IMO, you still owe us a description on entities and flows in your scheme. > It is completely unclear to me at least. > > Example: > http://webpki.org/papers/PKI/__EMV-Tokenization-SET-3DSecure-__WebCryptoPlusPlus-combo.pdf#__page=4 <http://webpki.org/papers/PKI/EMV-Tokenization-SET-3DSecure-WebCryptoPlusPlus-combo.pdf#page=4> > > > > > > I remain quite confused about your understanding of Web Architecture. > > > I'm talking about the browser-based scheme Melvin is advocating which still > is completely undocumented. > > > A browser is one kind of HTTP User Agent. That's it! > > > Indeed, and I guess that is the one Melvin talked about. If it was not > he should tell us. > > Regards, > Anders > > > > -- > 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 <http://www.openlinksw.com/__blog/~kidehen> <http://www.openlinksw.com/__blog/~kidehen <http://www.openlinksw.com/blog/~kidehen>> > Twitter Profile:https://twitter.com/____kidehen <https://twitter.com/__kidehen> <https://twitter.com/kidehen> > Google+ Profile:https://plus.google.____com/+KingsleyIdehen/about <https://plus.google.com/+__KingsleyIdehen/about <https://plus.google.com/+KingsleyIdehen/about>> > LinkedIn Profile:http://www.linkedin.____com/in/kidehen <http://www.linkedin.com/in/__kidehen <http://www.linkedin.com/in/kidehen>> > Personal WebID:http://kingsley.idehen.____net/dataspace/person/kidehen#____this <http://kingsley.idehen.net/__dataspace/person/kidehen#this <http://kingsley.idehen.net/dataspace/person/kidehen#this>> > > > > > >
Received on Wednesday, 31 December 2014 14:39:53 UTC