Dave Welsh's WebLog : Standards Organizations

World Standards Day -- October 14

Dave Welsh — Fri, 15 Oct 2004 20:21:00 GMT

Did anyone notice?

Details are here http://www.iso.org/iso/en/commcentre/wsd/2004wsdindex.html and this year's theme was "Standards Connect the World" - which seems to line up with the thinking that we do live in a 'connected world'. Past annual themes have included 'Standards in Daily Life', 'Trade', 'Services', and 'Transportation'.

Ok, I see ISO and ITU (which is in the UN system) and IEC - but no UN itself or UN/CEFACT on the poster? Here is the Press Release the THREE international standards bodies came out with:

"From the simple to the complex, from the minute to the massive, from the local to the global, international standards are omnipresent in products and services and in the components of the global supply chains for which they provide the backbone.

The international standardization system that comprises ISO, IEC and ITU transforms qualities like efficiency, effectiveness, economy, quality, ecology, safety, reliability, compatibility and interoperability into concrete characteristics of products and services for implementation in their manufacture, supply or utilization. The three organizations thus develop workable solutions to technical and economic challenges faced by business, government and society and publish them as international standards.

The products and services shaped by international standards need to be transported, delivered, transferred or otherwise exchanged between suppliers and their customers or end users. Exchange necessitates connections and interfaces. International standards harmonize the connections and facilitate exchange by ensuring smoother, swifter, safer and more economical delivery.

The variety of exchange where standards overcome challenges is considerable: examples are getting food from farm to kitchen table, raw materials to processing plants and on to industrial users, products to distributors and shops and then to consumers, power from generating plants to industry and the home, messages that pass between telecommunication networks and computer systems.

The connections and interfaces that standardization renders more efficient and more effective are just as varied. They may be mechanical, electrical or computer-based - or combinations. They range from pipes and couplings, to lifting and handling gear, pallets,freight containers, switches, cables and connectors, computer hardware and software, to transport, power and information and communications technology (ICT) networks.

In turn, the scale of standardization ranges from point to point (be they next door or on opposite sides of the globe), to whole countries (as in the case of power grids), to worldwide (such as ICT networks).

In addition to connecting markets, international standards connect developing countries and transition economies to state-of-the-art technological know-how enabling them to increase their export capability and competitiveness.

Beyond the technical and economic benefits of international standards, participating in their development enhances human connectedness. It is a matter for pride and optimism that thousands of men and women of different political and religious beliefs, national and racial origins and cultural backgrounds come together within ISO, IEC and ITU to cooperate effectively on the task of achieving international consensus on standards that make a positive difference to our world.

Standards provide solutions, get the job done, connect people. Standards connect the world."

Financial Services & SWIFT, ISO, Web Services, Domain Specific Languages and Software Factories

Dave Welsh — Fri, 15 Oct 2004 19:46:00 GMT

I just got back from the annual SWIFT conference, this year in Atlanta. Some 5,500 delegates from around the world showed up to the conference and vendor exhibition; and of course SWIFT had the event perfectly organized as only SWIFT knows how to do.

This year, for the first time apprently, there was a serperate "Standards Forum" launched; to talk about the financial industry and general cross industry standards issues. I was invited to speak at the Forum opening launch, together with an extremely distinguished panel including Renato Polo who has been on the SWIFT Board for 15 years and knows more about SWIFT than probably anyone, Richard Soley who is the OMG CEO, Nourrredine Yous the Chair of ISO TC68 SC4 who have just approved the new ISO 20022 spec for Universal Financial Messaging - and myself.

Just to rat hole on the new ISO spec; cause it's nice to go vertical industry and face some industry reality. International Standard ISO 20022 - UNIFI (previously called the second, XML edition of ISO 15022) is composed of 5 parts: two International Standards and three Technical Specifications that will be published by ISO in 2004.

(side note for those not familiar with ISO work - the only *true* ISO standards are called 'International Standards' and to get them you need to go the whole loooong standards route with all the countries voting. ISO *also* has something called a 'Technical Specification' which is really what a lot of people on the street would know as a 'White Paper', which you still need to buy from ISO and "they are not with the ISO Gold Star" as someone commented to me over lunch at SIBOS. The Oasis ebXML specs in ISO are only TS's and not ISO Information Standards, as another example, where none of that spec work is done in ISO - so pure spec marketing leveraging the ISO brand name)

"ISO 20022 parts 1 and 2 cover a general explanation of the concepts that are used for the definition of ISO 20022 compliant standards. The explanation gives a high level description of the business-centric standards design methodology and the rationale behind this methodology and a description of the input that is required when submitting a request for the registration of an ISO 20022 compliant standard to the ISO 20022 Registration Authority, i.e. SWIFT."

The "Three Technical Specifications of ISO 20022 parts 3, 4 and 5 are ISO documents that give more detailed information regarding technical aspects of the standard including Modeling guidelines for development of syntax-independent business standard XML design rules, and Reverse engineering approach for existing non-compliant messages."

Microsoft had an exhibition stand at the SIBOS conference and together with SWIFT's exhibition stand there was a working demo of the new 20022 messages for Corporate to Bank payment processes between the Microsoft stand and the SWIFT stand; on the Microsoft side using the newly SWIFT certified BizTalk adapter for SWIFT. InfoPath was also part of the demo scenario and I gathered a lot of people found the whole demo very powerful in that it showed how simple it can be to use XML, 20022, web services and the Internet with SWIFT all together. (and if you haven't seen the new service pack release for InfoPath, it almost programs itself with anyone's XML. You can even get away from a lot of JScript programming in multiform apps) For web services we were just using the WSE 2.0 bits.

What stuck in my memory from the show, and knowing SWIFT for a while, was that they really have put into practice a sort of a mini software factory concept to produce their new XML based standards. In their case they managed to make some UML work for them using financial services industry concepts they know better than anyone else. SWIFT also have some software that converts XMI ('injecting in' the SWIFT 'core components' pre-defined XML structures) into a final XML message that works for their industry.

I'm not exactly sure how much they used their new approach to help create ISO 20022 but SWIFT have been all over 20022 for some time now and I heard some internal study numbers from SWIFT about how much more efficent in general they have become with their new modeling approach to internal standards development; something a lot of the SWIFT user community would like SWIFT to be much quicker on.

I also had a nice long chat with Richard Soley on UML, Domain Specific Languages (DSL), Software Factories in general and I believe he acknowledges that DSL/Software Factories is a good long term strategy; and I'd venture a guess that a lot of the 'original UML folks' would agree too. I think the public question about what is "long term" around this space or is the space "closer than you think", will become a lot clearer at OOPSLA when that community meets for their annual event; which is in just a week (Oct 25 - 28 in Vancouver Canada)

Catching up on blogging and Web Service Standards

Dave Welsh — Sat, 09 Oct 2004 20:23:00 GMT

It's been a few weeks since I've blogged. I've just been too busy, heads down with day job work which I can't talk about just yet, but I thought I'd just get back into the blogging rhythm here a few of the things from the past few weeks; to catch up on the news.

In any order.

There was the recent announcement of WS-Addressing work group set up in W3C and the WS-Management 'coming out' the other day regarding a joint Microsoft - AMD - DELL - Intel - SUN submission of WS-Management to the DMTF folks.

I first got a glimpse at WS-Management about a month ago and I'd expected the spec to already be out, but better a little late than never. WS-Management is a nice spec to setup instrumentation monitoring, which is going to become very important around observing the operational behavior of running services. Don't underestimate how it's going to fit into a bigger picture.

It's nice to see SUN Corporate take on more of the web service standards with us. That might not make much paparazzi press but the customers will benefit at the end of the day, and it's clear now that at the very top Executive level that SUN is going with web services; and clearly moved the corporation past their earlier efforts like ebXML.

Speaking of web service standards, it should be obvious by now that what's happening around standardizing the many web service specs is that the web service concept covers a broad range of technical infrastructure. You have to grok that scope issue first before moving to the next step of understanding where the standards are going. There's been some traffic in the press / blogs by some 'XML names' about 'WS-complexity', and that the world doesn't need all the web service specs. Well if all you want to do is move a file, like a biz document from point A to B, and you don't care about a bunch of other things then there is ftp today; go for it! It all depends on how far you want to go, and that context gives these new specs their inherent technical value.

So, since web service specs are reaching out to address a broad scope and as it's a fact that no one standards organization can realistically claim to have all the working domain expertise over such a broad range of technology - what is really going on with the standards process is an effort to gather together the leading industry domain experts and openly collaborate on making the new web service specs as real world as possible. The litmus test on the specs is by taking them thru the workshop process (which I blogged on earlier). The basic idea on standardizing the web service specs is to end up with a real world working spec which already has major industry buy in.

The next step in standardizing the work is taking the 'post workshop process' specs from the industry experts into those open standards bodies which today closest align the industry practice in that particular domain of activities. Oh yes, to create open and royalty free web service standards.

I've heard some people make side comments that this particular standards development process breaks the normal 'committee driven' 'life unto its own' 'politically charged' conventional standards process. Well ... YES I hope so. We all know making standards is not a quick process and it also doesn't have the greatest track record; sometimes.

Going into the traditional standards committee process you probably can't really say what the committee will really produce as a final standard (and you are not always sure you have all the relevant domain experts - but you've probably got some great 'professional standards technocrats'). I mean, there's so many easy political ways to steer or stall a standards committee, irrespective of what the people who actually do the standards work want; like only show up with a gang of 'friends' for a vote to block any new work - then the 'gang' leaves after the vote or doesn't do any work.

