Subject: Re[2]: IPP>PRO - Print by reference

From: "gregory leclair" <[email-masked]>
Date: Wed, 04 Jun 97 10:37:13 PDT

IMHO, I think the Print by reference requirement should stay in IPP.  

The client capabilities are defined by the implementation. An example is the 
difference in capabilities between browsers, say Lynx (text) vs Navigator or 
Explorer.

A simple printer can define its capabilities and make those known.

------------------------

Greg LeClair
EPSON Imaging Technology Center
[email-masked]

______________________________ Reply Separator _________________________________
Subject: RE: IPP>PRO - Print by reference
Author:  Stephen Holmstead <[email-masked]> at Internet
Date:    6/4/97 10:20 AM

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]

---

From: JK Martin <[email-masked]>
Date: Wed, 4 Jun 1997 15:24:00 -0400 (EDT)

> >What about other files (.doc, .prz, .ppt, .xls, .mov, .avi, .pdf, 
> >etc.)?  Does the printer have to have code to handle all of these?  
> 
> Not unless you can watch movies on a piece of paper :)
> Seriously, there are some data types that shouldn't HAVE to be printed.
> That's the whole point of a PDF file (which should be handled).

Hmmm...  Interesting thought.  (Not about movies on the printer, but
being able to handle a wide variety of data types..  ;-)

Say I am an IPP client and I tell my friendly IPP server to print a file.
In that request I declare the incoming data type to be "crap-from-mars".

Of course, the IPP server (only recognizing "crap-from-earth") would
reject the request out of hand.

In the case of Print-by-Reference, why wouldn't the printer just reject
the client request once it has realized that the target URL contains
data of an unsupported type?  Granted, this assumes the entire printing
process is lock-step-sequential, whereby the client remains connected
to the server during the print processing, or at least long enough for
the server to know whether it can actually print the requested job.

If, on the other hand, the IPP server queues the Print-by-Reference
request, then wouldn't it seem reasonable for the server implementation
to simply print an "error page" in place of the actual print data?

In either case the job status information would reflect the actual
final outcome.

Doesn't seem like that big of a deal.  Of course, I don't develop
printers for a living...  ;-)

Just some thoughts.

	...jay

---

From: JK Martin <[email-masked]>
Date: Wed, 4 Jun 1997 15:46:37 -0400 (EDT)

Jeff,

You know, your response leads me to say something that may seem like
a contradiction to some:

  If forced to decide on whether to include Print-by-Reference as
  a base IPP requirements VERSUS having only a single level of IPP
  conformance, then I would vote for the single level of conformance
  in a heartbeat.

Yeah, that means I'd be willing to give up the highly desired feature
of Print-by-Reference if it resulted in a SINGLE level of IPP conformance
for the first release of IPP in the marketplace.

Interoperability is Number One.  All else is subordinate.

Hmmm... that's putting the cart before the horse.  How about:

Pervasive acceptance and deployment is Number One.  And this can only
be achieved (from industry experience) by pervasive interoperability.

Thanks for helping with the prioritization process, Jeff.

	...jay

PS:  Now, about that SWP proposal from Microsoft and Hewlett-Packard...

When are the others in the IPP list going to start the discussion on
this topic, the very thing that created the "Levels of Conformance"
thing in the first place?...

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

>From [email-masked] Wed Jun  4 15:37 EDT 1997
From: [email-masked] (Jeff Copeland)
Subject: Re: IPP>PRO - Print by reference
To: [email-masked] (JK Martin)
Date: Wed, 4 Jun 1997 13:36:27 -0600 (MDT)
Cc: [email-masked]

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
	folks --- I think Jay's statement:

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

	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

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

---

From: [email-masked] (Bill Wagner)
Date: Wed, 4 Jun 1997 16:17:11 -0400

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 <[email-masked]> 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.

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

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

---

From: Stephen Holmstead <[email-masked]>
Date: Wed, 4 Jun 1997 15:05:36 -0600

Michael E.  Gaines wrote:
>If IPP takes off, then I believe
>responsible web masters will place data on pages in a format that will
>be suited for IPP devices and all will be well.

Right now, web masters don't even put their pages in a format that will be 
suited for both Internet Explorer AND Netscape!  Some do 'frames only' 
pages.  Why do you think this will change?

Ok, I did notice that you wrote "responsible web masters", but I don't 
believe that I have met one yet. :-)

---

From: [email-masked]
Date: Wed, 04 Jun 97 17:01:22 -0600

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 <[email-masked]>
      
      Applications Area Director(s): 
          Keith Moore  <[email-masked]>
          Harald Alvestrand  <[email-masked]>
      
      Area Advisor:

      Mailing lists: 
          General Discussion:  [email-masked]
          To Subscribe:        [email-masked]
          Archive:             ftp://ftp.pwg.org/pub/pwg/ipp
     
      Editor
          Scott Isaacson <[email-masked]>
      
     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:  <[email-masked] (Bill Wagner)> at Internet-Mail
Date:    6/4/97 4:17 PM

     

     
     
     Bill Wagner  Osicom/DPI

     

     

     

     

     

     

        ...jay

     

     

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

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 06 Jun 1997 10:20:37 -0400

>>>>> "LM" == Larry Masinter <[email-masked]> writes:

LM> I think that you might want to allow a 'reference'
LM> to be a compound attribute consisting of a URL (the
LM> location of the referenced resource) and the credentials
LM> (the authority by which the reference is being accessed),

  Without quoting all of it, I agree completely with Larrys suggestion
  to formulate print-by-reference to allow including 'transferable'
  credentials (there are security schemes out there that include such
  things).  If there are no credentials supplied, the request
  degenerates to my suggestion that the printer provide credentials of
  its own, etc...

--
Scott Lawrence           EmWeb Embedded Server       <[email-masked]>
Agranat Systems, Inc.        Engineering            http://www.agranat.com/