IPP> FW: Thoughts on the new Move-Job operation

IPP> FW: Thoughts on the new Move-Job operation

IPP> FW: Thoughts on the new Move-Job operation

Michael Sweet mike at easysw.com
Wed Mar 22 08:55:11 EST 2000

"Hastings, Tom N" wrote:
> Michael, Ira, Bob, and I have been exchanging email on the Move-Job
> operation as a result of last week's IPP telecon.  We have a few
> issues left.  But here is where we are for tomorrow's IPP telecon,
> 3/22.

As usual, I won't be able to "attend" the telecon...  :(

My comments are below...

> ...
> ISSUE 01:  There is some debate as to whether to ALLOW the Move-Job
> operation to be supported when the job is in the 'processing' state.
> If it is allowed, it would be a MAY, not a MUST, because some
> systems will have problems with accounting if the same job-id is
> reused for the job again if some resources had been consumed.

See my other comments on this; to summarize, I think we'll need to
allow the "move-job" operation to create a new job-id and job-uri
as needed by the implementation.  The new job-id should not be
REQUIRED, since this will open up another can of worms with
accounting and job persistence - e.g. doubling the server's disk/
memory requirements if document files are persistent until purged.
(something that CUPS 1.1 supports)

> ...
> 2. In case the Printer defaults are different for the new Printer,
> we need to specify that the new Printer's defaults will be used when
> the job is processed, even if they differ from the defaults of the
> old Printer.

This makes sense, since in the absense of job template attributes the
printer defaults (which the client may be oblivious to) are used
anyways by Create-Job, Send-Job, and Send-URI.

> ...
> "printer-uri" (or old "job-uri") and the new "printer-uri".

Which should be called "job-printer-uri" to avoid ambiguitity with
the printer-uri used to identify the job.

> ...
> ISSUE 02:  Ok to REQUIRE that the "ipp-attribute-fidelity" operation
> attribute be copied to the Job object, if the Move-Job operation is
> supported?

Yes.  Similarly, if the new printer object does not support the
attributes provided, and ipp-attribute-fidelity is true, then
a client-error-conflicting-attributes error needs to be returned
and the job is not moved.

> 6. Finally, do we want to make Move-Job be like the Job Creation
> operations and specify that the Move-Job response MUST be the same
> as the Print-Job response:


> ...
> ISSUE 03: Ok that Per-Job Subscriptions are automatically updated to
> be for the new job (whether the job-id changes or not)?

This is a sticky problem; if the job-id (and job-uri) changes, then
the recipient of the notifications may not know what the notification
is for (e.g. I am subscribed to job 5, I move the job, now I am
subscribed to job 6???)

Obviously we'll need a "move-job" event subscription, and that
event needs to provide the new job-id, job-printer-uri, and
job-uri attributes for the job (whether the job-id has changed or

> ISSUE 04:  Should there be a new 'job-moved' event or is moving a
> job, just another operation that generates the 'job-created' (along
> with Print-Job, Print-URI, and Create-Job)?

I think we need it.  If we end up requiring a new job-id (something
I'd rather not do), then we also need to add a new job-state value
for "job-moved", since "completed", "cancelled", and "aborted" do
not make sense.

> 10. ISSUE 05:  For all of us to consider:
> Should we add this operation to the Set Job and Printer Spec
> (because it is similar to scope and usage to the Set-Job-Attributes
> and Set-Printer-Attribute spec), add it to the Administrative Set2
> spec, or keep it as a separate spec?

It might make sense to include it there.  However, I think we've
identified enough issues that move-job may be large enough to make
it a separate spec all by itself.

> ...
> spec to go out for last call soon (as soon as we agree on the
> collection syntax encoding).  On the other hand, if we are far from
> ...

Once again, let me voice my *lack* of support for the collection
syntax, as it will needlessly complicate implementation and support
of IPP.  The new "printer-xri-supported" attribute could use a new
compound value tag ("xri") that would provide a URI and two keywords
to cover what is needed for that attribute (and other similar
situations we're likely to run into)

Michael Sweet, Easy Software Products                  mike at easysw.com
Printing Software for UNIX                       http://www.easysw.com

More information about the Ipp mailing list