Subject: Re: IPP> MOD - Push back on simplifying Print operation response

From: Tom Hastings <[email-masked]>
Date: Wed, 19 Feb 1997 22:59:50 PST

Larry, HTTP convenor, points out that HTTP 1.1 has concept of connections,
so that a client could perform a Print Operation followed by two Get-Attributes
operations, one to the Job using the URL returned in the Print operation 
and one to the Printer using the same URL that the requester supplied in the
Print operation, as a single connection rather than the 3 complete set up/tear 
down connections that HTTP 1.0 requires.

However, if the real Printer state of interest is not the Printer to which the
client submitted the Print operation to, but is some downstream Printer or
output
device that the submitter couldn't even know about, then the requester doesn't 
know what Printer URL to pass in the second Get-Attributes operation to get the
Printer state, if the original Printer object fans out to several other Printer
objects or to more than one output device or forwards the jobs to another
Printer.

Currently there is no job status attribute that returns a URL of
the Printer to which the job has been assigned, only output-device-assigned
which returns the text string name, not a URL.  If a Printer fans out to several
output devices or forwards the job to another Printer, there isn't a way in the 
current IPP Model to get the status of the particular output device that the
job 
is using or will be using.

That is why in ISO DPA, we have a job-status *job* attribute called
printer-state-of-printers-assigned, so that a client could determine the
state of
the printer(s) that a job was using or was going to use simply by specifying the
job-identifier as the input parameter in a Get-Attributes operation.
The client doesn't have to know anything about fan-out and does not have to know
anything about the printer configuration.
Also the ISO DPA Printer operation returns the value of the job's
printer-state-of-printers-assigned attribute in the Print result, so the client
doesn't need to make another query of the server to get the Printer state
and the client gets the proper printer state, independent of the configuraion
of the printers.

So even though the efficiency argument is no longer valid, assuming that
HTTP 1.1
will be being used when heavy traffic use of IPP is a reality, the simplicity to
the client of requiring the return of the printer-state, and
printer-state-reasons, 
in the Print operation response is still compelling to me.  Getting the printer
status right after the Print submission is something we want to have work with
all Printer implementations and all Printer configurations; we do not want to
require the client to do different tricky additional operations depending on
the 
Printer implementaton and the Printer configuration.

Now that IPP has both a simple printer-state and a printer-state-reasons, both
need to be returned in the Print operation.  The most recent proposal that I
just sent out on printer-state and printer-state-reasons proposes that the
needs-attention is not a printer-state, but a printer-state-reasons condition,
since an idle and a processing printer can need attention (usually, its a
processing
Printer that needs attention, but an idle printer could get too hot, or a user
could remove an input tray from an idle printer, or open a door).

On the other hand, we could have the Print operation return two URLs (instead
of any Job and Printer status and reasons):
one for the job and one for the Printer to be used to get printer status
for this job (and add a corresponding printers-assigned-urls job status
attribute 
to the job object, so that a client could determine what Printer URL to use
later).
Then the client could make two subsequent Get-Attribute calls in the same
HTTP 1.1
connection after getting the response from the Print operation.

A third alternative would be for Print to return only the Job URL, but the
client
could request any job attributes in the first Get-Attributes operation on
the job,
including the new job attribute: printers-assigned-urls.  The client would
use the value(s) returned from the printers-assigned-urls to get the status
of the
printers that were assigned to the job.

Comments?

Tom

>Return-Path: <[email-masked]>
>Sender: [email-masked]
>Date: Tue, 18 Feb 1997 23:00:42 PST
>From: Larry Masinter <[email-masked]>
>Organization: Xerox PARC
>To: Tom Hastings <[email-masked]>
>Subject: Re: IPP> MOD - Push back on simplifying Print operation response
>References: <[email-masked]>
>
>http/1.1 doesn't set up & tear down connectiosn for every
>call any more.
>
>

---

From: Larry Masinter <[email-masked]>
Date: Wed, 19 Feb 1997 23:30:01 PST

There's a good architectural principle in web applications that
anything you want to name you should name with a UR*. So, if
you're really thinking of doing this using the web (whether HTTP
or some other future web protocol), then it's probably a good
idea for each job (once submitted) to have its own URL, rather than
its own job-id. (Of course, the URL will probably be 
http://printer.name/job/job-id or some such, but the architecture
doesn't have to know that.)

It does make sense to return the status of both the job
and of the printer to which the job has been assigned in
a single get status request, but it also makes sense to
be able to ask a job the URL of the printer it was assigned
to, e.g., if the job failed for printer reasons, to query
the printer more carefully.

I just think you probably will do fine if you worry about the
semantics of the operations rather than the performance of
setup and teardown for operations that occur as infrequently
as print requests.

Larry