August 1, 1997

Salutation Consortium

Request For Information

Salutation Port-of-Entry

Prepared by: Robert A. Pascoe
[email protected]
10702 North 5250 West
Highland, UT 84003


This Request For Information is issued by the Salutation Consortium for the purpose of gathering information and assessing bids for the production of a Salutation Port-of-Entry. The Salutation Port-of-Entry is a program that runs on a Windows desktop environments, and represents the capabilities of that environment to other entities via the Salutation Protocols. This Request For Information details the minimum requirements for the Salutation Port-of-Entry and a test scenario which will be used to verify that the minimum functions are met. Those responding to this Request For Information are asked to specify additional functionality that will be provided by their implementation, the business model to be followed for the Consortium's use and distribution of the resulting product, and a schedule for delivery and support. This Request For Information contains a list of questions intended to guide the considerations of the respondent. Please answer each question as completely as possible.


The Salutation Consortium is targeting application developers and service providers as potential users of the Salutation Architecture. The Salutation Port-of-Entry is seen as an enabler for the Windows environments, providing a consistent user interface and basic set of Functional Units. This functionality will allow software manufactures to concentrate on their unique functionality without diverting resources to develop Salutation specific enablers. The Salutation Consortium is considering partially funding the development of the Salutation Port-of-Entry, and to utilize its channels for distribution of the product to potential users. The Consortium expects some remuneration for this support. For example, the Consortium may share royalties and/or discounts may be offered to its members. The Salutation Consortium will review the business models of each respondents which will be factored into the selection processes.


The Salutation Consortium ( is a non-profit corporation with member organizations in the United States, Europe, and Japan. Member companies include APTi, Axis Communications, Brother, Canon, Casio, Cisco, Eastman Kodak, Fuji Xerox, Fujitsu, Hewlett Packard, Hitachi, Integrated Systems, IBM, Iwatsu, Justsystem, Kobe Steel, Konica, Kumatsu, Lexmark, Matsushita, Microware Systems, Minolta, Mita, Mitsubishi, Murata (Muratec), Novell, Oki Data, Ricoh, Rios Systems, Sanyo, Seiko Epson, Sharp, Sun Microsystems, Toshiba, and Xerox. The Salutation Consortium has published an open specification that enables an application to locate a particular resource on a network through a broadcast query. The specification is independent of network transport, hardware platform, and operating system software and supports standard Internet and other message formats.

The Salutation Architecture was created to solve the problems of service discovery and utilization among a broad set of appliances and equipment in an environment of widespread connectivity and mobility.

The architecture provides a standard method for applications, services and devices to describe their capabilities, to advertise their capabilities to other applications, services and devices, to find out the capabilities of other applications, services and devices, to search applications, services or devices for a particular capability, and to request and establish interoperable sessions with other applications, services or devices to utilize their capabilities.

Given the diverse nature of target appliances and equipment in an environment of widespread connectivity, the architecture is processor, operating system, and communication protocol independent, and allows for scalable implementations, even in very low-price devices.


A brief overview of the Salutation Architecture is given. Full details of the architecture are provided on the Salutation Consortium's Web Site ( and are available to anyone, royalty free.

Salutation Manager (SLM)

As shown in Figure 2-1, the Salutation Architecture defines an entity called the Salutation Manager(SLM) that functions as a service broker for applications, services and applications called Network Entity. The SLM allows Network Entities to discover and utilize the capabilities of other Network Entities.

A Network Entity may be a service provider which is called a Server. The Server registers its capability with an SLM. A Network Entity may be a service user which is called a Client. The Client discovers Servers and requests to use them through an SLM. A Network Entity may serve as both a Client and a Server.

The SLM communicates with other SLMs to perform its role as a service broker. The SLM-to-SLM communications protocol is defined by the architecture and called the Salutation Manager Protocol.

The Salutation Manager Protocol uses Sun Microsystems' Open Networking Computing Remote Procedure Call version 2 protocol, referred to as RPC hereafter.

The Salutation Manager Protocol requires that the underlying transport protocol support multiple reliable bi-directional communications.

Each SLM has a universally unique identifier, SLM-ID. SLM-ID is a 16-octet-long opaque OCTET STRING used by Clients, Servers, and SLMs to uniquely identify a particular SLM in a transport independent way.

The SLM provides a transport-independent interface, called the SLM Transport Interface (SLM-TI), to transport-dependent entities, called Transport Managers (TM). The Transport Manager is introduced to make the SLM transport-independent. The SLM and TM(s) together perform the service broker role. The SLM-TI will be defined in a future release of this architecture.

An SLM works with one or more TMs. Each TM discovers other remote SLMs connected to the transport it supports. For each discovered remote SLM, the TM finds the SLM-ID of the remote SLM, registers the SLM-ID with the local SLM, and maintains the association between the transport address and the SLM-ID of the remote SLM.

The TM discovers other remote SLMs in a number of ways such as the following:

TM has a static table of the transport address of remote SLMs. The format and structure of the table is outside the scope of this architecture.

TM broadcasts a query to find other remote SLMs over the transport using the protocol defined by this architecture. (This method is possible only if the transport supports a broadcast mechanism.)

If there is a central server containing the directory of Salutation equipment, TM may inquire the transport address of other SLMs there. The protocol between the TM and such directory is outside this architecture's scope.

The application specifies the type of transport and the transport address of a remote SLM through the SLM-API.

Each piece of Equipment has, at most, one SLM. When there is no local SLM, Clients/Servers may use a remote SLM, an SLM in another piece of Equipment, through RPC. It is up to the implementation of each SLM whether or not it provides the RPC interface to remote applications.


The Salutation Port-of-Entry high level design is shown in Figure 3.1. Components unique to the Salutation Port-of-Entry are depicted in bold outlines. These are the Salutation Manager module, the Salutation Port-of-Entry Capabilities Population module, the Salutation Port-of-Entry User Interface module, and multiple Functional Unit modules. The combination of the Salutation Port-of-Entry Capabilities Population and User Interface modules act as a Server to the Salutation Manager. Each of the Functional Unit modules acts as a Server to the Salutation Manager. There is no requirement to provide a Client in the Salutation Port-of-Entry implementation, although the design allows for Clients to exist in the Host Desktop Environment. These modules serve the following functions: