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

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

Randy Turner wrote:

You are not considering the other advantages of the 'CreateJob'
operation. The 'Validate' option only validates a set of
attributes against what a particular object supports. It
has no relationship to a job. Meaning that just because
you send a 'Validate' request, does not necessarily mean
that a print job is next in the sequence.

RKD> No, but it might be.

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?

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?

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

Also, 'CreateJob'
returns the URI for the job object created immediately so you have some
way to either do a 'GetAttributes'
or a 'Cancel' on the job if either one of these operations is required.

RKD> Doesn't PrintJob return a URI? If not why doesn't it?

If you're looking to delete operations, 'Validate' would go before
'CreateJob' IMHO.

---

From: Randy Turner <[email-masked]>
Date: Wed, 28 May 1997 12:15:38 -0700

> 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> 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> 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> Doesn't PrintJob return a URI? If not why doesn't it?

Yes, 'PrintJob' does return a URI, but only after all of your job data
has been
transferred. Over the internet, this is completely non-deterministic.

Randy