Standards Best Practices Blog

As Andy Updegrove points out today it’s payback time as SC34 is having trouble getting sufficient votes to pass any of their ballots, as the countries who joined specifically to vote on OOXML have now lost interest in further SC34 work. As JTC1 voting requires 50% of P members to approve, if there are a lot of P members in a subcommittee who don’t vote then nothing will ever get approved. This is just the situation I warned against a week or so ago.

To continue my thread of blog posts on the subject of standards best practices, how is such a situation solved? The first step is, as I’ve suggested in several posts, is to prevent stacking by requiring some sort of waiting period, by requiring participation over a period of time before granting voting rights. The second step covers the other end of the timeline: The committee process should include some provision to get rid of members who don’t participate.

There are, of course, a number of valid reasons why a particular member doesn’t participate in any particular ballot. The member may not feel that he has the technical expertise to form a valid opinion on the topic, or perhaps a member hasn’t had sufficient time to acquaint herself with the specification under review. Travel and other work activities, as well as holidays and vacations, interfere. The standards organization should provide sufficient time for a member to review the specification and form an opinion, but it should also provide members the opportunity to abstain from voting. The organization should never expect 100% participation by eligible voters, yet should require a sufficient number to ensure that the voice of the committee or other consensus body is being heard.

What should the organization do with a member who simply does not participate? Most organizations have rules regarding the retention of voting rights; these rules would generally mirror the rules for gaining voting rights. The organization could require, for example, that a new member attend two out of three meetings for some period of time before being able to vote, then would require the same level of meeting attendance plus the return of two out of any three ballots in order to retain voting rights. These rules should take into account valid reasons for non-participation, yet recognize that if a member is truly interested in participating he or she would do so.

But even with any fair set of rules it will take time to remove inactive members from the voting roster. Inactive members should be encouraged to resign if their presence on the voting roster is preventing other work to proceed. It is important to structure the committee process to encourage participation, provide for valid absences, but not penalize active members who want to get work done within the committee.

Standards organizations pay a great deal of attention to the development and approval of new standards. But if that’s all that they are doing they’re only doing part of the job. A standard that is not adopted, that has no implementations, is wasted effort.

The standards organization can do a number of things to promote adoption of the standard. These occur during all phases of the organization’s process and activities.

First, the specification that will become the standard must be designed with adoption in mind. The specification must solve a specific problem or meet a specific need. The committee or work group developing the specification should start by identifying those needs or problems through the creation of specific use cases. The specification must be well engineered to prevent ambiguities and undefined behaviours. The scope should be well defined to prevent feature creep or the inclusion of out-of-scope features, and the specification should reuse or reference existing work.

The committee should not be restricting its work to creation of the specification itself. Conformance requirements and/or a conformance test suite should be part of the committee’s work, as well as the creation of reference implementations or proofs of concept.

The organization’s process contributes to the quality of the specification as well. The development process should be open to all interested parties, and balance should be sought from a variety of interests and not just from vendors or manufacturers. Reviews, both public and committee, should be required, and the organization should provide facilities to support accurate and complete disposition of received comments. The process should require some number of implementations of the specification before approval to ensure that the specification is indeed implementable. Testing of the interoperability of those initial implementations will further prove the quality of the specification.

After development of the specification and its approval as a standard, the document must be distributed. This phase also has a great deal to do with the adoption of the standard. If the standard is not easily obtained then it is not as likely to be implemented. This includes making it easy for potential implementers to find the standard by publishing information about it on the organization’s web site and in databases of standards. The process for buying and/or downloading the document should be simple, and the cost of the document should be reasonable from the implementer’s perspective.

Even after publishing the standard, the organization’s work is not completed. The organization should engage in promotional activities such as sending out press releases, conduct educational workshops and seminars, host interoperability plug fests, and engage test labs to conduct third-party certification testing. And finally, the organization should have a plan for the maintenance of the standard, including ongoing collection of comments and then periodically revisiting the specification for updates and reapproval.

Keeping in mind the adoption of the standard throughout its development, approval, and after will go a long ways towards ensuring the success of the standard.

So, your technical committee or work group has just completed development work on a specification. How do you go about approving the work and releasing it into the wild? Obviously you need some sort of approval process, and obviously that would include approval by the people who developed the specification. But is that enough?

