attachment-0002
<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>Hi Pete<div><br></div><div>Pull printing for the cloud seems like a natural solution that would work in just about any scenario without bringing in another protocol - what is your reason for trying to avoid "pull" ?</div><div><br></div><div>R.</div><div><br></div><br><br><br>-------- Original message --------<br>Subject: RE: [Cloud] Cloud Print binding to IPP<br>From: "Zehler, Peter" <Peter.Zehler@xerox.com><br>To: "Petrie, Glen" <glen.petrie@eitc.epson.com><br>CC: RE: [Cloud] Cloud Print binding to IPP<br><br><br><div class="WordSection1"><p class="MsoNormal"><span style="color:#1F497D">Glen,<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">Please continue to comment. I value your input. It helps me to clarify my thoughts. Another viewpoint helps a lot more than the silent monitoring of discussions of the PWG. <o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">We always seem to talk past each other a bit. I am discussing Cloud Print from a protocol specific view. Note that I strayed from the functional model we drew up at the February meeting. <<a href="ftp://ftp.pwg.org/pub/pwg/cloud/slides/cloud-printing-bof-february-11.pdf">ftp://ftp.pwg.org/pub/pwg/cloud/slides/cloud-printing-bof-february-11.pdf</a>> In my original post I addressed only the job processing aspects of the “Cloud Print Provider” I did not address discovery, or selection and only touched on registration since it involves capabilities. I’m not forgetting them it’s just that I never pursued them in a form I believe is useful to the PWG. I did not mention the IPP Clients but I expect that is what would be sending the jobs to the Queue. <o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">As I mentioned both the Queue and the Printer are IPP Printers. From a protocol point of view it does not matter if they can actually produce output themselves. It also does not matter how they forward jobs onto a physical printer. It could be IPP or it could be a simple protocol such as port 9100. The most important thing is that it doesn’t matter if the Queue is “THE” implementation of the Cloud Print Provider or simply a protocol gateway to it. From a protocol point of view you can’t tell the difference. The most flexible implementation is that the Queue is a protocol Gateway to the Cloud Print Provider. Other Gateways can be implemented to allow an implementation to service multiple Cloud Print services (i.e., Cloud Print from vendors with their own protocol binding).<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">The reason I have worked on the Semantic Model and the Print Job Ticket I want to get agreement across the industry on the semantics of Services, Jobs and Documents. With a common model for state transitions and the semantics of the elements that comprise a Job Ticket it simplifies the Gateways necessary to integrate with a Cloud Print Provider implementation. It allows a protocol binding to be IPP, WS-Print, Google Cloud Print, or some vendor’s REST binding. My preference would be a Web Service binding of IPP but since there is no existing standard or deployed base I’ll go with IPP. IPP has the common model for state transitions and Job Ticket that has a demonstrated scalability from a dongle that hangs off a parallel port up to full production class printers. While IPP semantics is used in many environments I still see a bit of a gap between protocol centric and driver centric views in printing.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">IPP has most everything we need for a Cloud Print protocol. One thing that is missing is a mechanism to traverse a firewall. My model is not a pull-model. My initial implementation was pull-model only to get around the limitations of printing to a printer behind a firewall. I viewed moving to a push model as an optimization to be done in a later iteration. I do not advocate a pull model in a real world implementation. I don’t disallow it either. It seemed to me upon Printer initialization the Printer would not wait for a signal from the Queue to begin processing jobs. Getting the available work would be part of the startup synchronization. To solve the firewall issue I believe we will need a partial IPP binding to a protocol such as XMPP. I would think XMPP can be used to deliver events in through a firewall. Some IPP operations might be needed (e.g. GetJobs, GetPrinterAttributes) to allow a Queue to synchronize with the Printer on startup.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">You were concerned that low end physical printers may have no concept of a job. The low end physical printer that have no concept of a job and no support for IPP, or a cloud print protocol, are not within the domain of this discussion. In order for those types of printers to participate they need to have a front end (Cloud Print Manager in the functional model) that interacts with the Queue (Cloud Print Provider in the functional model). If low end printers wish to embed the Cloud Print Manager it need only support a list of jobs 1 deep (i.e. the current job) and only allow a single document jobs. I agree that one of the advantages of Cloud Print is that all of the “printing smarts” (jobs, driver, transform, rendering, etc.) can actually be in the cloud based Print Service Provider (aka Queue). That intelligence may also reside in the Cloud Print Manager (aka Printer). Note that this need not be collocated with the physical printer. The Cloud Print Manager could be communicating with the physical printer via port 9100 and maybe SNMP. The IPP model accommodates this variation in architecture quite nicely.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">I did not quite follow your fan-in/fan-out being “behind the scenes”. My reason for mentioning it is the flexibility it allows for implementations and deployments. It is easily supported within the IPP protocol model. I think we are in agreement when you discuss the Print Manager creating instances of Print Protocol front-ends. This Port Mapper like functionality is certainly possible. However, as previously stated, from a protocol point of view you cannot tell the difference between that and a monolithic implementation. The network behavior is the same.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">You did not understand my concept of “locking the job”. I am assuming the possibility of cluster printing. If it is one Printer per Queue than this is almost a noop. The Job could move from the ‘Pending’ to ‘Processing’ state on this call. It also is the point at which the job mapping is known to both sides. The operation is needed to allow for flexibility of system wide job scheduling. While it is true that a Cloud Print Provider may have the intelligence necessary to schedule jobs to the appropriate Printer based on current configuration. It is also possible a group of jobs could be given to a number of printers allowing a long job or printer fault not to block the Queue.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">Finally, I agree that is registration is not just about the printer; but about the User and the printer. I would go a little farther and include the printer identity as a “user” and access control that specifies what Users may put jobs into a Queue and what Printers may process jobs in a Queue. <o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="color:#1F497D">Pete<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><div><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-family:"Impact","sans-serif";color:navy">Peter Zehler</span><span style="color:#1F497D"><br><br></span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:navy">Xerox Research Center Webster<br></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Email: <a href="mailto:Peter.Zehler@Xerox.com">Peter.Zehler@Xerox.com</a></span><span style="color:#1F497D"><br></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Voice: (585) 265-8755</span><span style="color:#1F497D"><br></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">FAX: (585) 265-7441</span><span style="color:#1F497D"><br></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">US Mail: Peter Zehler</span><span style="color:#1F497D"><br></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Xerox Corp.</span><span style="color:#1F497D"><br></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">800 Phillips Rd.</span><span style="color:#1F497D"><br></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">M/S 128-25E</span><span style="color:#1F497D"><br></span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Webster NY, 14580-9701</span><span style="color:#1F497D"> </span><span style="font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F497D"><o:p></o:p></span></p></div><p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Petrie, Glen [mailto:glen.petrie@eitc.epson.com] <br><b>Sent:</b> Thursday, December 15, 2011 8:56 AM<br><b>To:</b> Zehler, Peter<br><b>Cc:</b> cloud@pwg.org<br><b>Subject:</b> RE: [Cloud] Cloud Print binding to IPP<o:p></o:p></span></p></div></div><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Cambria","serif";color:blue">Peter<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Cambria","serif";color:blue"><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Cambria","serif";color:blue"><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Cambria","serif";color:blue">While I understand your model and I failed to understand, as was pointed out to me, that it represented the more generic case. Therefore, I must revoke my comments and will refrain from others.<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Cambria","serif";color:blue"><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Cambria","serif";color:blue">Glen <o:p></o:p></span></p></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.
<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>