Network Computing Client Technical Standard
Copyright © 1998 The Open Group


Frontmatter

Technical Standard
Network Computing Client
Document Number : C801

© 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
Apex Plaza
Forbury Road
Reading
Berkshire, RG1 1AX
United Kingdom
or by electronic mail to:
OGSpecs@opengroup.org

Contents

Preface
   The Open Group
   Development of Product Standards
   Open Group Publications
   Versions and Issues of Specifications
   Corrigenda
   Ordering Information
   This Document
   Structure
   Trademarks
   Referenced Documents

1.   Introduction
1.1.   Scope
1.2.   Positioning
1.3.   Separation of Management and User/Application Features
1.4.   Network Computing Clients and PCs
1.5.   Overriding Standards
1.6.   Compliance Considerations
1.6.1.   Conformance
1.6.2.   Brand Program
1.7.   Terminology

2.   Conceptual Architecture
2.1.   Providing a User Environment
2.2.   Processing URLs
2.2.1.   Establishing and Conducting Virtual Terminal Sessions
2.2.2.   Selecting and Retrieving Files
2.2.3.   Sending E-Mail
2.2.4.   Transmitting Resource Requests/Receiving Requested Resources
2.3.   Viewing E-Mail
2.4.   Executing Java Bytecode
2.5.   Processing and Presentation of Resources
2.6.   Answering SNMP Queries
2.7.   Underlying Network Services

3.   Management Features
3.1.   Starting the Implementation
3.1.1.   Permanently Connected Systems
3.1.2.   Occasionally Connected Systems
3.2.   User Authentication
3.3.   User Configuration View and Modification
3.4.   Selecting a Printer
3.5.   Answering SNMP Queries
3.6.   Providing a File System

4.   User and Application Portability Features
4.1.   Providing a User Environment
4.1.1.   Selecting and Executing Java Applications
4.1.2.   Selecting the User's Locale
4.1.3.   Selecting the Default Character Encoding for Incoming Text Resources
4.2.   Processing Uniform Resource Locators
4.2.1.   Establishing and Conducting Virtual Terminal Sessions
4.2.1.1.   Telnet Terminal Sessions
4.2.1.2.   TN3270 Terminal Sessions
4.2.2.   Selecting and Retrieving Files
4.2.3.   Sending Electronic Mail
4.2.4.   Transmitting Resource Requests
4.3.   Viewing Electronic Mail
4.3.1.   Email Client Interface Capabilities
4.3.2.   Message Access
4.4.   Executing Java Bytecode
4.5.   Providing a Distributed Object Environment
4.6.   Processing and Presentation of Resources
4.6.1.   Processing of Encapsulated Resources
4.6.1.1.   Java Applets
4.6.1.2.   In-line Images
4.6.1.3.   Background Images
4.6.1.4.   ECMAScript Scripts
4.7.   Underlying Network Services
4.7.1.   Transmission Control Protocol
4.7.2.   User Datagram Protocol
4.7.3.   Internet Protocol
4.7.4.   Secure Sockets Layer (SSL)

5.   Rendition Requirements

6.   User Authentication Protocol
6.1.   Introduction
6.2.   Basic Authentication
6.2.1.   Issues with Basic Authentication
6.3.   Secure Authentication
6.3.1.   Issues with Secure Authentication
6.4.   Root Certificates

A.   Glossary


Preface

The Open Group

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.

Development of Product Standards

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 Open Brand Trade Mark License 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.

Open Group Publications

The Open Group publishes a wide range of technical documentation, the main part of which is focused on specification development 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:

In addition, The Open Group publishes:

Versions and Issues of Specifications

As with all live documents, Technical Standards and 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:

Corrigenda

Readers should note that Corrigenda may apply to any publication. Corrigenda information is published on the World-Wide Web at http://www.opengroup.org/corrigenda.

Ordering Information

Full catalog and ordering information on all Open Group publications is available on the World-Wide Web at http://www.opengroup.org/pubs.

This Document

