Subject: IPP> Re: SENSE> Time to shutdown the SENSE project?

From: Roger K Debry <[email-masked]>
Date: Thu, 5 Feb 1998 08:24:43 -0500

Jay,

I think SENSE has been more of a topic of discussion at printer MIB meetings.
I don't recall ot getting much attention at IPP meetings.  Of course, I have not
been able to attend all of the meetings, but I have not personally seen a
pointer to the documentation nor seen a formal presentation on SENSE.
Would it be worthwhile at an IPP meeting to do this?

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 02/05/98 06:21
AM ---------------------------

[email-masked] on 02/04/98 10:16:49 PM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @ internet
Subject: IPP> Re: SENSE> Time to shutdown the SENSE project?

Ron Bergman wrote:

> I would hope that before SENSE is shutdown that it is determined if this
> technology is applicable to IPP.  As you see by the email and minutes of
> the Maui meeting, the issue of notifications is becoming a very hot topic.
> The SENSE work and the knowledge you obtained should certainly be of
> significant benefit to IPP.

Ron, what would you suggest I do at this point to help describe
how SENSE can be used for IPP?  I have repeatedly requested folks
to read the SENSE documentation, yet very few people have come back
saying that agree/disagree on even the basic Proposed Requirements
document.

I guess I'm kind of at a loss at how to proceed.  (You know, you
can lead a horse to water, but you can't...)

It appears to me that the folks on the IPP list are taking somewhat
of a "fundamental research" technique in approaching async event
notifications for IPP.  Rather than examining an existing system
(defined for that kind of operation) and seeing how it can be used
to solve their particular problem, they appear to instead want to
focus on the basics (eg, transports, etc) and work up from there,
teaching themselves how to build a system from scratch in the
process.

I think that would be a shame, but if that's what it's going to
take for people to understand the how's and why's of where we
ended up with SENSE, then so be it.

I just hope it doesn't take too long, that's all...  8-)

If there's anything you (or anyone else) can do to help guide me
in explaining how SENSE can be used to solve IPP's event
notification problem, I am all ears.

 ...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Jay Martin <[email-masked]>
Date: Thu, 05 Feb 1998 12:55:49 -0500

Roger,

> Would it be worthwhile at an IPP meeting to do this?

