attachment-0002
<html><head></head><body bgcolor="#FFFFFF"><div>I agree with Ira on the push issue, except I would say that the target rendering device "could" be behind a firewall, so some type of pull will need to be supported...possibly using existing print-by-reference mechanisms</div><div><br></div><div>R.<br><br><br></div><div><br>On Dec 13, 2011, at 9:35 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>Hi,<br><br>Pete - thanks for writing all this up - I haven't got any bandwidth<br>to read it today or probably tomorrow, but will look later this week.<br><br>Glen - push printing is hopelessly impossible for Cloud Printing<br>
(except via terrible SMTP transport) - the target PrintService/Printer<br>is behind a firewall - that's problem number one.<br><br>Cheers,<br>- Ira<br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>
Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP & Printer MIB<br>
Blue Roof Music/High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<div style="display:inline">
</div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div><br>
<br><br><div class="gmail_quote">On Tue, Dec 13, 2011 at 12:07 PM, Petrie, Glen <span dir="ltr"><<a href="mailto:glen.petrie@eitc.epson.com">glen.petrie@eitc.epson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>
<u></u>
<u></u>
<u></u>
<u></u>
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">Hi Peter,<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">Your description sound a lot like DocuPrint
or a (Production) Print Manager. Is this a good Cloud-Print
model? It could be, since DocuPrint like entities have been around more
than two (maybe three) decades. Terminology, I believe, is a little
different today. The other aspect I note, and, again, it more in line
with a production print model (like DocuPrint), is your model is a pull-model
from the physical printer out of a print queue; while my model is a push-model
to the physical printer. While I have actually been involved in studies
that show the pull-model is beneficial for production printing, I don’t
yet have the same understanding that a pull model is beneficial for Cloud
Printing. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">Print Queue (Print Queue) =
Print Service <u></u><u></u></span></font></p>
<p class="MsoNormal" style="margin-left:2.75in"><u></u><font color="blue" face="Wingdings" size="3"><span style="font-size:12.0pt;font-family:Wingdings;color:blue"><span>n<font face="Times New Roman" size="1"><span style="font:7.0pt "Times New Roman"">
</span></font></span></span></font><u></u><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">Assuming
a Print Service can hold (queue) more than a single job. The Print
Service is its own Print Manger. Is this the desired functionality?
Maybe<u></u><u></u></span></font></p>
<p class="MsoNormal" style="margin-left:2.75in"><u></u><font color="blue" face="Wingdings" size="3"><span style="font-size:12.0pt;font-family:Wingdings;color:blue"><span>n<font face="Times New Roman" size="1"><span style="font:7.0pt "Times New Roman"">
</span></font></span></span></font><u></u><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">An
opposing model is for a new instance of a Print Service is created for each
Print Job. This begs the question of who manages the multiple instance of
a single Print Service. Thus, a Print Manager for the multiple
instances of a Print Service is still required. <u></u><u></u></span></font></p>
<p class="MsoNormal" style="margin-left:2.75in"><u></u><font color="blue" face="Wingdings" size="3"><span style="font-size:12.0pt;font-family:Wingdings;color:blue"><span>n<font face="Times New Roman" size="1"><span style="font:7.0pt "Times New Roman"">
</span></font></span></span></font><u></u><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">I
believe this means there must be a Print Manager; called it the Cloud Print Manager.
<u></u><u></u></span></font></p>
<p class="MsoNormal" style="margin-left:3.25in"><u></u><font color="blue" face="Courier New" size="3"><span style="font-size:12.0pt;font-family:"Courier New";color:blue"><span>o<font face="Times New Roman" size="1"><span style="font:7.0pt "Times New Roman"">
</span></font></span></span></font><u></u><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">Could
the Cloud Print Manager allow implementation of either or both types of Print
Services models (pull and/or push); sure.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">Printer =
Printer (maybe this means the Print Service of the Printer)<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">You also discuss the idea that a Print
Job is on a Printer. That may or may not be true depending the size
and capabilities of printer. This may be true for some office and most production
printers but as you move down is physical printer size there is no need for the
physical printer to ever have or know about a/the Print Job. The
physical printer’s Print Service knows about the Print Job.
One of the advantages of Cloud Print is that all of the “printing smarts”
(jobs, driver, transform, rendering, etc) can actually be in or by a/the cloud based
Print Service and very little, beyond status and base printing functionality
(think processing vendor specific PDL) needs to be in the actual physical printer.
This means the physical printer is not IPP based; it would be the
Print Service (maybe).<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">This brings up the concept that perhaps
the Cloud Print Manager creates an instance of a Print Protocol front-end (like
IPP) and connects to an internal protocol neutral instance of a Print
Service!!!! Thus, if a Print Client supports a different Print Protocol, a
different front-end is spawned!!! Not one protocol configuration will fit
all solutions but since Cloud supports real-time configurability of services in
general, any Cloud Print Manager/Solution should take advantage of this.
So, no Cloud Printer Manager is tied to a single protocol but will (may) be
required to support different ones.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">Support for fan-in and fan-out in the
traditional sense is “behind the scene” and an implementation
detail within a specific Cloud Print Manager / Solution implementation. Maybe
what you describe below is more like federation of Cloud Print Manager. The
other part of your discussion on queues is about User specific
capabilities. I agree this is needed functionality; the spawning of
a Print Service instance makes this functionality easy. When the Print
Service is spawned, the capability data of that Print Service only includes
those allowed capabilities available for the User. This action is
additive; that is, if there site or department policies restricting the User
capabilities; those capabilities can also be removed for the capability data
for a specific Print Service instance. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">The way I see the processing (workflow)
of Cloud Print Job is not from the pull-model (that is, from printers or queues
perspective of checking to see there is a Print Job to do (do I want potentially
thousands upon thousands of physical printers sending internet messages to Cloud
Print Queues of Cloud Print Solution checking to see if there is something to
print!) ) but rather from a push-model from the User. That is User makes
a Print Request to the Print Cloud Manager, a Print Service is selected, if the
specific Print Service does not always exist; then, an instance of the selected
Print Service is spawned based on User permission and site policies, a Print
Client creates the User’s Print Intent from the Print Service capabilities,
the Print Service (including physical printer) status is checked, the Print
Intent is passed to the Print Service to become a Print Job (actually I like
the concept that Print Client to create a Print Job and simply passes it to the
Print Service but this is not generally agreed upon by others), the Print Job
starts, status is reported as required/requested, the Job finishes. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">I don’t understand the concept of “lock
the job”; to me, once the Print Service accepts the Print Job (not error
in the Print Job Ticket) that it is.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">I believe that is registration is not
just about the printer; but about the User and the printer. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue">Glen<u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="blue" face="Cambria" size="3"><span style="font-size:12.0pt;font-family:Cambria;color:blue"><u></u> <u></u></span></font></p>
<div>
<div class="MsoNormal" style="text-align:center" align="center"><font face="Times New Roman" size="3"><span style="font-size:12.0pt;font-family:"Times New Roman"">
<hr align="center" size="2" width="100%">
</span></font></div>
<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma">
<a href="mailto:cloud-bounces@pwg.org" target="_blank">cloud-bounces@pwg.org</a> [mailto:<a href="mailto:cloud-bounces@pwg.org" target="_blank">cloud-bounces@pwg.org</a>] <b><span style="font-weight:bold">On Behalf Of </span></b>Zehler, Peter<br>
<b><span style="font-weight:bold">Sent:</span></b> Tuesday, December 13, 2011
5:34 AM<br>
<b><span style="font-weight:bold">To:</span></b> <a href="mailto:cloud@pwg.org" target="_blank">cloud@pwg.org</a><br>
<b><span style="font-weight:bold">Subject:</span></b> [Cloud] Cloud Print
binding to IPP</span></font><font face="Times New Roman" size="3"><span style="font-size:12.0pt;font-family:"Times New Roman""><u></u><u></u></span></font></p>
</div><div><div class="h5">
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">All,<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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.)<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">I
had a couple of assumptions going in.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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. <br>
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).<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Check
for work:<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">The
Operation IsThereAnyWork <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1036" target="_blank">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1036</a>><u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Lock
the Job:<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Once
a Printer has determined the job it will process, it sends a DeQueuePrintJob
operation <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1035" target="_blank">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1035</a>>
<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"> 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.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Update
the Job Status:<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Retrieve
the Document:<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">The
Printer retrieves the documents to process using the Retrieve Document
operation<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1038" target="_blank">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1038</a>>.
<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Finish
the Job:<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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 <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1034" target="_blank">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1034</a>><u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Synchronize
Printer/Queue state,<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Synchronize
Job state,<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Moving
from Polling to Event Driven<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Firewall
traversal<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Eventing:<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Registration:<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">I
did not do anything with registration other than put in a place holder.
The RegisterPrinter operation <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><<a href="http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1037" target="_blank">http://www.pwg.org/mfd/navigate/PwgSmRev1-160_ServiceOperations.html#Link1037</a>><u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">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. <u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt">Comments?<u></u><u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Calibri"><span style="font-size:11.0pt;color:#1f497d"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font color="navy" face="Impact"><span style="font-size:11.0pt;font-family:Impact;color:navy">Peter Zehler</span></font><font color="#1f497d"><span style="color:#1f497d"><br>
<br>
</span></font><u></u><u></u><font color="navy" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;color:navy">Xerox</span></font><u></u><font color="navy" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;color:navy"> <u></u>Research<u></u> <u></u>Center<u></u></span></font><u></u><font color="navy" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;color:navy"> Webster<br>
</span></font><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Email: </span></font><a href="mailto:Peter.Zehler@Xerox.com" target="_blank"><font face="Arial"><span style="font-size:10.0pt;font-family:Arial">Peter.Zehler@Xerox.com</span></font></a><font color="#1f497d"><span style="color:#1f497d"><br>
</span></font><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Voice: <a href="tel:%28585%29%20265-8755" value="+15852658755" target="_blank">(585) 265-8755</a></span></font><font color="#1f497d"><span style="color:#1f497d"><br>
</span></font><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">FAX: <a href="tel:%28585%29%20265-7441" value="+15852657441" target="_blank">(585) 265-7441</a></span></font><font color="#1f497d"><span style="color:#1f497d"><br>
</span></font><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">US Mail: Peter Zehler</span></font><font color="#1f497d"><span style="color:#1f497d"><br>
</span></font><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Xerox Corp.</span></font><font color="#1f497d"><span style="color:#1f497d"><br>
</span></font><u></u><u></u><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">800 Phillips Rd.</span></font><u></u><u></u><font color="#1f497d"><span style="color:#1f497d"><br>
</span></font><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">M/S 128-25E</span></font><font color="#1f497d"><span style="color:#1f497d"><br>
</span></font><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Webster NY, 14580-9701</span></font><font color="#1f497d"><span style="color:#1f497d"> <u></u><u></u></span></font></p>
<p class="MsoNormal"><font color="#1f497d" face="Times New Roman" size="3"><span style="font-size:12.0pt;font-family:"Times New Roman";color:#1f497d"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Calibri"><span style="font-size:11.0pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font face="Times New Roman" size="3"><span style="font-size:12.0pt;font-family:"Times New Roman""><br>
-- <br>
This message has been scanned for viruses and <br>
dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b><span style="font-weight:bold">MailScanner</span></b></a>, and is <br>
believed to be clean. <u></u><u></u></span></font></p>
</div></div></div><div><div class="h5">
<br>--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is
<br>believed to be clean.
</div></div></div>
<br>_______________________________________________<br>
cloud mailing list<br>
<a href="mailto:cloud@pwg.org">cloud@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/cloud" target="_blank">https://www.pwg.org/mailman/listinfo/cloud</a><br>
<br></blockquote></div><br><div style="" id="avg_ls_inline_popup"></div>
<br>--
<br>This message has been scanned for viruses and
<br>dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br>believed to be clean.
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cloud mailing list</span><br><span><a href="mailto:cloud@pwg.org">cloud@pwg.org</a></span><br><span><a href="https://www.pwg.org/mailman/listinfo/cloud">https://www.pwg.org/mailman/listinfo/cloud</a></span><br></div></blockquote><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>