Most standards organizations have multiple, usually two, levels of approval within the organization, There’s a good reason for this: the two levels of approval combined, within the committee that developed the work and then at the organizational level, provide a good level of oversight and allows all members to participate in the development and/or approval at whatever level interests them.

Some smaller, less formal organizations may not see the need for multiple levels of approval. Isn’t the approval within the developing committee sufficient? Perhaps, but there’s a few problems with doing this. First and foremost, any group of people who develops something will always approve their work once they’ve completed it. (Have you ever heard of a group putting a lot of time and effort into something then, when it is completed, deciding that it’s not any good?) A second opinion is needed.

The second opinion also brings the opportunity to look at a work from a different perspective. The developing committee should have been working from a specific set of technical requirements and developed a technical solution to that problem. But the wider organizational membership may have a different and broader set of requirements or criteria, perhaps more related to market needs, adoptability, political issues, etc.

Furthermore, if the specification is to carry the organization’s name, calling it e.g. “An XYZ Standard,” shouldn’t the entire organization have a say in its approval? And while the membership of the entire organization may have had the opportunity to participate in the developing committee, perhaps they weren’t interested or competent enough to do so.

Having multiple levels of approval also provides the opportunity for different criteria for voting eligibility. For example, voting in the development committee would generally be one vote per person, as it is individuals who are doing the development work regardless of who they are working for. But at the organizational level voting would be one vote per member company.

For purposes of ANSI requirements – or for any other organization that seeks to maintain balance in its approval process – membership in the consensus body, i.e. the body giving the final approval, must be balanced by interest category, e.g. manufacturer, vendor, implementer, user, or academic. It is sometimes difficult to get balance among participants who are interested in developing a specification; these are usually technical people from manufacturer or vendor members. So having two levels of approval allows the development committee to be dominated by technical people, while the final level of approval is given by a membership balanced among all types.

An issue that needs to be considered in bi-level voting, however, is when not enough of the entire organizational membership is interested or competent enough in a particular area to vote one way or the other. The organization may work on a variety of topics that, while somehow related, are not related enough to be of interest to everyone; any particular organizational member may be interested in some but not all of the specifications being created.

There are two ways to handle this situation. The first is to have a low threshold for approval. For example, the organization may only require that one quarter or one third of the membership approve the specification, as long as there are more affirmatives than negatives. Another is to define voting groups, where members declare their interest in a topic at the beginning of the work, and only the votes of those members are used to approve the work at the end.

With either of these solutions there is going to be the problem that it is only some small portion of the membership speaking on behalf of the entire organization, but the alternative is to require that members vote on something that they have no interest or competence in.

Several days ago I made some suggestions for improvement of the processes used for advancement of standards to international approval. In various blog articles I’ve been critical of the practice of stacking, where membership in a committee or other voting body suddenly increases just prior to an approval vote, and have suggested restricting the right to vote to those who have been involved in the committee for some period of time.

But on the other hand, I’ve also been a very vocal proponent of the principle of openness, defined in the U.S. Standards Strategy as “Participation is open to all affected interests,” and consensus, defined as “Decisions are reached through consensus among those affected.”

Am I contradicting myself? Is it a contradiction to suggest that all interested parties should be allowed to participate, yet participants should not be allowed to join at the last minute? What if they are interested in the topic and have something to say?

Let me suggest some reasons why this is not a contradiction, and why allowing last-minute voting eligibility is not a good idea.

First, if a person or group is truly interested in the topic or the work being done they probably would not have waited until the last minute to join. For committees at the development level, once the specification is completed and ready for vote it’s too late to be making new contributions. For example, a vote against a specification because it does not fill a particular requirement would have been prevented by that requirement having been communicated at the start of the development process. And for committees or bodies at higher approval levels, some amount of background or familiarity with the topic is required in order to make an educated decision.

In many cases the specification or other work under consideration may be of some length or technical complexity; it takes time to read and understand the specification, and having participated in the development of the work will help a participant understand how and why the specification defines things as it does. For levels of approval post development, a potential voter should have been involved long enough to be acquainted with the specification during its development and/or reviews. A considerable amount of work and discussion goes into the creation of most specifications; if the new participant isn’t acquainted with this discussion they may not have knowledge of all the issues involved.

At the very least, granting the same voting rights to someone arriving at the last minute as those given to someone who has been working on the topic for years devalues the contributions of the latter. In some respects a participant should have to prove his interest through the investment of effort over a period of time, either by participating in the development of the work or in taking the time to read and study the specification, participate in reviews of the work, or becoming acquainted with the issues related to the work.

