Randy
-----Original Message-----
From: Harry Lewis [SMTP:harryl@us.ibm.com]
Sent: Wednesday, April 15, 1998 4:29 PM
To: don@lexmark.com
Cc: sdp@pwg.org; ipp@pwg.org
Subject: IPP> Re: SDP> Charter eyeglasses
I agree with Don that IPP is not optimized for a print subsystem
running on an
embedded controller. And, I may even be convinced to focus on
the merits 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 recently
charted PWG effort.
The more important point is... will this single protocol evolve
from IPP or
will we all be forced to adopt a standard with a
control/command/response 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, have 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 would
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
From my perspective, this is clearly server to printer
communications is
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 protocol
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) *
**********************************************