| Technical Standard |
|---|
| Network Computing Client |
| Document Number: C801 |
| Publication Date: October 1998 |
© 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 Groupor by electronic mail to:
Apex Plaza
Forbury Road
Reading
Berkshire, RG1 1AX
United Kingdom
OGSpecs@opengroup.org
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)
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
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:
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.
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:
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.
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.
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:
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: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.
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
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 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 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, Control Functions for Coded Character Sets
ISO/IEC 8859-1:1987, 8-bit Coded Character Set, Latin Alphabet 1
ISO/IEC 9594-8:1995, X.509 v3 Certificate
ISO/IEC 10918-1:1994, Compress and Coding of Images (JPEG)
ISO/IEC 10918-4:1998, JPEG File Format (JFIF)
ISO/IEC 13818-2:1996, Coding of Moving Pictures and Audio (MPEG-2)
ISO/IEC 16262:1998, ECMAScript: A general purpose, cross-platform programming language
Java Virtual Machine Specification
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
This document provides the technical specification for client systems in a Network Computing environment. A rich heritage of open systems standards in 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 does not define a complete implementation, nor does it preclude provision of additional features and functions outside the scope of this Technical Standard.
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.
Systems conforming to this Technical Standard support a common HTML and 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:
or
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 Technical Standard. 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:These are identified throughout the Technical Standard, and are also collected in Referenced Documents.
Unlike most existing specifications from The Open Group, this Technical Standard 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, Inc.
1.6. Compliance Considerations
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 Technical 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.
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 Technical Standard are included in a 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 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/).
The following terms are used in this Technical Standard:
(Same meaning as "implementation-defined".) Describes a value or behavior that is not defined by the Standard but is selected by an implementor. The value or behavior may vary among implementations that conform to the Standard. An application should not rely on the existence of the value or behavior. An application that relies on such a value or behavior is not portable across conforming implementations.
The implementor normally documents such a value or behavior so that it can be used correctly by an application.
Describes a feature or behavior that is being retained for compatibility with older applications, but which has limitations which make it inappropriate for developing portable applications. New applications should use alternative means of obtaining equivalent functionality.
Describes a feature or behavior that is optional for an implementation that conforms to the Standard. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior is not portable across conforming implementations.
To avoid ambiguity, the opposite of "may" is expressed as "need not", instead of "may not".
Same meaning as "shall"; "shall" is the preferred term.
Describes a feature or behavior that is mandatory for an implementation that conforms to the Standard. An application can rely on the existence of the feature or behavior.
For an implementation that conforms to the Standard, describes a feature or behavior that is recommended but optional. An application should not rely on the existence of the feature or behavior. An application that relies on such a feature or behavior is not portable across conforming implementations.
For an application, describes a feature or behavior that is recommended programming practice for maximum portability.
Describes the nature of a value or behavior not defined by the Standard which will result from use of an invalid program construct or invalid data input.
The value or behavior may vary among implementations that conform to the Standard. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior is not portable across conforming implementations.
Describes the nature of a value or behavior not specified by the Standard which will result from use of a valid program construct or valid data input.
The value or behavior may vary among implementations that conform to the Standard. An application should not rely on the existence or validity of the value or behavior. An application that relies on any particular value or behavior is not portable across conforming implementations.
Same meaning as "shall"; "shall" is the preferred term.
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.
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.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. 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 Sockets 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.
The user can elect to view their electronic mail. 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. 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. This chapter describes features that are components of a complete Network Computing environment, but that are either:or
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
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. 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 an 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. 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. 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: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, 8-bit Coded Character Set, Latin Alphabet 1.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:
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:
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: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, Control Functions for Coded Character Sets 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 Technical Standard 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: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:
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: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: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.
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: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:
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, 8-bit Coded Character Set, Latin Alphabet 1 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 8859-1.
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:
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 and the rules
for FRAMES as defined in HTML 4.0 Reference
Specification Chapter 16 - Frames, subsections 16.1 through 16.4. When they are supported, style
sheets shall be processed using the rules defined in Cascading
Style Sheets, level 1.
Resources of this type may contain data or refer to resources that require
further processing - see Processing of Encapsulated
Resources.
Image/gif shall be decoded in accordance with the Graphics Interchange Format Specification (GIF), Version 89a, and the results rendered on the display.
Image/png shall be decoded in accordance with the Portable Network Graphics Specification (PNG), Version 1.0, and the results
rendered on the display.
Image/jpeg shall be decoded in accordance with ISO/IEC 10918-1:1994, Compress and Coding of Images (JPEG). The implementation shall accept data in the file format specified
in the JPEG File Information Format (JFIF) Specification as defined in
ISO/IEC 10918-4:1998, JPEG File Format (JFIF).
The results of decoding such a resource shall be rendered on the display.
Audio/basic shall be processed in accordance with the Audio File Information Format (.au), Sun Microsystems, and the results emitted
through the product's audio output device.
When the audio/midi type is supported, it shall be processed and sent to the audio device in accordance
with the Complete MIDI 1.0 Detailed Specification.
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. An implementation shall be able to process the
following encapsulated audio formats: Pulse Code Modulation,
ALAW, and MULAW formats.
When video/mpeg is supported, it shall be decoded in accordance with the definition in
ISO/IEC 13818-2:1996, Coding of Moving Pictures and
Audio (MPEG-2).
The results of decoding shall be rendered to the
product's video and audio devices. The user shall be able to control the
presentation of the decoded data such that they can at least pause the
presentation, restart the presentation, and select the point at which presentation
should start using a time-based selection mechanism.
When application/pdf is supported, it shall be decoded in accordance with the Adobe Portable Document Format version 1.2 specification. The results of
the decoding shall be rendered on the display such that the user can navigate
through the document. The results of decoding shall also be able to be
sent to the user's chosen printer.
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 implementation (including at least
the set described here) shall be processed in turn.
When x-world/x-vrml is supported, it shall be processed in accordance with the definition in the Virtual Reality Modeling Language standard (ISO/IEC 14772-1:1998, The Virtual Reality Modeling Language -- Part 1: Functional Specification and UTF-8 Encoding).
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 Technical Standard. When an <APPLET> element that references a Java applet is encountered, the system shall load and execute the referenced Applet (see Executing Java Bytecode). 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. 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. 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:
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:
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements.
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
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. 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
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:
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.
Basic Authentication uses the authentication mechanism defined in the HTTP 1.1 specification. It works as follows:
Note that if the connection to the User Authentication server cannot be established, user authentication fails.
WWW-Authenticate: Basic realm="UAP"Note that the realm is required to be "UAP".
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
version
nfs.server*
user.id*
group.id*
user.home*
The value for version shall be "1.0" for this version of the User Authentication Protocol.
Items marked with an asterix (*) are only require to be present when the Management Feature Group and remote file access are supported. In this instance, the value for nfs.server is the IP address or DNS name associated with the NFS server that exports the home directory for the user identified by the user.id. The values for user.id and group.id are as specified in The Open Group's Protocols for Interworking: XNFS - Version 3W for user and group id's. The value for user.home is the name of a file system exported by the declared NFS server that contains the user's home directory.
The key/value pairs may occur in any order and may be interspersed with comment lines that begin with the hash (#) sign. Additional key/value pairs may be in the authentication document and their meaning is undefined. Clients shall not reject documents that contain undefined key/value pairs. Instead, they shall ignore keys and values (other than those specified above) that they can not use.
An example authentication document is:
<application/nc-userauth>
#NC Basic Authentication
#Mon Mar 09 08:08:30 PST 1998
version=1.0
nfs.server=10.234.1.15
user.id=4357
group.id=10
user.home=/export/home/jack
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.
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.
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