The organization should be aware of the possibility that a late-joining voters have some hidden motivation. Are they, for example, participating in a scheme to “buy” votes? Granted, all participants have motives for participating in standards work; they participate because they seek to gain something from that standard, but generally that is accomplished by steering the direction of the work through participation in its development or reviews. A party that has no interest in a standard’s development but only in its final approval or disapproval may be suspect.

Finally, late joiners can cause problems within the committee going forward, even outside the scope of the standard being voted on. Most committees operate under a process that requires quorum before doing any sort of business or making any decisions, and if large numbers of new members join simply for a specific vote then drop out of sight after the vote, their continued presence on the membership roster of the committee will make it difficult or impossible for the committee to achieve quorum.

So I’ll suggest again that voting rights should be reserved for those who (in addition to other eligibility requirements the organization may have) have been members of the committee or group long enough to be acquainted with the work in question, and have been involved in enough of the discussions to be aware of the issues related to the work.

I wrote in January about ITU’s experiment in allowing free downloads of their standards in hopes of promoting adoption. Yesterday ITU announced that the program has been deemed a success.

Not only has the program resulted in a greater awareness of ITU work, but the no-charge policy is helping promote adoption in developing countries. Malcolm Johnson, Director of ITU’s Telecommunication Standardization Bureau (TSB) reported that “Last year exactly 500 ITU-T Recommendations had been sold to developing countries; this year, after allowing free access, they have downloaded some 300,000.”

ITU is to be congratulated for taking this step. For an organization that has gained a fair amount of revenue from the sales of standards, making these freely available was taking a big risk. But ITU has shown that the benefits of broader adoption, especially in markets that may have been discouraged by the price of purchasing the standards, is worth the change.

I read an interesting editorial at Wired.com by Bruce Schneier discussing single points of failure, using the recent NBA referee betting scandal as an example. Schneier suggests that a small number of players and a reliance on judgment calls by trusted individuals rather than quantitative measures put the system at risk. Vulnerabilities can exist in any system where a person has authority or access to privileged information, including referees, police officers, judges, TSA employees, stock brokers, or even computer repairmen.

There have been articles in the press lately suggesting that the greatest threat to enterprise security is from within; employees have access to company data and physical property, and can cause much greater damage than someone from outside. Think of the damage that could be inflicted on a company by a disgruntled IT sysadmin. (This is not new; military conquests going back to the dawn of recorded history have used traitor insiders to grant them access to a city when a siege had turned to a stalemate. And when a traitor cannot be found, a Trojan Horse can always be introduced.)

What has this got to do with standards? Plenty.

Standards activities are based on and assume a desire by all parties involved to work for the common good. While the participants each have their own motives – usually involving increased revenues for their company – they recognize that this is best achieved by working together to grow the size the pie through developing a standard around which they can all build products.

A great deal of trust is placed in small number of people in positions of authority, including committee chairs and process administrators. Participants should be able to trust other participants to play by the rules, make fair IPR disclosures, do their share of the work, and work for the good of the project. Participants should not need to be monitored closely, nor should anyone have to worry about watching their backs.

But we can’t always count on such a Pollyanna-ish situation; a rule book and a referee are required before a sandlot game can turn into the major leagues. Here’s a few things that should be done:

• Select committee chairs that are professional, fair, and technically competent, that can be relied on to provide leadership for the committee and follow the rules. The chair should have the ability to take off his or her company hat and act as a neutral party for the benefit of the committee’s work and the standards organization.
• The same goes for the organization’s standards administrator, only more so. This person monitors the activities of the organization’s committees to make sure that the rules are being followed. The administrator must know the rules and how to enforce them. Judgment calls must occasionally be made, so the administrator must be capable of making these in an impartial and consistent manner.
• Of course none of the above is possible if the organization does not have a good set of rules, the committee process document. It’s fine to work under the assumption that everyone will play nice together, but what happens when they don’t, or when some controversy arises? The standards administrator cannot enforce rules that don’t exist, and making it up as you go is not a good policy.
• The rules need to include an appeals process. What happens when a participant disagrees with something that the chair did, or the standards administrator? Who can she appeal to, and how? Who settles the dispute, and how?
• The organization needs to be very careful about fully documenting the standards development and approval process including archiving all email discussions, versions of documents, and ballots, and taking and retaining meeting minutes. If a question arises about how or whether something was done, whether as part of an appeal or audit or simply for a participant’s curiosity, historical records can save the day.

