- it is a different protocol with different semantics
- it is a 'best endeavors' protocol, you might or might not get the message
- HTTP was chosen for IPP for its universal reach (firewalls, proxies,
etc.), SNMP is not normally carried as far.
> -----Original Message-----
> From: Caruso, Angelo [SMTP:Angelo.Caruso@usa.xerox.com]
> Sent: Wednesday, February 04, 1998 5:30 AM
> To: Paul Moore; 'Larry Masinter'; Turner, Randy
> Cc: 'ipp@pwg.org'
> Subject: RE: IPP> Notifications
>
> Paul,
>
> Has anyone considered using SNMP traps for these kinds of asynchronous
> notifications? It's light-weight and quick and designed for this sort of
> thing, unlike HTTP or email. Just a thought.
>
> Thanks,
> Angelo
>
> -----Original Message-----
> From: Paul Moore [SMTP:paulmo@microsoft.com]
> Sent: Tuesday, February 03, 1998 8:05 PM
> To: 'Larry Masinter'; Turner, Randy
> Cc: 'ipp@pwg.org'
> Subject: RE: IPP> Notifications
>
> We need to distinguish two types of notification. (This was a
> long and
> exciting debate in Maui!).
>
> Firstly a client should be able to request that (for exmaple)
> when a print
> job is completed that a human readable notification be sent to
> some URL,
> that a pager be bleeped, that a robot arm should waved over a
> fire to create
> a smoke signal, whatever.
>
> We also agreed that if IPP were to be extended to manage the
> lower level
> interface from the server/cleint to the printer then some
> machine readable
> noification mechanism was needed. For example the printer is
> running low on
> paper it may signal a listener somewhere, if a configuration
> change takes
> place or whatever. This notification may even be the 'job
> completed'
> notification back to a server that triggers it to send the human
> readable
> notification that was requested in the original print job from
> the client to
> the server.
>
> > -----Original Message-----
> > From: Larry Masinter [SMTP:masinter@parc.xerox.com]
> > Sent: Tuesday, February 03, 1998 4:56 PM
> > To: Turner, Randy
> > Cc: Paul Moore; 'ipp@pwg.org'
> > Subject: Re: IPP> Notifications
> >
> > I like the idea of the client supplying, as part of a request,
> > the URL for notifications. In email, this address could be
> > supplied by the disposition-notification-to header, as with
> any
> > kind of receipt notification. For requests that get delivered
> > via IPP and POST, the address to which notifications get
> posted
> > could be supplied by the client via a URL, too. Clients would
> > have to know their own address, though, and make some kind of
> > service guarantee that they're willing to listen to responses
> > at that address. In some cases, the address of notification
> will
> > be different than the client address.
> >
> > In email delivery for Internet Fax, we've also wanted to have
> > a notification protocol for "successful printing"; I'd like to
> > make sure that IPP and Internet Fax don't invent different
> > mechanisms for no good reason.
> >
> > Larry
> > --
> > http://www.parc.xerox.com/masinter