Subject: Re: IPP>MOD - Too Many IPP Operations?

From: [email-masked]
Date: Wed, 28 May 1997 11:13:45 -0400

Roger:

My understanding is as follows:

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

In the simple case of 1 job/1 document:

 PrintJob - Creates a job and send it to be printed.

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

Rather than overloading PrintJob we have added CreateJob
to support multiple documents per job.

CreateJob - Use to create a job on the server which
                           responds with some job identifier

SendDocument - Used multiple times to send the
                           multiple documents which make up the job
                           created with CreateJob

With a server that does not support multiple documents
per job, the CreateJob operation is rejected.  The client
can either split the multiple document job into multiple
jobs or go look for a server that supports multiple
documents per job.

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

ValidateJob is just as you describe.

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

Hope this helps!

Don

To:       ipp%pwg.org @ interlock.lexmark.com
cc:        (bcc: Don Wright)
From:     rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA
Date:     05/28/97 10:18:34 AM AST
Subject:  IPP>MOD - Too Many IPP Operations?

You all must pardon me if I am covering ground that has been covered
before, but since I was not able to attend the IPP meetings last week my
thinking may be a bit behind where everyone else is at.
In reading through the minutes of the meeting and recent email on the
discussion list, it seems to me that we may have invented more
operations for IPP than we really need. It seems to me that we added
CreateJob to allow a client to validate job attributes prior to sending
all of the print data.  The original send operation (which I think we are
back to) simply transmits the print data. The deBry/Carter proposal
to use multiple send Documents was not accepted. We are
depending upon http chunking to allow the client to send the
print data in pieces and  upon tcp/ip to guarantee delivery.
We added Validate and PrintJob to provide for the simple print case
proposed by Microsoft.  As I read the minutes and email it also seems
that we generally agreed that well behaved clients would always know
printer characteristics, either because the Printer has been "installed"
on the desktop or the client has queried the capabilities of the printer.
So as I see it, we are left with the following:
CreateJob - used to validate the print job
Validate - used to validate the print job
SendDocument - its only value is to transmit the job data
PrintJob - transmits the job data and the job attributes
What am I missing?  In the spirit of simplification, it appears to me that
we
could get rid of CreateJob and SendDocument. I see little value to
these operations given the current set of proposals on the table.   The
only thing I see is that I save resending the job attributes in the
sequence
CreateJob, SendDocument over the sequence Validate, PrintJob.  Since
a well behaved client would know the capabilities of the Printer it would
normally not be necessary to validate job attributes and PrintJob
would almost always be the preferred method to use.

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

---

From: Roger K Debry <[email-masked]>
Date: Wed, 28 May 1997 12:26:15 -0400

We should not design a protocol that depends upon  failure
of an operation in order for clients to know what to do next.  If the
client  doesn't know what the Printer is capable of doing it should
ask, not  assume something works and wait to see if it does or not.

Sure, we have to consider what happens when an operation
fails, but we should not require failure to occur in order to do
simple operations.

The logic you suggest seems complex and poor design.  It puts
extra burden on the client, which I would think we want to keep
as simple as possible.

The client logic ought to be:

Do I know I know about the Printer?

If no - query the printer, otherwise go ahead

Send a PrintJob operation with the job attributes
and the document(s) to be printed.  If the response to
the query tells me that the Printer only supports one
document per job, I will do multiple PrintJobs, otherwise
I will put all of the documents in one PrintJob.

I don't view this as overloading the PrintJob operation.

Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/28/97 10:04
AM ---------------------------

        don @ lexmark.com
        05/28/97 09:22 AM
Please respond to [email-masked] @ internet

To: Roger K Debry/Boulder/IBM
cc: ipp @ pwg.org @ internet
Subject: Re: IPP>MOD - Too Many IPP Operations?

Roger:

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

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

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

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

Hope this helps!

Don

Roger K deBry

---

From: [email-masked]
Date: Wed, 28 May 1997 12:39:01 -0400

Roger:

I don't think the intent was that the only way to know if a printer
supports multiple documents per job was through the failure
of the CreateJob operation.  The intent was that if the client
failed to ask, a predictable response, i.e. a failure, would be
returned and could be acted upon.  This also insured that the
client could learn of the failure early: prior to posting megabytes
of data to a printer that couldn't support printing the
multi-document print job.