Coming out of the traditional standards committee political process, in practice you still have to go at least another round with starting up the 'industry interop workshops' and 'vendor plugfests' only to discover probably that the original spec has 'a few technical holes' - so wait for version 3! (or worse - the spec is out of sync with leading industry thinking and developments)

Time will tell how well the new standards process proves itself with customers, but I'm an optimist; and when you've got that much industry push behind it and all those thousands of people working towards a common vision - something good is bound to come out (sooner or later).

Elsewhere in the past few weeks, it seems there's been a lot more 'press' about our competitors than us; which is nice - thank you very much :-)

The fading myth of Open Systems, time to think about Interoperability

Dave Welsh — Fri, 17 Sep 2004 00:36:00 GMT

A message via via from onStrategies just passed my way and it had to do with a new piece that should be out on Friday Sept 17th called "The Myth of Open Systems". Before going any further this is not trying to slam Open Source.

The author Tony Baer wrote a nice small piece to introduce the article "After attending a panel session convened by the NY Software Industry Association, comprising representatives from IBM, Microsoft, CA, Information Builders, and Oracle, we concluded that debate about open systems is growing increasingly meaningless. Everybody claims their system is open but uses different definitions. ... While we're tired of the term open systems, we believe in openness."

The actual copy of the article I saw was a nice easy and entertaining read and it concluded with "Forget about "open."Everybody's products are open to a point. Instead, think interoperability, which is exactly why vendors are coalescing around web services."

Check it out, I enjoyed it.

How Standards Orgs work with each other, and ‘referencing’ others standards

Dave Welsh — Thu, 09 Sep 2004 21:43:00 GMT

A few people have been asking about why don’t the different standards groups work more closely with each other. The joke goes “the good thing about standards it there are so many to choose from”. Seriously, it becomes increasingly harder for customers to have to choose from a variety of what may look like similar but different standards.

A lot of standards groups, maybe most, today face some fairly hard (tight) financing and or a flattening of new membership, leaving the permanent standards organization staff hurting; sometimes having to do layoffs. To help sustain the standards orgs growth, some groups will aggressively go out and seek to expand the working boundaries of their traditional standards domain. Invariably though this growth leads the orgs into new areas of work which are covered by someone else; and duplication of standards efforts suddenly exists, not that being there first is any legal claim to owning the domain.

A while back I contributed a white paper to the UN, hoping they (the UN) would get the hint and get some more formal awareness and process in place to better work with (and legally protect the work with) other standards organizations. Part of that contribution had to do with “referencing” (or building upon) other’s standards work; so we can be comfortable that new standards are Open without any legal “gotcha’s” as sometimes has happened in the past.

The big concern I’ve seen with standards orgs is there is a lot of great ‘good will’ at the working group level to ‘work with others’ but far too often there’s almost a naïve realization that forming a working alliance with another standards org needs some solid prep work to protect the common work you both do. After all, the standards groups are all about generating IP!

I’ve reproduced (the long) paper below in 4 parts, and I hope you enjoy it. Actually I’ve heard that a number of different standards groups (including the UN) have asked for the paper (like WS-I) and taken it in as a bit of a base line reference upon which to consider how they can better organize their working relationships with other standards groups.

All I can do is hope more people in the Standards Org communities read the material and in future takes the extra efforts to do a GOHIO. (Gets Our House In Order) so the work you and others ‘contribute’ to making better open standards is well protected; and stays open.

How Standards Orgs (should) work with each other - Part 1 of 4

Dave Welsh — Thu, 09 Sep 2004 21:42:00 GMT

I. INTRODUCTION

Standards development organizations (“SDOs”, including consortia) increasingly collaborate with one another, both domestically and internationally, with respect to the development of technical specifications/standards. These collaborative efforts (commonly referred to as “liaisons”) exist in various forms, ranging from (1) an informal, but coordinated effort involving some type of structured cross-communication, to (2) a formal, written agreement between the SDOs establishing each organization’s rights and obligations, to (3) one SDO “normatively referencing” the specifications/standards of a second SDO as a required element of the referencing organization’s own standards.

