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 -----