August 1, 1997

Salutation Consortium

Request For Information

Salutation Port-of-Entry

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

PURPOSE

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.

INTENT

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.

BACKGROUND

The Salutation Consortium (www.salutation.org) 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.

SALUTATION ARCHITECTURE OVERVIEW

A brief overview of the Salutation Architecture is given. Full details of the architecture are provided on the Salutation Consortium's Web Site (http://www.salutation.org/ordrspec.htm) 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.

SALUTATION PORT-OF-ENTRY OVERVIEW

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:

• The Salutation Manager Module: This module is an instance of the Salutation Architecture. It exposes the Salutation APIs to the applications and services contained in the desktop environment and receives and generates the Salutation protocol through the Communications Stack(s) contained on the Host Desktop Environment. The Salutation Manager may be licensed from one of the existing implementers, or may be built from scratch by the respondent.




Minimum requirements for the Salutation Manager Implementation:



• Must expose the Salutation APIs for access by applications and services other than the Port-of-Entry
• Must support TCP/IP stack (NetBios and IrDA stacks are optional)
• Minimal Capabilities Registry, supporting no less than 6 Functional Units registered from the Host Desktop Environment
• Except where modified above, must meet the Salutation Conformance Requirements established by the Salutation Technical Committee



• The Salutation Port-of-Entry Capabilities Population Module: This module provides an interface between the Host Desktop Environment and the Capabilities Registry of the Salutation Manager. It uses automatic and user intervention means consistent with the Host's operating system for determining the capabilities of devices, applications and services which exist in the Host Desktop Environment. For example, this module will access the DMI MIBs stored by Windows 95 and convert appropriate information to Salutation Functional Unit Description Records. If the information about the Host's Functional Units can not be accessed automatically, this module will query the user to input capability information through the Port-of-Entry User Interface Module.




Once the information is gathered, it will be posted to the user through the Port-of-Entry User Interface Module for content verification and user override of availability. When user interaction is complete, the Port-of-Entry Capability Population Module will register the results with the Salutation Manager.



Minimum requirements for the Salutation Port-of-Entry Capabilities Population Module:



