|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 Groupor by electronic mail to:
Berkshire, RG1 1AX
The Open Group
Development of Product Standards
Open Group Publications
Versions and Issues of Specifications
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.2. Brand Program
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.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
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
188.8.131.52. Telnet Terminal Sessions
184.108.40.206. 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
220.127.116.11. Java Applets
18.104.22.168. In-line Images
22.214.171.124. Background Images
126.96.36.199. 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)
User Authentication Protocol
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
The Open GroupThe 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:
Development of Product StandardsThis 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 PublicationsThe 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 have usually addressed an emerging area of technology and consequently are not yet supported by multiple sources of stable conformant implementations. They are published for the purpose of validation through implementation of products. A Preliminary Specification is as stable as can be achieved, through applying The Open Group's rigorous development and review procedures.
Preliminary Specifications are analogous to the trial-use standards issued by formal standards organizations, and developers are encouraged to develop products on the basis of them. However, experience through implementation work may result in significant (possibly upwardly incompatible) changes before its progression to becoming a Technical Standard. While the intent is to progress Preliminary Specifications to corresponding Technical Standards, the ability to do so depends on consensus among Open Group members.
The Open Group publishes specifications on behalf of industry consortia. For example, it publishes the NMF SPIRIT procurement specifications on behalf of the Network Management Forum. It also publishes Technology Specifications relating to OSF/1, DCE, OSF/Motif, and CDE.
Technology Specifications (formerly AES Specifications) are often candidates for consensus review, and may be adopted as Technical Standards, in which case the relevant Technology Specification is superseded by a Technical Standard.
In addition, The Open Group publishes:
This includes product documentation-programmer's guides, user manuals, and so on - relating to the Pre-structured Technology Projects (PSTs), such as DCE and CDE. It also includes the Single UNIX Documentation, designed for use as common product documentation for the whole industry.
These provide information that is useful in the evaluation, procurement, development, or management of open systems, particularly those that relate to the Technical Standards or Preliminary Specifications. The Open Group Guides are advisory, not normative, and should not be referenced for purposes of specifying or claiming conformance to a Product Standard.
Technical Studies present results of analyses performed on subjects of interest in areas relevant to The Open Group's Technical Program. They are intended to communicate the findings to the outside world so as to stimulate discussion and activity in other bodies and the industry in general.
Versions and Issues of SpecificationsAs 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:
CorrigendaReaders 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 InformationFull catalog and ordering information on all Open Group publications is available on the World-Wide Web at http://www.opengroup.org/pubs.
This DocumentThis 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.
TrademarksMotif®, 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 DocumentsThis 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 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.1. ScopeThis document provides the technical specification for client systems in a network computing environment.
1.2. PositioningA 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 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 FeaturesIt is useful to separate the features of network computing clients into
1.4. Network Computing Clients and PCsNetwork 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 StandardsAll 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. ConformanceA 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 ProgramA 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/).
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.
2. Conceptual ArchitectureThe 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.
2.1. Providing a User EnvironmentConforming 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 URLsWhen 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 SessionsURLs 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 FilesURLs 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-MailURLs 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 ResourcesURLs 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-MailThe user can elect to view their electronic mail.
2.4. Executing Java BytecodeWhen 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 ResourcesResources 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 QueriesWhen a query is directed at an implementation using the SNMPv1 protocol, the implementation responds with the requested information.
2.7. Underlying Network ServicesAll the services provided by an implementation depend upon a variety of network services.
3. Management FeaturesThis 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 ImplementationWhen 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 SystemsIf 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:
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 SystemsIf 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:
3.2. User AuthenticationWhen 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 ModificationWhen 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 PrinterWhen 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 QueriesWhen 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:
3.6. Providing a File SystemWhen 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 FeaturesThis 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 EnvironmentIn 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 ApplicationsWhen 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 LocaleThe 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 ResourcesThe 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 LocatorsUniform 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
188.8.131.52. Telnet Terminal SessionsWhen 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, 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:
184.108.40.206. TN3270 Terminal SessionsWhen 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 FilesWhen 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 MailWhen 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:
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:
4.2.4. Transmitting Resource RequestsThe 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.
4.3. Viewing Electronic MailWhen 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 CapabilitiesAn 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 AccessIn 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 BytecodeConformant 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:
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 EnvironmentWhen 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 ResourcesWhen 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:
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
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 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 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 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 Information Technology -- Computer Graphics and Image Processing -- The Virtual Reality Modeling Language -- Part 1: Functional Specification and UTF-8 Encoding).
4.6.1. Processing of Encapsulated ResourcesIn 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:
220.127.116.11. Java AppletsWhen an <APPLET> element that references a Java applet is encountered, the system shall load and execute the referenced Applet (see Executing Java Bytecode).
18.104.22.168. In-line ImagesWhen 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.
22.214.171.124. Background ImagesWhen 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.
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 ServicesA 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 ProtocolMost 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.2. User Datagram ProtocolSome services send queries via the User Datagram Protocol (UDP). It is defined in Internet Standard 6, User Datagram Protocol:
4.7.3. Internet ProtocolTCP sessions are conducted over Internet Protocol-based networks. The implementation shall adhere to Internet Standard 5, Internet Protocol, Version 4 (IPv4):
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:
5. Rendition RequirementsSome 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. IntroductionThis 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.
6.2. Basic AuthenticationBasic 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==
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:
#NC Basic Authentication
#Mon Mar 09 08:08:30 PST 1998
6.2.1. Issues with Basic AuthenticationTypical 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 AuthenticationSecure 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 AuthenticationX.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 CertificatesThe 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. GlossarySee also the list of terms in Chapter 1 which have specific meaning when used in this specification.