IPP Mail Archive: RE: IPP> Notifications

RE: IPP> Notifications

Turner, Randy (rturner@sharplabs.com)
Thu, 5 Feb 1998 11:31:14 -0800

Of course polling is the "standard" solution for status notification in
IPP v1.0. Per our last meeting, IPP v1.0 is "in the bag". We're done. It
was my impression that the entire discussion on async notifications was
within the context of what we need for v2.0.

Randy

-----Original Message-----
From: Roger K Debry [SMTP:rdebry@us.ibm.com]
Sent: Thursday, February 05, 1998 10:04 AM
To: ipp@pwg.org
Subject: RE: IPP> Notifications

> What will actually happen is that we will all poll :-(

I think that's the best we can do if we limit ourselves to the
existing Web
infrastructure. Meanwhile, implementers will find ways to do
asynchronous
notifications outside the IPP box, as proprietary extensions.
Later, the IPP
v2 working group can look at what works and select or synthesize
some approach
as standard for IPP asynch notification. And by then maybe the
Web won't be so
asymmetrical.

Anyway, polling might not be elegant, but I think it can do the
job. With
HTTP/1.1, the client will be polling over a persistant
connection,

<RKD> So you assume that we would keep a connection open until
<RKD> a print job is completed and a notification provided? I
<RKD> don't know if I'd agree that this is a good idea.

so the
overhead should be low. Polling rates could be fairly slow,
since there's no
need for instantaneous notification with an application like
printing.

-Carl

ipp-owner@pwg.org on 02/04/98 01:53:15 PM
Please respond to ipp-owner@pwg.org @ internet
To: ipp@pwg.org @ internet, Carl Kugler/Boulder/IBM@ibmus
cc:
Subject: RE: IPP> Notifications

No argument at all. This is othogonal to the XML debate.

I am looking at expanding IPP to cover many needs beyond the
relatively
simple feature set currently defined, the extensibility issue
led me to the
XML proposal, the unsolicited message issue led me to this
thread.

The point I am making is that using HTTP asymmetrically (i.e the
client
always POSTs, the printer always listens for POST - which is the
'natural'
use of HTTP) precludes the core IPP protocol from generating
asynchronous or
unsolicited reverse messages. This is a major limitiation - I
want to be
sure that everybody knows that we are doing it and that we all
accept the
trade-off. I'm sure we could invent lots of hacks later on the
will work
round this but that's not an ideal solution. What will actually
happen is
that we will all poll :-(

> -----Original Message-----
> From: Carl Kugler [SMTP:kugler@us.ibm.com]
> Sent: Wednesday, February 04, 1998 9:40 AM
> To: ipp@pwg.org
> Subject: Re: IPP> Notifications
>
> Paul-
>
> I would like to point out that the XML/new method proposal is
no better in
> this
> respect. The problem is not that IPP is asymmetric: the
underlying HTTP
> transport layer is asymmetric, and that is common to both
approaches.
>
> - Carl
>
>
>
> ipp-owner@pwg.org on 02/03/98 12:24:44 PM
> Please respond to ipp-owner@pwg.org @ internet
> To: ipp@pwg.org @ internet
> cc:
> 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?
>
>
>