Category: Internet Protocols

I'm writing an enterprise service. A request comes in. Do I honor the request or reject it? Answering this apparently trivial access control question has spawned whole universes of interlocking protocols. Kerberos, Shibboleth, SAML, WS-*, Liberty, OAuth, OpenID and so on. Before I can pick which protocol to use I need to define my requirements.

DISCLAIMER: Although I am an architect on .NET Services' Access Control Service nothing said in this document necessarily represents the opinions of my employer, my friends, my enemies or my teddy bears. No warranty express or implied. Your mileage may vary. Do not remove tag.

Continue reading Claims, Tickets and HTTP – Security protocols for
services

O.k., it's pet peeve time. Otherwise intelligent people seem to get really confused whenever they hear "two phase commit". They immediately assume that if one is using two phase commits then one must be implementing an ACID or at least Atomic transaction. Nonsense! A two phase commit is nothing more than a coordination mechanism. It allows one to guarantee that a group of independent systems will either all perform or all not perform a particular action. Historically the 'action' was usually some kind of ACID or at least Atomic transaction. But there is nothing in two phase commits that requires or even implies any particular action, atomic, ACID or otherwise.

Continue reading Two Phase Commit Need Have Nothing To Do With ACID or Any
Other Kind of Transaction!

Our rights only exist to the extent that we defend them in our daily lives. The right to free speech, for example, would quickly drain away if we didn't frequently exercise it and by so doing kept the knowledge of the rights importance and the mechanisms to protect it alive and well. But too often people believe that the need to defend our rights doesn't apply to them because they are just a single individual. Who cares what a single person does? But when each individual believes their actions don't matter then they significantly reduce the work required by those who would take our rights away.

Continue reading Rights Not Exercised are Lost – Tibco, BPEL &
Rendezvous

Issue 202 in the BPEL TC is a demand from Tibco that the BPEL TC change the word 'rendezvous' that is used as the value of an attribute in the BPEL programming language because Tibco has trademarked the word 'rendezvous'. To be clear, trademarks do not apply to 'descriptive' uses and that is exactly how BPEL uses the term 'rendezvous'. So legally speaking Tibco most likely doesn't have a leg to stand on. I do have sympathy for Tibco because one is required to 'vigorously' enforce a trademark in order to keep it. So to protect their trademark they need to be seen to be defending it, hence issue 202. But now people in the group are scared that Tibco will sue them (or their employer) if we don't change the term. Hopefully the group will stand up for the freedom to use the English language and reject issue 202 on next week's call. An even better outcome would be a change in the law that would make it illegal to get a Trademark on a common English word. The fact that Tibco could trademark the word 'rendezvous' and then try to banish its use from technical efforts is insane.

When designing a protocol or programming language the inclusion of extensibility is essentially an act of humility. One is minimally admitting that one's design is not complete and more generally one is admitting that one's design is not perfect. By providing for extensibility one is enabling others to improve and in many cases fix one's design.

Unfortunately it's easy to get extensibility design wrong. Typically such design errors result from assuming oneself or others to be perfect and in that assumption one fails to provide for sufficient extensibility. A rather subtle example of this problem recently came up in the Web Services – Business Process Execution Language Technical Committee (WS-BPEL TC).

Continue reading The Importance of Humility in Extensibility Design

Adam Bosworth's blog had a pointer to an interesting entry in another blog on innovation and standards which itself pointed to another good blog entry on the subject. All three came to the same conclusion – Standards shouldn't innovate. As anyone who has read my rule's of standardization knows, I agree wholeheartedly. And yet, premature standards, standards in areas that are not well understood, keep getting churned out. Why?

Continue reading Innovation, Premature Standardization and Caveat
Emptor

The Web's slow but inexorable movement from a read only to a collaborative environment is increasing WebDAV's success. But WebDAV still has a serious functional outage – search. The DASL community has been keeping hope alive by continuing to work on a search grammar for WebDAV. But much as WebDAV adopted XML both to solve real problems and to ride on the coat tails of XML's success, so DASL could solve a number of serious technical issues and increase its own visibility and leverage the excitement and investment in the XPATH/XQUERY community if it adopted a profile of XPATH 2.0 as its basic search grammar. In the article below I discuss some of the details of how DASL could use XPATH.
Continue reading WebDAV, DASL, XQUERY and XPATH 2.0

Most of my job for the last few years has been working on standards. In that time I noticed a fairly obvious pattern for technologies that tend to make successful standards, they meet three criteria:

Yaron's rules of standardization:

• The technology must be very old and very well understood
  • 20 years is a good rule of thumb
• Everyone must implement the technologies in essentially the same way
  • A good rule of thumb is, how hard would it be to build a bi-directional proxy between the various players implementation of the technology?
• Standardizing the technology must provide greater advantage to the software writing community then keeping the technology incompatible
  • Even in the open source world standards can fail if there isn't enough advantage in it, just look at the fights over RSS.

Lots of commercial companies are getting very worried about Open Source. They view Open Source as a direct threat to their success. After all, how do you compete with free? I think these companies are missing the point, Open Source is just another commoditizer and anyone who has succeeded in the technology business long ago learned how to deal with being commoditized. In fact, as commoditizers go Open Source is not a bad way to go. In the old days when a technology became commoditized it would disappear into some dominant platform that no one could access. With Open Source when a technology is commoditized it instantly becomes available to everyone which is to everyone's benefit, except of course to the dominant platform owners.

Continue reading Patents, Open Source and GPL

This article talks about the two criteria a technology buyer can apply to determine if the 'open standard' they are intended to rely on is really open at all. Those criteria are – licensing and change control.

Licensing controls who gets to implement the standard and what price they have to pay to do it. Open standards are licensed under 'royalty free' terms which means that anyone can implement the standard any time they want without having to pay any money or ask anyone's permission. Closed standards are almost universally RAND or RAND-Z based.

Change control identifies who has the right to say what the standard is and change it as time goes on. Open standards are owned by open standards organizations which have reasonably open membership and voting procedures to approve standards that can not be hijacked by a small group of people/companies. Closed standards either haven't been submitted to any open standards organization, have been submitted under dubious circumstances or have been submitted to pseudo-open standards organizations created to provide the veneer of openness.

Of these two criteria licensing is the most critical. If you check nothing else, check the license because if it isn't royalty free it isn't open.

Continue reading A Buyer's Guide to Standards