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:rturner@sharplabs.com]
> Sent: Tuesday, February 03, 1998 1:29 PM
> To: Paul Moore; 'ipp@pwg.org'
> 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:paulmo@microsoft.com]
> Sent: Tuesday, February 03, 1998 1:05 PM
> To: 'Turner, Randy'; 'ipp@pwg.org'
> 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:rturner@sharplabs.com]
> > Sent: Tuesday, February 03, 1998 11:29 AM
> > To: Paul Moore; 'ipp@pwg.org'
> > 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:paulmo@microsoft.com]
> > Sent: Tuesday, February 03, 1998 10:51 AM
> > To: 'ipp@pwg.org'
> > 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?