Subject: IPP> Notification content

From: Harry Lewis <[email-masked]>
Date: Mon, 9 Mar 1998 12:26:37 -0500

In Austin, I think we discussed the IPP notification requirement that any
attribute may be requested during registration for a given event. I think the
requirement stems from the notion that notification content should just "mimic"
the response to a query. But this is probably unrealistic. A query/response is
synchronous - during which, the "agent's" job is to gather the requested
information and package the response. With notifications, you pre-register for
asynchronous events. It would be a much greater burden on the agent, whether it
be IPP, SNMP or whatever, to maintain, not only of who wants which
notifications, but also what information they requested with each type of event!

Harry Lewis - IBM Printing Systems

---

From: Jay Martin <[email-masked]>
Date: Mon, 09 Mar 1998 13:13:56 -0500

Harry,

I agree with your observations entirely.  And these concerns
are *exactly* why SENSE was designed to _not_ support any kind
of filtering, so as to ease the burden on the SENSE server
(which is the "agent" in your text below).

	...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: James Walker <[email-masked]>
Date: Wed, 11 Mar 1998 15:16:50 -0600

> notifications, but also what information they requested with each type of event!

IMHO, this is one of those areas where the requirements differ depending
upon whether we are talking about a host->device protocol, or the more
general client->server protocol.

In the case of a host->device protocol, I agree 100%... the host should
be able to register for specific event types, where the event associated
with each event type has some fixed, standardized content.  This is
along the lines of what was discussed in the JMP meeting in Austin.

However, in the more general client->server case, I think that variable
content is an important requirement.  Specifically, I think that it is
important that the notification be capable of holding enough information
such that the client does *not* have to go back and query the server to
get what it needs.  Seeing as how we cannot mandate what information the
client should be interested in, this implies that we should allow the
client to specify its interest.  Furthermore, if we are to allow vendors
to extend IPP, then the only way that clients can get at that extended
information in a notification is if we allow the client to ask for what
it wants.

one man's opinion...
...walker

--
Jim Walker <[email-masked]>
System Architect/DAZEL Wizard
DAZEL Corporation, Austin, TX