I want to remind you all that we stated as our intent when we started
work on IPP V1.0, that we were trying to solve 80% of the problem in
the first version, which means that we conciously left out a number of
things to be resolved later.
We also stated that we were trying to concentrate on solving the user
to what-ever problem in our first version, leaving some of the device
and management type problems for a future version.
Also remember, that some of the intial reactions in the IETF was that
we were trying to do far too MUCH in IPP V1.0, while now we seem to be
hearing that there is too much missing.
You cannot have your cake and eat it.....
I do not buy the argument that HTTP is bad, even if you choose to
use IPP to acces your print device. I think there is enough evidence
from prototyping at that stage to show that it works pretty well.
Some printer vendors started putting in HTTP in their printers to
do configuration and management even before we started talking about
using it for IPP.
I would hope that the current IPP approach can be used as a common
basis for developing both client to print server and print server to
device communication, even though I agree that IPP V1.0 was developed
to primarily support the former. If this results in an additional
protocol optimized for print server to device, so be it. I expect that
any printer that is aimed for shared use on the network would want to
include the IPP server functionality anyway, so that leaves the
discussion about how big a share of remaining printers would really
need an additional simpler protocol that is optimized for the device.
My 2 cents...
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514