The revived interest is most encouraging. One concern I have with PWG going
off and defining a Cloud Printing model (that may be unjustified) is that we
may not fully understand cloud printing aspects beyond the printing, part of
the "gap" that Randy refers to. Another is wondering who would implement a
PWG model.or perhaps the model would just be intended to illustrate some
ideas that other implementations could adopt. By all means, if there is
interest and personnel, lets proceed with the model that Pete has identified
(and perhaps it is more practical to do an IPP binding directly without
doing the abstract model first.)
But, from what I understood of our objective, I thought that the suggestion
from Ranga Raj was very good, particularly to the extent that Celstream, as
an Cloud Printing implementer, could provide much of the information about
current solutions and problem areas...and perhaps about the "gaps". His
suggestion, which to an extent is consistent with our print ticket mapping
effort, was:
- We look at the Cloud Imaging Workflow and current solutions being
offered today - current CISPs are tending to be proprietary silos in most
cases
- Evaluate what components in the workflow and deployment use cases
that are most likely to benefit from a standardization effort from PWG and
re-order the sequence of standards being released for adoption (not that I
am stating that the current sequence may not be right)
- This would enable CISPs (we are one of them) to consider PWG
standards adoption in our roadmap, especially in areas with maximum pain
points or to tackle interoperability aspects.
At any rate, I strongly suggest that we do complete our existing effort with
print tickets since they are a contribution to both the PWG model and
something that could be adopted by existing implementations.
Bill Wagner
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Randy Turner
Sent: Tuesday, December 13, 2011 12:03 PM
To: cloud at pwg.org
Subject: Re: [Cloud] Cloud Print binding to IPP
Hi Pete,
I think it's great to see this initiative.my fundamental question regarding
cloud print has been identifying really where the differences are between
network printing in an enterprise, and a cloud print model, and then just
gap filling.
Microsoft Windows Servers (specifically the print server capability) has
always had the ability to store queues on a server and deliver jobs to
"known" (or "registered") printers -- and to your point about being able to
fan-in / fan-out, you can (in theory) string together print servers that
print to print servers that eventually hold queues to actual physical
devices.
All of the print job semantic model applies to cloud printing, I don't think
we need to re-visit anything -- it seems to me that's it's only a problem of
registration.and possibly security, but existing systems may have a model
for this as well.
I guess what I'm curious about is identifying the "gap" between network
printing on an enterprise and cloud printing -- my hunch is the gap isn't
much. We're just moving the print server to the internet, and scaling the
fan-in problem (but that's an infrastructure problem, not a printing
problem)
R.
On Dec 13, 2011, at 5:33 AM, Zehler, Peter wrote:
All,
I would like to see an IPP binding for Cloud printing. I see a significant
advantage to an IPP based solution given the maturity of the protocol and
the industry wide support. I experimented with a cloud based print service
back in 2009. I based my experiments on a WS-Print binding but an IPP
binding would also work. I switched the binding from WS-Print to PWG SM and
included it in v1.160 of the PWG SM Schema. It is easier for me to write
Schema than IPP and easier to display. It is not difficult to move between
the two mappings. The issues I did not address include an environment
agnostic registration and a common security model.
For clarity I will refer to the Cloud based Printers as Queues and the
devices as Printers even though in the IPP model they are both
implementation of IPP Printers. In v1.160 of the PWG Semantic Model Schema
I included two files (i.e., PwgCloudPrintQueue.wsdl and
PwgCloudPrintQueueMsg.xsd) that have some of the operations fleshed out a
bit. (I dropped a couple things moving from WS-Print to PWG SM.)
I had a couple of assumptions going in.
I believe that Queues and Printers contain Jobs and are stateful. There is
an association between the Jobs in a Queue and the Jobs being printed on a
Printer. A mapping between them should be maintained on both sides and
carried explicitly in the protocol. I do not believe we should be
implementing "remote markers" where Jobs only reside in the Cloud. It
should be possible for either side to use IPP operations to query the state
of the Printer/Queue and their Jobs.
I believe it is a requirement that the Cloud Print model must support both
Fan Out and Fan In. In other words it should be possible for a single Cloud
Queue to act as a proxy for other Cloud Queues. This will allow a Printer
to interact with a single Cloud Queue but still service jobs in multiple
Cloud Queues. Taking this approach allows you to do things such as set
different default behaviors for Queues that all map to the same Printer.
(The User does not need a Job Ticket since the intent is associated with the
various Queues.) This approach also allows you to enforce different
capabilities for different users. Users have permission to use specific
Queues. The Queues could prohibit color printing or limit the size of a
Job.
It should also be possible for one Printer to interact with a Queue and
forward Jobs to other Printers. For example a Printer in an enterprises DMZ
could forward jobs to internal Printers or a software only Printer could
front end legacy devices (i.e., proxy).
The way I broke the processing of Cloud Jobs up was; Check for Work, Lock
the Job, Update the Job Status, Retrieve the Document(s), and Finish the
Job. I also had another group of things that include; synchronization of
Printer and Job state, Firewall Traversal, Moving from Poll Driven to Event
Driven, and Eventing.
Check for work:
The Printer should be event driven when processing Jobs. See below for a
discussion on eventing. The printer should query the Queue for available
work.
The Operation IsThereAnyWork
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link10
36>
is used by the Printer to ask a Queue to see if any work is available. The
request contains a list of DestinationServiceUuids (i.e. printer-uuid) where
the Jobs will be printed. The response will have a list of work entries.
Each entry contains the SourceServiceUuid, DestinationServiceUuid (missing
in schema) and a list of Job ids. I used a UUID instead of an ID but as
long as the source Queue is identified either would work.
Lock the Job:
Once a Printer has determined the job it will process, it sends a
DeQueuePrintJob operation
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link10
35>
to the Queue. This operates a little differently than CreateJob in that
the Printer Job identifier needs to be reserved until the operation
succeeds. If the operation fails or times out the identifier and any
allocated resources are discarded. The request includes the identifiers for
the source and destination Queue/Printer and Jobs. The response contains
the number of documents in the job as well as some job information such as
the job name and owner. Although not included a JobTicket should be passed
in the response as well. The payload of the response should closely match a
CreateJob operation. We may also want to consider passing a JobTicket by
reference which IPP does not permit at this time.
Update the Job Status:
Event notifications are used to keep the state of the Job, Document and
Service updated. I used WS-Eventing but an IPP notification method can be
substituted. See eventing discussion below.
Retrieve the Document:
The Printer retrieves the documents to process using the Retrieve Document
operation
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link10
38>.
The request identified the source Service, Job and Document number. The
response includes the document number and a flag to indicate if it is the
last document. Other information such as a Document Ticket or the
DocumentFormat can also be included. Since the Printer does not know if the
document will be pushed or pulled it must be ready to accept a DocumentUri
or Document Content in the response. I used MTOM but IPP already has an
acceptable encoding. It is most efficient to use print by reference
whenever possible.
Finish the Job:
Once the Job has been printed the final update of the Job is done. Note
that events are used to handle updates as the Job is being processed. The
CompleteDequeuePrintJob operation
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link10
34>
request contains the Source and destination Queue/Printer and Jobs and the
details of the Destination Job. Included is The JobState, any
JobStateReasons, DateTimeAtCompletion and the ImpressionsCompleted. The
PrintJobReceipt can also be included.
Synchronize Printer/Queue state,
Synchronize Job state,
Moving from Polling to Event Driven
Firewall traversal
Eventing:
This nice thing about outbound (i.e., Printer to Queue) eventing in a Cloud
environment is that no event subscription needs to be sent. The Printer
knows the Queue is interested in Printer and Job events. Either a
well-known listener port can be used or the location can be part of
registration. Since the Printer knows which jobs came from the Cloud it can
filter the Job events. Whenever a Printer is initialized a printer state
event should be sent to its registered Queues. If the content of the event
is insufficient then a one way message that looks like a
GetPrinterAttributes operation response could be used.
In order to move from a poll model to an event driven model we need a
mechanism to traverse the firewall. I originally used a hacked together
HTTP trickle protocol. A standardized protocol such as XMPP can be used
instead. The PWG can create PWG specific stanzas that map to existing IPP
operations such as GetPrinterAttributes, GetJobs or GetJobAttributes. A new
stanza would be needed to let the Printer know it's time to send an
IsThereAnyWork operation to a Queue.
Registration:
I did not do anything with registration other than put in a place holder.
The RegisterPrinter operation
<http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link10
37>
request contains some Printer information such as the identifier for the
Queue and the Printer. It was not clear to me if the existence of a Queue
is a prerequisite or a result of the operation. The Printer information
would also include the PrinterCapabilities that we recently defined in the
Job Ticket work. This contains the defaults, capabilities and document
generation information. I included some "Agent" information. I assumed
there would be some security information exchanged so I just put a
placeholder there.
Comments?
Peter Zehler
Xerox Research Center Webster
Email: <mailto:Peter.Zehler at Xerox.com> 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
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean. _______________________________________________
cloud mailing list
cloud at pwg.orghttps://www.pwg.org/mailman/listinfo/cloud
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--
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/cloud/attachments/20111213/aa993168/attachment-0002.html>