This document provides the technical specification for the class of devices that act as clients in a network computing environment. It defines a collection of features and, where appropriate, specific subsets of those features that implementations are required to support. If a product supports a feature defined in this specification, it is required to do so in a manner consistent with the requirements of this specification. Whether a product is required to support specific features is defined in the related product standard(s).

The first release of this document was published as the Network Computer Profile, Document Number X975, June 1997. That release was superseded by the Network Computer CAE Specification issue 1.1, document number C720, published February 1998. Similarly, the Network Computer Product Standard issue 1.1, document number X98NC, published February 1998 superseded the conformance requirements contained in X975.

Structure

Trademarks

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.

Referenced Documents

This section contains an alphabetized list of all the specifications referenced by this specification. In the on-line version of this document, each entry is linked to its formal entry in The Open Group Standards Information Base ().

Adobe Portable Document Format version 1.2

Audio File Information Format (.au), Sun Microsystems

Cascading Style Sheets, level 1

Common Object Request Broker Architecture

Complete MIDI 1.0 Detailed Specification

Graphics Interchange Format Specification (GIF), Version 89a

HTML 3.2 Reference Specification

HTML 4.0 Reference Specification

HTTP 1.1 specification

IETF RFC 768, User Datagram Protocol

IETF RFC 791, Internet Protocol

IETF RFC 792, Internet Control Message Protocol

IETF RFC 793, Transmission Control Protocol

IETF RFC 821, Simple Mail Transfer Protocol

IETF RFC 822, Standard for the Format of ARPA Internet Text Messages

IETF RFC 854, Telnet Protocol Specification

IETF RFC 855, Telnet Option Specifications

IETF RFC 919, Broadcasting Internet Datagrams

IETF RFC 922, Broadcasting Internet Datagrams in the Presence of Subnets

IETF RFC 950, Internet Standard Subnetting Procedure

IETF RFC 959, File Transfer Protocol

IETF RFC 974, Mail Routing and the Domain System

IETF RFC 1034, Domain Names - Concepts and Facilities

IETF RFC 1035, Domain Names - Implementation and Specification

IETF RFC 1049, Content Type Header Field

IETF RFC 1112, Host Extensions for IP Multicasting

IETF RFC 1122, Requirements for Internet Hosts - Communication Layers

IETF RFC 1123, Requirements for Internet Hosts - Application and Support

IETF RFC 1179, Line Printer Daemon Protocol

IETF RFC 1521, MIME (Multipurpose Internet Mail Extensions) - Part 1: Mechanisms for Specifying and Describing the Format of Internet Message Bodies

IETF RFC 1647, TN3270 Enhancements

IETF RFC 1738, Uniform Resource Locators (URL)

IETF RFC 1869, SMTP Service Extensions

IETF RFC 1870, SMTP Service Extension for Message Size Declaration

IETF RFC 1945, Hypertext Transfer Protocol - HTTP/1.0

IETF RFC 2001, TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms

IETF RFC 2008, Implications of Various Address Allocation Policies for Internet Routing

IETF RFC 2060, Internet Mail Access Protocol - version 4

IETF RFC 2068, Hypertext Transfer Protocol - HTTP/1.1

IETF RFC 2131, Dynamic Host Configuration Protocol (DHCP)

Internet Standard 3, Requirements for Internet Hosts

Internet Standard 5, Internet Protocol, Version 4 (IPv4)

Internet Standard 6, User Datagram Protocol

Internet Standard 7, Transmission Control

Internet Standard 8, Telnet Protocol

Internet Standard 9, File Transfer Protocol

Internet Standard 10, Simple Mail Transfer Protocol

Internet Standard 11, Format of Electronic Mail Messages

Internet Standard 13, Domain Name System

Internet Standard 14, Mail Routing and the Domain System

Internet Standard 15, A Simple Network Management Protocol (SNMP)

Internet Standard 17, Management Information Base for Network Management of TCP/IP-based internets: MIB-II

Internet Standard 33, Trivial File Transfer Protocol (TFTP)

Internet Standard 51, Point to Point Protocol

Internet Standard 53, Post Office Protocol - version 3

ISO/IEC 6429:1992, Information Technology -- Control Functions for Coded Character Sets [spec]

