UDP datagram notificaton still has the firewalls and proxies problem, u=
nless
everyone goes to SOCKS5.
-Carl
ipp-owner@pwg.org on 02/04/98 11:53:58 AM
Please respond to ipp-owner@pwg.org @ internet
To: paulmo@microsoft.com @ internet
cc: ipp@pwg.org @ internet
Subject: RE: IPP> Notifications
I agree that using SNMP solely for IPP notifications might be too much,=
but I still consider the use of UDP datagrams for asynchronous
notification to be valid for the IPP case. And with a simple
acknowledgment scheme you can achieve reliable delivery. I do not think=
a server would have to open a TCP connection to a notification receiver=
just to send a small notification message; for a notification message I=
think TCP is too much as well. UDP datagrams will also scale much bette=
r
than TCP connections in the event of a server having to handle a lot of=
notification subscriptions.
Randy
-----Original Message-----
From: Paul Moore [SMTP:paulmo@microsoft.com]
Sent: Wednesday, February 04, 1998 9:41 AM
To: 'Caruso, Angelo '; 'Larry Masinter'; Turner, Randy
Cc: 'ipp@pwg.org'
Subject: RE: IPP> Notifications
This has been actively considered - the main problems are:-
- 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
=