All,
Below is the original note regarding a request for parent/child job
identifiers and the meeting minutes from the MFD working group
discussion. It was felt that the place for this discussion should not
be in the MFD working group but rather in the IPP working group along
with the discussion of IPP, IPP Everywhere and Cloud Printing. I
request that this issue be added to your IPP teleconference agenda.
Thanks,
Pete
Peter Zehler
Xerox Research Center Webster
Email: Peter.Zehler at Xerox.com <mailto:Peter.Zehler at Xerox.com>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701
Original note:
Hi,
Would it also be possible to add some sort of parent job UUID
list/hierarchy? So it will be possible to track source/parent jobs after
splitting a job into several jobs.
For example (maybe not the best, but..):
Imagine I have a company internal print cloud, to which I submit the
jobs. This cloud could forward jobs to other external clouds, based on
location (one provider for US, another for EU,...), cost or other
parameters.
So if I need to print a marketing document in both US and EU, I could
submit the job to a special queue in the company cloud, which again
would submit 1 copy to my local DeskJet printer, submit a new job with
10000 copies to the external EU print/cloud partner and another 10000 to
the US partner.
In this example, the jobs at the two external clouds, better not have
the same UUID if I need to track them. But I would still need the "root
job" UUID for doing accounting.
Hope this makes sense,
Christoph Lindemann
MFD Meeting minutes on the subject:
1. Discuss Parent Job UUID
* Christoph briefly described the use case for cloud print he
sent previously in IPP Working Group list. The use case requires the
parent job identification besides Job UUID for tracking a job sent from
a originating cloud to two other cloud print services because of job
size, cost, print service location,... etc.
* It was clarified that although the given use case only
involved one parent job, a parent job in the cloud could be fanned-in
from other multiple parent jobs and could be further fanned out to
multiple other clouds as multiple child jobs.
* Pete pointed out that although UUID is globally unique, its
encoding is meaningless and not very useful for job tracking purpose.
Thus a list of pairs of parent-child URIs was preferred for representing
a sequence of job's fan-in/fan-out performed in the cloud.
* Since a job to be fanned in or fanned out could be completed,
or in stopped or pending state depending on how the cloud print service
job processing is implemented, an additional job state reason
"fan-in/fan-out" is required for these states. The client should also be
notified when the very last page of his job is finally printed.
* Since job fan-in/fan-out is a service property, there is a
need for an attribute in Service Capabilities to indicate whether and
how this can be supported by a service, e.g. based on job size, cost,
..., etc., which could affect chaining of jobs and services.
* Today in IPP there exist partially stopped/partially
successful state reasons. IPP is also completely extensible. Hence
near-term use of such can be added without problem.
* In cloud print service, it is recommended that fan-out is
always assumed for failed job recovery purpose. However, this is out of
scope in MFD model. But there is nothing in the current model that
prevents implementation of this feature.
* Agreed that the discussion of this subject today should be
forwarded to the IPP working group for future IPP Everywhere and Cloud
Print discussions.
o AI: Pete to forward today's discussion to the IPP working group.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20100910/e681a7fc/attachment-0001.html>