Now that we're getting down to the final days of the DIS29500 standards process, it's interesting to see the tactics being used by those who have commercial interests that place them in opposition to this standard. Their tactics have changed quite a bit since the heady days of the DIS ballot period, and the most common tactic I've seen or heard of in recent weeks can be characterized as "changing the subject." It seems that there are people involved in the DIS29500 standards process (many of whom got involved quite late in the process) who want to convince various standards bodies to focus their time and efforts on a long list of proposed distractions, instead of the work at hand.
Whereas the work of evaluating a standard is technical, these proposed distractions tend to be emotional topics that are easy to convey quickly but don't shed any light on the core issues. And as the clock winds down on the DIS29500 process, some of the people who have vested interests in the outcome are really turning up the heat on the emotional topics.
A couple of supporting tactics are also used to add a multiplier effect to these efforts to derail the process. One is the tactic of dragging non-combatants into the debate without their permission. Another tactic is the longstanding Groklaw tradition of deleting comments that disagree with their statements, to reduce the risk of their claims being debunked publicly.
My colleagues Oliver Bell and Eric White have posted recently about the tactics of the anti-Open XML lobbyists, and I'd like to add a few to that list from my own experiences. Here are some examples of the sorts of things that various people are trying to convince standards bodies to think about these days, instead of the actual DIS29500 spec:
Process issues. A recurring piece of advice from some sectors is that standards bodies should change their vote to Disapprove as a statement on the Fast-Track process. Don't like the rules? Great, you can switch your vote to Disapprove without bothering to read any of the spec!
To state the obvious, each country's vote is on the DIS29500 specification and nothing more. It's not a vote on whether a BRM should allow visitors, or how the voting should be conducted, or anything else: it's a vote on whether DIS29500 should become an ISO/IEC standard. And if a country changes its vote, it should do so based on changes that have been made to the DIS29500 specification, and nothing else.
The final specification. Speaking of the final spec, another thing some people want to talk about these days is the question of whether there's a final spec available with every change already made. The anti-Open XML crowd has been trying to sell the concept that if there isn't a final spec available with every approved change already made, then countries "can't decide how to vote" and should therefore (decide to) vote Disapprove.
This one was explicitly addressed in the BRM, and it's pretty simple: the national bodies make their reconsideration decisions based on the documents that came out of the BRM.
As an ISO/IEC official explained to everyone in the BRM, there are two reasons for this approach. The first reason is that ITTF is responsible for verifying the accuracy of every change, and they don't have the resources to do this quickly. The second reason is that the process needs to be fair to all countries, and it would be unfair to have different documents available at different times during the 30-day reconsideration period. That might penalize those whose schedules required making a decision earlier in March, for example.
All national bodies have access to all of the documents describing all of the changes to be made, and that's what should form the the basis of voting decisions. If your national body has heard otherwise and needs verification of the ISO/IEC policy on this matter, they can contact ITTF directly to confirm the details. Communications directly from a national body to ISO/IEC get high priority, so that's the way to go.
Raising new technical objections. Many national bodies are being asked to consider brand-new technical objections to the DIS29500 standard, even though the 5-month period for submitting such comments concluded long ago in September. Then, when somebody points out that there is no process for resolving such comments until the future maintenance period, the lobbyists say "see, the process is broken!"
It's an easy tactic to try, because it's always possible to find a few more things that need correction in any large standard. Japan, for example, recently found a list of issues with the ISO ODF spec that has been out for a couple of years, and Brian Jones has a blog post today in which he takes a look at some of the ways common criticisms of Open XML apply equally to ODF.
The rules are pretty simple on this one: comments were submitted with the ballots (last September in this case), and any further technical concerns are addressed in maintenance. This is the way the process has always worked.
Talking about other standards, or non-standards. This one really takes the cake for pure chutzpah. Some vendors (Microsoft competitors, frankly) are going to national bodies and telling them to consider alleged problems with other standards instead of DIS29500. Sounds crazy, but it's really happening.
For example, one big US-based vendor is shopping around a list of complaints about an RFC that Microsoft has submitted to IETF as a courtesy, to make the Pack URI portion of OPC more broadly available. This isn't even a normative document, and isn't referenced in the DIS29500 specification at all, but for some reason this vendor thinks national bodies should be spending their time this week studying a Microsoft competitor's reaction to it.
Extending the reconsideration period. This is another creative tactic: telling national bodies that they should ask to have the reconsideration period extended from 30 days to some longer period of time. The advice is never a straightforward "ask ISO/IEC if there's a way to do this," but rather a more roundabout "vote Disapprove and say you might change your mind if you had more time."
This topic was discussed a year ago, and ISO/IEC have been consistently clear that the decision on DIS29500 would be reached at the end of this month. This was explicitly said in the DIS29500 session held at the JTC 1 Plenary last fall in Australia, and there is no defined procedure for ISO/IEC to extend the reconsideration period. So this advice is essentially "ask for something we know they can't do, then vote Disapprove to indicate your unhappiness about it."
Casting this as a "new vote." This is a subtle one: the claim that countries must vote again. That's not accurate: this isn't a "vote," but rather an opportunity for reconsideration of a country's position from last September based on changes that have been made to the spec, or information that the national body has received which they didn't have last September. So, for example, if a country voted Disapprove last September but many of their comments were addressed in a satisfactory way, they could now change that vote to Approve.
One thing that can cause confusion on this point is the difference between ISO/IEC and JTC 1 Fast-Track processes. DIS29500 is going through a JTC 1 Fast-Track process, and in that process there is not a final vote, only a reconsideration period during the 30 days after the BRM. But in the ISO/IEC Fast-Track process, there is another final vote, as described in the ISO/IEC Directives Part 1, Annex F.
It's quite rare for a country to shift their vote in a negative direction at the end of a JTC 1 Fast-Track process, by the way. (I think only one country has ever done that -- anyone know for sure?) The reason is obvious: if you have a BRM and make a bunch of changes or improvements that countries asked for, then the spec is probably better than before, or at the very least no worse than before.
Re-raising contradiction-period comments. This is one that's come up very often: vendors telling national bodies that they should consider the comments raised during the contradiction period (January of last year), such as the claim that DIS29500 isn't appropriate for a Fast-Track process.
These comments were raised during the contradiction period, Ecma responded as required, and ISO/IEC agreed with Ecma's responses and decided to start the 5-month DIS ballot period in early April. That's all ancient history now, but some of those working to defeat DIS29500 have gotten involved since then, and apparently don't know that.
What should a standards body do?
Some of those topics are interesting, and some are even relevant to standards work in general. But none of them can inform a voting decision on DIS29500: they're other topics that one might ponder in other contexts.
So how can standards bodies best inform their decisions on DIS29500? I think most people would agree that the best approach doesn't start with studying whatever random topic opponents of DIS29500 claim is important.
A good place to start would be to study the spec itself, and the other documents that will determine the final specification. If you're on a standards body involved in the process, you have access to all of these documents and should study them carefully:
- Study the original DIS29500 submission, or the ECMA-376 specification. That's the starting point: the standard as submitted to ISO/IEC. We started studying this in the US V1 committee in January 2007, and some people were looking at it even earlier as it went through the Ecma process in 2006.
- Next, study the national body comments submitted with the votes last September. The comments from your country show the main concerns of your country, so you'll want to focus on those first, but you can also review other countries' comments as well. (You'll see a lot of duplication, including word-for-word duplication of specific comments across many countries -- that's from the "denial of service attack" strategy the anti-Open XML crowd was using during the ballot period.)
- Now take a close look at the proposed dispositions that Ecma distributed on January 14. For each national body comment, Ecma proposed a change to address the problem (in the majority of cases), or explained why they felt a change wasn't a good idea at this time (in a small minority of comments).
- The final set of documents to review is the BRM resolutions that describe changes approved at the ballot resolution meeting. These are solutions to technical problems, editorial changes, or other changes that were suggested by BRM attendees and approved by the majority of countries attending the BRM.
And that's it: everything you need to study to reach a well-informed conclusion about DIS29500. You don't need to study documents prepared by big US-based vendors, web pages on lobbying sites, blog posts, IETF RFCs, or anything else. Just read and study the documents above, and you'll be among the best-informed participants in this debate.
Armed with that informed perspective, you'll be in a good position to protect your country's interests and take a long-term view of issues like interoperability, global competitiveness, job creation in the tech sector, retention and archiving considerations, and protection of existing investments. Your vote on DIS29500 will determine who will control the ongoing evolution of the standard, and whether your country has a say in that evolution.
Study the issues closely, avoid the distractions, and reach your own conclusions. This should be a rational process, not an emotional one.