Network Computer
Copyright © 1997 The Open Group

Profile Definition
Network Computer
X/Open Document Number: X975
ISBN:


Network Computer Profile

Scope

This document defines a Profile for the class of devices known as "Network Computers". It identifies a minimum set of requirements that must be met by a product in order to be formally recognized and registered as a Network Computer (NC).

This Profile differs from most other Open Group Profiles in that it fully specifies the Profile itself rather than referencing a separate function specification. As a consequence, its structure does not follow the conventional pattern of Open Group Profile Definitions.

Introduction

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, there will be a number of emerging technologies and potential standards, both open and proprietary, competing for acceptance. There will also be 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 would be beneficial if there were a common set of standards which facilitate a broad application base, interoperability, simple and unified system administration, end-user ease-of-use, and low cost of ownership.

This Profile Definition is designed to promote this objective. The Profile is intended to provide a common foundation of popular and widely used features and functions across a broad range of scaleable network computing devices, including personal computers. The specifications in this Profile are intended to be open standards that anyone can implement. The Profile encourages interoperability with servers and is designed to facilitate development of a broad application base to run on compliant devices. The Profile also provides guidelines to content and service providers for designing and building applications and other Internet content which will interoperate with Profile-compliant devices.

This Profile does not specify an implementation for a network computer, nor does it preclude additional features and functions outside the scope of the Profile. It is open, 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.

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 adhering to this Profile 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.

A variety of network computers will likely emerge in a number of different arenas. It is desirable that these network computers support a base 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 based upon the same common foundation of open systems standards.

Network computers are not intended to replace personal computers. Today's personal computers are fully capable of supporting this Profile. 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 Profile are intended to have the following attributes:

This Profile Definition is platform-independent. Any system that meets the defined functional requirements can be branded as conformant.

Note:
It is anticipated that the set of required features of the Network Computer will be increased incrementally over time, and that corresponding advanced versions of this Profile Definition will be introduced. Such advanced versions will not automatically supersede earlier versions.

Conceptual Architecture

The conceptual architecture described in this section 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 Network Computer Abstract Architecture , the required elements of the architecture are denoted by solid lines, and the optional elements by dotted lines.

Provide a User Interface

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.

Process URLs

When a user enters or selects a Uniform Resource Locator, this needs to be evaluated by the system. Depending upon the URL's scheme, different tasks will be performed:

Execute Java Applets

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.

Process and Present Resources

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.


Conformance Requirements

The Network Computer Profile Definition is platform-independent. Any product that meets the conformance requirements described in this document can be branded as conformant. A conformant product consists of a particular combination of hardware and software, and the specific product must therefore be uniquely identified in the Conformance Statement.

A single configuration of the product shall meet all the mandatory conformance requirements defined in this document. In addition to the mandatory requirements, conformant products may implement the optional services as they are defined in this Profile. Conformant products may also provide additional standards-based or proprietary services, as 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.

Unlike traditional Open Group Profile Definitions, this Profile does not rely solely upon Open Group specifications and formal standards for its specifications. Instead, it also contains specifications that are widely recognized in the industry as being de facto standards. The majority of these specifications are developed by the Internet Engineering Task Force (IETF). Where possible, hypertext links to the actual text of the specifications being referenced are provided.

Providing a User Interface

The product shall include hardware that provides the following User Interface characteristics:

Processing Uniform Resource Locators

Uniform Resource Locators (URLs), as defined in document IETF RFC 1738, Uniform Resource Locators (URL), are used to identify objects within the network to which the product is attached. While the aforementioned RFC is the definitive authority on URL construction and processing, some basic rules can be stated here:

URLs may be entered in an implementation-defined 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 product shall provide the appropriate service.

The remainder of this section describes the various schemes available, and how a conformant product will process each scheme. Where the processing of a scheme is optional, this is clearly indicated.

Transmit Resource Requests

When a URL of the scheme http: or https: 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 HTTP encapsulated within the Secure Sockets Layer Protocol (SSL), Version 2.0, February 9th, 1995, respectively. Both of these protocols shall be transmitted using the Transmission Control Protocol (see 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 ) to the user if the user made the request.

Send Mail

A conforming product 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: IETF RFC 822, Standard for the Format of ARPA Internet Text Messages. When such a URL is used, the product 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: ITEF RFC 821, Simple Mail Transfer Protocol, IETF RFC 1870, SMTP Service Extension for Message Size Declaration, and IETF RFC 1869, SMTP Service Extensions.

The structure of the transmitted message shall conform to the standards defined in Internet Standard 11, Format of Electronic Mail Messages: IETF RFC 822, Standard for the Format of ARPA Internet Text Messages and IETF RFC 1049, Content Type Header Field. 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. Such usage shall be documented in the product's Conformance Statement.

It is implementation-defined whether the messages are transmitted through an SMTP relay host, or whether messages are sent from the product directly to each recipient. The product's Conformance Statement shall identify the method that the product supports.

The product 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: IETF RFC 974, Mail Routing and the Domain System.

Note that a conforming product is only required to act as an SMTP client, sending messages to SMTP servers. It need not be able to receive incoming messages.

Select and Retrieve Files

A URL of the ftp: scheme has the format ftp : // username : password @ hostname : port / url-path. When a URL of this scheme is used, and the product supports the File Transfer option (see File Transfer ), the product shall attempt to open a connection with the host named by the hostname portion of the URL.

Establish and Conduct Virtual Terminal Sessions

