| Profile Definition |
|---|
| Network Computer |
| X/Open Document Number: X975 |
| ISBN: |
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.
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.
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.
In
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, this needs to be evaluated by the system. Depending upon the URL's scheme, different tasks will be performed:
If the Terminal Emulation (see
If the File Transfer (see
URLs using the mailto: scheme will allow the composition and transmission of mail using the Simple Mail Transfer Protocol.
URLs using the http: or https: schemes will be sent to the specified host using the HTTP or Secure Socket Layer Protocol, 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 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.
The product shall include hardware that provides the following User Interface characteristics:
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:
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: IETF RFC 1034, Domain Names - Concepts and Facilities and IETF RFC 1035, Domain Names - Implementation and Specification.
These queries are sent using the User Datagram Protocol (see
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.
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
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
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.
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
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
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:
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 HTML 3.2, HTML 3.2 Reference Specification.
When processing resources of this type, a conforming product shall do the following:
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 ISO/IEC 10918-1:1994.2 A conforming product shall accept data in the file format specified in the JPEG File Information Format (JFIF) Specification, as defined in ISO/IEC 10918-1:1994. 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 bgcolor="#FFFFFF"-part that is of a content type supported by the product (including at least the set described here) shall be processed in turn.
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.
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.
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
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.
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
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.
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.
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.
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.
Some of the features identified in
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.
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.
As the Network Computer Profile is new, there are no issues of migration from earlier versions.
All formal standards included within the Network Computer Profile are specified by a direct reference to the formal standard document itself.
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 Groupor by electronic mail to:
Apex Plaza
Forbury Road
Reading
Berkshire, RG1 1AX
United Kingdom
OGSpecs@opengroup.org