> CBM> The first set of IPP implementations will most certainly be of type
> CBM> print server that can front for any type of printer, including a $150
> CBM> printer which is hooked up directly to the print server machine.
> CBM> The next stage is more likely to include IPP servers embedded in
> CBM> print devices connected to the network, and whether that networked
> CBM> printer fits on a desktop or not seems really irrelevant.
Ok, this sounds better to me. (Does everyone else agree with this??)
As far as deriving base constraints goes, to me the real question is:
Must an "IPP Printer" must be able spool print jobs?
I would like to see an answer of "Yes", but clearly this is where desktop
printers (and many, if not most, network printers) fail to perform. And I
believe this is usually the reasons behind most case of "we can't do that
due to printer limitations."
> CBM> I do not think that anybody is neglecting the intranet type scenarios.
The phrase "neglecting the intranet" may not be the best choice of words
here. With all due respect, the IPP may be "neglecting to provide a
reasonably simple and efficient network printing protocol for the intranet."
I'm hoping the Model team can start working more closely with Netscape
(as briefly discussed during today's telecon), whereby we investigate the
approach of adding a new standard protocol to web browsers. This approach
could end up making all parties happy in the end.