Subject: IPP> 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: "Scott Isaacson" <[email-masked]>
Date: Wed, 15 Apr 1998 19:23:08 -0600

Harry,

When I read:

>>> Harry Lewis <[email-masked]> 04/15/98 04:24PM >>>
>The Internet Print Protocol is a CLIENT-SERVER type protocol which
>a printer with embedded networking capabilities. 

I assume CLIENT/SERVER in the distributed systems architecture sense
NOT in the literal CLIENT = PC and SERVER = file server/printer server hardware
box sense.  I see client/server meaning request/response rather than distribute object
remote methods, IIOP, RMI stuff. 

In other workds, I am not confused into thinking end-user to file server only (not server
to device) when I see the term "client/server"

Good reading of the charter thought, very helpful.

Scott

---

From: "Scott Isaacson" <[email-masked]>
Date: Fri, 17 Apr 1998 01:16:37 -0600

Thanks to Bob and Harry for these very reasonable, rationale points.
My comments below are just 100% percent endorsements of their comments.

>>> Robert Herriot <[email-masked]> 04/16/98 01:40PM >>>
> I agree with  Scott's interpretation.  I think we chartered IPP to solve 
> communication among clients, servers and printers, not just between end 
> users and print servers.

> I am concerned that SDP is a big mistake and will create yet another 
> protocol, incompatible with all others including IPP. I think that it is 
> reasonable to borrow ideas from other protocols, such as TIPSI, but I think 
> we should continue along the IPP path we started.

SDP is a big mistake if it is not IPP with enhancements or it is
not the ALREADY STANDARD SDP:  TIPSI.  If neither IPP nor
TIPSI could not be enahanced to meet whatever the needs of a
server to device protocol, then what makes someone thing that they
can get a group of company reps together, start from scratch, and 
get it right?! given that is what we have done several times now.

> If IPP is not a reasonable embedded solution, I wonder why we are just now 
> hearing that, nearly a year after we decided on the encoding.  If IPP is 
> really such a bad embedded solution, perhaps we should fix it before we all 
> commit to supporting it and end up with support for both IPP and SDP.

I feel that it is a reasonable embedded solution.  Any "fixes" are just part of the
process now to move IPP/1.0 to 1.1 and beyond.

---

From: "Zehler, Peter " <[email-masked]>
Date: Fri, 17 Apr 1998 04:48:48 PDT

All,
   I also believe it would be a mistake to create yet another protocol for
printing.  Some issues have been identified as shortcomings in the current
IPP mapping.  Those issues should be addressed.  There are, of course, a
number of ways to address them.  We also have need of a richer printer model
as we move IPP forward to monitor and control a print device.  We already
have a widely deployed model, the printer MIB.
   I do not believe IPP is unreasonable to embed in a device.  We should
keep the mandatory features focused on basic needs.  This approach allows
the model and protocol to scale.  As of yet I have no trouble implementing
IPP in a lower end device.
Pete
Peter Zehler
XEROX
Networked Products Business Unit
Email: [email-masked]
Voice:    (716) 265-8755
FAX:      (716) 265-8792 
US Mail: Peter Zehler
	        Xerox Corp.
	        800 Phillips Rd.
	        M/S 111-02J
	        Webster NY, 14580-9701

	-----Original Message-----
	From:	Robert Herriot [SMTP:[email-masked]]
	Sent:	Thursday, April 16, 1998 3:41 PM
	To:	Harry Lewis; [email-masked]
	Cc:	[email-masked]; [email-masked]
	Subject:	Re: IPP> Charter eyeglasses

	I agree with  Scott's interpretation.  I think we chartered IPP to
solve 
	communication among clients, servers and printers, not just between
end 
	users and print servers.

	protocol, incompatible with all others including IPP. I think that
it is 
	reasonable to borrow ideas from other protocols, such as TIPSI, but
I think 
	we should continue along the IPP path we started.

	If IPP is not a reasonable embedded solution, I wonder why we are
just now 
	hearing that, nearly a year after we decided on the encoding.  If
IPP is 
	really such a bad embedded solution, perhaps we should fix it before
we all 
	commit to supporting it and end up with support for both IPP and
SDP.

	Bob Herriot

	At 07:04 AM 4/16/98 , Harry Lewis wrote:
	>Scott, I agree with your interpretation 100% and believe this is
the only
	valid
	>interpretation. Otherwise, I think the overall charter would have
been way
	too
	>limiting - even if this is where we ended up for v1. I put the
emphasis there
	>to show how I think some must be reading the charter and the
conclusions they
	>must have made.
	>[email-masked] on 04/15/98 08:15:10 PM
	>Please respond to [email-masked]
	>To: Harry Lewis/Boulder/IBM@ibmus, [email-masked], [email-masked]
	>cc:
	>Subject: Re: IPP> Charter eyeglasses
	>
	>
	>Harry,
	>
	>When I read:
	>
	>NOT in the literal CLIENT = PC and SERVER = file server/printer
server
	hardware
	>box sense.  I see client/server meaning request/response rather
than
	distribute
	>object
	>In other workds, I am not confused into thinking end-user to file
server only
	>(not server

---

From: "Zehler, Peter " <[email-masked]>
Date: Fri, 17 Apr 1998 04:48:48 PDT

All,

	-----Original Message-----
	From:	Robert Herriot [SMTP:[email-masked]]
	Sent:	Thursday, April 16, 1998 3:41 PM
	To:	Harry Lewis; [email-masked]
	Cc:	[email-masked]; [email-masked]
	Subject:	Re: IPP> Charter eyeglasses

	Bob Herriot

the only
	valid
been way
	too
emphasis there
conclusions they
server
	hardware
than
	distribute
server only