Using SendDocument to clearly separate the multiple
documents within a job was deemed to be good by those in
attendance.  Using CreateJob to start the process of printing
a multiple document job where all the documents were not
going to be sent in a single POST was deemed worthy of a
separate operation rather than a PrintJob with a special
attribute indicating there were multiple documents
within a single PrintJob.  And, as I said above, it also made
it easier for the simple implementation to deal with the case where,
through an error on the client-end, a multi-document
job was sent to a printer that couldn't support thatfunctionality.

Don

To:       Don Wright
cc:       ipp%pwg.org @ interlock.lexmark.com
From:     rdebry%us.ibm.com @ interlock.lexmark.com @ LEXMTA
Date:     05/28/97 12:26:15 PM AST
Subject:  Re: IPP>MOD - Too Many IPP Operations?

Roger K deBry

---------------------- Forwarded by Roger K Debry/Boulder/IBM on 05/28/97
10:04
AM ---------------------------
        don @ lexmark.com
        05/28/97 09:22 AM
Please respond to [email-masked] @ internet

Roger:

Don

---

From: Roger K Debry <[email-masked]>
Date: Wed, 28 May 1997 16:09:27 -0400

... snip ...
>
> The 'CreateJob' not only validates attributes but also
> determines whether or not resources can be applied NOW
> to processing a job with these requirements.
>
> RKD> This must mean that upon receiving a CreateJob, the
> RKD> Printer promises to maintain the state it was in with
> RKD> respect to requested resources until the print job
> RKD> is complete. Is this agreed?

Yes, to some degree, its possible that the server has locked down one or
moreresources to process this job.

RKD> This seems pretty loose. If a positive reponse to CreateJob
RKD> means the resources can be applied NOW (as you suggest in your
RKD> initial email) then the resources better be locked down.
RKD> If it means it is possible, to some degree, etc ...
RKD> then a positive repnsese only means that a job object
RKD> is created and waiting for job data. It means nothing in
RKD> terms of being able to print NOW.

> RKD> Does a client send CreateJob, assuming that if resources are
> RKD> not ready that the Printer will schedule the job accordingly,
> RKD> i.e. schedule all jobs waiting for A4 paper to print when A4
> RKD> paper is loaded, or does a client keep "pinging" the Printer
> RKD> with CreateJobs until it finds the resources are ready, then
> RKD> consummates the print job by sending the data?

It depends upon the type of 'resource' that may or may not be available.

In your example, you specify media as the resource in question (A4).
This is only one of numerous possible types of resources.
The response to a 'CreateJob' operation (and the clients
reaction to this response) is really dependent upon the
type of resource allocation problem that might occur,
as specified by the clients explicit or implicit job requirements.

RKD> Help me by giving some other examples where the response
RKD> might be different. I'd like to understand this better.

> RKD> If we believe that the first is the preferred method for
> RKD> handling jobs waiting for resources then I claim that just
> RKD> using the PrintJob operation works as well as CreateJob and
> RKD> SendDocument since I don't care if the resources are actually
> RKD> ready NOW or not (and I doubt that I want to keep "pinging"
> RKD> the Printer to find out).

An out of resources condition is definitely going to happen, and
yes,implementations will have to incorporate retries (much like LPD does
today) in order to see that the job is printed.

RKD> Will we really expect to see clients retry while waiting
RKD> for a resource to become available. This implies that
RKD> they understand that the resource is supported and
RKD> will become available reasonably soon (as opposed to
RKD> sometime next week). Does LPD really do this?

---

From: Harry Lewis <[email-masked]>
Date: Wed, 28 May 1997 16:57:52 -0400

I'm wondering what happened to Paul Moore's proposal to use a job attribute
rather than SendDocument to link the multiple documents in a job. I remember
the idea, discussed in SanDiego, of a job being submitted with a attribute
which indicated it was the start of a "multi-document" job and the IPP server
returning a specific URL to which all documents of this job should be submitted
(as separate jobs using a single post for each).  I thought this was the start
of a good proposal to get around what appears to be one of the main limitations
of "Simple Web Printing" which was lack of multi-doc support.

Harry Lewis - IBM Printing Systems

--------- Forwarded by Harry Lewis/Boulder/IBM on 05/28/97 02:44 PM ---------

        [email-masked]
        05/28/97 01:22 PM
Please respond to [email-masked] @ internet

To: Roger K Debry/Boulder/IBM@IBMUS
cc: [email-masked] @ internet
Subject: Re: IPP>MOD - Too Many IPP Operations?

Roger:

Don

To:       Don Wright

Roger K deBry

Roger:

Don