Hi Pete
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" ?
R.
-------- Original message --------
Subject: RE: [Cloud] Cloud Print binding to IPP
From: "Zehler, Peter" <Peter.Zehler at xerox.com>
To: "Petrie, Glen" <glen.petrie at eitc.epson.com>
CC: RE: [Cloud] Cloud Print binding to IPP
Glen,
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.
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. <ftp://ftp.pwg.org/pub/pwg/cloud/slides/cloud-printing-bof-february-11.pdf> 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.
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).
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.
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.
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.
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.
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.
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.
Pete
Peter Zehler
Xerox Research Center Webster
Email: 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
From: Petrie, Glen [mailto:glen.petrie at eitc.epson.com]
Sent: Thursday, December 15, 2011 8:56 AM
To: Zehler, Peter
Cc: cloud at pwg.org
Subject: RE: [Cloud] Cloud Print binding to IPP
Peter
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.
Glen
--
This message has been scanned for viruses and
dangerous content by 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/20111216/3de25d8f/attachment-0002.html>