Potential IP (Patent, not Protocol) Troubles for SOAP 1.2

sckienle writes "Infoworld has an article on possible patent problems ahead for the SOAP 1.2 recommendation. Apparently two companies are claiming they may have patents that cover parts of the specification. But, they have yet to specify the relevant patent numbers or even how they feel there would be infringement. Here is The Register's spin on this."

how about previous SOAP versions ?

[wotevah]

I am curious whether the said patents apply to previous SOAP versions as well.

Why HTTP?

[mhesseltine]

I know this question has been asked before, but why do people insist on SOAP running over HTTP? HTTP isn't designed to store state information. It's a Hyper TEXT TRANSFER protocol. I know that it runs over port 80, so sysadmins don't have to open another port; but seriously, if you have an application running through your firewall, wouldn't you want to see that traffic as something other than typical web traffic?

Not trying to flame here; actually looking for a serious answer.

Re:Why HTTP?

[sckienle]

I don't really know the answer to this, but I think it is basically because:

• XML is text, after all
• The original use of SOAP wasn't for "stateful" objects, but really as a light weight RPC protocol
• The designers were more playing around initially, so they used what transport protocol was available
• The designers also were not Network people, but programmers, so the intricacies of creating a new network protocol were more than they wanted to bite off at the time (The old, we'll fix it later, but it never happens syndrome)
• Someone thought that it would be "good" for security to use an existing protocol and port
• You can use any port you want for SOAP traffic, it doesn't have to be 80 (The old "it's a user error" excuse ;-)

Hopefully someone else with more knowledge will pipe in but, from my experience on development projects, that is what I really expect to be what happened.

I also agree with your statement: in reality, you do not want SOAP traffic filtered and controlled in the same way as "standard" HTTP traffic. Maybe version 2.0 will address this. But then, given that the group didn't think that data encryption or user authentication was important enough to be in the original spec, I'm not holding my breath.

Re:Why HTTP?

[King of the World]

HTTP as it turns out is a good general purpose protocol. It has download resuming, and compression (zip), and many other features that weaker protocols like FTP don't have. It's also being extended via WebDAV (webdav is mostly a subset but there are planned extensions). Regardless of whether it's a "text transfer" protocol, everyone uses it for images, pdfs and zips, and it's quite good at it.

SOAP isn't anything to do with HTTP. SOAP can go via SMTP for all it cares. People tend to use HTTP, but then they do that for many things anyway.

Also understand that - like the web - all SOAP applications don't need to store state. A stateful protocol would be overkill, when you can implement state in SOAP. HTTP works, and is very well understood by many people.

Finally, SOAP has a specific HTTP header that firewalls can recognise (and then block if need be). Considering that SOAP can be just a wrapper for a request that returns some xml it's often similar to submitting a query to google. It could be dangerous, but so is allowing all kinds of downloads, so you have to get into HTTP filtering anyway.

Re:Why HTTP?

[J. Random Software]

HTTP is only so-so. A good RPC protocol should label requests and allow servers to execute them and send responses out of order (without an extra connection per logical thread) as well as negotiating the best mutually-supported encoding (US-ASCII headers are almost as ludicrously expensive as XML, and HTTP doesn't even allow compression there), and a UDP mapping (something like SIP) would really help with round-trip latency for isolated requests.

AFAICT, SOAP/1.2 will drop the SOAPAction header in favor of an optional action parameter in the media type--not that it wouldn't be easy to spoof and hard for a proxy to find (everything's variable-length in HTTP headers), even if it were mandatory.

Re:Why HTTP?

[Helen O'Boyle]

Many apps folks just want to get their line-of-business projects done under deadline, and find themselves severely restricted in how they can implementsolutions, by their organization's network security departments. No, we can't open any more ports on the firewall. No, B2B commerce is not an acceptable reason. You'll have to convince that Fortune 50 company to do e-commerce another way (from a staffer at a Fortune 1000) if you want on-line transactions with them.

Since almost all organizations allow HTTP through their routers, SOAP over HTTP is the way around this bureaucratic/political issue. I'm not defending this from a security standpoint, just explaining how apps folks (who tend to care more about pleasing their immediate stakeholders and bringing projects in under deadline, than security) tend to think.

Re:Why HTTP?

[metamatic]

You don't have to use HTTP. You can run SOAP over IBM MQSeries if you want to, to pick one example.

Re:Why HTTP?

[EvilTwinSkippy]

Simple: You can retrofit state into the system by using Kerberos-style cookies. I have an RPC system used internally on our network that has an extra argument for the SOAP session id. The server checks to see if that session id is still valid and presto.

Think of it like Soapy cookies.

What patents?

[Groote Ka]

Here [uspto.gov] is the only granted (US) patent of Epicentric I was able to find. Perhaps someone who's familiar with SOAP can look into this (I'm an electronics & patent guy, not a software engineer).

EpiCentric also has a patent application running.
webMethods only has one application running. No patent, no royalties (yet).

Why didn't the press bother to find this out?

Anyway, I suspect both companies are not too sure about the position of their IP. I wonder whether they consulted their patent attorney before they contacted the W3C.
Unfortunately, there's no search report for the applications, yet.

Re:What patents?

[King of the World]

They might own other companies. They might even be warning on behalf of others for a cut in the profit. There are all kinds of other scenarios.

Re:What patents?

[Groote Ka]

That's correct.

I searched for the applicant/assignee. It might be just as well that employees of both companies filed applications on their own name.
For more information, I'd have to do a search on each of the inventors to check whether they have more patents on their name.

Nevertheless, I still have a gut feeling that we have two boys here who want to mess with then men. But it's merely a gut feeling, no legal advise.

Re:What patents?

[EvilTwinSkippy]

Why didn't the press find it out? Its called selling fishwraps. They wanted to get the story out, and make it something interesting to read.

Given the tentative nature of these patents trying to apply to openly developed protocols, I think that we definitely have a case for prior art.

Re:That Patent...

[EvilTwinSkippy]

I did a cursory check of the patent, and it patents the concept of a central authenticating mechanism for a web portal. The style (of writing) is so DotComeeses its hard to say what the hell they are actually patenting. At first its a portal, than an administrative interface, the claims are circuler and deliberately vague.

I keep thinking of the tool Hari Seldon used in the Foundation Series to analyze the information content of what people actually said. One politician's visit in the story yielded no information, despite several speeches.