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: <masinter@parc.xerox.com>
>Sender: masinter@parc.xerox.com
>Date: Tue, 18 Feb 1997 23:00:42 PST
>From: Larry Masinter <masinter@parc.xerox.com>
>Organization: Xerox PARC
>To: Tom Hastings <hastings@cp10.es.xerox.com>
>Subject: Re: IPP> MOD - Push back on simplifying Print operation response
>References: <9702190726.AA08440@zazen.cp10.es.xerox.com>
>
>http/1.1 doesn't set up & tear down connectiosn for every
>call any more.
>
>