Network Computer Technical
Standard
Copyright © 1998 The Open Group
| Technical Standard |
|---|
| Network Computer |
| Document Number: C720 |
| February 1998 |
©February 1998, The Open Group All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the prior permission of the copyright owners.
Any comments relating to the material contained in this document may be submitted to The Open Group at:
The Open Group
Apex Plaza
Forbury Road
Reading
Berkshire, RG1 1AX
United Kingdom
or by electronic mail to:
The Open Group is the leading vendor-neutral, international consortium for buyers and suppliers of technology. Its mission is to cause the development of a viable global information infrastructure that is ubiquitous, trusted, reliable, and as easy-to-use as the telephone. The essential functionality embedded in this infrastructure is what we term the IT DialTone. The Open Group creates an environment where all elements involved in technology development can cooperate to deliver less costly and more flexible IT solutions.
Formed in 1996 by the merger of the X/Open Company Ltd. (founded in 1984) and the Open Software Foundation (founded in 1988), The Open Group is supported by most of the world's largest user organizations, information systems vendors, and software suppliers. By combining the strengths of open systems specifications and a proven branding scheme with collaborative technology development and advanced research, The Open Group is well positioned to meet its new mission, as well as to assist user organizations, vendors, and suppliers in the development and implementation of products supporting the adoption and proliferation of systems which conform to standard specifications.
With more than 200 member companies, The Open Group helps the IT industry to advance technologically while managing the change caused by innovation. It does this by:
The Open Group operates in all phases of the open systems technology lifecycle including innovation, market adoption, product development, and proliferation. Presently, it focuses on seven strategic areas: open systems application platform development, architecture, distributed systems management, interoperability, distributed computing environment, security, and the information superhighway. The Open Group is also responsible for the management of the UNIX trademark on behalf of the industry.
This process includes the identification of requirements for open systems and, now, the IT DialTone, development of Technical Standards (formerly CAE and Preliminary Specifications) through an industry consensus review and adoption procedure (in parallel with formal standards work), and the development of tests and conformance criteria.
This leads to the preparation of a Product Standard which is the name used for the documentation that records the conformance requirements (and other information) to which a vendor may register a product.
The "X" Device is used by vendors to demonstrate that their products conform to the relevant Product Standard. By use of the Open Brand they guarantee, through the X/Open Trade Mark Licence Agreement (TMLA), to maintain their products in conformance with the Product Standard so that the product works, will continue to work, and that any problems will be fixed by the vendor.
The Open Group publishes a wide range of technical documentation, the main part of which is focused on development of Technical Standards and product documentation, but which also includes Guides, Snapshots, Technical Studies, Branding and Testing documentation, industry surveys, and business titles.
There are several types of specification:
The Open Group Technical Standards form the basis for our Product Standards. These Standards are intended to be used widely within the industry for product development and procurement purposes.
Anyone developing products that implement a Technical Standard can enjoy the benefits of a single, widely supported industry standard. Where appropriate, they can demonstrate product compliance through the Open Brand. Technical Standards are published as soon as they are developed, so enabling vendors to proceed with development of conformant products without delay.
CAE Specifications and Developers' Specifications published prior to January 1998 have the same status as Technical Standards (see above).
Preliminary Specifications have usually addressed an emerging area of technology and consequently are not yet supported by multiple sources of stable conformant implementations. They are published for the purpose of validation through implementation of products. A Preliminary Specification is as stable as can be achieved, through applying The Open Group's rigorous development and review procedures.
Preliminary Specifications are analogous to the trial-use standards issued by formal standards organizations, and developers are encouraged to develop products on the basis of them. However, experience through implementation work may result in significant (possibly upwardly incompatible) changes before its progression to becoming a Technical Standard. While the intent is to progress Preliminary Specifications to corresponding Technical Standards, the ability to do so depends on consensus among Open Group members.
The Open Group publishes specifications on behalf of industry consortia. For example, it publishes the NMF SPIRIT procurement specifications on behalf of the Network Management Forum. It also publishes Technology Specifications relating to OSF/1, DCE, OSF/Motif, and CDE.
Technology Specifications (formerly AES Specifications) are often candidates for consensus review, and may be adopted as Technical Standards, in which case the relevant Technology Specification is superseded by a Technical Standard.
In addition, The Open Group publishes:
This includes product documentation - programmer's guides, user manuals, and so on - relating to the Pre-structured Technology Projects (PSTs), such as DCE and CDE. It also includes the Single UNIX Documentation, designed for use as common product documentation for the whole industry.
These provide information that is useful in the evaluation, procurement, development, or management of open systems, particularly those that relate to the technical Standards. The Open Group Guides are advisory, not normative, and should not be referenced for purposes of specifying or claiming conformance to a Product Standard.
Technical Studies present results of analyses performed on subjects of interest in areas relevant to The Open Group's Technical Program. They are intended to communicate the findings to the outside world so as to stimulate discussion and activity in other bodies and the industry in general.
As with all live documents, CAE Specifications require revision to align with new developments and associated international standards. To distinguish between revised specifications which are fully backwards compatible and those which are not:
Readers should note that Corrigenda may apply to any publication. Corrigenda information is published on the World-Wide Web.
Full catalogue and ordering information on all Open Group publications is available on the World-Wide Web.
This document is the Technical Standard for the class of devices known as Network Computers. It defines the minimum set of requirements which must be met by a product in order for that product to conform to an Open Network Computer: Foundation Product Standard.
The first release of the Network Computer specification was published as the Network Computer Profile, Document Number X975, June 1997. Now, this Network Computer Technical Standard - which was also known during its development as NC1.1 - supersedes the Network Computer specification contained in document X975. Similarly, the referenced Open Network Computer: Foundation Product Standard supersedes the conformance requirements contained in document X975.
Motif®, OSF/1®, and UNIX® are registered trademarks and the IT DialToneTM, The Open GroupTM, and the "X Device"TM, are trademarks of The Open Group.
The following documents are referenced in this standard:
This document provides the technical specification for the class of devices known as Network Computers (Network Computer). It identifies the minimum set of requirements which must be met by a product in order for that product to conform to the referenced Open Network Computer - Foundation Product Standard.
A rich heritage of open systems standards in a dynamic and heterogeneous computing environment led to the evolution of the Internet and network computing as it now exists.
As the focus on the Internet, Intranets, and this network computing environment continues to increase, a number of emerging technologies and potential standards will emerge, both open and proprietary, competing for acceptance. Along with this will come a growing variety of network-attached devices, which will implement various combinations of these standards.
As consumers, developers, manufacturers, corporations, education, government, service providers, and others, approach this complex and sometimes confusing landscape, it will be beneficial if a common set of standards exists which facilitates:
This Technical Standard is aimed at promoting this objective. It provides an entry-level definition for an Network Computer, to define common sets of popular and widely used features and functions across a broad range of scaleable network computing devices, including personal computers. It is flexible, architecturally neutral, and is intended to facilitate the growth of network computers while helping to protect investments made by customers and by content, system, service, and application providers. It encourages interoperability with servers, and facilitates development of a broad application base to run on compliant devices. It also provides guidelines to content and service providers for designing and building applications, and other Internet content which will interoperate with Network Computer devices which are standards-compliant.
This Technical Standard does not define a complete implementation for a Network Computer, nor does it preclude provision of additional features and functions outside the scope of this Technical Standard.
Network Computers are expected to be highly scaleable and to span a product range from the palmtop to the desktop. They attach to the network and interoperate with other network nodes and network content in an IP-based network. They are end-user devices.
Network Computers conforming to this Technical Standard support a common Java-based execution environment, enabling network-resident applications, as well as stand-alone applications, to execute on them. They are typically dependent on the network, but may offer stand-alone functionality.
This Technical Standard defines an open standard which can be fully implemented from the information included and referenced by this document. There is no dependency on any other information or proprietary technology.
Network Computers (Network Computer) are not intended to replace Personal Computers (PC). Today's Personal Computers are fully capable of satisfying the requirements of this Technical Standard. However, unlike Personal Computers, Network Computers are designed from the outset with the network, Internet, and Intranets in mind. Additionally, Network Computers which comply with this Technical Standard are intended to have the following attributes:
All formal standards included within this Technical Standard are specified by a direct reference to the formal standard document itself.
These are identified in the list of Referenced Documents.
A Network Computer product that meets the functional requirements as defined in the relevant Open Network Computer Product Standard can be submitted with an application to The Open Group for award of the corresponding Open Network Computer Brand.
Any Network Computer product which satisfies the mandatory parts of this Technical Standard may expect to satisfy the conformance requirements for the Open Network Computer Brand. If any optional facilities defined in this Technical Standard are included in a Network ComputerC product, then those facilities must be implemented as defined in this Technical Standard.
Conformant products may also provide additional standards-based or proprietary services, so long as the mandatory conformance requirements continue to be met, or an environment in which these requirements are met can be configured by a user.
In all cases, the definitive conformance requirements are specified in the applicable Open Network Computer Product Standard.
Information on how to apply for award of an Open Network Computer Brand can be obtained from The Open Group's Network Computing Public Web page.
The conformance requirements for a Network Computer product are defined in an Open Network Computer Product Standard.
It is clear that the market will demand a variety of Network Computer products to satisfy the differing requirements in a number of market areas.
It is desirable that all these Network Computers support a foundation level of functionality and standards, and that classes of devices, which may provide unique features and functions specific to their particular market, do so consistently, and where possible are based upon the same common foundation of open systems standards.
Accordingly, future versions of this Network Computer Technical Standard will define additional functionality.
As the set of etwork Computer functional components increases, new Open Network Computer Product Standards will be generated, to define conformance requirements for higher-functionality Network Computer products. In addition, one Product Standard may call up other Product Standards, so enabling various combinations of functionality to be defined. Thus, a range of Open Network Computer Product Standards will emerge, to meet market demand for the Open Network Computer Brand for various configurations of Network Computer products, for general use, and for specific vertical markets. These Product Standards will coexist.
The following terms have special meaning in this document:
This describes a permissible optional feature or behavior available to the user or application; all systems support such features or behavior as mandatory requirements.
The value or behavior is not consistent across all implementations. The provider of an implementation normally documents the requirements for correct program construction and correct data in the use of that value or behavior. When the value or behavior in the implementation is designed to be variable or customisable on each instantiation of the system, the provider of the implementation normally documents the nature and permissible ranges of this variation. Applications that are intended to be portable must not rely on implementation-dependent values or behavior.
With respect to implementations, the feature or behavior is optional. Applications should not rely on the existence of the feature. To avoid ambiguity, the reverse sense of may is expressed as need not, instead of may not.
This describes a requirement on the application or user.
This means that the behavior described is a requirement on the implementation and applications can rely on its existence. See also "will".
With respect to implementations, the feature is recommended, but it is not mandatory. Applications should not rely on the existence of the feature.
With respect to users or applications, the word means recommended programming practice that is necessary for maximum portability.
A value or behavior is undefined if this document imposes no portability requirements on applications for erroneous program constructs or erroneous data. Implementations may specify the result of using that value or causing that behavior, but such specifications are not guaranteed to be consistent across all implementations. An application using such behavior is not fully portable to all systems.
A value or behavior is unspecified if this document imposes no portability requirements on applications for correct program construct or correct data. Implementations may specify the result of using that value or causing that behavior, but such specifications are not guaranteed to be consistent across all implementations. An application requiring a specific behavior, rather than tolerating any behavior when using that functionality, is not fully portable to all systems.
This means that the behavior described is a requirement on the implementation and applications can rely on its existence.
The following conceptual architecture description illustrates the basic capabilities of a Network Computer and how they relate to one another.
Note that this is an abstract architecture, and is in no way meant to describe the inner workings of any particular Network Computer, nor is it meant to dictate implementation. Instead, it is meant to help the reader understand how the various elements of a Network Computer might work together.
Figure: Network Computer Abstract Architecture
In this Figure, the required elements of the architecture are denoted by solid lines, and the optional elements by dotted lines.
Conforming products are required to provide a set of capabilities that together make up the interface between the system's user and the system services.
When a user enters or selects a Uniform Resource Locator (URL), this needs to be evaluated by the system. Depending upon the URL's scheme, different tasks will be performed:
If the Terminal Emulation option is supported by the product, URLs using the telnet: scheme will cause a virtual terminal session between the user's system and the specified host to be established using the Telnet Protocol.
If the File Transfer option is supported by the product, URLs using the ftp: scheme will cause files, or lists of file names, to be obtained using the File Transfer Protocol.
URLs using the mailto: scheme will allow the composition and transmission of mail using the Simple Mail Transfer Protocol (SMTP).
URLs using the http: or https: schemes will be sent to the specified host using the HTTP or Secure Sockets Layer Protocol (SSL), respectively.
The resources referenced by URLs using the http: or https: schemes are received by the system and their contents made available for processing.
When a Java bytecode file is referenced through the HTML <APPLET> tag, that bytecode file will be retrieved via the HyperText Transfer Protocol and executed.
Resources that are requested via the URL http: or https: schemes have content types. These content types will cause them to be processed in different ways prior to rendering them to the product's output devices.
The Network Computer is platform-independent. It consists of a particular combination of hardware and software.
This chapter specifies the mandatory features for a conformant Network Computer product. Optional Facilities defines optional facilities which may be included.
Unlike most existing specifications from The Open Group, this specification does not rely solely upon other specifications from The Open Group along with standards issued from formal standards bodies. Instead, it also references specifications that are widely recognized in the industry as being de facto standards. The majority of these specifications have been developed by the Internet Engineering Task Force (IETF).
The Network Computer shall include hardware that provides the following User Interface characteristics:
Uniform Resource Locators (URLs), as defined in IETF RFC 1738, Uniform Resource Locators (URL), are used to identify objects within the network to which the Network Computer is attached. While the aforementioned RFC is the definitive authority on URL construction and processing, it is useful to list some basic rules here:
The hostname portion of a URL shall be translated into that host's Internet Protocol address by querying a name server using the protocol defined in Internet Standard 13, Domain Name System:
These queries are sent using the User Datagram Protocol over an Internet Protocol.
URLs may be entered in an implementation-dependent manner using the text input capability, or may be selected using a hypertext link in a displayed HTML resource that contains the tag <A HREF=>...</A>. When the user enters or selects a URL, they are said to be "using" that URL. When a URL is used, the Network Computer shall provide the appropriate service.
The remainder of this section describes the various schemes available, and how a conformant Network Computer will process each scheme. Where the processing of a scheme is optional, this is clearly indicated.
When a URL of the scheme http: is used, a request for the resource shall be transmitted using the protocol defined in IETF RFC 1945, Hypertext Transfer Protocol - HTTP/1.0, or using the protocol defined in IETF RFC 2068, Hypertext Transfer Protocol - HTTP/1.1. If a URL of the scheme https: is used, the HTTP/1.0 or HTTP/1.1 request shall be encapsulated within the Secure Sockets Layer Protocol (SSL), Version 2.0, February 9th, 1995. All of these protocols shall be transmitted using the Transmission Control Protocol.
Resources returned in response to a transmitted request shall be made available for processing directly to Java Applets (see Processing and Presentation of Resources), or to the user if the user made the request. The implementation shall be able to process responses that are encoded using either HTTP/1.0 or HTTP/1.1 protocols.
The Network Computer sends mail when a URL of the scheme mailto: is used. These URLs have the form mailto : <rfc822-addr-spec>, where <rfc822-addr-spec> is as defined in Internet Standard 11, Format of Electronic Mail Messages:
When such a URL is used, the Network Computer shall do the following:
The message shall be transmitted to the recipient(s) using the protocol defined in Internet Standard 10, Simple Mail Transfer Protocol:
The structure of the transmitted message shall conform to the standards defined in Internet Standard 11, Format of Electronic Mail Messages:
The transmitted messages may also use the extensions defined in IETF RFC 1521, MIME (Multipurpose Internet Mail Extensions) - Part 1: Mechanisms for Specifying and Describing the Format of Internet Message Bodies.
It is implementation-dependent whether the messages are transmitted through an SMTP relay host, or whether messages are sent from the product directly to each recipient.
The Network Computer shall determine the Internet Protocol address of the hostname of each message recipient using the Domain Name Service as described in Processing Uniform Resource Locators. However, the Internet Protocol address shall be determined by using the method specified in Internet Standard 14, Mail Routing and the Domain System:
Note that a conformant Network Computer is only required to act as an SMTP client, sending messages to SMTP servers. It need not be able to receive incoming messages.
A URL of the ftp: scheme has the format:
When a URL of this scheme is used, and the product supports the File Transfer option, the Network Computer shall attempt to open a connection with the host named by the hostname portion of the URL.
A URL of the telnet: scheme takes the form:
If a URL of this scheme is used, and the product supports the Terminal Emulation option, a virtual terminal connection to the host named in the hostname portion of the URL shall be opened. If a username and password are specified, then the Network Computer shall attempt to negotiate a login.
When resources requested using the URL schemes http: and https: are received, they must be transmitted to the Network Computer using HTTP (encapsulated within SSL if https: is used).
When such resources are sent, the header portion of the resources can contain several pieces of information.
One such piece is a declaration of the resource's character set encoding. This optional header may specify the character set of the following data. The ISO 8859-1:1987 character sets shall be supported. If no such header is received, the Network Computer shall proceed as if the document is encoded using ISO 8859-1:1987.
Another header element is the Content-type: . The Network Computer evaluates this header to determine the resource's type, process the resource, and present it appropriately. The Network Computer must process and present at least the following content types:
Text/plain shall be rendered on the display as plain text.
Text/html shall be processed and the results rendered on the display in accordance with the rules of the HyperText Mark-up Language (HTML) defined in the HTML 3.2 Reference Specification.
When processing resources of this type, the Network Computer shall:
Image/gif shall be decoded in accordance with the Graphics Interchange Format Specification (GIF), Version 89a, and the results rendered on the display.
Image/jpeg shall be decoded in accordance with the specification in ISO/IEC 10918-1:1994 Information technology - Digital compression and coding of continuous-tone still images: Requirements and guidelines. A conforming product shall accept data in the file format specified in the JPEG File Information Format (JFIF) specification; this is contained in ISO/IEC 10918-4:1992. The results of decoding such a resource shall be rendered on the display.
Audio/basic shall be processed and sent to the audio device in accordance with the Audio File Information Format (.au), Sun Microsystems, and the results emitted through the product's audio output device.
Audio/x-wav shall be processed and sent to the audio output device in accordance with the MMIO_5, Waveform Structures (files), encapsulated as RIFF Waveform Audio Format, Microsoft.
Multipart/mixed shall be processed in accordance with the definition in IETF RFC 1521, MIME (Multipurpose Internet Mail Extensions) - Part 1: Mechanisms for Specifying and Describing the Format of Internet Message Bodies, as refined by the definitions in IETF RFC 1945, Hypertext Transfer Protocol - HTTP/1.0. Each boundary-separated body-part that is of a content type supported by the Network Computer (including at least the set described here) shall be processed in turn.
The Network Computer shall provide a set of services that permit the execution of pre-compiled applications that use the Java Virtual Machine. This environment consists of two parts: the Java Virtual Machine and the Java Class Libraries.
The Java Class Libraries shall support referencing URLs with content types of audio/basic, audio/x-wav, image/gif, and image/jpeg.
The product requirements necessary for support of the execution of Java Applets are given in the following documents:
Applications developed in the Java Programming Language, using only those classes defined in Javasoft's JDK 1.1 class libraries named "java.", and compiled using a Java byte code compiler equivalent to the one in Javasoft's JDK 1.1, shall execute without change on a conforming product.
A Network Computer can optionally provide the following facilities:
If such facilities are provided they shall conform to the specification defined in this Technical Standard.
A Network Computer product that supports the File Transfer option shall provide access to directories and files using the protocol defined in Internet Standard 9, File Transfer Protocol:
This protocol is carried over Transmission Control Protocol connections. It is implementation-dependent whether and under what conditions this connection is left open.
When the URL does not specify a username, then an implementation-dependent username shall be used.
When the URL does not specify a password and a password is required for access to the referenced resource, the user shall be prompted for one.
When the URL does not specify a port, port 21 shall be used.
When the url-path component of the URL refers to a directory, the names of the files in that directory shall be presented on the display.
When the url-path component of the URL refers to a file, the contents of that file shall be retrieved:
The file transfer facilities shall support the transfer of both raw (IMAGE) and translated (ASCII) format files.
A Network Computer product that supports the Terminal Emulation option shall provide access to remote systems by terminal emulation using the Telnet protocol.
All interaction with the user shall conform to the required rendition behavior specified in Internet Standard 8, Telnet Protocol:
All communication with the remote system shall use the protocol specified in Internet Standard 8, Telnet Protocol:
The Telnet protocol shall be carried over the Transmission Control Protocol.
The Network Computer is a true Internet host. As such, it must adhere to the basic standards that permit the interoperability of all hosts on the Internet.
The basic architecture and behavior of such hosts are described in Internet Standard 3, Requirements for Internet Hosts:
The Network Computer shall adhere to the specific elements of this architecture as described in this Technical Standard.
Most of the services for the Network Computer require reliable, end-to-end connections for their execution. Consequently, they are defined to be implemented on top of the Transmission Control Protocol (TCP).
TCP defines a method for connection-oriented, end-to-end communications to take place over Internet Protocol-based (IP) networks. It is defined by Internet Standard 7, Transmission Control:
The Domain Name Service required in the Network Computer sends queries via the User Datagram Protocol (UDP) as defined in Internet Standard 6, User Datagram Protocol:
over Internet Protocol-based networks. UDP is a connectionless protocol designed for lightweight communication. UDP messages can also be sent and received by Java Applets.
TCP sessions are conducted over Internet Protocol-based networks. Hosts on such networks, including products which conform to an Open Network Computer Product Standard, shall adhere to Internet Standard 5, Internet Protocol, Version 4 (IPv4):
Note that this Network Computer specification not specify the physical connection mechanism between the Network Computer and a network. Nor does it specify the mechanism whereby an IP connection is first made via that physical connection.
Rendition requirements are defined in the Network Computer Rendition Requirements specification.
See also the Terminology section for common english words which have special meaning in this document.
A Network Computer which is awarded the Open Network Computer Brand is registered as conformant to the applicable Network Computer Product Standard. The Open Network Computer Brand represents a guarantee that the product to which it applies conforms to the applicable Product Standard, will continue to do so, and carries a vendor guarantee that it will be brought into conformance if in the future it is found not to be conformant. This guarantee is underwritten by a trademark law agreement between the vendor and The Open Group.
Hypertext Mark-up Language
Hypertext Transfer Protocol
Internet Engineering Task Force
The ability of software and hardware on multiple machines and from multiple vendors to communicate effectively.
International Standards Organization
Network Computer
The document that defines the conformance requirements that a Network Computer product must satisfy in order to be awarded an Open Network Computer Brand.
Personal Computer
Uniform Resource Locator