Subject: RE: IPP> Notification content

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

Yes, thank you Randy. We went on, at the JMP meeting, to discuss this quite at
length. I am preparing the JMP minutes for distribution today or tomorrow. I
will cross post a reference (if that's still allowed).

Harry Lewis - IBM Printing Systems

[email-masked] on 03/09/98 10:34:27 AM
Please respond to [email-masked] @ internet
To: [email-masked] @ internet, Harry Lewis/Boulder/IBM@ibmus
cc: Roger K Debry/Boulder/IBM@ibmus
Subject: RE: IPP> Notification content

I seem to remember there was some concensus towards the end of the
discussion that two items needed to be defined:

1. What events cause a notification to be generated, and
2. What parameters get transmitted along with the event
notification.

I emphasized at the meeting that the parameters that are transmitted
along with a particular event are "standardized" (fixed) in a
standards-track document. If a client needs to know more about the
particular event, the client can subsequently issue an IPP request or
possibly an SNMP request depending upon the original event.

Randy

 -----Original Message-----
 From: Harry Lewis [SMTP:[email-masked]]
 Sent: Monday, March 09, 1998 9:27 AM
 To: [email-masked]
 Cc: Roger K Debry
 Subject: IPP> Notification content

 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: Tom Hastings <[email-masked]>
Date: Wed, 11 Mar 1998 09:50:40 PST

If the notification transport is SNMP, then I can see why the
registration would be difficult if it included sending attributes
that the registration specified.

On the other hand, if the registration mechanism is simply attributes
in a Job object that remain stored in that Job object for the life of
the job, then allowing the requester to include the attribute names to 
be sent with the notification is straightforward and natural.

>From a model point of view, we could cover both by saying that on an
SNMP transport binding, the trap recipient has to go and read the
attributes desired, but in a notification transport binding to, say,
UDP data grams or email, the attributes and their current values at the
time of the event would be bound into the notification information.

Tom