- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Thu, 12 Jan 2012 21:00:30 -0500
- To: Web Payments <public-webpayments@w3.org>
On 01/12/2012 02:56 PM, Jake Howerton wrote: > On Thu, Jan 12, 2012 at 1:58 PM, Manu > Sporny<msporny@digitalbazaar.com> wrote: >> bcc: opentransact >> >> The interoperability that we're after is at least at the level of >> SMTP... where you can be on one server and send an e-mail to >> someone else on another server. The same sort of interoperability >> is required for payments... OpenTransact does not specify how you >> do that. > > You are confusing "the transaction" and "the delivery", which is why > you misunderstood how I categorized ACH. I think you think I'm talking about "the delivery" - I'm not. See this (the transaction-backhaul algorithm): http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0025.html > Payment networks cannot always work like SMTP because SMTP has the > benefit of both of these actions happening in the same medium. Why not? A gigantic portion of the world's day-to-day wealth transfer is electronic. The future will have an ever-increasing amount of transactions performed electronically. > If I am paying you with gold through an electronic system, at some > point the gold has to be moved from my vault to your vault, and > unfortunately I can't do that with an HTTP ;) Ah, but how often does that happen? Often it is certificates for gold deposits that are bought and sold, not the actual gold itself. The gold is kept in a heavily guarded facility. > Also, there is nothing to hold back two clearing partners in a > network from settling delivery using standard OpenTransact, if it is > physically possible. Yes, this is what I'm saying that the OpenTransact folks need to spec out in order to ensure interoperability. > I think you read past my criticism, I am not talking about your use > cases, unless the documentation of your spec is confusing me. I am > talking specifically about "2. The Conceptual Model" The things you > outline here are business rules which will limit interoperability. > Limiting interoperability would be self detrimental since that is one > of your stated goals. How does it limit interoperability? What use case can you not perform via the conceptual model? > The entire point (from my perspective) of specifications and > standards is to get people to come together philosophically around a > common problem, and then decide on a technical document that > describes the philosophy around solving that problem, which is why > you are hearing feedback about these issues instead of technical > comparisons/flaws. Specifically, I was referring to non-actionable statements like the following: "OpenTransact vs PaySwarm is like Libertarianism vs Socialism." "the basic PaySwarm philosophy of wanting to design a whole world view is very similar to central planning" "trying to model entire systems of commerce, and what amount to business rules inside of a supposed payment standard, and at the same time having a goal of interoperability, seems self detrimental to me." You explained a bit more about this last comment in your previous e-mail, so that you for that. That was helpful and we can finally start talking about specifics, of which I've asked you the first set of questions above. :) -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) Founder/CEO - Digital Bazaar, Inc. blog: PaySwarm vs. OpenTransact Shootout http://manu.sporny.org/2011/web-payments-comparison/
Received on Friday, 13 January 2012 02:01:10 UTC