I agree with Carl-Uno that we did what we said we were going to do. And
I, for one, am optimistic about what we have done for both intranets and
internets. We have a model and framework for printing, and outside of
more advanced job management and async notifications (which we clearly
knew from the get-go we wouldn't do for 1.0), we've got a very good
printing solution.
Randy
-----Original Message-----
From: Carl-Uno Manros [SMTP:cmanros at cp10.es.xerox.com]
Sent: Thursday, February 12, 1998 4:04 PM
To: ipp at pwg.org
Subject: RE: IPP> Does the world need a robust
host-to-device network printing protocol?
At 03:10 PM 2/12/98 PST, Wagner, William wrote:
>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
>
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: manros at cp10.es.xerox.com