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.
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
At 09:52 03/09/1998 PST, Harry Lewis wrote:
>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
>
>
>
>
>rturner@sharplabs.com on 03/09/98 10:34:27 AM
>Please respond to rturner@sharplabs.com @ internet
>To: ipp@pwg.org @ 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:harryl@us.ibm.com]
> Sent: Monday, March 09, 1998 9:27 AM
> To: ipp@pwg.org
> 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
>
>
>
>
>
>
>