Open Software Foundation H. Melman (OSF) Request For Comments: 79.0 February 1995 PST ACCEPTANCE CRITERIA 1. INTRODUCTION OSF uses the criteria in this document to evaluate PST proposals and to form a recommendation to the OSF Board of Directors for whether the proposal should be accepted. This document is meant to codify the OSF practices and to inform Authoring Groups of OSF's criteria. These criteria are based on OSF's principles and end-user and sponsor goals. 2. RELATIONSHIP WITH OTHER DOCUMENTS OSF is developing an architectural document known as the Open Information Infrastructure or OII. Ultimately this RFC will be a part of the OII and as such it refers to other sections of that document. Specifically it refers to the Roadbed which defines the common infrastructure that OSF supports for Open Systems. For example, in a given technology area (e.g., GUI's) it recommends Open Systems technologies to be used (e.g., Motif). There are several different classifications for technologies in the Roadbed, an important one is known as the Main Roadbed. It describes technologies that are clear choices in their area due to expected longevity, wide-spread deployment, maturity, quality, adherence to standards, and technical superiority. 3. APPLYING THESE CRITERIA OSF staff evaluates each PST proposal against all criteria. It is expected that all criteria be met at some point in the life of the technology. Note that due to business and time constraints, this does not mean that all criteria must be met in the initial release. Information about all criteria must be provided in the PST proposal, regardless of whether an individual item is met in the initial release. For example, if 64-bit support can't be addressed in the current release, information about plans for supporting it in the future must be included. In addition nothing in the initial release may preclude it's addition; e.g., an incompatible protocol change required to support it. Melman Page 1 OSF-RFC 79.0 PST Acceptance Criteria February 1995 OSF will remain as open to PST proposals as our members allow. As such, there are only a few strict criteria below. Some "reasonable" number of the others criteria must be met with the initial proposal, with all others not precluded and in fact planned for in future releases. 4. TECHNICAL CRITERIA These criteria apply mostly to the technical content of a PST proposal. There are other business requirements as well. For details see [PSTGUIDE]. (a) The deliverables for all PST's must include the following: (i) Specification (ii) Source code (implementation) (iii) Documentation (iv) Verification (test suites) In most cases, these parts are incomplete when the PST is proposed. However, the proposal must include a plan for completion of each part. Note that this criteria is relative to the scope of the PST. A PST could be for a test suite of some standard and the test suite code would be considered the source code. OSF is known for producing code and believes that this distinction greatly benefits the open systems industry, so specifications alone are not sufficient for a PST. (b) Proposals must be for portable, vendor-neutral technologies. All OSF offerings must be portable across a variety of platforms. This means that source code must be written so that it can run on many platforms, instead of being limited to one or only a few. Further, the technology must not be designed, and the source must not be written such that the technology runs significantly better on one platform than on others; it must be vendor-neutral. (Licensees are encouraged and expected to add value to their product versions in part by tuning technologies to their own platforms.) Other parts of a PST (specs, documentation, test suites) must likewise be portable and vendor-neutral. (c) Must be scalable to a variety of hardware platforms. The technology must have no architectural impediments to running on the spectrum of hardware platforms -- from PCs to Melman Page 2 OSF-RFC 79.0 PST Acceptance Criteria February 1995 mainframes. We accept that some (small) systems may not be able to fully support a particular technology, however a reasonable level of support must be provided for the system. For example, it might be reasonable to expect that PCs cannot be servers, but they should be able to be clients. (d) Must adhere to relevant industry standards or explain why such standards are not being used. Technologies must adhere to the standards that OSF members and licensees believe are relevant. The Roadbed defines which standards are judged relevant in various areas. In most cases, these are de jure standards, but there are cases when de facto usage outweighs a paper de jure standard. In the case of competing, conflicting standards, PST's must adhere to whichever one the roadbed specifies (if OSF has made that choice). (e) Must define the problem the PST is designed to solve and then provide information demonstrating how the PST actually does so. PST's need to demonstrate that they do what they say they do. To take an extreme (and unrealistic) example, if a PST claimed to solve all printing problems, and then actually only addressed dot matrix printing, the PST would not be recommended for approval. (It could be re-proposed as a dot matrix printing PST.) The text about a PST and the proposed implementation must match. Also, a PST is limited to the problem set that it describes. It must not provide additional unexpected functionality. For example if the same printing PST provided an entire distributed object oriented framework and 10 distributed services, it would not be recommended for approval. The PST could be re-proposed in a larger scope. (f) Either must provide new functionality or define the functionality being replaced (and provide a transition plan from the existing solution to the new one). In order to help move the industry toward common solutions, OSF will not offer multiple solutions for the same problem (except in cases of legacy support). However, improved solutions come along over time, and OSF must be able to accept technological advances and retire obsolete software. Any PST that provides updated solutions to a previously solved problem must identify which technology it is designed to replace. Such a PST must also include a transition plan for moving from the existing solution to the new one. (See also next requirement on coexistence.) Melman Page 3 OSF-RFC 79.0 PST Acceptance Criteria February 1995 An implication of this requirement is that proposed PST's must use applicable technologies in the Roadbed. For example, if a PST needed security support, it would have to use security as provided in DCE (since its in the roadbed) or extend that model rather than using a proprietary or other security system. (g) Should coexist with widely-deployed, relevant technologies. Although the goal of Open Systems is to move toward single, unified solutions, there are today multiple solutions in many areas. PST's should ensure that they can coexist with other relevant solutions (e.g., DCE RPC and ONC). Therefore, PST's should not be written such that they "break" other existing solutions. In addition, it's desirable for related technologies to be able to work with each other (e.g., DCE talking to Netware). This may require some bridging functionality on the part of the PST. (h) Should include support for pervasive, cross-technology issues including: (i) 16-bit through 64-bit scalability (ii) Common administration (iii) Internationalization (I18N) (iv) Multiprocessor-safety (v) Naming (vi) Security (vii) Threads-safety Some issues can not be dealt with in a single PST or single technology. Rather, they have an impact on nearly all technologies, and so support for them must be handled across PST boundaries. PST's should include support for these cross- technology issues, and where applicable must use the technologies described in the Roadbed to achieve this support. For example, in supplying I18N support, PST's must use API's defined in POSIX and the X/Open Portability Guide (XPG). The need for common administration is complicated by the fact that there is no universally accepted management framework. Lacking this, OSF technologies should be administrable via secure and scalable means with consideration to existing administrative solutions. Common administrative actions such as user, host, and data management; backups and restorations; and monitoring all should be possible using reasonable (i.e., Melman Page 4 OSF-RFC 79.0 PST Acceptance Criteria February 1995 not overly complex or time consuming) and secure means. (i) Must coexist with Main Roadbed technologies. OSF technologies must fit together. Licensees want to be able to take different OSF technologies and use them together. For example, it is highly desirable to be able to write one application that uses Motif and DCE on top of an OSF/1 system. All PST's must at least coexist with if not make use of existing Main Roadbed technologies. (j) Should make use of Roadbed technologies as appropriate. In addition to coexisting with main Roadbed technologies, PST's should be well integrated with relevant Roadbed technologies. OSF technologies may depend on other Roadbed technologies. There may be cases when technologies require the presence of other OSF technologies in order to work. This is permitted, but such dependencies must be documented in a PST proposal. (k) Should define open interoperable protocols for use in heterogeneous environments. Where appropriate, there needs to be a protocol layer for clients and servers that defines how they talk to each other. This protocol layer needs to be independent of system-specific characteristics such as those that might be present in an OS or a transport layer. (l) Should be for either enabling or non-competitive technology. OSF technologies should not impinge on areas in which the industry should be free to provide different, competing solutions. OSF technology is typically middleware infrastructure or commodity applications. Examples of commodity applications are `xclock' or `xcalc' which offer basic functionality that users expect to be provided with their systems. (m) Must exhibit an acceptable level of quality and performance. PST's must define quality and performance criteria, as well as measurement methods to be used in assessing whether the criteria have been met. (n) Should demonstrate some level of technical superiority. In the case of emerging technologies, OSF may receive competing PST proposals. Assuming the proposals solve the same problem and adhere to other criteria, they will be evaluated on their technical superiority. Melman Page 5 OSF-RFC 79.0 PST Acceptance Criteria February 1995 (o) All information submitted as part of a PST must be in American English. Since English is the language that the largest majority of OSF members understand (either as a first or second language), all information provided as part of a PST must be in American English. This obviously includes specifications and documentation, but also includes human-language-sensitive parts of source code (e.g., comments, some variable names, etc.). (p) Must document known restrictions. A PST must document whether there is anything in the proposed technology that would be difficult or impossible to change in a follow-on release (e.g., protocol limitations, binary compatibility promises, use of a specific technology without a layer of abstraction, etc.). 5. ACKNOWLEDGEMENTS This RFC is based on drafts originally written by Sandra Martin O'Donnell and presented to the Architecture Planning Council for review. REFERENCES [PSTGUIDE] The PST Process: A Practical Guide, Open Software Foundation, Cambridge, Massachusetts. Available via: `http://www.osf.org:8001/pst/index.html'. Send questions to Ken Flowers (e-mail: flowers@osf.org). AUTHOR'S ADDRESS Howard Melman Internet email: melman@osf.org Open Software Foundation Telephone: +1-617-621-8989 11 Cambridge Center Cambridge, MA 02142 USA Melman Page 6