Subject: RE: IPP>PRO - Print by reference

From: JK Martin <[email-masked]>
Date: Wed, 4 Jun 1997 14:49:20 -0400 (EDT)

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

----- Begin Included Message -----

>From [email-masked] Wed Jun  4 13:14 EDT 1997
From: Stephen Holmstead <[email-masked]>
To: "[email-masked]'" <[email-masked]>
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
[email-masked]

----- End Included Message -----

---

From: [email-masked] (Jeff Copeland)
Date: Wed, 4 Jun 1997 13:36:27 -0600 (MDT)

JK Martin wrote,
	a well-thought-out message about print-by-reference, ending with
	the question,
> Anyone out there with an opinion on this situation?

	As an employee of a printer company (though speaking for
	myself :-), I have to agree with Stephen Holmstead's misgivings
	about IPP getting so bloated that it can't fit into a printer.

	Jay, you and I are seeing different things:  I'm hearing from
	our marketing folks that people actually *do* want all that
	functionality in the printer, rather than having to hang printers
	off of servers.

	However, that discussion aside --- mostly because I need to think
	up arguments as well-reasoned as the ones of Jay's to which I'm
	responding, and beat some more information out of the marketing

> focus on a single conformance level at this time.

	is a vitally important point.	No matter what we decide on
	this issue -- or a host of others like it -- if we don't have a
	single IPP conformance level, we will have simply shot ourselves
	in the foot.  Let's remember this every time one of us mentions
	multiple conformance levels.

-- 
Jeffrey L Copeland			+1-303-443-7227 x14
QMS, Inc, Boulder R&D Center		fax:  +1-303-443-7107
2945-D Center Green Court South		[email-masked]
Boulder, CO 80301

---

From: Larry Masinter <[email-masked]>
Date: Wed, 4 Jun 1997 13:14:32 PDT

A HTTP client is not the same thing as a web browser.
One way to simplify the 'footprint' requirement is to
assert that any 'reference' that you want to 'print by'
must be from, for example, a HTTP server, be directly
available without redirection, and only be in a media type
that the printer said it already supported.

So, the implementation on the printer end would be basically:
    open a connection to the host in the URL
    send "GET url HTTP/1.1" and "accept: application/postscript"
    read the result: 
      if not 200, error
    read headers:
      scan for content-type; if type isn't recognized, error
    read data as print data.
    close connection

Maybe 100 lines of code? Certainly not megabytes.

Don't turn a little capability (print by reference) into a big one
(printer is a web browser) and then complain that the result is too big.
-- 
http://www.parc.xerox.com/masinter