Subject: RE: IPP> Notifications

From: "Turner, Randy" <[email-masked]>
Date: Wed, 4 Feb 1998 12:56:00 -0800

UDP has no more firewall or proxy problem than TCP, given any arbitrary
port number.
The issues are the same for both. 

Randy

	-----Original Message-----
	From:	Carl Kugler [SMTP:[email-masked]]
	Sent:	Wednesday, February 04, 1998 11:16 AM
	To:	[email-masked]
	Subject:	RE: IPP> Notifications

	Randy-

	UDP datagram notificaton still has the firewalls and proxies
problem, unless
	everyone goes to SOCKS5.

	 -Carl

	[email-masked] on 02/04/98 11:53:58 AM
	Please respond to [email-masked] @ internet
	To: [email-masked] @ internet
	cc: [email-masked] @ 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 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:[email-masked]]
	 Sent: Wednesday, February 04, 1998 9:41 AM
	 To: 'Caruso, Angelo '; 'Larry Masinter'; Turner, Randy
	 Cc: [email-masked]'
	 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:[email-masked]]
	 > Sent: Wednesday, February 04, 1998 5:30 AM
	 > To: Paul Moore; 'Larry Masinter'; Turner, Randy
	 > Cc: [email-masked]'
	 > 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:[email-masked]]
	 >  Sent: Tuesday, February 03, 1998 8:05 PM
	 >  To: 'Larry Masinter'; Turner, Randy
	 >  Cc: [email-masked]'
	 >  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:[email-masked]]
	 >  > Sent: Tuesday, February 03, 1998 4:56 PM
	 >  > To: Turner, Randy
	 >  > Cc: Paul Moore; [email-masked]'
	 >  > 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

---

From: Larry Masinter <[email-masked]>
Date: Wed, 4 Feb 1998 18:20:04 PST

> The issues are the same for both. 

Is this a "first principles" argument? That is, are you speaking from experience
with firewall developers and maintainers, or is it just based on reasoning
about the nature of the protocols? What I have heard, both from
local firewall maintainers at Xerox and more generally in discussions of
firewall issues in other Internet protocols, is that there's
a substantial difference in the considerations of a site allowing
inbound UDP packets, allowing TCP connections with known semantic
content, and allowing inbound HTTP posts with well known data content.

Perhaps you have some different data that you could share with us?

Larry