Doing the above will save the standards organization from the points of failure inherent in a system based on trust. Having competent leadership and a good set of rules will go a long ways towards ensuring the success of the standards activity.

If you’ve been following the progress of OOXML through Ecma and the fast track approval process at ISO you know that the approval vote over the weekend failed. There’s been a large number of bloggers tracking and commenting on the issue, so I don’t need to go into the details. Over the past few months I’ve contributed a few entries related to process in keeping with this blog’s theme of best practices; in this entry I’d like to wrap it up a bit.

The potential for ISO approval of OOXML isn’t over quite yet; there is still the possibility that the hundreds of submitted comments can be resolved at the February ballot resolution meeting and sufficient numbers of “No With Comment” votes be changed to “Yes,” but it sounds unlikely at this point.

So now that the game is (almost) over, it’s time to grab the popcorn and start the post-game analysis. Specifically, how did all this controversy happen, and what can or should be done to improve the situation the next time around? I suppose that depends a bit on whose camp you’re in; some may say that the process should be loosened to allow a submitted work to sail through the ISO approval process without so much fuss, but I am of the opinion that doing so would cheapen the value of ISO standards and the idea of standards in general.

The fast track process at ISO allows work created outside of ISO committees to be submitted to ISO for approval under its process to become an International Standard. This process recognizes that not all “worthy” work is being done at ISO but can come from any of a number of sources including consortia and other industry organizations. This is a good thing, in my opinion. I’ve been involved in doing this myself; in my work at OASIS we took advantage of this process and submitted OASIS-created and approved work to ISO and ITU for approval.

However, ISO has allowed a loophole in that, while work created under its own process must be created using the accepted principles of openness, balance, due process, transparency, etc., work it accepts from elsewhere has no such requirement. This is proved by the fact that a specification, in this case OOXML, created by a single vendor under a closed process without input from any other interested parties, was able to be accepted by and then submitted to ISO by an organization, in this case Ecma, which does not require an open process.

After submission of the specification to JTC1 it is then sent to the national bodies for six months for their review and vote. The first month is allowed for submission of “contradictions” by national bodies, but this term isn’t well defined. In the case of a contentious issue such as OOXML this caused a great deal of confusion with the various camps, pro and con, trying to use the undefined term to their advantage.

The following five months are allowed for the national bodies to comment on the specification and determine how they were going to vote. The national bodies themselves are allowed to determine which comments they will submit and how they will vote, but in the case of OOXML there were numerous allegations of vote stacking, disenfranchisement, and mismanagement of the voting process. While this is really the national bodies’ business, ISO and JTC1 should be concerned about how the vote is achieved.

If and when ISO and its JTC1 committee decide to re-evaluate their fast track process, and I hope that they do, here’s a few of my suggestions for them to consider:

• Specifications submitted for consideration for fast-track approval, must at their source have been developed under a process that follows the same principles of openness, balance, due process, transparency, etc. that the ISO process is based upon. And further, the organization submitting a specification to ISO must show that its approval and advancement of the work was done following those same principles with sufficient input and further development to show that the specification is an open work – in other words, no rubber stamping.
• Terminology used in the fast track process must be well defined.
• As part of the fast track process ISO and JTC1 should establish rules regarding how national bodies decide their vote, including for example that voting eligibility requires membership from the beginning of the comment period or for some significant period of time before the vote.
• To avoid the last-minute stacking of JTC1 itself, last-minute upgrades of memberships from non-voting to voting should not be allowed; only countries who were voting members at the time of the submission and during the entire six-month review period should be allowed to vote.
• Allegations of mismanagement or disenfranchisement will be investigated and if found true could result in loss of eligibility for some future period of time.

A voluntary consensus standards process works quite well when all parties are interested in cooperatively developing and approving work for everyone’s benefit. Many organizations have less-than-robust processes because they operate under the belief that everyone will work together for the common good. In most cases this is true. But even well thought out processes will have weaknesses and loopholes that are only discovered under extreme situations. In the few cases where the work becomes contentious, when market position and large amounts of money are at stake, it is wise for the organization to have a robust process that will provide a defense against parties trying to game the system.