For starters, check out the PWG website (http://www.pwg.org) where
you will find the SENSE project listed along with all the other PWG
projects.  Follow the link to the SENSE home page, where all the
current documents are listed with easy single-click access to
each and every document.

In particular, I would request that everyone take about 5 minutes
to review the very first document published for SENSE, namely the
"SENSE Proposed Initial Requirements" document located at:

    ftp://ftp.pwg.org/pub/pwg/sense/reqmts.txt

Since the document is pretty small I have taken the liberty of
attaching it below so folks can start looking at the fundamentals.

If nothing else, some of the functional requirements and constraints
listed in that document could be used to jump-start the IPP async
notification function requirements.

	...jay

                Simple Event Notification Service Environment
                                   (SENSE)
                        Proposed Initial Requirements

                                 Version 1.0

                               28 November 1995

This document describes the requirements for a Simple Event Notification
Service Environment (SENSE) and related protocol(s).  This document is
intended to serve as a basis for ongoing research and discussion by interested
parties in developing more formal specifications and implementations.

Overview
--------

The need for SENSE stems from the widespread need for simple notification of
events from various kinds of network entities to network clients.

Work in this area was originated by JK Martin (Underscore), Rick Landau
(Digital) and Mike Timperman (Lexmark) in response to an identified need for
transmission of events from network printer devices to network management
applications designed to monitor such devices.  As work progressed it became
readily apparent that the need for such notification services are pervasive in
today's widespread client/server environments.

The operative word in this initiative is "simple"; the intent is to derive a
very simple facility that serves as a "wrapper protocol" that can support the
delivery of event messages from a wide variety of sources.  It is all too easy
to go "hog wild" and specify intricate mechanisms for such a facility.

It is the intent of the original development group to keep the SENSE facility
very, very simple so as to support both simple client implementations and
simple server implementations.  It is a specific goal to make the SENSE
facility easily implementable in small embedded systems, such as low-cost
network printers and printer server devices.

While it is not the intent to support only network printer devices, the final
results of this initiative should support network printer devices to the
maximum extent possible.

Glossary
--------

Following is a brief set of terms used elsewhere in this document:

    Event           Any single instance of time-oriented information that may
                    arise during the operation of an entity.  There are no
                    semantics associated with an Event; an Event can be
                    anything from a "warning" to an "alert" to a simple
                    informational statement.

    Event Source    An entity that emits Events during its operation.

    Event Message   A message containing an Event.  The contents and format of
                    the message are not defined by the SENSE facility; that
                    is, the message content is opaque with respect to the
                    protocol used by the SENSE facility.

    Event Server    A network entity that provides event notification
                    services.

    Event Client    A network entity that consumes event notification
                    services.

    Registration    The transaction initiated by an Event Client to an Event
                    Server in which the Client requests services from the
                    Server.  A Server expects Registration requests at any
                    time during its operation.

    Subscription    The relationship between an Event Client and an Event
                    Server.  A Client registers a Subscription with the Server
                    for an agreed upon period of time, afterwhich the
                    Subscription is automatically terminated by the Server.
                    A "Subscription" can be viewed as a time-limited session
                    between a Client and a Server.

SENSE Requirements
------------------

A primary motivation for developing the SENSE specification is to improve the
delivery of critical messages as compared to the SNMP TRAP model.  In
particular, the SENSE specification should improve on these difficiencies in
the SNMP TRAP mechanism:

    - No standard method for adding/removing TRAP destination addresses,
      either statically or dynamically

    - All TRAP messages are directed to a fixed UDP port number, thereby
      forcing the implementation of a demultiplexing mechanism on hosts
      where multiple recipients operate

    - Only a single copy of the TRAP message is delivered to any given
      destination address; if the message gets lost, then no recipient
      is able to determine that a TRAP message was sent

SENSE must satisfy the following functional and operational requirements
(not listed in any particular order):

   1.  Relatively reliable receipt of Event Messages

       A key requirement is for a Client to expect reasonably reliable receipt
       of Event Messages.  The term "reasonably reliable" is used to denote
       the fact that a Server should make multiple attempts to deliver the
       message to the Client.  It should be noted that absolute reliability is
       not considered practical, and thus, not considered as a requirement.

   2.  Datagrams are used at the transport layer

       Since stream-oriented protocols are typically considered too "heavy"
       for lightweight services, datagrams should be used for all SENSE
       protocol implementations.       

   3.  A well-known transport address is defined for common use

       To facilitate interoperability, the Server should operate using a
       standard, "well known" transport address.

   4.  A Server can operate using any transport address

       The Server should be able to operate with any defined address within
       the target transport environment.  This will, of course, require that
       Clients know of and use the non-standard transport address.  This
       requirement is called out so as to allow a Server to operate in an
       environment in which the standard transport address is already in use.
       This requirement should be considered optional for an implementation.

   5.  Minimal protocol data formatting requirements

       To maintain simplicity, the protocol data units (PDUs) should use
       displayable text strings for all data components rather than the
       equivalent binary forms.  Using displayable text circumvents the
       incompatibilities between various network platforms and allows for
       simple implementation of Client applications.  Since the number of PDUs
       exchanged between a Client and a Server is expected to be rather small,
       the resulting parsing of the data components by the Client and Server
       should not be considered a performance problem.

   6.  Multiple sources of events can be managed by a single Server

       A Server should be able to "front-end" any number of Event Sources.
       No minimum or maximum number of supported Event Sources should be
       required.

   7.  A Server can be queried to determine the set of event sources
       managed by the Server

       A Client should be able to request the list of Event Sources
       supported by the Server.  The list should be formatted in
       displayable text.

   8.  A Server can be queried to determine its operational parameters

       A Client should be able to request a list of operational parameters
       and their values from the Server.  The list should be formatted in
       displayable text.

   9.  A simple loopback capability to determine Server existence

       A Client should be able to "ping" the Server to determine whether
       the Server is operating at the target transport address.  This
       requirement could be reasonably satisfied through the implementation of
       Requirement #8 above

  10.  A client dynamically registers for receipt of events from multiple
       event sources

       A Client should be able to dynamically request the creation of a
       Subscription from a Server, in which any number of Event Sources
       may be specified as being part of the Subscription.  The Subscription
       request also includes a requested period of time for which the
       Subscription remains active; once this time period is exceeded, the
       Server automatically terminates the Subscription without further action
       by the Client.

  11.  A client specifies the network endpoint to which all Event Messages are
       directed

       When the Client requests the creation of a Subscription, part of the
       request includes the destination transport address (network address and
       transport port number) to which all Event Messages are delivered.

  12.  A client can cancel a subscription at any time

       A Client is free to prematurely cancel a Subscription (before the
       Subscription period runs out).

  13.  Event Messages are asynchronously transmitted by the Server to all
       registered clients when an event occurs

       The Server should send Event Messages to the network/transport address
       specified by the Client at Subscription request time as events occur.
       The Server will continue to periodically retransmit an Event Message
       until either the Server-defined retransmit time/count runs out, or
       until the Client acknowledges receipt of the event.

  14.  Clients acknowledge receipt of events

       A Client must acknowledge receipt of an Event Message from a Server.

  15.  The precise content and format of an Event Message is opaque relative
       to the underlying SENSE protocol

       The format and contents of an Event Message are (by definition) not
       defined within the SENSE specification; instead, the Client is expected
       to be intimately familiar with the format of such messages based on the
       associated Event Source.

  16.  A Server must be able to control resource consumption

       A key aspect of the SENSE facility is to be highly "Server-oriented"
       with respect to implementation and performance.  In particular, the
       Server should be allowed to arbitrarily implement the values for such
       parameters as:

           Maximum number of Subscriptions
           Maximum Subscription period
           Maximum number of retries for delivery of event messages

       It is expected that the values of these parameters (and probably many
       others) will be part of the response to a request for a Server's
       operational parameters as described in Requirement #8 above.

While not called out as a requirement in the above list, it is expected that
the SENSE facility should be implemented for use with at least the following
transports:

    - UDP/IP
    - IPX
    - AppleTalk DDP

Other datagram-oriented transports are not necessarily precluded from
implementation.

Functional Model
----------------

A crude structural diagram that can be used to describe the desired functional
model is shown below:

              Client -----|
                 .        |                |--- Event Source
                 .        |                |         .
                 .        |                |         .
              Client -----+----- Server ---+--- Event Source
                 .        |                |         .
                 .        |                |         .
                 .        |                |--- Event Source
                 .        |
              Client -----|

This diagram describes the three primary interworking entities:

    Client
    Server
    Event Source

The protocol used between the Client and the Server is expected to be defined
for the SENSE facility.  On the other hand, the protocol(s) between the Server
and the Event Sources are not expected to be defined in the SENSE
specification.

Protocol Exchange Example
-------------------------

Following is a rough protocol diagram describing the basic, error-free
exchange between a Client and a Server whereby:

    o  The Client registers a Subscription with the Server
    o  The Server later sends Event Messages to the Client
    o  The Client cancels the Subscription

    Client                                      Server
    ------                                      ------

       >---------- registration request ----------> 

       <----------  registration reply  ----------<
                           .
                           .
                           .
       <----------    event message     ----------<

       >---------- event acknowledgement ---------> 
                           .
                           .
                           .
       <----------    event message     ----------<

       >---------- event acknowledgement ---------> 
                           .
                           .
                           .
       >---------- termination request  ----------> 

       <----------  termination reply   ----------<

                                  # # # # #