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

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

RE: IPP> Re: SDP> Charter eyeglasses

Turner, Randy (rturner@sharplabs.com)
Wed, 15 Apr 1998 21:28:51 -0700

I believe the IPP model document stands on its own merits. It defines
the model for printing as we know it today. Whether your printer is on
your wrist watch, or whether it fills a 10'x20' publishing room. I'm not
sure I really care about how the SDP is transported, or what media is
used to deliver it. Where I would be concerned is if someone decided to
define another "model" for SDP; which I think would be extremely
unfortunate, especially for the 99.9% of the printer industry that would
be forced to write complicated gateways to connect these two paradigms.


-----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
>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
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
running on a general computing platform to communicate with a
printer/marking engine running on a separate piece of hardware,
- long, internationalized, text-string parameter based
commands and responses are not optimal for an embedded
- 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

* 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) *