Subject: RE: IPP> Does the world need a robust host-to-device network prin ting protocol?

From: "Wagner, William" <[email-masked]>
Date: Thu, 12 Feb 1998 18:10:07 -0500

Considering the depth of feeling about IPP inadequacy, I suggest that
some attempt be made to more clearly identify the perceived problems...
Is it because IPP does not address the published requirements or because
the requirements were inadequate (or changed).

It seems, for example, that Mr. Walker feels that IPP is not adequate
for the Internet because too many compromises were made for the embedded
implementation. Mr. Moore, on the other hand, seems to suggest that IPP
may be fine for the internet but is inappropriate for an intranet.
(because too many compromises were made). Jay seems to be just unhappy
with IPP, suggesting perhaps that it is not good for anything (because
to many compromises were made?)

The positions  point to at least four different protocols; Internet
client to server; Intranet client to server, server to printer, and  a
client to printer. Is this what is necessary? Is it not possible to come
up with a sufficiently extensible protocol to handle all of these?

W. A. Wagner (Bill Wagner)
OSICOM/DPI

---

From: Carl-Uno Manros <[email-masked]>
Date: Thu, 12 Feb 1998 16:03:58 PST

>W. A. Wagner (Bill Wagner)

I want to remind you all that we stated as our intent when we started
work on IPP V1.0, that we were trying to solve 80% of the problem in
the first version, which means that we conciously left out a number of
things to be resolved later.

We also stated that we were trying to concentrate on solving the user
to what-ever problem in our first version, leaving some of the device
and management type problems for a future version.

Also remember, that some of the intial reactions in the IETF was that 
we were trying to do far too MUCH in IPP V1.0, while now we seem to be
hearing that there is too much missing. 
You cannot have your cake and eat it.....

I do not buy the argument that HTTP is bad, even if you choose to
use IPP to acces your print device. I think there is enough evidence
from prototyping at that stage to show that it works pretty well.
Some printer vendors started putting in HTTP in their printers to
do configuration and management even before we started talking about
using it for IPP.

I would hope that the current IPP approach can be used as a common 
basis for developing both client to print server and print server to
device communication, even though I agree that IPP V1.0 was developed 
to primarily support the former. If this results in an additional 
protocol optimized for print server to device, so be it. I expect that 
any printer that is aimed for shared use on the network would want to 
include the IPP server functionality anyway, so that leaves the
discussion about how big a share of remaining printers would really 
need an additional simpler protocol that is optimized for the device.

My 2 cents...

Carl-Uno

Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]

---

From: Jay Martin <[email-masked]>
Date: Fri, 13 Feb 1998 15:43:06 -0500

Bill,

> Jay seems to be just unhappy

Aw now, c'mon.  I have pointed out several specific concerns I
have with IPP--in the role of a host-to-device protocol--on this
DL.  Perhaps you've missed them?

I think a lot off pro-IPP folks are perhaps missing the point,
at least with regard to my concerns, and probably Paul Moore's
concerns.

Paul has repeatedly pointed out the problem of asymmetry of
IPP-over-HTTP in the context of host-to-device support.  This
is a big concern for me, also (both of us being "driver"
developers that need a good "host-to-device" protocol).

The lack of symmetry in the protocol makes life unnecessarily
difficult to develop robust, highly functional drivers.  For
example, during the job submission transaction with the printer,
the driver needs to be able to asynchronously receive events
from the printer that may cause a change in the transaction,
or at least cause the driver to "pass along" information to
the originator in a timely and reasonable simple manner (eg,
"Paper out", "PDL error", etc.)

IPP as currently defined (over HTTP) does not provide this
kind of protocol interaction...at least not very easily.
Or more specifically, not as easy as it should be when
compared to similar protocols in the Internet.

Hopefully Paul Moore will comment a bit about this,
but at least this describes one of my concerns about IPP.
Please don't say "Jay doesn't think IPP is good for anything".

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------