IPP> suggested workplan - host to device protocol

IPP> suggested workplan - host to device protocol

Roger K Debry rdebry at us.ibm.com
Tue Feb 17 10:00:40 EST 1998


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


















=



More information about the Ipp mailing list