ISO/IEC 8859-1:1987

ISO/IEC 9594-8:1995

ISO/IEC 10918-1:1994 JPEG

ISO/IEC 10918-4:1998 JFIF

ISO/IEC 13818-2:1996 MPEG-2

ISO/IEC 14772-1:1998 Information Technology -- Computer Graphics and Image Processing -- The Virtual Reality Modeling Language -- Part 1: Functional Specification and UTF-8 Encoding

ISO/IEC 16262:1998 - ECMAScript: A general purpose, cross-platform programming language

Java Virtual Machine Specification

Java Platform 1.1 Core API

MMIO_5, Waveform Structures (files)

Network Computer CAE Specification issue 1.1

Network Computer Product Standard issue 1.1

Portable Network Graphics Specification (PNG), Version 1.0

Protocols for Interworking: XNFS - Version 3W

RIFF Waveform Audio Format, Microsoft

Secure Sockets Layer (SSL V3.0) Protocol


1. Introduction

1.1. Scope

This document provides the technical specification for client systems in a network computing environment.

1.2. Positioning

A rich heritage of open systems standards in a dynamic and heterogeneous computing environments 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 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 that 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 a definition of the features that might be present on an implementation, and where appropriate specifies what options associated with those features are required to be supported when the feature is supported. 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 conformant implementations. It also provides guidelines to content and service providers for designing and building applications, and other Internet content which will interoperate with compliant products.

This specification 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 specification.

Products are expected to be highly scalable 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 specification support a common HTML & 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 is an open systems specification, meaning that it defines an open standard which can be fully implemented from the information included in this document and referenced by this document. It has no dependency on any other information or proprietary technology.

1.3. Separation of Management and User/Application Features

It is useful to separate the features of network computing clients into

1.4. Network Computing Clients and PCs

Network Computing Clients are not intended to replace personal computers. Today's personal computers are fully capable of satisfying the requirements of this specification. However, unlike traditional personal computers, network computing clients are designed from the outset with the network, Internet, and Intranets in mind. Additionally, network computing clients are intended to have the following attributes:

1.5. Overriding Standards

All formal standards included within this specification are specified by a direct reference to the formal standard document itself.

These are identified throughout the specification, and are also collected in Referenced Documents.

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 are developed by the Internet Engineering Task Force (IETF). Other key specifications have been developed by Sun Microsystems.

1.6. Compliance Considerations

1.6.1. Conformance

A conformant implementation is a collection of services that conform to the requirements defined in the associated Product Standard (see Brand Program).

For the purposes of this standard, a conformant system is the combination of a software implementation and the hardware on which it is running, that together make available the services defined in this standard. Note that it is possible that an implementation is wholly software, and that it is executing on an arbitrary piece of hardware. In such a case, the system is that hardware and the software implementation.

A conformant product is an instantiation of a conformant system.

1.6.2. Brand Program

A product that meets the functional requirements as defined in the relevant Product Standard can be submitted with an application to The Open Group for award of the corresponding Brand.

Any product which satisfies the elements of a Product Standard defined as mandatory may expect to satisfy the conformance requirements for the Brand. If any facilities defined in this specification are included in a product, then those facilities must be implemented as defined in this specification.

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 Product Standard.

The process to apply for award of a Brand is described in information linked from the associated Brand Program's public Web page (http://www.opengroup.org/nc/).

1.7. Terminology

The following terms are used in this Technical Standard:


2. Conceptual Architecture

The conceptual architecture described in this chapter illustrates the basic capabilities of a network computing client 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 product, nor is it meant to dictate implementation. Instead, it is meant to help the reader understand how the various elements of an implementation might work together. Finally, note that this chapter does not contain any normative requirements. The requirements for the features mentioned in this chapter are fully defined in subsequent chapters or in other referenced documents.

Conceptual Architecture
Figure: Abstract Architecture

2.1. Providing a User Environment

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. This User Environment includes the following capabilities:

2.2. Processing URLs

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

2.2.1. Establishing and Conducting Virtual Terminal Sessions

