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