Subject: RE: IPP> Notifications

From: Paul Moore <[email-masked]>
Date: Tue, 3 Feb 1998 13:05:03 -0800

The minutes dont really discuss it. There is talk about email vs 'IPP
notifications' But no real discussion of how IPP notification could be done.
A device-level protocol that does not allow Out of band feedback seems
pretty broken 

> -----Original Message-----
> From:	Turner, Randy [SMTP:[email-masked]]
> Sent:	Tuesday, February 03, 1998 11:29 AM
> To:	Paul Moore; [email-masked]'
> Subject:	RE: IPP> Notifications
> 
> 
> Yes, this was discussed. Several solutions were proposed. Check out the
> minutes of the IPP meeting that Don just posted.
> I think some of the ideas were included in the minutes.
> 
> Randy
> 
> 
> 	-----Original Message-----
> 	From:	Paul Moore [SMTP:[email-masked]]
> 	Sent:	Tuesday, February 03, 1998 10:51 AM
> 	To:	[email-masked]'
> 	Subject:	IPP> Notifications
> 
> 	Has anybody noticed that IPP will be useless for notifications
> due to the
> 	asymmetry of the protocol? As currently constituted a printer
> cannot send an
> 	unsolicted message to anybody. 
> 
> 	Was this discussed later on on the Thursday brainstorm?

---

From: Paul Moore <[email-masked]>
Date: Tue, 3 Feb 1998 13:45:08 -0800

What I was meaning regarding device level protocol is --

Today we have something that does not push the server or printer envelope -
I agree it cannot be called a device protocol. We did discuss extending IPP
into very precise printer managment (feature and configurtion discovery and
control, plus some maybe queuing control). I really need a protocol to fill
that space and I know others do as well. The fact that IPP will be severly
challenged as it currently stands is a potential showstopper.

The problem with using a non-HTTP based solution is the old firewall/proxy
argument. We could be in the wierd position where IPP can reach the device
but the notifications cannot get back. That, in theory would make a whole
chunk of the protocol optional and therefore useless.

Putting a web server on the client seems a bit of a sledge hammer sized
solution.

One solution - carry everything on raw TCP. 

I dont like UDP - it is a 'best endeavors' transport. You cannot build real
functionality based on it because you never know if you will receive the
messages. (This was the whole point of SENSE)

> Sent:	Tuesday, February 03, 1998 1:29 PM
> I remember we talked about maintaining persistent connections to the
> server during job processing, as well as possibly having the clients
> allocate a socket to receive UDP or TCP - based notifications from a
> server.  And on your last statement, I disagree that we have a
> device-level protocol; Most IPP servers, including your own, will be
> implemented on server-based systems, detached from the actual physical
> printer. Its possible that some server-based implementations might not
> have device-level access or at least accurate realtime access to device
> status.
> 
> Nonetheless, I would like to see further discussion on this topic via
> the mailing list. I personally favor something along the lines of a UDP
> message sent to a client socket from the server which includes some type
> of encapsulated notification message.
> 
> Randy
> 
> 
> 	Sent:	Tuesday, February 03, 1998 1:05 PM
> 	To:	'Turner, Randy'; [email-masked]'

---

From: Josh Cohen <[email-masked]>
Date: Tue, 3 Feb 1998 15:28:10 -0800

I thought the consensus that the first step was to have
a requirements document written up for IPP.
Since there are many generalized notification efforts
underway ( or soon to be), we can judge the suitability
of using one of them or writing one specific to IPP.
However, that can only be done if we know our requirements
first.

-> -----Original Message-----
-> From: Paul Moore 
-> Sent: Tuesday, February 03, 1998 1:05 PM
-> To: 'Turner, Randy'; [email-masked]'
-> Subject: RE: IPP> Notifications
-> 
-> 
-> The minutes dont really discuss it. There is talk about email vs 'IPP
-> notifications' But no real discussion of how IPP 
-> notification could be done.
-> A device-level protocol that does not allow Out of band 
-> feedback seems
-> pretty broken 
-> 
-> > -----Original Message-----
-> > From:	Turner, Randy [SMTP:[email-masked]]
-> > Sent:	Tuesday, February 03, 1998 11:29 AM
-> > To:	Paul Moore; [email-masked]'
-> > Subject:	RE: IPP> Notifications
-> > 
-> > 
-> > Yes, this was discussed. Several solutions were proposed. 
-> Check out the
-> > minutes of the IPP meeting that Don just posted.
-> > I think some of the ideas were included in the minutes.
-> > 
-> > Randy
-> > 
-> > 
-> > 	-----Original Message-----
-> > 	From:	Paul Moore [SMTP:[email-masked]]
-> > 	Sent:	Tuesday, February 03, 1998 10:51 AM
-> > 	To:	[email-masked]'
-> > 	Subject:	IPP> Notifications
-> > 
-> > 	Has anybody noticed that IPP will be useless for notifications
-> > due to the
-> > 	asymmetry of the protocol? As currently constituted a printer
-> > cannot send an
-> > 	unsolicted message to anybody. 
-> > 
-> > 	Was this discussed later on on the Thursday brainstorm?
->

---

From: Larry Masinter <[email-masked]>
Date: Tue, 3 Feb 1998 17:04:52 PST

I believe that "mailto" can include session-based
connectivity if it's available.

Larry
-- 
http://www.parc.xerox.com/masinter

---

From: Larry Masinter <[email-masked]>
Date: Tue, 3 Feb 1998 16:56:20 PST

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

---

From: "Caruso, Angelo " <[email-masked]>
Date: Wed, 4 Feb 1998 05:30:29 PST

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.

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

---

From: Paul Moore <[email-masked]>
Date: Wed, 4 Feb 1998 09:40:34 -0800

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.

> From:	Caruso, Angelo  [SMTP:[email-masked]]
> Sent:	Wednesday, February 04, 1998 5:30 AM
> To:	Paul Moore; 'Larry Masinter'; Turner, Randy
> Cc:	[email-masked]'

---

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

> UDP has no more firewall or proxy problem than TCP, given any arbitrary
> port number.
> 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