URLs using the telnet: scheme will cause a telnet session between the implementation and the specified host to be established. A user can also elect to establish a terminal session between the implementation and a specified host using either the Telnet or TN3270 protocols through an implementation-defined method.

2.2.2. Selecting and Retrieving Files

URLs using the ftp: scheme will cause files, or lists of file names, to be obtained using the File Transfer Protocol.

2.2.3. Sending E-Mail

URLs using the mailto: scheme will allow the composition and transmission of mail using the Simple Mail Transfer Protocol (SMTP).

2.2.4. Transmitting Resource Requests/Receiving Requested Resources

URLs using the http: or https: schemes will cause requests to be sent to the specified host using the HTTP or Secure Socket Layer (SSL) protocol, respectively.

Those requests will result in the resources referenced by the URLs being received by the system and their contents being made available for processing.

2.3. Viewing E-Mail

The user can elect to view their electronic mail.

2.4. Executing Java Bytecode

When a Java bytecode file is referenced through the HTML <APPLET> element, that bytecode file will be retrieved via the HyperText Transfer Protocol and executed as a Java applet within the context of the HTML browser. When a Java bytecode file is selected by the user through an implementation-defined mechanism, it will be executed as a Java application.

2.5. Processing and Presentation of 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.

2.6. Answering SNMP Queries

When a query is directed at an implementation using the SNMPv1 protocol, the implementation responds with the requested information.

2.7. Underlying Network Services

All the services provided by an implementation depend upon a variety of network services.

3. Management Features

This chapter describes features that are components of a complete Network Computing environment, but that are either:

For purposes of identification, this collection of features is known as the "Management Feature Group".

3.1. Starting the Implementation

When the Management Feature Group is supported, an implementation needs to perform certain functions when it starts up (for example, boots or is launched). While many of these start-up functions are implementation dependent, their general structure is specified here:

3.1.1. Permanently Connected Systems

If the implementation uses a dedicated network connection (for example, a hard-wired network connection), it is said to be "permanently connected". Such an implementation shall support start-up through the following protocol: An implementation uses DHCP to obtain configuration information such as its IP address. The implementation shall be capable of using the following fields and options when they are made available by the DHCP Server:

DHCP fields

DHCP options Any additional required parameters are implementation-defined.

Based upon the information discovered through DHCP, the implementation may then retrieve additional implementation-defined data using Internet Standard 33, Trivial File Transfer Protocol (TFTP) or any other protocols from among those defined in this standard.

3.1.2. Occasionally Connected Systems

If the implementation does not use a dedicated network connection, it must use some other mechanism (for example, a modem or a serial cable) to connect to a network. Such an implementation shall use the Point-to-Point protocol to establish a dynamic connection: Such a dynamic connection will require at least the same information as a permanently connected system would have discovered using DHCP. It is implementation-defined how this information is obtained by the product.

3.2. User Authentication

When the Management Feature Group is supported, an implementation shall support user authentication using the User Authentication Protocol (see User Authentication Protocol). The implementation uses this protocol to confirm that the user has provided the correct password for a specific username (solicited in a implementation-defined manner from the user). It shall be possible to configure a conformant product so that no authentication is required.

Details of the protocol and its requirements are available in Chapter 6.

If authentication is enabled on a conformant product, users shall be asked to authenticate themselves at the beginning of each session.

All actions performed by the implementation on behalf of an authenticated user shall be performed using the privileges associated with that user. That is, the implementation (and systems to which the implementation is connected) checks that the operations the user requests are allowed by the user's privileges and relevant security settings. Note that if no authentication is required, the only operations allowed should be those allowed to anyone with physical access to the system.

3.3. User Configuration View and Modification

When the Management Feature Group is supported, the implementation shall permit the persistent setting of user preferences such as the choice of a printer and the selection of user locale (see below). These preferences settings are stored in an implementation-defined manner.

3.4. Selecting a Printer

When the Management Feature Group is supported, the implementation shall provide access to a printer to which the user can send output. It is implementation-defined whether this access is to a printer physically connected to the system, or to a printer accessible via the network. If the implementation supports access to network printers, it must do so using the protocol defined in IETF RFC 1179, Line Printer Daemon Protocol.