I’ve written before about the qualifications and responsibilities of various kinds of participants in standards activities, including the committee members, chairs, and the organization’s standards administrator. There’s another player that I’d like to describe: the person at a member company who manages or coordinates the standards work and participation of the company’s various employees.

This person usually has the title of VP or Director of Standards and is responsible for ensuring that the company’s interests are being represented in standards activities. Companies participate in standards activities because doing so brings them some benefit. They get to help drive the direction of standards and hence their industry, have their technology turned into standards, and learn what others in the industry are doing. It helps them gain or retain a position on the leading or even bleeding edge of technology. All of this can be used to positively affect the company’s bottom line.

In small companies with just a few employees participating in standards coordinating their efforts is not difficult. But large enterprises with tens of thousands of employees overall may have hundreds of those employees participating in hundreds of committees at dozens of standards organizations. It’s a huge effort to manage and coordinate the efforts of these employees.

Why bother? Why not just give employees the freedom participate where they see fit, whether or not they can justify their efforts to their immediate manager? Consider the costs to the company of participating with regards to the employee’s time (salary), direct participation costs such as membership dues and travel to meetings, and the opportunity cost of the employee working on something other than e.g. product development, all multiplied by dozens or perhaps hundreds of employees. Consider the waste of costs associated with participating in the wrong committees at the wrong organizations. Further, consider the potential for employees disclosing proprietary information such as technology in development before the company is ready to release this information. Ultimately, though, why would you ever let employees do what they want, when they want, without managing them to ensure that they are making a positive contribution to the company?

The company needs to have a standards strategy with regards to what it is trying to accomplish by participating in standards activities, which activities to participate in, which and how many people to send to each activity and how much time to assign them to devote to these activities. The company may wish to not only participate at the technical level in committees but also to seek leadership opportunities within an organization in order to help set the strategy and direction for the organization.

This company standards strategy should not be set in an ad hoc manner by the individual employees. It may not even be set by the VP of Standards, but should be created by a team including upper management, product development, marketing, public relations, legal, government affairs, etc. It is the VP of Standards’ responsibility to ensure that this strategy is being followed, that the company’s activities are in line with this strategy.

This mission is complicated by the fact that the participating employees generally do not report directly to the VP of Standards. Rather, they are employees of various departments and divisions, and their salaries and other participation costs come out of various budgets. Perhaps the VP of Standards controls a budget for paying the membership dues of the standards organizations that the company has joined, in which case the VP can act as a gateway to control which organizations the company will participate in, but any control over the extent of participation will have to be coordinated with the managers of the employees. The departments and/or divisions of the company may have their own goals for participation, which may overlap or conflict with the overall company goals, and these must all be coordinated as well.

Monitoring the extent and quality of activities is a difficult task for the VP of Standards given the numbers involved, not just of employees but also of committees and organizations. How do you ensure that not only the right people are in the right committees, but that they are voting the way the company desires, that they are contributing only technology that the company is ready to contribute, they are not disclosing confidential or proprietary information – or even that they are actively participating and not using this as an opportunity simply to get out of the office?

The VP of Standards may wish to maintain a database of all company standards participants, and require periodic reports from the participants. Training of participants so that they are knowledgeable about the company’s standards strategy and legal/IPR policies is extremely useful. Access to document, email, and balloting archives at the standards organization may be requested in order to monitor company activities. But most important may be getting the various department and division managers to understand the importance of the company’s standards strategy and the necessity of following it and allowing the VP of Standards to have some level of control over their employees.

I’ve always had a thing for obscure collective nouns and units of measure. I suppose that you could call these standards – at least those terms that are somehow agreed upon and institutionalized. More likely they have simply grown out of long-time practice.

A collective noun is a term used to describe a group or multiple of anything, e.g. the “flock” in “flock of pigeons” or the “herd” in “herd of tourists.” Others include school of fish, litter of puppies, murder of ravens, nest of rabbits, parliament of owls, etc. I sometimes tease my kids by faking early-onset dementia and mixing these up, e.g. a herd of ducks. A great book on the subject (collectives, not dementia) is An Exaltation of Larks by James Lipton, who is now better known for interviewing celebrities on Inside the Actor’s Studio on the Bravo channel.

As for units of measure, we’re all familiar with the crazy English system of inches, feet, yard, miles; of teaspoon, ounce, pint, quart, gallon; and ounces (again), pounds, ton, etc. and of the more well thought out metric system where everything is related to each other by tens or tenths.

