IPP Mail Archive: IPP> Re: SDP> Charter eyeglasses

IPP Mail Archive: IPP> Re: SDP> Charter eyeglasses

IPP> Re: SDP> Charter eyeglasses

Harry Lewis (harryl@us.ibm.com)
Wed, 15 Apr 1998 19:29:29 -0400

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@lexmark.com on 04/15/98 04:54:54 PM
Please respond to don@lexmark.com
To: Harry Lewis/Boulder/IBM@ibmus
cc: Sdp@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@lexmark.com *
* Product Manager, Strategic Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************

=