L2/00-245R
Subject: Comments requested on the structure and working of JTC1
August 10, 2000
From: NCITS/L2
This paper asks for suggestions on how to deal with SC voting issues and membership criteria in the new participation mode.
L2's initial recommendation would be to open the SC participation to industrial consortia and academic organizations. Working at that level would allow both corporate and academic interests real input into the standard-making, where they choose to participate, but would keep the corporate competition and/or academic infighting in their appropriate arenas, and not just import all that into the SC's as well.
Within that context, we think the industrial consortia (and related groups like the IETF) should be seated at the table as *full* voting members, along with the NB's. In the arena of character encoding, this would mean that the Unicode Consortium would be a full member of SC2, and would *vote* on 10646 -- not just send in liaison statements about it.
We think going this route could be considered to be gradualist enough by the NB's that it could be a consensus position about participation.
A rather radical recommendation:
In concert with the other re-engineering efforts, JTC1 has the opportunity to bring a number of other specifications from other consortia under the ISO standard umbrella. This has the prospect of benefiting ISO by making a broader range of standards available, and allowing a much more timely development of standards.
The proposal is to allow JTC1 to designate other organizations as being completely responsible for certain specific standards. For example, the W3C could designated as the responsible organization for, say, "ISO 99999 -- XML Schema". The designated organization would be completely responsible for the development and maintenance of that standard, with the ability to issue updates, revisions, and corrigenda to that standard, on its own schedule.
This procedure goes beyond the limitations of the PAS process. A consortium such as W3C spends years in development of a specification like XML Schema. To face the prospect of going through the ISO process, even on a fast-track, in order to make any change to the specification is too great a burden for the outside consortium. Moreover, the prospect of any changes to a specification that has reached consensus, typically after a long and arduous process of compromise within the organization, is not acceptable. Even if the vote is simply up or down, without allowing changes, the prospect of having a update version of the specification being rejected after it has been approved by the consortium is also not acceptable.
While such a change may seem radical to some, it has the opportunity to bring a variety of specifications back under the ISO umbrella, and allow ISO to take advantage of the wealth of outside technical expertise.
This paper requests input of the proposed changes to the JTC 1 structure.
The main focus of these proposed changes are a streamlining of the organization to have merely an executive group (much like JTC 1 today) and then technical groups (which would do all the technical work in an area -- combining what the SC's and WG's do now, with less bureaucratic process and more freedom of operation).
In L2's opinion, this is a good thing to do, for our area of concern. SC2, WG2, WG3 would be organizationally merged. Informal working groups could still be maintained, presumably, but would no longer have layered formal reporting responsibilities, and sequential voting by WG2 and then by SC2 could be eliminated. The entire technical group would meet and do its work and make its decisions, instead of the now rather farcical situation with WG2 meeting and passing a bunch of resolutions, which then get handed over to SC2, where most of the same people meet, declare it is o.k. for WG2 to do what it wants to do, and pass a bunch of resolutions allowing that, which they then pass on to JTC1.
The main danger in this is the squabble over who formally controls the work of the new technical group. The technical group would have to resolve the situation of currently have an SC chair and two WG convenors into a situation with one formal committee with one chair. It is conceivable that this could end up being resolved in such a way that working with the new technical group becomes *more* difficult for the Unicode Consortium, rather than easier. In that case, we'd be better off maintaining what we currently have!
On the other hand, merging all this work together might be the key to finally shutting down the autonomous and seemingly unstoppable work of WG3 at churning out more 8-bit character encoding standards, in favor of focusing all JTC 1 character encoding on the UCS.
A minor comment on the list of major responsibilities of a Technical Group. It currently states that it would be responsible for "Establishment of liaisons with other JTC 1 Technical Groups". It is clear to me that this should be broadened to include liaisons to other standardization bodies outside JTC 1 and to other interested organizations that do not choose to directly participate in the Technical Group as full members. We see no reason to clamp down the formal communication to just within the JTC 1 context. We can see the executive group wanting to maintain control over liaison with other "ISO and IEC groups outside of JTC 1", so that they can deal with inter-group turf squabbling in the arena of ISO/IEC management, but we would reserve directly to the Technical Groups responsibility for communication with groups outside the overarching ISO context.
This paper asks for input of funding the JTC 1 program, and points out that Secretariats will continue to be held by National Bodies.
However, in the particular case of SC2 we should note that, given the way reorganizations like this are likely to proceed, it is rather likely that the Secretariat for the new Technical Group dealing with character encoding (along with internationalization, possibly) is likely to be the Japanese NB, simply because the SC2 Secretariat is the Japanese NB, and that will be easier all around for everybody to transition to. This may (or may not) have a bearing on how funding would have to be set up.
This document asks for input on the establishment of Maintenance Teams to replace the current systematic five-year review of standards by a more flexible approach.
L2 is not sure whether the establishment of Maintenance Teams would result in less overhead or more. But in the area of character encoding standards, it would be nice if essentially finished standards -- in particular the 8-bit encodings -- could be tossed over the wall, so to speak, and be given "archival" status, so that they would not come up for review unless actively excavated for some reason by the Technical Group. Perhaps NCITS could contribute some suggestions in this regard, since it has been recently working on means and procedures for archiving frozen old standards, so that they don't have to be constantly reviewed and rubber-stamped (or withdrawn) when no one wants to change anything in them.
L2 suggestions:
1. Use the NCITS process for "archived standards" to reduce the need for periodic reviews of standards that meet certain criteria (see attached excerpt from the NCITS process manual SD-2)
2. Maintenance teams for fast-tracked standards should be recruited mainly form the organization that submitted the standard.
--end of document--