When successful, liaison arrangements can serve many useful purposes, such as reducing duplication, expediting standards development and adoption, and promoting the interoperability of standards. On the other hand, if not clearly understood and defined at the outset, such liaisons can create real risks and problems not only for the SDOs, but also for the SDOs’ members and for any implementers of standards that are developed by the SDOs.

One of the most common and most problematic liaison scenarios occurs when specifications created in one SDO are subsequently used (in whole or in part) to develop specifications/standards in a different SDO. In particular, while SDOs often own the copyrights in the standards they adopt, they generally do not own the patent rights that may be infringed by implementing the standard. Instead, it is common practice for the SDO members to retain their ownership rights in their patents and only to commit to licensing their patents to implementers of the specific standard under the terms of the patent policy of the SDO that developed the standard. Thus, when an SDO contributes a standard to another SDO’s standards development effort which results in a new and/or different standard, the patent commitments that were made with respect to the original standard may not extend to the newly developed standard effort. With this background in mind, consider the following hypothetical (yet fairly typical) scenario:

SDO 1 develops a technical specification. At some point, however, SDO 1 wishes to hand off this specification to SDO 2 for completion, adoption, promotion, and/or to further ensure the commercial deployment and success of such specification. Even assuming SDO 1 has copyright ownership in the specification and thus has the ability to hand it off to SDO 2 for such further processing, various patent issues and risks may exist. Suppose that there are five key contributors to the specs developed by SDO 1 that are not members of SDO 2. Unless SDO 1 and SDO 2 establish a clear understanding beforehand as to the rights and obligations of these five key contributors, there is the potential for confusion and derailment of SDO 2’s objectives. What if one of these key contributors was only willing to make its original contribution of essential patented technology to SDO 1 because it could do so on a reasonable and non-discriminatory (“RAND”) basis including the ability to charge reasonable royalties, but is unwilling to extend use of such essential patented technology to SDO 2, whose intellectual property (“IP”) policy requires all essential patent holders to commit to royalty-free licensing to all implementers of SDO 2’s standards? Further complicating matters, what if SDO 2 only wants to include a portion of a specification developed by SDO 1 in an SDO 2 standard? Even assuming the two SDOs’ IP policies are similar (i.e., both allow for RAND royalties), if the contributors to SDO 1 agreed to certain licensing terms based on implementation of the SDO 1 specification in its entirety, the partial implementation of the SDO 1 specification by implementers of the SDO 2 standard may give rise to the argument that SDO 1 contributors would not have any obligation to license their essential patented technology to SDO 2’s implementers. In either case, the negative impact on the success of the SDO 2 standard could be significant.

As this hypothetical illustrates, it is essential that SDOs understand the key issues surrounding their collaborative relationships with other SDOs in the development of standards and address them before pursuing the adoption and promotion of such standards. This paper provides an overview of the risks and core issues that are generally at stake when creating these types of liaison relationships.

More specifically, this paper (1) describes the various ways in which SDOs collaborate with one another on the development of specifications/standards (including through normative references),
(2) identifies the principal legal risks associated with such collaborations, and (3) suggests key issues for SDOs to consider as they contemplate the creation of a liaison and/or normative referencing policy to minimize such risks.

It is important to stress at the outset that all SDOs are different, serving different constituents often with unique needs and requirements. As such, it is not possible to design a generic liaison or normative referencing policy that is suitable for each and every SDO. As the discussion below indicates, different SDOs have approached these questions with different points of emphases, undoubtedly driven by the particular needs, characteristics, and operations of their own organizations. This paper does not endorse any one approach or suggest that one is better or worse than the others. Rather, the purpose and hope of this paper is that SDOs will recognize that before they form liaisons with, or normatively reference the standards of, another SDO they should first put in place clear written policies, customized to their organization, that govern these relationships and references so as to avoid ambiguity and legal risks to the SDO and its members/contributors, as well as to implementers of their standards.

II. MAIN VARIETIES OF SDO LIAISON ARRANGEMENTS TO DEVELOP JOINT STANDARDS

The overall formality of a liaison arrangement between SDOs can vary greatly. However, roughly speaking, there are generally two types of liaison relationships that may arise when SDOs wish to assist one another in the joint development of standards – (1) informal liaison arrangements, and
(2) formal liaison agreements. Each is discussed below.

A. Informal Liaison Arrangements