• Provide for the definition of multiple Print, Document Storage and Address Book Functional Unit Description Records.
• Map Print Functional Unit Description Records to printer(s) locally attached to the Host Desktop Environment
• Map Document Storage Functional Unit Description Records to an available hard disk directory locally available in the Host Desktop Environment
• Map Address Book Functional Unit Description Records to an available address book repository typically found in personal information management applications, e.g. Lotus organizer.
• May extend the Functional Unit Attributes as may be required to support any optional functionality provided by the respondent
• Provide a means for the user to verify the capabilities of Functional Units and make modifications as required
• Provide a means for the user to manually define Functional Units and make modifications as required
• Provide a means for the user to change the availability of Functional Units (register and un-register with the Host's Salutation Manager).



• The Salutation Port-of-Entry User Interface Module: This module provides the interface between the Salutation Port-of-Entry and the user. It provides a Wizard-like interface similar to the Add New Hardware and System Properties interfaces found in the Control Panel Program Group of Windows 95.
  
  

  Minimum requirements for the Salutation Port-of-Entry User Interface Module:
  
  

  • Initialization:
  1. Information panel indicating this Wizard will assist the user in finding and defining Functional Units. The Functional Unit Maintenance panel's appearance will be similar to that shown in Figure 4.1.
  2. Completion of the first panel will activate a radio button panel, allowing the user to select automatic or manual detection of Functional Units. The Functional Unit Detection panel's appearance will be similar to that shown in Figure 4.2.
  3. Completion of the second panel will activate a List box panel, showing the Functional Units Categories with expansion (+) indications if Functional Unit Description Records have been built. A click on the (+) will cause a sub-tree to expand showing the defined Functional Units for that category. Functional Unit Category panel's appearance will be similar to that shown in Figure 4.3.
  4. A click on a Functional Unit will open a Functional Unit Description Record panel showing the capabilities assigned to that Functional Unit. Each capability is editable from this panel. By selecting a Functional Unit Category and clicking on the Create button, a Functional Unit Description Record panel will open providing editability of each of the capabilities for a new Functional Unit Description Record. The Functional Unit Description Record panel's appearance will be similar to that shown in Figure 4.4.
  5. Completion of step four will activate a list box panel showing all defined Functional Units with a check box associated with each item. A check in the check box indicates that this Functional Unit is available (registered with the local Salutation Manager). The Functional Unit Availability panel's appearance will be similar to that shown in Figure 4.5.
  
  
  
  • Availability:
  
  
  
  • The user may modify Functional Unit availability using step 5 above.
  
  
  
  • General:
  • The Salutation Port-of-Entry must be enabled for national language support (i.e., double byte enabled).
  • The Salutation Port-of-Entry will run minimized. When restored, the window will offer the user the following choices through a push button interface:
  • Terminate - Shut down the Salutation Port-of-Entry.
  • On-line/Off-line - Toggle the state of the availability of all registered Functional Units.
  • Off-line will un-register all Functional Units, but keep the Salutation Manager active. The state of all Functional Units will be saved. Modifications to Functional Unit definition will be honored but not registered in the off-line state. Modifications to Functional Unit availability made during the off-line state will be reflected in the Salutation Manager Functional Unit Registry when the user places the Salutation Port-of-Entry on-line.
  • On-line will restore the Functional Unit Registry of the Salutation Manager to the condition in effect prior entering the off-line state, reflecting any modifications made during the off-line state. On-line is the initial state.
  • Refresh - Activate the Functional Unit Definition panel as described in step 1 above.
  • Modify Availability - Activate the Availability Modification panel in step 5 above.

• The Salutation Port-of-Entry Functional Unit Modules: These modules provide a bridge between the Salutation Manager Service Requests and the actual device, application, or service that has been represented in the Salutation Manager via a registered Functional Unit Description Record. These modules are activated when a Service Request (fnOpenService() call) is directed to the Functional Unit from the Salutation Manager. The Functional Unit module will then manage the transfer of data to/from the device, application, or service via fnReceiveData() call and/or the slmTransferData() call respectively. The Functional Unit Modules are required to support the Emulated Personality. Support for Native and Salutation Personalities are optional.
  
  

  Minimum requirements for the Salutation Port-of-Entry Functional Unit Modules: The following specifies the Functional Unit types required in the Salutation Port-of-Entry and the minimum requirement for the each. The format and protocol of the data carried by Salutation packet in the Emulated mode is not specified and may be selected/defined by the respondent. The technologies used to support these Functional Units is not specified and may be proprietary to the responder.

  • Print Functional Unit: Route Emulated Service Request data received via a fnReceiveData() call to printer(s) represented via a Print Functional Unit Description Record
  • Document Storage Functional Unit: Route Emulated Service Request data received via a fnRecieveData() call to local disk directory represented via a Document Storage Functional Unit Description Record. Transfer data from a local disk directory represented via a Document Storage Functional Unit Description Record via a slmTransferData() call in Emulated Personalities
  • Address Book Functional Unit: Transfer the user's identification information via slmTransferData() call.
  
  
  

  Additional functionality may be provided at the respondents discretion.
  
  
  
  

• Other Requirements:



• The Salutation Port-of-Entry must run in the Windows 95 and Windows NT platforms. Other platforms are optional.



• Support Emulated Personality (support for the Native and Salutation Personalities is optional)



• Test Scenario:



• Another Salutation Manager must be able to access the Salutation Port-of-Entry via TCP/IP and determine:



• The local SLM-ID via an Exchange SLM-ID call
• The local Functional Unit(s) capabilities via a Query Capability call
• The local Functional Unit(s) availability via a Check FU Availability call



• Another Salutation Manager must be able to make a Service Request to any of the available Functional Units via Emulated Personalities



• Print to the Print Functional Unit(s)
• Store/Retrieve files to/from the Document Store Functional Unit(s)
• Retrieve information from the Address Book Functional Unit(s)



• A user must be able to manually generate, modify, register and un-register a Functional Unit Description Record with the Salutation Manager.






SPECIFIC QUESTIONS ABOUT THE PROPOSED OFFERING




• Technology of the Solution
• What functionality will be offered in the respondents solution over and above the minimum requirements listed in this Request For Information?
• Are proprietary technologies used in the solution? If yes, what are the licensing considerations for the Consortium?
• What assumptions are made concerning the Consortium involvement in the development process; i.e., providing technical support?
• Business Model to be Followed
• Assuming the Consortium retains sole ownership, what is the cost of the solution, (respondent acts as a sub-contractor to the Consortium)?
• Assuming the respondent retains ownership, how much must the Consortium invest in the solution? In this case,
• How will the Consortium share in the royalties generated through the sale and use of the solution?
• Will Consortium members be offered discounts to royalties?
• What role will the Consortium be asked to play in the marketing/promotion of the deliverables?
• What are the 'target' prices for the deliverables?
• Schedule
• When will Beta code be available for each of the required operating system platforms?
• When will Golden code be available for each of the required operating system platforms?
• Will there be subsequent releases? On what schedule?
• Will there be international releases? On what schedule?
• Support
• How will the code be maintained and supported?
• Will a Software Developers Toolkit be available?
• Are classes/seminars required? Will they be provided?
• What type of "End-User" support is required and how will it be delivered




SUBMISSION OF THE RESPONSE

Schedule:



All responses are required to be in the hands of the Salutation Consortium by September 30, 1997.



The Consortium will review all responses and may contact the respondent for further details. It is intended that the consortium will make a final decision regarding proceeding with the Port-of-Entry by October 31, 1997.

Address:



Responses may be submitted electronically to:



[email protected]



or overland to:



Robert Pecora
Salutation Consortium
c/o IBM
Dept 2U7/Bldg 501
PO Box 12195
Research Triangle Park, NC 27709-2195



Technical questions may be sent to:



Robert A. Pascoe
Senior Technical Staff Consulting
10702 North 5250 West
Highland, UT 84003
801-763-8216
[email protected]

Format:



The response should be in the form of a high level product design specification. This should include:



• Product description
• Prerequisites
• Development Environment
• Development/test schedule
• Predicted reliability




Functional options, provided in addition to minimum requirements specified in this Request For Information, should be highlighted.



The response should also include a business proposal, addressing the business model and support questions provided above.