3.5. Answering SNMP Queries

When the Management Feature Group is supported, a conformant product shall respond to network management queries that are targeted at the implementation. The product requirements necessary for support of these queries are defined in the following documents: The implementation shall respond to SNMP requests for relevant MIB-II elements. During startup, the implementation shall send an SNMP coldStart trap to (at least) the local network broadcast address on the well-known SNMP port 162.

3.6. Providing a File System

When file access is supported, the characteristics of the file system shall be as defined in Executing Java Bytecode.

When the Management Feature Group and remote file access is supported, the file system shall be accessed via the protocol(s) specified in Protocols for Interworking: XNFS - Version 3W.


4. User and Application Portability Features

This chapter describes features that ensure a consistent environment for which application developers can produce content, and in which users of conforming products can work.

4.1. Providing a User Environment

In the context of a Network Computing Client, the User Environment consists of certain minimum hardware characteristics and certain functions that effect the operating environment on a per-user basis. The hardware characteristics for an implementation are defined in the associated Product Standard(s). The environmental functions are defined in this section:

4.1.1. Selecting and Executing Java Applications

When Java Application Execution is supported, the implementation shall provide a mechanism where the user can view a set of available Java Applications, select one (or more), and cause them to execute. The exact mechanism for doing this is implementation-defined.

4.1.2. Selecting the User's Locale

The user shall be able to select the locale in which they prefer to view system messages and interact with the system from a set of implementation-defined locales that shall include at least the English locale for the United States (defined as "en_US" in the 1.1 version of the Java class libraries for internationalization). This selection shall be persistent for the user - being restored each time the user is authenticated (for example, logs on) to an implementation.

4.1.3. Selecting the Default Character Encoding for Incoming Text Resources

The user shall be able to select the default character encoding for incoming "text/" resources that are requested using the http: or https: schemes from an implementation-defined list of encodings that includes at least the encoding ISO/IEC 8859-1:1987.

4.2. Processing Uniform Resource Locators

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 implementation is connected. While the aforementioned RFC is the definitive authority on URL construction and processing, it is useful to list some basic rules 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 element <A HREF=>...</A>. When the user enters or selects a URL, they are said to be "using" that URL. When a URL that references a resource of a type required to be supported is used, the implementation shall provide the appropriate service.

The remainder of this section describes the various schemes available, and how a conformant product will process each scheme.

4.2.1. Establishing and Conducting Virtual Terminal Sessions

4.2.1.1. Telnet Terminal Sessions

When telnet terminal sessions are supported, a URL of the telnet: scheme takes the form
telnet : // username : password @ hostname : port.
When the URL does not specify a port, port 23 shall be used. If a URL of this scheme is used 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 implementation shall attempt to negotiate a login. A telnet session shall also be able to start in an implementation-defined way through explicit user action.

Terminal emulation for such a session shall be done using one of an implementation-defined, user selectable set of terminal types that includes at least the type ANSI as defined in ISO/IEC 6429:1992, Information Technology -- Control Functions for Coded Character Sets [spec] in a window that accommodates at least 80 columns and 24 rows of rendered mono-spaced characters.

Interaction with the user shall conform to the required rendition behavior specified in Internet Standard 8, Telnet Protocol:

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

4.2.1.2. TN3270 Terminal Sessions

When TN3270 terminal sessions are supported, they shall be started in an implementation-defined way, through explicit user action.

Interaction with the user shall conform to the required rendition behavior specified in IETF RFC 1647, TN3270 Enhancements. This specification requires support for Internet Standard 18 (above), and is carried over the Transmission Control Protocol (see Transmission Control Protocol).

4.2.2. Selecting and Retrieving Files

When the ftp: scheme is supported, the implementation shall process a URL of the format
ftp : // username : password @ hostname : port / url-path.
by attempting to open a connection with the host named by the hostname portion of the URL using the protocol defined in Internet Standard 9, 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.

4.2.3. Sending Electronic Mail

