Hi,
Pete - thanks for writing all this up - I haven't got any bandwidth
to read it today or probably tomorrow, but will look later this week.
Glen - push printing is hopelessly impossible for Cloud Printing
(except via terrible SMTP transport) - the target PrintService/Printer
is behind a firewall - that's problem number one.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Tue, Dec 13, 2011 at 12:07 PM, Petrie, Glen
<glen.petrie at eitc.epson.com>wrote:
> ** ** ** ** **
>> Hi Peter,****
>> ** **
>> 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. ****
>> ** **
>> Print Queue (Print Queue) = Print Service ****
>> **n **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****
>> **n **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. ****
>> **n **I believe this means there must be a Print Manager; called it
> the Cloud Print Manager. ****
>> **o **Could the Cloud Print Manager allow implementation of either
> or both types of Print Services models (pull and/or push); sure.****
>> Printer = Printer (maybe
> this means the Print Service of the Printer)****
>> ** **
>> 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).*
> ***
>> ** **
>> 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.****
>> ** **
>> 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. ****
>> ** **
>> 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. ****
>> ** **
>> ** **
>> 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.****
>> ** **
>> I believe that is registration is not just about the printer; but about
> the User and the printer. ****
>> ** **
>> Glen****
>> ** **
> ------------------------------
>> *From:* cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] *On Behalf
> Of *Zehler, Peter
> *Sent:* Tuesday, December 13, 2011 5:34 AM
> *To:* cloud at pwg.org> *Subject:* [Cloud] Cloud Print binding to IPP****
>> ** **
>> 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#Link1036> >****
>> 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#Link1035>
> ****
>> 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#Link1038>.
> ****
>> 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#Link1034> >****
>> 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#Link1037> >****
>> 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: 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 *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. ****
>> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>> _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>
--
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/e76c9bb3/attachment-0002.html>