The objectives of the meeting was to finalize Salutation Architecture enhancements. These
included Service Discovery based on Service Location Protocol (SLP) Version 2, and [JetSend
Devices] FU support. It is planned to integrate these changes into Salutation Architecture
Specification as Version 2.1 by the end of this year. Technical Committee also reviewed the
XtraWorX Port-Of-Entry product (See Salutation News and Product Focus articles in this
editions of Greetings!).
The Technical Committee reviewed the draft specification for Service Discovery Enhancement
which was modeled on the multicast-based, directory-based Service Location Protocol Version 2
(SLP V2.0). Although the SLP V2.0 is still Internet Draft level and a few companies are planning
to implement SLP V2.0, it is expected that it will be on the standard track by the time Salutation
Architecture V2.1 is released.
Service Discovery using SLP extends the reach of Salutation Protocol beyond the subnet,
allowing devices, applications, and services to advertise their capabilities and locate needed
services and functionality across a broader geography. The proposal recognizes that a mix of
Salutation and SLP service discovery may exist in a network and allows both techniques to exist
simultaneously. Both Salutation and SLP discovery functionality is provided under the Single
Salutation API specification. Therefore, an application programmer is unaware of the discovery
technique used and the Salutation manager adapts to the network characteristics.
A Salutation Manager under SLA V2.1 will have a Service Agent (SA) and a User Agent (UA) to
support SLP V2.0. The SA/UA attempts to find a Directory Agents (DA) by preconfiguration,
multicast, or broadcast through the UA. The SLM V2.1 will continue to support Salutation
Search and Query to assure it can discover FUs registered with SLM V2.0.
If the SA has found DAs, it will unicast to each DA to register the Salutation FU as a service
URL and a set of attributes. If the UA has not found any DAs, the SLM will maintain capability
registration locally, waiting for Salutation Search and Query commands.
When the FU is un-registered, the SA will unicast a un-register request to all the DAs it has
registered.
If the UA has found DAs, it will unicast a service request to only one of the DAs (communication with one DA is sufficient as all DAs have the same content). If the UA has not found any DAs, it will multicast a service request to SAs. This multicast operation will enable service discovery by SLP under directory-less environment beyond a single subnet. These operations will discover FUs that are registered with SLM V2.1. In either case, the Salutation Manager will provide discovery services under SLA V2.0 if it wants to discover FUs that are registered with SLM V2.0. The Salutation manager will consolidate replies from a DA in response to unicast, from SAs in response to multicast, and from Salutation, and will remove any duplicates before it returns the result to the client application through the Salutation API.
HP's JetSend provides the ability for devices to connect and have a meaningful exchange of data
without having to understand details about the device in question. However, the need to learn
about devices and their capabilities is dependent upon the environment and context within which
a person is using the device. Discovery techniques are also environmentally dependent, and HP
has chosen to allow the device implementation to determine the required discovery technology
for its devices. To assist in using the Salutation discovery technique with JetSend enabled
devices, HP has petitioned the Technical Committee to approve a specification for the
[JetSendDevice] FU.
The [JetSendDevice] FU allows a client application to obtain information about the JetSend device. Typical equipment that would utilize [JetSendDevice] FU include:
The attributes for the [JetSendDevice] FU include the Device Class, the Sub-address, and the encoding techniques offered/accepted for image, text, audio, and video.