SDOs will sometimes collaborate for extended periods of time on the development of a specification or standard without any written documentation as to the applicable rules of governance, IP policy, etc. For example, SDOs like IETF (http://www.rnp.br/ietf/internet-drafts/draft-iab-liaison-mgt-00.txt) that traditionally operate on an informal basis are less likely to have detailed liaison policies and may prefer to retain that informality, to the extent possible, in a joint development arrangement. While such informal collaborations can certainly streamline standards adoption, they also present the greatest potential for legal risks and problems.

Specifically, if there are no written guidelines or rules explaining how such joint standards development will work, a number of fundamental and complex questions will go unanswered, such as the following: (1) how will IP contributions to the joint effort be treated and licensed? (2) what patent disclosure obligations, if any, will apply to the contributors to, and participants in, the collaborative effort? (3) who will own and be in charge of future updates to the jointly developed standard? (4) what licenses will implementers need to create compliant products and what are the permissible terms for such licenses -- royalty-free? RAND? Particularly if the separate IP policies and other governance documents of the collaborating SDOs differ, the absence of a clear document explaining how their collaborative work will be done and how any resulting intellectual property and other issues will be handled can lead to significant confusion and legal problems, thereby undermining the potential efficiency benefits of the informal arrangement.

B. Formal Liaison Agreements

1. Examples of Formal SDO Liaison Agreements to Develop Joint Standards – ITU, ISO, and JTC1

Recognizing the pitfalls associated with undocumented, informal liaisons as discussed above, some SDOs (such as ANSI, ITU, ISO, OASIS, W3C, OMA, and others) have established formal written procedures and guidelines as to how, with whom, and under what circumstances they may form formal liaisons with other SDOs in order to jointly develop a specification or standard. One of the most common ways such joint development is done is through the establishment of a joint technical committee staffed by members of each respective SDO which operates under policies and procedures specifically designed for such joint effort.

For example, ITU Study Groups engage in active collaboration with ISO, IEC, and JTC1 working groups, as well as with other outside entities, to develop certain standards. Typically, these joint efforts are governed by formal written policies (including IP policies and IP disclosure forms) unique to such joint efforts. In fact, the ITU and JTC1 have developed a “Guide for ITU-T and ISO/IEC JTC1 Cooperation” (http://www.itu.int/itudoc/itu-t/80718.html), which specifies the procedures to follow when ITU-T and JTC1 collaborate to develop an International Standard. ITU and ISO have also adopted a joint patent disclosure form (http://www.itu.int/ITU-T/dbase/patent/index.html) that is to be used for disclosing patent information for common texts developed through these collaborative efforts. One such collaborative effort is the “Joint Video Team” (“JVT”), comprised of members of the JTC1/SC 29/WG 11 and the ITU-T’s SG-16, to develop MPEG-4 Part 10 Advanced Video Coding (AVC). Special guidelines, called “Terms of Reference,” have been established to govern this joint standards effort (see http://www.itscj.ipsj.or.jp/sc29/29w12911jvt.pdf).

Again, the point of such examples is not to endorse any particular liaison arrangement, but instead to identify key issues that should be considered by SDOs when contemplating similar collaborative efforts. The next section discusses in greater detail a number of the key issues that SDOs should consider addressing, in writing, as part of any such joint standards development effort.

How Standards Orgs (should) work with each other - Part 2 of 4

Dave Welsh — Thu, 09 Sep 2004 21:40:00 GMT

1. Key Issues for SDOs to Consider When Developing Formal Liaison Agreements

SDOs that have formalized their intent to collaborate on the development of a joint standard typically have (or should) address, in writing, the following key areas governing this joint development process:

1. Scope: Have the parameters of the joint effort been defined as clearly as possible at the outset and reduced to writing? Does each organization have the same understanding of what those parameters are? If one organization determines that the joint effort has crept outside the agreed-upon scope, are there procedures in place to address these concerns?

2. Termination and Withdrawal: Will there be a sunset on the relationship? If so, will that sunset be on the occasion of a particular event (i.e., development of a specification) or following expiration of a time limit? If not, is there a process in place for dissolving the liaison relationship? If one organization unilaterally wishes to withdraw or otherwise sever the relationship, is there a mechanism in place to provide for this? Does the reason for withdrawal matter? (See ITU-R Liaison Policy (http://www.itu.int/itudoc/itu-r/publica/res/res9-2_ww9.doc), Annex 1 at 5, 7).

3. Relationship: Will one organization be designated lead sponsor (based on expertise or responsibility to be assumed for a particular standard, etc.), or will the SDOs act as joint sponsors of the effort? (See ANSI Guideline for Cooperative Standards Development Efforts (http://public.ansi.org/ansionline/Documents/Standards Activities/Information Infrastructure Standards Panel/Guidelines.doc))

4. Procedures: What procedures will be used in the maintenance of the joint development effort? Each SDO may have a different style/format that must be followed in drafting/submitting a specification. If the lead sponsor were an ANSI accredited SDO, for example, the ANSI approved standards writing (i.e., style/format specifications) and approval procedures of the lead sponsor might be selected. If that is not the case, alternate procedures should be agreed on. Provisions for procedure modification after the initial agreement should also be considered. (See INCITS discussion in section III below) Some of the elements to be considered in terms of procedures are:

· Administrative Responsibilities: How will the administrative responsibilities of the joint effort be managed? (See Memorandum of Understanding on Electronic Business between IEC, ISO, ITU, and UN/ECE (http://www.itu.int/ITU-T/e-business/files/mou.pdf))

· Organization: The agreement should set forth exactly how the joint effort will be organized, including voting procedures, any committee chairs, subcommittees, review boards, etc. – both initially and as the process evolves.

· Dispute Resolution: The agreement should contain a provision that instructs how to move forward if an impasse or stalemate situation has occurred.

· Meetings: Who determines the scheduling, frequency, format, and location of meetings?

· Funding: How are the joint activities funded?

5. Applicable IP Policy: What IP policy will govern the collaborative effort? How will essential IP be licensed? What patent disclosure provision governs? (See W3C Process Document §10.1.1 (http://www.w3.org/2003/06/Process-20030618/liaisons.html); see also IEEE Cooperation Agreement between IEEE 802.16 and ETSI BRAN, Patent Policy and Procedures (http://www.ieee802.org/16/liaison/docs/80216l-00_12.pdf)). In the worst case scenario, the two collaborating SDOs may have inconsistent IP policies (e.g., one requires mandatory royalty-free licensing for all Essential Patent Claims covering a standard and the other allows for a RAND licensing option, or one requires patent disclosure and the other merely encourages it). Unless it is made clear how IP will be governed, the potential for uncertainty, disputes, confusion, and loss of participants’ IP rights is significant.

6. IP Management: How will patent disclosures and licensing declarations relating to the jointly developed standard be received and processed? Who will maintain the website storing such disclosures/declarations and be the contact point for implementers or potential implementers with questions?

7. Naming: How will the approved standard(s) be named? Will the organizational acronyms of both developing organizations be used?

8. Announcements: Who makes announcements regarding jointly developed standards, and when are particular announcements made? Can public announcements be made unilaterally, or do they require approval by both groups?

9. Revisions: If allowed, how will it be determined when revisions are necessary? Which party will have the responsibility for revising a jointly-developed standard?

10. Indemnification: To what extent, if at all, will each SDO provide indemnification (either to the other party or to third parties) in connection with potential liabilities arising out of their joint development process and/or any jointly developed standards?

11. Copyright and Royalties: Which SDO will retain the copyright in the drafts and approved standards? How will licensing rights be determined? How will royalty or exploitation rights arrangements be made?

12. Pricing: How is the pricing of the resultant product determined? If both organizations sell the standard, are prices the same?

(See ANSI Guideline for Cooperative Standards Development Efforts (http://public.ansi.org/ansionline/Documents/Standards Activities/Information Infrastructure Standards Panel/Guidelines.doc); ITU-R Liaison Policy (http://www.itu.int/itudoc/itu-r/publica/res/res9-2_ww9.doc); OMA Liaison Policy (http://www.openmobilealliance.org/collaborating/index.html).

How Standards Orgs (should) work with each other - Part 3 of 4

Dave Welsh — Thu, 09 Sep 2004 21:35:00 GMT

I. CONSIDERATIONS WHEN ONE SDO SUBMITS ITS DRAFT OR FINAL WORK TO ANOTHER SDO FOR COMPLETION AND/OR APPROVAL

Many times two SDOs may not work together on the joint development of a standard (as discussed in the previous section). Rather, one SDO may develop a specification and then hand it off to another SDO for further development work, international adoption, commercialization, etc. It is equally important for an SDO in this scenario to have a defined policy governing the submission of its work to other SDOs for completion/adoption/promotion, or for the receipt of the same from another SDO. As identified below using OASIS and INCITS as examples, the concerns in this latter scenario are very similar to those discussed above in connection with two SDOs collaborating together from the outset on the development of a joint standard.

A. OASIS

The following is an excerpt from the OASIS Liaison Policy (http://www.oasis-open.org/committees/liaison_policy.php) that provides guidance on how this type of hand-off of a specification must be done when OASIS is involved:

The request for permission to submit a specification to another organization may originate with a TC [Technical Committee], the TAB [Technical Advisory Board], or OASIS staff, but must include the following:

· The name of the organization and the organization's committee/group to which the submission will be made.

· The purpose of the submission (e.g., for approval under the other organizations' process; for inclusion in the other organization's work plan, etc.), as well as a short description of the other organization's approval process, including estimated time required, stages of approval and who votes at each step, and the desired outcome (i.e., what will the spec be called once it is approved).

· How the submission will benefit OASIS (e.g., enhance the status of the spec by
having the other organization's name on it).

· The copyright terms used by the other organization in regard to the submission.

Generally only completed and approved work (i.e., an approved OASIS Standard) should be submitted to another organization. If the work is not yet approved as an OASIS Standard, the proposal should include the reason why the work is not being completed and/or approved under the OASIS TC Process.

As OASIS owns the copyright on specifications produced by OASIS technical committees, submitting specifications to other organizations according to the guidelines of this policy will require the approval of the OASIS President. Approval to submit OASIS specifications with any terms other than those specified in this policy will require approval by the OASIS Board.

The OASIS copyright should remain on the specification when it is published by the other organization, i.e., both OASIS' and the other organization's copyright will appear on the specification. However, OASIS is willing for the other organization's copyright to be the only one on the specification as long as:

· The other organization agrees that OASIS will continue to maintain the specification until such time as OASIS gives up that right;

· The other organization agrees that it will not further modify the specification until such time as OASIS gives up the right to further maintenance; and

· OASIS can continue to publish the OASIS-copyrighted version of the specification under our copyright and distribution policy.

A memorandum of understanding should be signed between the two organizations to ensure that the above items are mutually understood. See, e.g., MOU Between UN/CEFACT and OASIS (http://www.ebxml.org/mou.pdf).

Even with the OASIS Liaison Policy (which is more developed than most) in place for guidance, there is still potential for unintended consequences. For example, while the above guidelines address copyright issues, what if the patent policy of the second SDO (SDO 2) is different from, or inconsistent with, the first SDO’s (SDO 1) patent policy? In such a circumstance, how might the rights and obligations of essential patent holders who contributed to the SDO 1 standard be affected, if at all, by the fact that SDO 2, with a different patent policy, is to be in charge of adoption, promotion, and implementation of the standard? Can members of SDO 1 refuse to license implementers of the standard as adopted by SDO 2 under the terms of the SDO 2’s patent policy? Would SDO 2 have to seek out and obtain separate patent licensing commitments from each contributor/essential patent holder? Similarly, although SDO 1 may own the copyright to the final specifications produced by SDO 1 technical committees, and therefore be entitled to pass off such specifications for further adoption, promotion, etc. by SDO 2, consider whether contributors to an SDO 1 specification could object, on copyright infringement grounds, if SDO 2 were to substantially change the SDO 1 specification or excise only discrete portions of that specification (including specific SDO 1 member contributions) for uses quite different from what SDO 1 and the SDO 1 contributing member intended.

All of these issues should be considered and addressed before an SDO attempts to hand off, or accept, a specification to or from another SDO, in order to avoid confusion and legal risks down the road that could negatively impact standards development and deployment.

B. INCITS

INCITS (http://www.incits.org/) is accredited by, and operates under rules approved by the American National Standards Institute (ANSI) (http://www.ansi.org/). An organization not accredited by ANSI may propose that a candidate standard be submitted for INCITS processing, or the organization that developed it may request INCITS processing. INCITS has developed a “Fast-Track” process for analyzing and accepting standards developed by other SDOs. This process is set out below.

INCITS “Fast-Track” Process for Externally Developed Standards

When such an initiative is being considered within INCITS or a preliminary inquiry is made by the sponsor, a proposal describing the candidate standard, its purpose, and scope is sent to the INCITS Secretariat for distribution to INCITS. The INCITS Secretariat issues a call for comments on the proposal, and INCITS members are asked to assess the proposal with respect to the following criteria:

· Is the proposed standard within the scope of INCITS?

· If there is a TC with responsibility for scope of this work, does the TC have objections to continued processing?

If no objections are raised during this review, the developer will then be invited to submit the following:

(1) Candidate standard.

(2) Memorandum of understanding, which may be negotiated by the INCITS Secretariat on behalf of INCITS, detailing: (a) agreement to respond and participate in accordance with the INCITS rules and procedures; (b) agreement regarding availability and distribution of copies for public review and balloting;
(c) agreement for maintenance responsibility in accordance with ANSI procedures; (d) agreement that interpretations shall be accomplished in accordance with INCITS procedures; and (e) agreement that participation in further processing of the document be open to all directly and materially affected interests. See, e.g., MOU between INCITS and Coudscape, Inc. (http://www.incits.org/FastTrack/it990095.pdf).

(3) Any other documentation the developer feels is relevant.

Again, if objections are raised, the INCITS Secretariat will distribute those objections to INCITS and the proposer. The organization submitting the candidate standard will be required to respond to the objections raised in addition to the other documentation specified above. The entire package will be submitted to INCITS for approval. Upon receipt, INCITS votes whether to accept the proposal and initiate a public review. Upon approval, the INCITS Secretariat shall assign a liaison project number, and processing commences. The INCITS Secretariat will notify the TC chairs and encourage them to notify their committee of the candidate standard’s public review period. The Secretariat’s notification will include the results of the INCITS vote and comments received.

The Secretariat initiates the following:

· 2 month/45-day public review (& announcement in ANSI’s Standards Action)

· Call for patents

· Press release

· The Secretariat will register all comments. The proposer will respond to the comments. The Secretariat will distribute all comments and responses to INCITS prior to the 30-day ballot.

After INCITS approval, the draft is sent to ANSI for final approval, and the approved standard is published shortly afterwards.

The type of rigorous review and analysis that INCITS performs before accepting a proposed standard from another organization highlights the risks associated with such acceptance. It is particularly important that the INCITS-type process invoking a “call for patents” include a review of any essential patents or essential patent holders/contributors to the proposed standard (as well as an associated review of the scope of the copyright license extended by the original contributions to the proposed standard). To the extent such IP issues are not fully investigated and approved, the same risks discussed above relating to the acceptance of another SDO’s work could arise.

How Standards Orgs (should) work with each other - Part 4 of 4

Dave Welsh — Thu, 09 Sep 2004 21:30:00 GMT

I. KEY RISKS AND ISSUES ASSOCIATED WITH ONE SDO NORMATIVELY REFERENCING THE STANDARD OF ANOTHER SDO

As described above, there are several ways that SDOs may choose to work together toward a mutual standards-setting goal, including informal and formal liaisons to jointly develop a standard, as well as the hand-off of one SDO’s work to another SDO for further development and deployment. Another common industry practice, “normative referencing,” is yet a further way that SDOs often merge their work, even though there may be little to no direct coordination between them. Generally, a normative reference is an SDO’s reference to a document (in this case, a specification or standard developed in another SDO) that must be followed in order to create a compliant implementation of the referencing SDO’s standard. Properly structured normative references can provide an efficient technique for referencing important and sometimes lengthy documents previously developed by other SDOs. This practice is not without its own risks, however, and the following hypothetical identifies key concerns that should be addressed whenever normative references are considered by an SDO.

A. Hypothetical Illustrating Potential Risks Associated with Normative Referencing

SDO 1, in attempting to develop a cable-ready television standard, wishes to normatively reference for the audio portion of such standard an audio standard previously developed by SDO 2 (rather than create the audio portion of the standard from scratch). SDO 1’s IP policy requires essential IP to be licensed on a royalty-free basis. SDO 2’s IP policy, on the other hand, allows its members and contributors to its standards to seek RAND/royalty-bearing licenses from implementers for their essential IP. Thus, if SDO 1 were to adopt a cable-ready television standard that included a normative reference to SDO 2’s audio standard, implementers of the SDO 1 standard – expecting royalty-free licenses – could be surprised to learn that license fees may be required for the normatively referenced SDO 2 audio technology. This could carry many negative consequences, not the least of which would be diminished acceptance of the SDO 1 standard by implementers. Had the members of SDO 1 considered and understood this issue beforehand, they very well might not have made the normative reference to SDO 2’s audio standard, or might have taken other steps, such as seeking royalty-free licensing declarations from the essential IP holders in the SDO 2 audio standard before including the normative reference in the SDO 1 standard.

This situation would only be made worse if, instead of being allowed merely to seek royalties on a RAND basis, SDO 2’s IP holders were allowed to block full access to the IP contained in the normatively referenced document, or otherwise condition access on onerous, private contractual agreements with implementers. For example, what if SDO 1 wished to normatively reference only a portion of SDO 2’s audio standard, as opposed to the entire SDO 2 audio standard? Could IP holders of essential technology in the SDO 2 audio standard argue that any commitment they may have made to license implementers of the SDO 2 audio standard do not extend to those parties who implement only a part of the SDO 2 audio standard (by virtue of their implementation of the SDO 1 standard)?

But what if the essential IP holders to the referenced SDO 2 standard are also members of SDO 1? Doesn’t that solve these problems? Not entirely. Even in this case, SDOs have addressed in different ways the scope of the licensing obligations of such members. For example, some SDOs define Essential Patent Claims to exclude any patent claims covering normatively referenced standards (see, e.g., W3C Patent Policy (§8.2) (http://www.w3.org/Consortium/Patent-Policy-20040205). Others, by contrast, make no such distinction and rather treat all required portions of the standard the same for licensing obligation purposes, regardless of whether or not the portion is a normatively referenced standard (see, e.g., EPCglobal IP Policy (§ 1.7) (http://www.epcglobalinc.org/action_groups/031223EPCglobalIPPolicy12152003A.html). It is thus very important for SDOs to make clear in their patent policies the scope of their members’ licensing obligations for “Essential Patent Claims” in normatively referenced standards. This clarity is particularly important in light of recent case law that places heightened obligations on SDOs to clearly define the difference between required and optional portions of their standards for licensing purposes. (See, e.g., Intel v. Via Technologies, 319 F.3d 1357 (Fed. Cir. 2003) (holding that, since ambiguity existed as to whether a particular protocol was included within a required portion of a standard and therefore subject to a reciprocal royalty-free licensing agreement, the ambiguity would be resolved against the drafter and, thus, there was no infringement by VIA Technologies for royalty-free use of the protocol in question).

B. Sample Normative Referencing Policies of Major SDOs

To address these potential problems, various SDOs have developed policies to govern their inclusion of normative references in their standards. For example, under the ITU-T’s normative referencing policy (which is set out in Appendix A to this paper), the ITU-T member proposing the inclusion of a normative reference must submit a contribution to the ITU-T study group or working party, which provides the required information outlined in sections 2.2.1 to 2.2.10 of ITU Recommendation A.5. Such contribution must include, for example, a justification for the normative reference, the relationship of the reference with other existing and emerging documents, and the degree of stability or maturity of the referenced document. The study group or working party evaluates the submitted information and comes to its conclusions based on the usual consensus process.

In addition to evaluating the document being proposed for reference, the ITU-T will also consider the referenced organization according to certain criteria (see ITU Recommendation A.5, sections 3.1-3.3). This analysis includes, for example, whether the referenced organization is open to all parties with a material interest in the organization, consistency of the organization's patent and copyright policies with those of the ITU-T, and well documented and fair working methods/processes.

Recently, ETSI adopted a normative referencing policy similar to the ITU’s (included in Appendix A to this paper).

In sum, before an SDO includes a normative reference to another SDO’s specification or standard, it must be sure that it understands the nature and policies of the other SDO, and that the licensing obligations of the essential IP holders to the referenced standard will extend to implementers of the referencing standard in ways that will not deter or stymie the widespread adoption and deployment of the referencing standard.

II. CONCLUSION / RECOMMENDATION

Liaisons among SDOs can provide an effective vehicle for streamlining the development of standards. At the same time, however, such liaisons – whether pursued as a joint standard development effort, the hand-off of a specification by one SDO to another SDO, or the normative reference by one SDO’s standard to another SDO’s standard – can present legal risks and confusion for the SDOs, as well as for their contributors and implementers. It is essential, therefore, that SDOs understand the key issues surrounding their collaborative relationships with other SDOs in the development of standards and address them before pursuing the adoption and promotion of such standards. This paper has provided an overview of the risks and core issues that are generally at stake when creating these types of liaison relationships. The purpose of this paper is not to endorse any particular method of approaching (and hopefully avoiding) the various problems with SDO liaisons identified above. Rather, it is to raise awareness of the issues and to encourage SDOs to develop written liaison / normative referencing policies -- based on the sample policies of major SDOs discussed herein, but of course customized to the SDO’s own unique processes and constituents -- in order to avoid legal risks and impediments to the SDO’s successful standards development efforts.

Update on WS-Eventing

Dave Welsh — Tue, 31 Aug 2004 17:55:00 GMT

What's cool for Industry Standards groups (retail, finance, manufacturing, apparel, utility services, ...), who typically work in their own process domains and with their own communities, is that they are all going to be on a common technical foundation for a common internet business 'dialtone'. The Web Services workshops are working at full effort, specs are coming through, all the major vendors are not only participating but also publicly taking firm postions of support from the CEO level down. By the time all the WS specs get out of workshops, which I blogged on earlier, there's going to be a good quality of standard spec with proven interop between the major market vendors before everyone can use these specs royalty free common use.

Just a short update message for those tracking the latest on the Web Services spec developments - BEA, CA, IBM, Microsoft, Sun, and TIBCO just published an update to the WS-Eventing specification; first released in January 2004.

You can see the new formal document at http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-eventing.asp or for and easier to read Dummies Guide to WS-Eventing check out http://blogs.msdn.com/bwill/archive/2004/02/10/70964.aspx

The updated WS-Eventing spec has new industry feedback out of feedback and interoperability Web Service workshops. With the new enhancements, higher level specifications such as WS-Notifications that layer on top of WS-Eventing should improve their prospects for syntactical interop for customers.

Distinguishing between Open Standards and Open Source -- Part I of III

Dave Welsh — Sun, 29 Aug 2004 02:55:00 GMT

The blurring of distinctions between Open Source Software and Open Standards – be it inadvertent or intentional – is confusing a lot of people and can be deceptive. The difference is something architects and decision makers need to be sensitive about to avoid costly errors and deliver solutions that are on target with client needs.

The term “standard” can really take on an array of meanings depending on the context, but to pick a point of reference, the International Standards Organization (ISO) defines a standard as “… a document, established by consensus that provides rules, guidelines or characteristics for activities or their results”. Probably the operative word for most general definitions of a standard is “consensus”, and a true test of a standard is if there is really an Open (by the widest possible community) consensus or agreement.

Standards may also be described by the process used to develop them and by the organizations where standards are developed and defined. Access to and use of the standard are also attributes used to describe the different types of standards. An “Open” standard is generally developed through an open collaborative and market driven process defined by an independent organization whose membership is not restricted in any discriminatory manner. But more importantly perhaps, an Open Standard is relevant to some community and publicly accessible to all who are interested in evaluating or using the standard.

Open, consensus-driven standards are product independent. In other words, Open Standards are not tied to the products or services of any particular vendor, and the licensing terms governing them do not restrict implementation to particular hardware or software products. For this discussion, an Open Standard is a technical specification developed and maintained by collaboration and consensus that is intended for widespread industry adoption and it facilitates interoperability among different products or services. Open standards exist to enable interoperability in the market place of multiple competing implementations of that standard. For example the ISO standard on metric screw threads dictates the dimensions of a 2mm thread size, not how the screw is constructed or with what materials.

Distinguishing between Open Standards and Open Source -- Part II of III

Dave Welsh — Sun, 29 Aug 2004 02:53:00 GMT

The term “Open Source Software” (OSS) is used in a variety of contexts to refer to any (or a combination) of four (4) interrelated concepts: an OSS development model, OSS philosophies, OSS licensing regimes, and OSS business models. The four concepts taken together help define what is known as OSS.

Unlike traditional software business models, where distribution and licensing are for the purpose of creating a sustainable return on R&D investments through direct commercialization of the software, Open Source Software is commercialized through the sale of related services, hardware and solutions.

There are varying degrees of freedom adopted by the OSS community, but there is no single or unified OSS philosophy. In fact, there is a great deal of disagreement within the community itself over the licensing terms controlling the distribution and use of OSS. The two most fundamental and often rival OSS schools of thought can be characterized loosely by the following:

Ideological. This school of thought contends that all software (both source and object code) should be available at no cost, because software should not be privately held.
Pragmatic. This school of thought supports the co-existence of privately held and Open Source Software, and seeks to use both to create healthy businesses.

As a result of these different philosophies, there are currently about 50 different licensing schemes governing the distribution of Open Source Software. The Open Source Initiative (OSI) (www.opensource.org) maintains a diverse list of licenses that cover both the ideological and pragmatic approaches. These licenses vary considerably as to specific terms, even key terms, but the vast majority of OSS licenses conform to the definition provided by the OSI. Of the ten essential OSI criteria, three are relevant to this discussion. In summary, every OSS license

requires that the source code be made available to the public
permits anyone to redistribute the source code without material restrictions
permits anyone to modify the code and freely redistribute the modified code

Within these broad parameters, however, Open Source Software licenses differ widely with regard to the nature and degree of restrictions they impose on licensees. Some OSS licenses are extremely permissive, such as the Berkeley Software Distribution (BSD) license, which is a simple, permissive, software license whose only restriction is copyright attribution and license reproduction. Others are moderately restrictive, such as the Apple Public Source License (APSL) or the Mozilla Public License (MPL), which requires that specific files that contain APSL/MPL code be distributed in source code form and under the terms of the APSL/MPL (although other files that do not contain APSL/MPL code that are contained in a larger work may be released under any license). Still others include greater restrictions such as the GNU General Public License (GPL), which forbids direct commercialization of the software and requires that any work that includes GPL code be released under the terms of the GPL.

Distinguishing between Open Standards and Open Source -- Part III of III

Dave Welsh — Sun, 29 Aug 2004 02:52:00 GMT

Distinguishing between Open Standards and Open Source Software is essential, as they each are tailored towards different ends. The fundamental purpose of a standard is to promote interoperability. The philosophical objective of OSS is to ensure that software users may access, modify and redistribute source code; as the name itself suggests.

An Open Standard is a specification to enable interoperability or portability developed through a consensus process. Open Standards can be implemented by both Non-OSS and Open Source products. Essentially OSS is code, and Open Standards isn’t. The Open Standards process is neutral with regard to software development, welcoming all and favoring none in it’s quest for the best solution.

There are a couple of points to make in distinguishing between Open Standards and Open Source Software:

- Software code is not an Open Standard.

§ There is no inherent connection between the model under which particular software is developed, licensed and distributed, and the fact that the software does or does not conform to a particular Open Standard. Claims that Open Source and Open Standards are the same are as mistaken as statements that claim the Internet and the World Wide Web are the same.

- Developing software differs from developing Open Standards.

§ The fact that a technical specification is implemented in Open Source doesn’t establish consensus in the implementation and does not make the technology a standard.

- Differences between de facto Product Standards and Open Standards.

§ In a somewhat different context, some software can be so widely adopted that it is considered a “Standard”. Irrespective of whether the software is distributed under OSS license or Non-OSS license like Java or Windows, market driven forces will encourage the creation of Open Standards to ensure that the ecosystem of complimentary products continue to effectively function.

- Reference Implementations.

§ Typically an implementation of a consensus based Open Standard can be developed in many different ways and can be made under a variety of different software licenses. To facilitate the adoption of a standard, it is sometimes desirable to make a reference implementation available as a starting point or as a sample for those who either do not want to invest in the development of a unique or optimized implementation, or simply do not have the expertise to do so.

§ The notion that the availability of an OSS reference implementation will advance adoption of a standard over Non-OSS reference implementations has a few flaws. Generally, the reference implementation will be made available under very favorable, often royalty-free, license terms. However, this does not necessarily mean that the license will be an OSS license approved by OSI. For example, the reference implementation may be available for evaluation, non-commercial use, or have restrictions on its modifications or limited distribution rights, all of which could be in opposition to the OSI criteria for Open Source Software licenses. In fact in some cases, reference implementations released under an OSI approved OSS license may do little for adoption. If the OSS license is one requiring that all modified and extended versions of the OSS program also be distributed as free software under the same OSS license, then some implementers may actually be discouraged from taking advantage of the free reference implementation, because they would be prohibited from commercially licensing a resultant software product (or combined hardware/software product) if that product includes this reference implementation.

§ Another concern may arise from the unknown origins of the code base. If the reference implementation was developed in a community project, or even under the auspices of the Standards Setting Organization, and if anyone can contribute code to the reference implementation they may not have had the rights to contribute, then the resulting reference implementation may not be deemed safe to use in commercial products. Consequently, reference implementations developed under these open but uncontrolled processes may not encourage the adoption of the standard in commercial settings at all.

§ Typically those who commercially distribute products that might include a reference implementation may have to provide their customers’ assurances in the form of representations or warranties that the software does not infringe the copyrights of another, violate any contractual agreements, or disclose the trade secrets of others. More importantly, such commercial vendors may have to indemnify their customers if their customers are sued for using code that they did not have the right to use.

OSS proponents frequently assert that the universal accessibility of OSS code promotes interoperability. Although the same could be said about commercial software, the potential risk of code being altered in a non-conformant manner is probably significantly lower when source code is under some form of tight control, such as with a commercial entity whose paying customers demand conformance. The freedom to modify code also includes the ability to undermine its interoperability.

As architects and IT decision makers, recognizing these distinctions between Open Standards and Open Source Software is essential to meeting the needs of clients. Open Standards are a vital part of solutions built for organizations that seek to implement interoperable solutions from multiple vendors, regardless of the development model used in the implementation.

Another Web Service spec comes together (MTOM)

Dave Welsh — Fri, 27 Aug 2004 01:18:00 GMT

More new Web Service work is making its way through the standards process, and this time it’s MTOM at W3C. MTOM (Message Transmission Optimization Mechanism) is a spec for attaching large binary data to a SOAP message, while still retaining the SOAP processing model (by mapping the attachments into the XML Infoset of the message). Achieving W3C CR status is an important milestone in the lifetime of this spec.

MTOM is very strategic because it enables composition of attachments with WS-Security. The original spec in this space, called SOAP with Attachments (SwA) is what ebXML Messaging has been using for the last 3 years.

I’m not sure that end customers understand that there is a critical 'gotcha' with using SwA - namely that you can't use WS-Security and SwA together to secure attachments in addition to the SOAP header/body. It seems unfair for customers to have to make a choice between security and attachments.

The W3C references for MTOM are here

http://www.w3.org/TR/2004/CR-xop10-20040826/

http://www.w3.org/TR/2004/CR-soap12-mtom-20040826/

http://www.w3.org/TR/2004/CR-soap12-rep-20040826/

and if you are interested in some more history on the MTOM pedigree then have a look at Omri Gazitt’s blog. I think the operative phrase, as Omri mentions, on getting to MTOM is "... our understanding of the requirements for Web Services attachments has evolved over time" which comes back to my earlier blog about how web services is breaking new ground as a process on how real world standards can be done in record time (for something of this global scale).

More good stuff to come from web service pipeline, in due time.

Stay tuned.

A Quicker Way to get Better Standards?

Dave Welsh — Tue, 17 Aug 2004 23:16:00 GMT

Customers always tell us they want open standards that work, yesterday. With last weeks news about WS-Addressing going in to the W3C, most of the public might not realize they are actually watching the end of an exhaustive standards development process - even though last weeks big news comes across as only the start of a new W3C process. The end result though of this new development process (which took a lot of lessons from the practice of developing software) is probably delivering better, more technically solid standards much quicker than the conventional standards development processes; with probably less customer grief in the end – and it still can help today’s standards bodies do their thing.

First of all, right up front, there’s been a few questions about web service specs but have a look at http://msdn.microsoft.com/webservices/understanding/specs/wslicensing.aspx and I think you will see it’s pretty clear that “Microsoft is committed to license its essential technology on royalty-free, and other reasonable and non-discriminatory terms”.

So, if we can all get beyond some competitors marketing FUD and look at what is really going on with how the web service standards are being developed, you’ll see it’s not your “normal” standards process; i.e. launch a committee, politically pick a chair, generate lots of hype and expectation on how this spec will solve world hunger, stack the new committee with people who may be able to contribute, host conference calls and arm wrestle the original idea down to some compromise that seems to make sense, then hope someone’s got a number of free weekends over to write up a draft of the new spec.

I think it is pretty obvious to anyone who has been involved with making standards (and still has a full head of hair) that especially these days it takes an increasingly large amount of effort, resource and time, to build the new big technical specs. The demand for standards to be available at an ever quicker pace and of better quality, than in the past, has even caused some standards bodies to try to find ways to instigate ‘fast track standards approval’ processes for their members. Terms like ‘no free lunch’ and ‘no one ever promised making standards was a quick process’ still come to mind though, and bottom line is it still takes a lot of work to make a standard easy to use; and practical.

It’s a fact these days. Most standards bodies don’t have the type of big development budgets and a large developer staff who can spend the necessary months or even years of constant technical work to not only write up a draft spec but also go through the process of aligning their technical designs with their competitors to get cross industry consensus; let alone go the extra mile and get through interoperability testing with your commercial competitor.

What Microsoft, IBM and other industry leaders have been doing for some time now as a key part in creating the new web service standards has been to work with a community “web services protocol workshops” process to get the new standards out. As time goes, on, I think it is going to become more apparent to everyone from the deliverables, that this approach is a better standards development process. You can find more info about the Workshop process (plus past and coming Workshops!) at http://msdn.microsoft.com/webservices/community/workshops/default.aspx but basically these workshops are about getting major technical industry players all behind developing common, open web service standards.

To save you a bit of reading time. There are two types of Workshops: Feedback and Interop. In Feedback Workshops, the web service spec authors discuss the content of the specification and solicit feedback from all attendees. In Interop Workshops, companies with implementations of a particular Web Service specification come together to test the interoperability of their implementations with others; i.e. don’t shop up unless you’ve brought your laptop.

So, why no big (hype) promotion of the Workshop process before? Well, all the material is public and there have even been some news articles in the past on the workshops that I seem to remember – but maybe it’s not really big news when you find Microsoft, IBM and other industry leaders getting together to work together?! From Microsoft’s perspective, we’re not trying to “do standards for standards sake” but use a standards approach to get the industry on the same wavelength.

In terms of Microsoft’s public position, it should be obvious that we don’t publicly speculate on the new web service specs till they have gone through their workshop process. Instead of marketing hype, we’re hitting for a reality homerun and I think the web service standardization track record will speaking for itself with time as the various specs come through the pipeline.

WS-Security has already successfully gone thru the process, in that case with Oasis, and now WS-Addressing has made it to a path with W3C. As for the other specs, well when they’ve ‘matured’ and we have the industry consensus which all customers need – then you’ll hear more news; as opposed to what potentially could exist in a new standard done under the more ‘traditional’ way of developing standards thru committee.

In coming postings I’ll be taking a closer look at how current standards bodies actually do their work, and I’ll try to suggest that there just might be a better way to develop real open standards for everyone.