Well, it looks like it is dead for the moment.
The W3C has closed down their project on it, and Henrik, who was the project
leader, is moving from W3C to Microsoft.
The IETF thought the whole thing was too ambitios and is only considering a
part of it to do with multiplexing, but that has been kind of quiet about
that also, no activity on this at all in Oslo.
Carl-Uno
> -----Original Message-----
> From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of
> kugler@us.ibm.com
> Sent: Friday, July 30, 1999 8:21 AM
> To: ipp@pwg.org
> Subject: Re: IPP> NOT - Suggested resolutions to the 27 Is
>
>
> <37a19d20.64ae693-@easysw.com> wrote:
> original article:http://www.egroups.com/group/ipp/?start=6092
> > Hugo Parra wrote:
> > >
> > > We've said that IPP Notification would allow printers to use
> > > "general-purpose" Event Notification Services available to them
> > > on the network. By not supporting straight TCP notification we
> > > might be hampering the implementation of this requirement. I
> > > don't understand why supporting the suggested three application-
> > > level protocols should preclude us from allowing straight TCP
> > > subscriptions that can be easily routed through network
> > > notification services.
> >
> > The problem is that using a direct TCP or UDP type of connection does
> > not allow any kind of error checking, and makes receiving multiple
> > messages over the same link potentially dangerous.
> >
> > There is talk of defining a (simple) alternate transport protocol for
> > IPP that can be used over things other than TCP/IP (in fact, I think
> > it's one of the things on the new IPP charter?), and that would
> > probably allow a direct TCP or UDP connection for notification.
> >
>
> Hey, what ever happened to HTTP-NG? That would have provided an
> excellent solution to these problems. When I last looked at it, it had
> a general application-level protocol that was like a peer-to-peer OO
> RPC.
>
>