Michael,
Thanks for pointing out this issue on the current Set-Job-Attributes
operation.
The IPP WG has debated whether or not operations should have side effects,
such as whether or not the Set-Job-Attributes operation should move a job
from one Printer to another, if the "job-uri" attribute is modified.
Generally, we have tried to avoid side-effects. Also we have tended to
separate into separate operations things that might not be supported by
everyone. Then we get better interoperability.
The ISO DPA (Document Printing Application) WG also debated this same issue
back in the mid 1990s when doing Part 3 of ISO 10175. For ISO DPA we came
up with the Resubmit-Job operation in which the Printer acts like a client
and submits the identified (pending or held) job to the indicated target
Printer (using the ordinary Create-Job operation). The target Printer MUST
do all of the validation. As far as the target Printer is concerned, the
old Printer is just like any other client submitting a job. If any
validation fails, then the new Printer returns the results (including the
unsupported and/or conflicting attributes) to the original Printer which in
turn returns the results to the client. Thus the Resubmit-Job Response to a
client looks like the response to a Create-Job: the new "job-id" and
"job-URL" is returned as part of the response, along with the job state and
the position in the queue.
Then you don't need the quirk in the Set-Job-Attributes response of
sometimes returning the "job-id" and "job-uri" depending on whether or not
the user modified the "job-uri". Also IPP Create-Job returns the
"job-state", "job-state-reasons", and position in the queue, all things
which Set-Job-Attributes is unlikely to return.
Also what is the setting of the "ipp-attribute-fidelity" when moving the
job? It is true or false? Another advantage of having a new operation,
like Resubmit-Job, is that it can have the "ipp-attribute-fidelity" as an
input operation attribute. Adding "ipp-attribute-fidelity" to
Set-Job-Attributes is another complication we have avoided by making
"job-uri" READ-ONLY.
In actual practice, the IPP Resubmit-Job only got implemented for the same
server, so that in fact the same Job object was re-used. You mention this
possibility as well in your point 2 below. So I guessing that the IPP WG
might want to have a simpler operation than Resubmit-Job, say, called
"Move-Job", which would be restricted to the same server. In any case, the
same principle would hold, that it would be a separate operation, not a side
effect of setting the "job-uri" attribute of the job.
So I would recommend that you make another private operation for moving jobs
and keep "job-uri" READ-ONLY. Then you avoid some of the complexities that
I noted above. Also you would probably be more in line with what might
happen in IPP in the future as well. Finally, it also makes your
Set-Job-Attributes response not have any special surprises for the client.
Comments everyone?
Thanks,
Tom
-----Original Message-----
From: Michael Sweet [mailto:mike at easysw.com]
Sent: Monday, March 13, 2000 05:44
To: IPP Mailing List
Subject: IPP> New CUPS 1.1 beta and set-job-attributes extension
Hi, All!
We're getting close to the second beta release of CUPS 1.1. Part of
the next beta release is support for the set-job-attributes operation
(see draft-ietf-ipp-job-printer-set-ops-01.txt)
HOWEVER
The current implementation of the set-job-attributes in CUPS will
support changing of the job-printer-uri attribute, which is currently
marked as READ-ONLY in the spec. I've mentioned this problem before,
but let me summarize once again:
1. The job-printer-uri attribute needs to be changeable to
support a "move-job" type operation.
2. We can eliminate certain "special case" problems such as
moving jobs to a different server by restricting the new URIs
to the same server, or allowing the server to reject changes
if they are not possible (e.g. SHOULD support moving to a
different server, MUST support moving to a different printer
object on the same server...)
3. To support implementations that maintain a separate job ID
space for each printer object, the set-job-attributes
operation would then also report the current job-id and
job-uri attributes in the response data.
Our current options with CUPS are to ship it with a non-conforming
implementation of set-job-attributes,or register yet another
extension operation that performs exactly the same functionality
as set-job-attributes but allows the job-printer-uri attribute to
be changed.
Thoughts?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw.com
Printing Software for UNIX http://www.easysw.com