When the implementation supports sending electronic mail, composition of a new message can be initiated through an implementation-defined explicit user action, or through the selection of a URL using the mailto: scheme. 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: Whether such a URL is used, or whether the user explicitly requests to compose a new message, the implementation 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-defined whether the messages are transmitted through an SMTP relay host, or whether messages are sent from the product directly to each recipient, or whether this is selectable by the user.

If the messages are transmitted directly to each recipient, the implementation 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 the support for sending messages via these protocols does not imply a corresponding ability to receive messages via these protocols.

4.2.4. Transmitting Resource Requests

The implementation shall support URLs of the scheme http:. When this scheme is used, a request for the resource shall be transmitted using either 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. Which of these protocols is used to transmit requests is implementation-defined. The conformant product will accept responses (at least) in the format in which the request was sent. However, since the server to which the request is sent may support a variety of protocols, the following algorithm shall be used by conformant products that have chosen to send requests using 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 (SSL V3.0) Protocol (see Secure Sockets Layer).

All 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 and Applications (see Processing and Presentation of Resources), or to the user if the user made the request.

4.3. Viewing Electronic Mail

When viewing of electronic mail is supported, conformant products permit the viewing of electronic mail when that service is selected by the user via implementation-defined explicit user action.

4.3.1. Email Client Interface Capabilities

An email client is used to view electronic messages that have been sent to the current user of the system. These capabilities must include the following basic services:

4.3.2. Message Access

In order for electronic messages to be viewed, they need to be accessed. The method for retrieving messages is implementation-defined, but shall use either Internet Standard 53, Post Office Protocol - version 3 or IETF RFC 2060, Internet Mail Access Protocol - version 4.

4.4. Executing Java Bytecode

Conformant products shall 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, image/png, and image/jpeg, as defined in Processing and Presentation of Resources.

The product requirements necessary for support of the execution of Java Applications and Applets are given in the following documents:

Applets developed in the Java Programming Language, using only those classes defined in the Java class libraries (version 1.1) named "java.*", extending the java.applet.Applet class, and encoded in Java bytecode as defined in the Java Virtual Machine Specification, shall execute without change on a conforming product from within the product's HTML browser when it encounters an <APPLET> element that references the pre-compiled class file.

When the implementation supports the execution of Java Applications, such applications developed in the Java Programming Language, using only those classes defined in the Java class libraries (version 1.1) named "java.*", and encoded in Java bytecode as defined in the Java Virtual Machine Specification, shall execute without change on a conforming product. The mechanism by which users select Java applications for execution is implementation-defined.

When the implementation makes a file system available to Java Applications and Applets, that file system shall have the following characteristics:

Even though an implementation makes a file system available, security restrictions may restrict Applet access to that file system.

4.5. Providing a Distributed Object Environment

When an implementation provides access to a distributed object environment, it shall do so through the Java Language binding to The Open Group's Common Object Request Broker Architecture Product Standard. This product standard supports the development of objects that act as peers to other objects, both locally and elsewhere on the network.

4.6. Processing and Presentation of Resources

When resources requested using the URL schemes http: and https: are received, they are transmitted to the implementation using HTTP (encapsulated within SSL if https: is used).

When such resources are received, 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/IEC 8859-1:1987 character sets shall be supported. If no such header is received, the implementation shall proceed as if the document is encoded using the user's chosen default encoding for text/ streams. If the user has not chosen a default encoding, the implementation shall proceed as if the document is encoded using ISO/IEC 8859-1:1987.

Another header element is the Content-type: . The implementation evaluates this header to determine the resource's type, process the resource, and present it appropriately. A variety of content types are available:


4.6.1. Processing of Encapsulated Resources

In some instances, resources received following HTTP requests may contain references to other resources that must be loaded, or may contain sections that require additional interpretation. The following types of encapsulated resources are defined by this specification:

4.6.1.1. Java Applets

When an <APPLET> element that references a Java applet is encountered, the system shall load and execute the referenced Applet (see Executing Java Bytecode).

4.6.1.2. In-line Images

