IPP>PRO - Print by reference

IPP>PRO - Print by reference

IPP>PRO - Print by reference

mabry at rd.qms.com mabry at rd.qms.com
Wed Jun 4 19:01:22 EDT 1997

     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 
     In fact, here is a snippet from the archives on pwg.org.  Remember the 
     old charter3.txt?
     Charter 3.0
     Internet Printing Project (ipp)
          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
          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

                < 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


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

More information about the Ipp mailing list