Subject: SDP> Charter eyeglasses

From: Harry Lewis <[email-masked]>
Date: Wed, 15 Apr 1998 18:24:26 -0400

We were having a "host-to-Device" discussion within IPP which, in Portland, got
split off to become a separate, Server-to-Device, PWG group. Now, we have to
debate which elements of printing belong to which protocol and which group and
run the risk of channeling our discussion to one group while overlooking the
other. The idea of splitting is supported by the notion that SDP like functions
are not in the IPP charter and that the concept of a "unified" protocol is
nonsense.

Re-reading, and presenting excerpts from the charter with capitalization for
emphasis, I see that the charter, itself, may contribute some of the confusion
and frustration expressed in Portland...

Group-A... Universal protocol, grow IPP to encompass SDP requirements.

"There is currently NO UNIVERSAL STANDARD FOR PRINTING. Several protocols are
in use, but each has limited applicability and none can be considered the
prevalent one. This means that printer vendors have to implement and support a
number of different protocols and protocol variants. There is a need to define
a protocol which can cover the most common situations for printing on the
Internet."

"The further goal is to define a new application level Internet Printing
Protocol for the following core functions:

- for a user to find out about a PRINTER's CAPABILITIES
- for a user to submit print jobs TO A PRINTER
- for a user to find out the STATUS OF A PRINTER or a print job
- for a user to cancel a previously submitted job"

"The Internet Print Protocol is a client-server type protocol which
should allow the server side to be either a separate print server or
a PRINTER WITH EMBEDDED NETWORKING capabilities. The focus of this
effort is optimized for PRINTERS, but might be applied to other
OUTPUT DEVICES. These are outside the scope of this working group."

Group-B... IPP to server only, Totally separate SDP discussion.

"There is currently no universal standard for printing. Several protocols are
in use, but each has limited applicability and none can be considered the
prevalent one. This means that printer vendors have to implement and support a
number of different protocols and protocol variants. There is a need to define
a protocol which can cover the most common situations for printing on the
INTERNET."

"The further goal is to define a new APPLICATION LEVEL INTERNET PRINTING
Protocol for the following core functions:

- for a user to find out about a printer's capabilities
- for a user to submit print jobs to a printer
- for a user to find out the status of a printer or a print job
- for a user to cancel a previously submitted job"

"The Internet Print Protocol is a CLIENT-SERVER type protocol which
should allow the server side to be either a separate print server or
a printer with embedded networking capabilities. The focus of this
effort is optimized for printers, but might be applied to other output
devices. These are outside the scope of this working group."

Granted... ALL THE WORDS are there - I'm not trying to imply that
these are the ONLY words that people read and interpret. But, at least
I see how my interpretation of the charter must differ greatly with
some others and how the resulting mismatch in expectations is fueling
many of our current disagreements.

Harry Lewis - IBM Printing Systems

---

From: [email-masked]
Date: Wed, 15 Apr 1998 18:51:33 -0400

(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: 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!

[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

---

From: Roger K Debry <[email-masked]>
Date: Thu, 16 Apr 1998 09:13:07 -0400

People correct me if I'm off base here, but I believe that
everyone wanted IPP to be everything defined in the charter.
Maybe we just failed to meet all of the goals, or at least we
haven't completed the job.

Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

[email-masked] on 04/15/98 04:27:03 PM
Please respond to [email-masked]
To: [email-masked], [email-masked]
cc:
Subject: SDP> Charter eyeglasses