When an <IMG> element or an <INPUT> element with a TYPE attribute of "image" is present and refers to a resource of content-type image/gif, image/png, or image/jpeg, the resource shall be requested and, when received, rendered as appropriate.

4.6.1.3. Background Images

When a <BODY> element that contains a BACKGROUND attribute is present, and that attribute refers to a resource of content-type image/gif, image/png, or image/jpeg, the resource shall be requested and, when received, rendered as appropriate.

4.6.1.4. ECMAScript Scripts

When ECMAScript is supported, and a <SCRIPT> element with the LANGUAGE attribute set to "ECMAScript" or "Javascript" is encountered, the system shall interpret the contained script as per the requirements defined in ISO/IEC 16262:1998 - ECMAScript: A general purpose, cross-platform programming language.

Scripts developed using only the interfaces and services defined in the ECMAScript specification shall execute without change on a conforming product from within the product's HTML browser.
 

4.7. Underlying Network Services

A conformant product is a true Internet host. As such, it must adhere to the 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 implementation shall adhere to the specific elements of this architecture as described in this section.

4.7.1. Transmission Control Protocol

Most of the services of a conforming implementation 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:

Two other useful, non-normative references on TCP are:

4.7.2. User Datagram Protocol

Some services send queries via the User Datagram Protocol (UDP). It is defined in Internet Standard 6, User Datagram Protocol: over Internet Protocol-based networks. UDP is a connectionless protocol designed for lightweight communication.

4.7.3. Internet Protocol

TCP sessions are conducted over Internet Protocol-based networks. The implementation shall adhere to Internet Standard 5, Internet Protocol, Version 4 (IPv4): Note that this specification does not specify the physical connection mechanism between the product and a network.

4.7.4. Secure Sockets Layer (SSL)

Many of the services of a conforming implementation require secure socket connections. Consequently, they are defined to be implemented on top of the Secure Sockets Layer(SSL). SSL is defined by: The specific list of cipher suites required to be supported by conforming products is defined in the associated product standard(s). It is necessary to require support of specific cipher suites to ensure system and application interoperability and portability.

5. Rendition Requirements

Some of the features identified in Management Features, User and Application Portability Features, and Underlying Network Services have rendition ramifications. These are specified in the associated Rendition Requirements specification.

6. User Authentication Protocol

6.1. Introduction

This chapter defines a protocol for use in authenticating users. The protocol is defined with two levels of security: basic and secure. Both levels use standard mechanisms available in all WWW browsers and servers today and thus are equally accessible to all vendors.

A simplifying assumption is that the implementation and its servers are both located within the same intranet (an IP domain contained within and administered by a single organizational entity). This is no different from the assumption made when using NIS, RAP, or PCNFSD (other, historical protocols designed to do approximately the same thing as this User Authentication Protocol). Because of this assumption, the implementation can trust responses it receives from the DHCP service and it can trust that its boot image is correct and safe to use. The DHCP service points the implementation to an authentication service and the boot image either contains public keys used for authentication or implements a mechanism for retrieving the public keys from local persistent store.

Clients must implement several levels of authentication security to enable the implementation to be introduced into existing organizations whose needs or resources are such that fully secure authentication is not required. The implementation shall have a facility (for example, using the DHCP vendor specific option) to allow the system administrator to configure the implementation such that it uses one of the following authentication policies:

The exact mechanism for this specification is implementation-defined.

No authentication is useful for kiosk and similar applications. Fallback is useful in situations where it is unknown whether the authentication service is configured for secure authentication but it is desired that the user be authenticated before being granted network access.

6.2. Basic Authentication

Basic Authentication uses the authentication mechanism defined in the HTTP 1.1 specification. It works as follows: Note that if vendors add key/value pairs, they should isolate the keys within their own name space by preceding them with a unique string (for example vendor MyCompany might add MyCompany.ldap.server).

6.2.1. Issues with Basic Authentication

