Subject: RE: IPP> Notifications

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)

> -----Original Message-----
> From:	Turner, Randy [SMTP:[email-masked]]
> Sent:	Tuesday, February 03, 1998 1:29 PM
> To:	Paul Moore; [email-masked]'
> Subject:	RE: IPP> Notifications
> 
> 
> 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
> 
> 
> 	-----Original Message-----
> 	From:	Paul Moore [SMTP:[email-masked]]
> 	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: [email-masked] (Zhi-Hong Huang)
Date: Tue, 03 Feb 1998 15:18:31 -0800

I don't see there is any need for the client to open
another socket waiting for the server notification.
Since an IPP connection is persistent, the server can
notify the client over the same socket any time. If
a notification needs to be sent after the session is
closed, the server can wait until the same client
opens another session, provided that the server can
uniquely identify the client. For completeness, a
time-to-live for the message may need to be defined.

What this means is that if the client is ever interested
in any notification from the server, it should remain
online or check back with the server later.