In order to move the ball on the host to device discussion,
I'd like to propose the following:
Assertions:
(1) IPP, as it is currently defined, is the correct protocol
for client to server, across the Internet.
(2) IPP, as it is currently defined, is the correct protocol
for client to server, across an Intranet
(3) IPP, as it is currently defined, is the correct protocol
between a server and a printer which contains an
imbedded server.
Therefore, let's focus on the open issue:
Do we need a different protocol between a print server
and a "simple" printer?
Requirements (largely from P. Moore's note)
1. Low level discovery
2. Discovery of device capabilities
3. Peer queuing
4. Machine readable asynchronous notifications
5. Security
6. Manage device settings
7. Transport neutral
8. PDL neutral
9. Capable of recovery - redriving the data stream if necessary
10. Reporting of device errors
11. Fast, wide delivery channel for print data
Proposed Work Plan
1. Agree on the problem statement (we need to address server
to simple printer case - the rest are okay with IPP as it stands)
2. Complete a requirements statement (as we did with IPP v1.0)
that is complete and concrete - get away from hand waving
3. Use the current IPP Model and Semantics document plus the
notifications work as the starting point.
4. Add new attributes or operations, as required, to meet requirements,=
or understand clearly why this will not work.
5. Define a new protocol mapping, if required, to meet server to
device requirements
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
=