IPP> Re: SDP> Charter eyeglasses

IPP> Re: SDP> Charter eyeglasses

Harry Lewis harryl at us.ibm.com
Wed Apr 15 19:29:29 EDT 1998


I agree with Don that IPP is not optimized for a print subsystem runnin=
g on an
embedded controller. And, I may even be convinced to focus on the merit=
s of


>a single..., well designed protocol to accomplish this goal and not
>a conglomeration of protocols patched together.


although not without pointing out that the Job MIB is receiving as much=


discredit, by those who have not made the effort to implement, as some =
feel
TIPSI is receiving for similar reasons - the Job MIB being the more rec=
ently
charted PWG effort.


The more important point is... will this single protocol evolve from IP=
P or
will we all be forced to adopt a standard with a control/command/respon=
se set
which, while in it's own right may be fine for server-to-host printing,=
 *is
not* the same as the IPP operations and attributes we, collectively, ha=
ve just
completed defining!


Harry Lewis - IBM Printing Systems








don at lexmark.com on 04/15/98 04:54:54 PM
Please respond to don at lexmark.com
To: Harry Lewis/Boulder/IBM at ibmus
cc: Sdp at Pwg.Org
Subject: Re: SDP> Charter eyeglasses






(I purposefully didn't sent this to the IPP group, anyone interested in=
 SDP
should be subscribed to this list.)


I agree with Harry in that there are multiple ways to interpret the
original IPP charter; however, rather than looking at the charter, I wo=
uld
like to look at the result.


I content that IPP is not optimized for a print server/print subsystem
running on a general computing platform to communicate with a
printer/marking engine running on a separate piece of hardware, e.g.
     - long, internationalized, text-string parameter based
     commands and responses are not optimal for an embedded product.
     - no support for alerts, etc.
     - no detailed control and status information e.g. TIPSI's
     "gas gauge" supplies level reporting


s
the target of the SDP.  It therefore needs to be optimized for:
     - delivering the job
     - reporting printer configuration and status
     - setting printer defaults
     - supporting alerts from the printer to the server
     - reporting the results of printing the job (accounting)


I continue to maintain that we need a single large, well designed proto=
col
to accomplish this goal and not a conglomeration of protocols patched
together.


**********************************************
* Don Wright                 don at lexmark.com *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************










=



More information about the Ipp mailing list