A URL of the telnet: scheme takes the form telnet : // username : password @ hostname : port. If a URL of this scheme is used, and the product supports the Terminal Emulation option (see Terminal Emulation ), 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 product shall attempt to negotiate a login.

Processing and Presentation of Resources

When resources requested using the URL schemes http: and https: are sent to a conforming product, they will be transmitted using HTTP (encapsulated within SSL if https: was 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 resources character set encoding. This optional header may specify the character set of the following data. Conforming products shall support the ISO 8859-1:19871 character set. If no such header is received, a conformant product shall proceed as if the document is encoded using ISO 8859-1:1987.

Another header element is the Content-type:. Conforming products are required to evaluate this header to determine the resource's type, process the resource, and present it appropriately. Conforming products are required to process and present at least the following content types:

Executing Java Applets

A conforming product 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 (as defined above).

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.0.2 class libraries named "java.", and compiled using a Java byte code compiler equivalent to the one in Javasoft's JDK 1.0.2, shall execute without change on a conforming product.


Footnotes

1.
ISO 8859-1:1987, Information Processing - 8-bit Single-byte Coded Graphic Character Sets - Part 1: Latin Alphabet No. 1.

2.
ISO/IEC 10918-1:1994, Information Technology - Digital Compression and Coding of Continuous-tone Still Images - Part 1: Requirements and Guidelines.

Conformance Requirements for Optional Facilities

A product conforming to the Network Computer Profile can optionally provide the following facilities:

If such facilities are included they shall conform to the requirements identified below.

File Transfer

A 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: IETF RFC 959, File Transfer Protocol. This protocol is carried over Transmission Control Protocol (see Transmission Control Protocol ) connections. It is implementation-defined whether and under what conditions this connection is left open.

When the URL does not specify a username, then an implementation-defined 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.

Terminal Emulation

A 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: IETF RFC 854, Telnet Protocol Specification and IETF RFC 855, Telnet Option Specifications.

All communication with the remote system shall use the protocol specified in Internet Standard 8, Telnet Protocol: IETF RFC 854, Telnet Protocol Specification and IETF RFC 855, Telnet Option Specifications.

The Telnet protocol shall be carried over the Transmission Control Protocol (see Transmission Control Protocol ).


Conformance Requirements for Underlying Network Services

Products conforming to the Network Computer Profile are true Internet hosts. As such, they need to 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: IETF RFC 1122, Requirements for Internet Hosts - Communication Layers and ITEF RFC 1123, Requirements for Internet Hosts - Application and Support. Products conforming to this Profile shall adhere to the specific elements of this architecture as described below.

Transmission Control Protocol

Most of the services in this Profile require reliable, end-to-end connections for their execution. Consequently, they are defined to be implemented on top of the Transmission Control Protocol, or TCP. TCP defines a method for connection-oriented, end-to-end communications to take place over Internet Protocol-based networks. It is defined by Internet Standard 7, Transmission Control: IETF RFC 793, Transmission Control Protocol.

User Datagram Protocol

The Domain Name Service required in this Profile sends queries via the User Datagram Protocol (UDP) as defined in Internet Standard 6, User Datagram Protocol: IETF RFC 768, 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.

Internet Protocol

TCP sessions are conducted over Internet Protocol-based networks. Hosts on such networks, including conforming products of this Profile, shall adhere to Internet Standard 5, Internet Protocol, Version 4 (IPv4): ITEF RFC 791, Internet Protocol, IETF RFC 950, Internet Standard Subnetting Procedure, IETF RFC 919, Broadcasting Internet Datagrams, IETF RFC 922, Broadcasting Internet Datagrams in the Presence of Subnets, IETF RFC 792, Internet Control Message Protocol, and IETF RFC 1112, Host Extensions for IP Multicasting.

Note that this Profile does not specify the physical connection mechanism between a conforming product and a network. Nor does it specify the mechanism whereby an IP connection is first made via that physical connection. These mechanisms actually used by the product shall be identified in its Conformance Statement.


Additional Rendition Requirements

Some of the features identified in Conformance Requirements , Conformance Requirements for Optional Facilities and Conformance Requirements for Underlying Network Services have rendition ramifications, but do not yet have specific rendition requirements. The Open Group will develop a Rendition Requirements document for the Network Computer Profile. Conformance to the requirements in the Rendition Requirements document will be added to this Profile Definition as soon as it is available.

A condition of registering a product as conformant to this Profile Definition is that the licensee commits to amending the product, if necessary, to conform to the Rendition Requirements within six months of their publication. If The Open Group is not notified that conformance to the Rendition Requirements has been achieved by the end of the grace period, the product will be automatically de-registered.


Indicator of Compliance

At the time of publication no Indicator of Compliance has been specified for the Network Computer Profile. However, The Open Group intends to introduce a test suite as soon as possible. This test suite will become a mandatory Indicator of Compliance three months after it is formally released. Reference should be made to Test Suites and Test Laboratories, which is available from The Open Group Conformance Administrator, to ascertain whether the suite is now available, and whether the three month period has elapsed.


Migration

As the Network Computer Profile is new, there are no issues of migration from earlier versions.


Overriding Standards

All formal standards included within the Network Computer Profile are specified by a direct reference to the formal standard document itself.


Copyright ©June 1997, 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.


Motif®, OSF/1®, and UNIX® are registered trademarks and the "X Device"TM; and The Open GroupTM; are trademarks of The Open Group.


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:
OGSpecs@opengroup.org