To take a brief walk down memory lane.....
At the New Orleans meeting (remember back that far) one of the initial
"requirements" mentioned was that this should be simple enough to
embed.
In fact, here is a snippet from the archives on pwg.org. Remember the
old charter3.txt?
Charter 3.0
11/8/96
Internet Printing Project (ipp)
-------------------------------
Chair(s):
Carl-Uno Manros <cmanros at cp10.es.xerox.com>
Applications Area Director(s):
Keith Moore <moore+iesg at cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand at uninett.no>
Area Advisor:
Mailing lists:
General Discussion: ipp at pwg.org
To Subscribe: majordomo at pwg.org
Archive: ftp://ftp.pwg.org/pub/pwg/ipp
Editor
Scott Isaacson <scott_isaacson at novell.com>
Description of Working Group:
This working group will work to solve the following Internet printing
problems. All solutions must be platform independent for maximum
effectiveness and deployment.
<lots of stuff snipped>
Simple enough for embedding in a network attached printer
- A legitimate implementation of this might be able to accept only
one
< the rest of the stuff snipped>
No doubt that things have changed since this early discussion, however I
agree with Bill that the "sense of urgency" is lost. The current state of
IPP is far from simple, IMHO.
Mabry Dozier
QMS
______________________________ Reply Separator _________________________________
Subject: Re[2]: IPP>PRO - Print by reference
Author: <bwagner at digprod.com (Bill Wagner)> at Internet-Mail
Date: 6/4/97 4:17 PM
There was, at least at one time, a sense of urgency to the IPP
mission. And this was accompanied by the understanding that a simple
basic capability had the best chance of rapid approval, implementation
and deployment. Indeed, one approach discussed was to provide multiple
specifications, each concentrating on one major aspect, with an
over-all structure making them compatible.
However, IPP appears to reverted to the overall grand document
approach which, I believe, will delay and possibly cripple the concept
because there will be multiple proprietary, incompatible
implementations in the field long before the ultimate IPP.
The HP/Microsoft proposal appeared to be a refreshing return to the
original concept; but it appears that IPP has simply absorbed it into
an increasingly cumbersome mass.
Although Carl-Uno suggests that the specific type of print by
reference being proposed is optional, Jay and others seem to believe
it should be a mandatory part of the base specification. I suggest
that this is undesirable, since without proper security, the
implementation is useful in some cases but generally flawed. This will
produce objections which should and will be worked out; but why put
this in the critical path of the very useful basic IPP printing
capability?
DPI, and I suspect others, do support an HTTP client as well as server
in its printer NIC's. That is not the point. The point is that if IPP
is to define internet printing successfully, it needs to get something
doable, agreeable, and widely useful out soon. IMHO, this will not
happen if functionality is increased to the point where separate
servers are needed, where IPP is only for limited special internet
applications, or where industry opposition is high.
Bill Wagner Osicom/DPI
______________________________ Reply Separator _________________________________
Subject: RE: IPP>PRO - Print by reference
Author: JK Martin <jkm at underscore.com> at Internet
Date: 6/4/97 2:49 PM
Stephen Holmstead submitted a fine posting on the pragmatic insights
as to why "Print by Reference" is so tough for embedded IPP servers,
such as network printers. (See attached message.)
I think his posting should cause the IPP project to stop for second
and consider exactly which set of solutions we're trying to solve
NOW versus the set of all known problems in the universe.
The IPP project now faces this situation:
1) Assumption: Print-by-Reference is a highly desirable feature.
2) Printer vendors declare that Print-by-Reference is too difficult
or otherwise costly to implement in low-cost embedded devices.
Some folks seem to think the obvious conclusion is:
Therefore, remove Print-by-Reference as a base requirement.
Am I the only person in the IPP world who has a hard time with this
conclusion? Or is this one of the not-so-subtle differences between
the two conformance levels of "IPP Level 1" and "IPP Level 2"?
Or is the base assumption of "Print-by-Reference is a Good Thing" an
invalid assumption?
I agree with Microsoft's stated belief that print services are best
provided by a front-end (host-based) server that "feeds" the printer
in a manner consistent with local policy (whatever that may be).
The continued drive by printer vendors to be "everything to everyone"
will continue to drive DOWN the set of base capabilities for new
network printing standards. We will continue to beat our heads against
the wall trying to make such standards scale from Enterprise-strength
down to simple peer-level printing at the consumer level.
If we are unable (or unwilling) to develop parallel sets of standards
that deal with scalability in a sane manner (which is very tough and
ugly, I'll admit), then why can't we focus on a "top-down" approach
that first addresses the Enterprise, then move on to a more consumer-
oriented (peer-level) standard?
While many folks in the IPP won't admit it, they are very focused on
using IPP as the vehicle for the pay-for-print Copy Shop solution.
These folks often cite that consumer-level clients will want to take
advantage of Copy Shop services via IPP...and this may be very true.
However, there is a tremendous difference between consumer-side clients
and consumer-side IPP servers. Based on Stephen's posting, it's fair
to say that low-end printers fall into the camp of consumer-side IPP
servers.
The question is, will the typical Copy Shop employ consumer-side IPP
servers, or will they more likely use higher-level Enterprise-side IPP
servers? My money (pun intended) is on the Enterprise-side for this
particular scenario.
Enterprise customers, on the other hand, are quickly moving their backbone
printing services away from peer-to-peer printing to server-based printing
to better manage their printer assets. That is, there is no desire for
clients to print directly to the network printer; hence, the need for the
printer to perform IPP services in this scenario is also quite weak.
I agree with Roger deBry that Print-by-Reference should be a base
capability for IPP. I also believe that we are headed for a trip
through Interoperability Hell if we continue along the track of
supporting multiple levels of IPP conformance, and that we should only
focus on a single conformance level at this time.
Anyone out there with an opinion on this situation?
...jay
PS: Print-by-Reference is not the only instance of this "High-vs-Low"
struggle. Similar situations have been repeatedly arisen in the
Job Monitoring (JMP) and Printer MIB/MIF (PMP) projects over the
course of the last four years.
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
----- Begin Included Message -----
From: Stephen Holmstead <stephen_holmstead at hp.com>
To: "'ipp at pwg.org'" <ipp at pwg.org>
Subject: RE: IPP>PRO - Print by reference
Date: Wed, 4 Jun 1997 11:00:26 -0600
Encoding: 22 TEXT
Print by reference is REALLY tough for the printer to do. Up until this
point, the printer only had to do http server capabilities (which can be
implemented fairly easily). However, print by reference now would require
the printer to implement http client capabilities (which is HUGE!!, not to
mention how unstable the client features are and the fact that the printer
most likely won't ever have a flash upgrade). What about all of the
embedded graphics files (gif, jpeg, pcx, tiff, etc.)? Does the printer
have to have code to convert all of these to printable output? What about
other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, etc.)? Does the
printer have to have code to handle all of these? What about plug-ins and
applets? Does the printer have to have a Java Virtual Machine to run Java
applets? The client (i.e. Browser) is quite large and has too many
features to be able to support by a printer.
I have to strongly protest print by reference as it causes the requirement
load on the printer to skyrocket.
--
Stephen Holmstead
Hewlett Packard Internet Solutions Operation
stephen_holmstead at hp.com
----- End Included Message -----