Subject: IPP> Re: SDP> Charter eyeglasses

From: Harry Lewis <[email-masked]>
Date: Wed, 15 Apr 1998 19:29:29 -0400

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

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

---

From: "Turner, Randy" <[email-masked]>
Date: 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.

Randy

	-----Original Message-----
	From:	Harry Lewis [SMTP:[email-masked]]
	Sent:	Wednesday, April 15, 1998 4:29 PM
	To:	[email-masked]
	Cc:	[email-masked]; [email-masked]
	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 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!

	(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

	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.