Subject: IPP>MOD - Print by reference

From: Roger K Debry <[email-masked]>
Date: Wed, 11 Jun 1997 09:54:47 -0400

There has been quite a storm of email on the print by reference subject lately.
Let me once again define what I believe to be a very significant customer
requirement that print by reference can satisfy.  In very carefully fencing
this requirement it is important to say what it is not.

It is NOT printing web pages. Much of the concern I have seen expressed in
recent email, especially from HP, has to do with printing web pages. I agree
that chasing links and dealing with the multitude of data types on the web is
very complex and could potentially bloat a Printer implementation.

It is NOT printing documents that require some security mechanism to
access them. In particular it does not deal with the printing of documents
where the right to print a copy of the document must be purchased.  As
Larry Masinter has suggested, the protocol may reserve some "space"
to encode credentials for such transactions, but I do not want to complicate
the model nor hold up approval of IPP as a standard trying to architect and
get approval of these security mechanisms.

There are at least two examples of what I think print by reference is for
version one of IPP:

First, consider the case of documents, such as Internet-Drafts, or those
documents which we have on the PWG ftp site which are accessible
by anonymous ftp, i.e. they are "publically accessible".  Print by
reference is a powerful tool for printing such documents. Documents
are in some print-ready format, such as Postscript.

Second, consider the case where an enterprise keeps a library of
documents (standards, reports, procedures, etc) on a central
repository that is accessible by anyone within the enterprise
firewall. It would probably be on a private internal network. Print
by reference is again a very powerful tool for printing such
documents which are in some print-ready format.

To summarize, this simple version of print-by-reference only
requires that the documents to be fetched are already
formatted for printing.  The Printer does not deal with links,
it does not format pages, it does not deal with dynamic web
formats, etc.

Roger K deBry
Senior Techncial Staff Member
Architecture and Technology
IBM Printing Systems
email: [email-masked]
phone: 1-303-924-4080

---

From: [email-masked]
Date: Wed, 11 Jun 1997 10:03:13 -0400

I have been listening to this discussion for a long time and I recognize
the
need for a human being to be able to print by reference.  This function can
be easily provided with HTML, etc on a Web page hosted by an IPP print
server (actually IPP is not even needed for this solution.)  Is the need as
pressing for this to be done programmatically?  The bottom line is can this
function be provided outside the scope of the IPP protocol?  If the
programmatic need is strong, is it sufficient to standardize the way this
is
done with HTML so that once the URL of a print by reference page is
know, a print by reference job can be submitted to it under program
control?

This could just be part of a multi-pronged standard approach.  Instead of
defining an all encompassing IPP standard, maybe we should
look at this from a difference perspective.  Do we really need:

1) An IPP Job Submission protocol
-and-
2) An IPP Print by Reference standard
-and-
3) An IPP Job Management protocol
-and-
4) An IPP Print Capability Discovery protocol
etc, etc, etc.

I know "compliance levels" and print by reference are not strictly related
but I would like to be able to define all these functions in a standard
way without requiring "compliance levels" or burdening the lowest
implementation with too much baggage.

... all right... fire away!!

Don

---

From: Roger K Debry <[email-masked]>
Date: Wed, 11 Jun 1997 10:31:11 -0400

Don, I got lost trying to follow your first paragraph. Perhaps you can
provide more details. Maybe its just to early in the morning for me! :-)

In all of the discussions we have had on this subject, we have agreed
that IPP only defines the way a reference is included in the print request.
It does not define the mechanism by which the Printer actually fetches
the document.  If the document reference is a URI, then I assume the
Printer would use the method inferred by the URI, e.g. ftp or http.

Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 06/11/97 08:22
AM ---------------------------

        ipp-owner @ pwg.org
        06/11/97 08:23 AM
Please respond to [email-masked] @ internet

To: ipp @ pwg.org @ internet
cc:
Subject: Re: IPP>MOD - Print by reference

Don

---

From: [email-masked] (Bill Wagner)
Date: Wed, 11 Jun 1997 13:00:44 -0400

Don, 
     
     I certainly agree that the approach should be pursued, although 
     perhaps the actual division might be somewhat different. Indeed, as I 
     may have inadequately indicated before, I thought Carl-Uno had 
     suggested that something like this may be necessary a long time ago.
     
     The key, and perhaps the difficult part, is to ensure that the various 
     related but independently specified IPP services, are compatible with 
     each other so that a device could support all services in a cohesive 
     way. 
     
     Bill Wagner, Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: Re: IPP>MOD - Print by reference
Author:  [email-masked] at Internet
Date:    6/11/97 10:03 AM

Don

---

From: [email-masked]
Date: Wed, 11 Jun 1997 17:37:56 -0400

> provide more details. Maybe its just to early in the morning for me! :-)
It is very easy to create a "fill in the blank" form that allows the user
to tell the server where the document is located, e.g. provide the
URL.  This filled out form can then kick off a CGI script or whatever
other means is available to execute a program of some kind to
go off, fetch the requested file, and then add it to the server's
job queue.  Alternatively, this process could be done on a
different server and submitted via IPP to the desired print
server.

The who issue with this concept is that doing it is easy for the
human being but much more difficult to do programmatically.

Is my explanation a little better?

Don

---

From: Harry Lewis <[email-masked]>
Date: Wed, 11 Jun 1997 19:38:27 -0400

Don, your question is crucial.

>Do we really need:
>etc, etc, etc?

 I've tried to indicate similar feelings and been laughed out of the room
(figuratively) for suggesting 3 and 4 could be handled via the Job and Printer
MIBs.

I'm drawing a conclusion that much of the churn on these issues relates to the
separate worlds that Jay described so well in a previous note to the JMP (which
I am including here, out of context).

>Seriously, some of us firmly believe in the importance of "out of band"
>job monitors (ie, processes monitoring job progression without being
>intrinsically part of the printing process, a la Unix and VMS).  The
>only consistent way to indentify jobs is through jobOwner, and hence,
>this data must be available for as long as the job entry exists in the
>agent.
>
>Those who will be using the Job MIB as an intrinsic part of the
>printing process are lucky (eg, Windows, OS/2, etc).  (We envy you,
>believe us!)  If someone can state a justifiable case for being able to
>monitor jobs with jobOwner, then great!  (And please do so soon!)
>Otherwise, we need that data for the duration of the job entry.

The point is, those who feel more comfortable with IPP as a "web based
submission protocol", by my observation, relate strongly with the intrinsic,
integrated print frameworks provided by Windows, OS/2 and similar operating
systems. In these environments, an end-to-end, all encompassing print protocol
is unnecessary because there is a query and status API (if you will) to
facilitate communication with the printer via some means other than the
submission protocol.

I think the desire for IPP to be all encompassing - query, submit, monitor,
control - stems from platforms which do not supply a "robust" print framework
as part of the native OS, today. Here, a robust replacement for LPR/LPD would,
appropriately,  include everything.

I don't want to ignore or prioritize any one platform (or family) but, if my
distinction is at all accurate, I think it would be a good idea to develop IPP
components that can work together in an end-to-end solution but also may
operate separately (at least the submission piece) in environments that do not
need or warrant a full solution.

>>> Harry Lewis <<<

---

From: Roger K Debry <[email-masked]>
Date: Thu, 12 Jun 1997 08:14:09 -0400

Harry Lewis Wrote ...

<RKD>  I don't think this is necessarily the case.  I believe there are some
(at least one) who believe that
<RKD> a single protocol is just simpler and more elegant that a set of
different, but related intefaces.