A short article in this month’s Wired magazine (Sept 2007, p. 58) discusses the effort to create a physical object that can be used as a reference definition of the kilogram. A sidebar lists some of the more commonly used units of measure including the meter, second, ampere, kelvin, mole, and candela. A second sidebar lists a few of the more obscure units of measure including the gou, nibble, twip, thrave, jansky, butt, and of course the infamous smoot, which is the length (or height) of Oliver Smoot, recently the chair of ANSI and president of ISO and who knows a thing or two about standards. (By the way, the Harvard Bridge between Cambridge and Boston is exactly 364.4 smoots and one ear long.)

A post at the Register web site is the immediate winner of my instantaneously created and judged “Best New Standard of 2007” contest. We’ve heard of the famous furloughs per fortnight, but what about the velocity of a sheep in a vacuum? Just as with the metric system, most of the new units are interrelated; this one uses the EU standard Florentine linguini (unboiled at sea level) as the base measure, moving up through double-decker busses and then on brontosauruses and the length of the universe.

However, I am still unable to find an acceptable definition for my all-time favourite unit of measure: just what is a grundle, anyway?

To follow up from the previous post about where to participate, let’s ask the question of where a company should choose to submit completed technical work for approval. Let’s say that your company, or perhaps you as an individual, has developed a specification, and would like to get it approved as a standard. Where do you take it?

As with the previous question, the answer depends a lot on what you intend to get out of the submission. At what level do you want your specification approved: at an industry, national, or international level? Do you expect the submission to sail through the approval process unchanged and as-is, or would you allow (or perhaps want or expect) that the organization to which you submit the specification will further develop it? And, what do you hope to gain by having the work approved: just the warm and fuzzy feeling of accomplishment, or perhaps the more valuable increase in adoption?

There are various criteria, and a number of questions you should ask yourself, when looking for a standards organization to submit your work to. First, of course, is whether the organization accepts work developed outside of the organization. And do they only accept submissions from members of the organization?

What are the IPR requirements for the submission? What declarations does the organization require with regards to associated patents and trademarks? What licensing terms does the organization require for patents associated with the specification? Who will own the copyright on the specification once the organization runs it through their process, the contributor or the organization?

What will the organization do with the submitted specification? Will they approve it as-is? Or does the organization’s process require that it undergo further development and review before approval? If the organization does additional work on the specification, what form will this take? Are the members of the organization technically qualified to do further development of the specification? Is the organization’s process conducive to positive improvement of the specification through technical work inside the committee combined with public review? What influence or control does the original submitter have on the direction of the work once the specification has been submitted?

(This is the dreaded “rubber stamping” question. There are organizations who have a reputation for approving submitted specifications with zero or minimal review and additional work, and some companies specifically seek out those organizations to approve their specifications which have been developed in-house without input from other interested parties. Operating in this manner is, in my opinion, a subversion of the standards process, which ideally should be based on the accepted principles of openness, balance, transparency, due process, etc. Accepting a “closed” specification into the standards process without further “open” development should not be considered as resulting in an “open” standard. Relinquishing control of the content of the submitted work is, or should be, the cost of pursuing approval of the work as a standard. If you don’t want to give up control and ownership, then call the specification a company-developed specification, but don’t call it an open standard.)

Next, what is approval by the standards organization worth? Does the organization have a good enough reputation in its industry that approval by the organization is recognized as something of value? Is the organization accredited or recognized by, or have official liaison with, national or international bodies so that specifications approved by the organization can be submitted for national or international approval?

What will the organization do with the specification once it is approved? Will it make it available to potential implementers, either for free or for sale? How easy will it be for interested parties to obtain a copy? (Assuming that your goal is for the specification to be implemented, you will want it to be as easy as possible for someone to get a copy of it.) What activities will the organization pursue to promote adoption? Will the organization organize educational events, conduct interoperability demonstrations, offer certification testing, etc.?

And finally, how will the organization maintain the standard over time? Will it guarantee a permanent archive of the standard? Will it assign the standard to a group or committee that is responsible for collecting and addressing comments from the public, and for revising and updating the standard over time?

As with the previous question of where to participate, there are no right answers to any of the above questions. Much depends on the goals that the initial developer has for the future of the specification. With the large number of standards organizations in existence there is a wide variety of operating policies and practices. The developer should research questions such as those above and come to his own conclusion whether the organization is the right one to submit work to.