IPP Mail Archive: Re[2]: IPP> Notifications

Re[2]: IPP> Notifications

Philip Thambidurai (pthambid@okidata.com)
Wed, 4 Feb 1998 14:27:18 -0500

I don't see how a UDP datagram originating from outside the firewall
is going to be let inside (without assigning a special port, and
security protocol). It is possible to provide a single proxy for the
clients which would receive UDP packets from the outside, but this
requires extra effort in terms of security admin. and client code.



In fact, one of the premises behind the firewall policy is to allow
only connections that originate inside --- this is going to be
problematic for any connectionless async notification --- and argues
in favor of the client (or an agent for the client) polling the IPP
Printer when desired. --- the notification request must be initiated
by the client (which is really not async.)


SMTP, although somewhat unpalatable, may not be as bad as one thinks.
In fact, one could have a very simple smtp "server" (receiver) in the
client, so that the mail is relayed directly to the client and does
not have to pass through user agents and systems like POP3/IMAP etc.
However this may be difficult from a policy/administrative view (since
mail must be relayed from the company's mail server(s), and possible
DNS changes to mx records).




note that many so-called "push" technologies are really pull (the client or
a daemon polls the external source for information).

Of course, if we are dealing only with the Intranet, there are many easy
solutions.

Philip Thambidurai

______________________________ Reply Separator _________________________________
Subject: RE: IPP> Notifications
Author: "Turner; Randy" <rturner@sharplabs.com> at INTERNET
Date: 2/4/98 10:15 AM

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 better
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