Typical WWW servers implement authentication databases within access control lists (ACLs) attached to documents or document directories. This presents a problem for organizations with already existing user authentication facilities. It means that the ACLs must be populated with the same data kept in the original authentication databases. Not only does this not scale well, but it requires the organization to maintain two parallel authentication databases. To overcome this, it is recommended that the authentication service either be implemented as a unique service (that is, not a general purpose web document server), or that a WWW server be used that can forward authentication requests to the existing facility either through a CGI, servelet, or similar interface.

Basic Authentication transmits the user's password in a fashion where the plaintext can be easily be recovered. Organizations are encouraged to use Secure Authentication whenever possible in order to protect their sensitive or valuable information.

6.3. Secure Authentication

Secure Authentication is the same as Basic Authentication except that the authentication transaction is encapsulated in a SSLv3 session.

The name/address of the authentication server is obtained as defined above. However, the implementation by default connects to port 443 on the authentication server rather than the default port 80. Of course, a vendor specific option may still be used to override this default behavior. If the authentication server refuses to accept a connection to port 443, and the implementation is configured to do so, the implementation will fall back to (non-Secure) Basic Authentication and attempt to connect to port 80. The system administrator may, through some implementation-defined mechanism, specify that the implementation is not permitted to fall back to Basic Authentication. In this case, if the connection to port 443 fails, the implementation shall not permit the user to be authenticated..

The secure authentication service must be configured to provide an ISO/IEC 9594-8:1995 X.509 v3 certificate to the implementation for server authentication. The implementation may be configured to provide a X.509 v3 certificate to the server if desired. However, the server shall not require the implementation to submit a certificate for authentication.

The implementation, of course, must have a way of authenticating the server's X.509 v3 certificate. This is done by verifying the signature on the X.509 v3 certificate using a set of root public keys made available to the implementation by either embedding them in the implementation or in persistent storage local and accessible to the implementation. This set of root keys must be sufficiently large to be useful for the intended purpose, but must be small enough to allow practical embedding of it in the implementation. A minimum set of root key certificates which must be included is listed in Root Certificates. The complete set of root certificates supported by an implementation is implementation-defined.

6.3.1. Issues with Secure Authentication

X.509 v3 certificates are only valid during the period stated on the certificate. If a root public key embedded in the implementation becomes invalid due to date constraints, the set of public keys available for the implementation to use will get smaller and could conceivably become empty. Vendors must periodically update the root keys (that is, the boot image or persistent store) to ensure the implementation is able to participate in the SSL session.

Certifying authorities can revoke certificates at any time. Revoked certificates are published in certificate revocation lists (CRLs). However there is no practical way for the implementation to obtain and use these lists. This is not just a network computing client authentication problem -- browsers typically do not consult CRLs either. The result is that it is impossible to rely on the trustworthiness of a root certificate, even if the certificate is used within its valid period.

If the implementation receives a server certificate signed by an entity for which it does not have a public key to verify the signature, it shall look up the public key certificate for the signing entity. If the implementation can verify the signature on the newly retrieved certificate, then it can use that public key to verify the server's certificate. However, if it cannot verify the signature on the new certificate, it shall continue the look up procedure, following the chain of signatures until it finds a signature it can verify with its set of public keys. There are two issues here. The public key for the signing entity is typically stored in some well known set of databases distributed over the global internet. If the implementation is not permitted to access the global internet, it can not obtain elements of the signature chain and therefore can not verify the signature on the server certificate. The other issue is that the name of the signing entity is embedded in the certificate as an X.500 distinguished name (DN). The DN is used as the key for database look up. This implies the implementation must implement an X.500 client in order to follow signature chains.

If the authentication service is a proxy authenticator that forwards authentication requests to another authentication service using a different protocol, then that protocol should not be one that sends sensitive data as clear or readily determined text.

6.4. Root Certificates

The following certificates must be available to the implementation (either by embedding them in the implementation or in persistent storage local and accessible to the implementation) so that it can verify the signature on the authentication server's certificate.
Thawte Server Basic
Thawte Server Premium
Verisign Class 1 Primary CA
Verisign Class 2 Primary CA
Verisign Class 3 Primary CA
Verisign/RSA Secure Server CA


A. Glossary

See also the list of terms in Chapter 1 which have specific meaning when used in this specification.