attachment-0002
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://11/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Hi Pete,<div><br></div><div>This reminds me of a comment I made last year at a Face-to-Face that cloud printing is a minor delta from just network printing, and there may be no reason to re-visit every operation. In a typical office environment, we've always had clients, and then a print server that supports operations related to queuing and other functionality.</div><div><br></div><div>We're basically moving the server outside of a firewall, so we may need to address aspects of the service that need to be added for firewall (or other security domain traversal), and not necessarily re-visit "printing".</div><div><br></div><div>In other words, the bulk of the job of supporting cloud printing may be the work that we've heretofore decided not to address yet (authentication, authorization, etc.).</div><div><br></div><div>in past messages, I have also recommended we look at XMPP as a potential protocol we could re-use for certain functionality related to cloud printing, although not necessarily as a print job transfer protocol (or what lately I've been referring to as a "bearer" channel). However, XMPP can be used for just about any of our other functionality, which I like to call "signaling" -- I've borrowed these terms from the SIP world, where they have a signaling protocol that does a lot of "setup" or negotiation of the bearer channel, and then the "bearer" protocol is often some other protocol that specializes in bulk data transfer.</div><div><br></div><div><br></div><div>Randy</div><div><br></div><div><br><div><div>On Aug 26, 2012, at 5:57 AM, "Zehler, Peter" <<a href="mailto:Peter.Zehler@xerox.com">Peter.Zehler@xerox.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">All,<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">As I mentioned at the Face to Face, my view is that both the Cloud Print Service and the Cloud Print Manager look like PWG Printers. I believe it is an absolute requirement that the Cloud Print Service make the usual client print operations available to a Cloud Print Client (e.g., CreateJob, SendPrintDocument, SendPrintUri, ClosePrintJob, GetPrinterElements). I see no reason that the Cloud Print Manager would not implement those same operations. The limitation for the Cloud Print Manager is those operations are only available to the Cloud Print Client if the Cloud Print Client has network access to the Cloud Print Manager. Of course a Cloud Print Manager could be implemented so that the only way to submit a job to it is through a Cloud Print Service.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">(Note lists below are not authoritative or are the operation necessarily in the right group.)<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; ">The list of possible user operations include: CancelPrintDocument, CancelPrintJob, CancelMyPrintJobs, ClosePrintJob, CreatePrintJob, GetActivePrintJobs, GetActivePrintJobs, GetPrintDocuments, GetPrintJobElements, GetPrintJobHistory, GetPrintJobs, GetPrintServiceElements, IdentifyPrinter, PrintJob, PrintUri, ReprocessPrintJob, RestartPrintJob, ResubmitPrintJob, SendPrintDocument, SendPrintUri, ValidatePrintDocumentTicket, ValidatePrintJobTicket,<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; ">The administrative operations include: ActivatePrinter, CancelCurrentPrintJob, CancelPrintJobs, DeactivatePrintService, DisablePrintService, EnablePrintService, HoldNewPrintJobs, HoldPrintJob, PausePrintService, PausePrintServiceAfterCurrentJob, PromotePrintJob, PurgePrintJob, ReleaseNewPrintJobs, ReleasePrintJob, RestartPrintService, ResumePrintJob, ResumePrintService, SetPrintDocumentElements, SetPrintJobElements, SetPrintServiceElements, ShutdownPrintService, SuspendCurrentPrintJob<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">I see no reason why any of these operations would not be applicable to a Cloud Print Service or a Cloud Print Manager. If we have some administrative scenarios from IPP, they can probably be reused. The interesting part come when discussing the upstream/downstream behavior. <o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; ">For example an administrator of a cloud print service is informed a specific printer will be down for a week waiting for a required part. The administrator wants to prevent more jobs from accumulating for this commonly used printer. The administrator disables the printer. <o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">Currently defined administrative operations affect the service to which the request is directed. In a fan out configuration, which may be likely in cloud environments, must an operation on the Cloud Print Service affect the downstream Cloud Print Managers identically? Is there any way to Pause a Cloud Print Service such that only the Jobs destined for a specific Cloud Print Manager are affected? I’m inclined to think that the only way to accomplish this would be to Disable the specific Cloud Print Service bound to the target Cloud Print Manager instead of a Cloud Print Service that acts as an aggregator for fan out printing.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; ">(Note that the operation names below are based on the current straw man operations in the PWG Semantic Model Schema.)<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; ">The operations that are new from the Cloud Print Manager to the Cloud Print Service would be calls to determine if any Jobs are available, retrieve a Job, retrieve a document and operations to update the Cloud Print Manager on the state of the Job/Document at the Job Print Manager. An operation is also needed to inform the Cloud Print Service of the state of the Cloud Print Manager.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><b>GetAvailableJobs</b><span class="Apple-converted-space"> </span>would return 0, 1 or more jobs. The response would be a list of job summaries. Of course 0 would be returned if no work is available. The question then is which entity controls Job Scheduling. I see no reason the model should take a position. If the Cloud Print Service controls Job Scheduling, then one Job would be returned at a time. If the Cloud Print Service is not controlling Job Scheduling, then a list of Jobs can be returned. The Job Summary information needs to be sufficient for basic Job scheduling.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><b>FetchJob</b> allows the Cloud Print Manager to select a Job in the Cloud Print Service for processing. Appropriate metadata, including the PrintJobTicket, is returned. The selected Job in the Print Cloud Service is no longer available to other Cloud Print Managers.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><b>ReportJobState/ReplyToJob</b><span class="Apple-converted-space"> </span>is used by the Cloud Print Manager to keep the Cloud Print Service up to date on the status of the processing Job or when it has reached a terminated state. The current operations are split into a general update and one used after Job creation. Time will tell if both are needed.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><b>FetchDocument<span class="Apple-converted-space"> </span></b>is used by the Cloud Print Manager to process a Document within the specified Cloud Print Service Job. Included in the response are the appropriate metadata, including a PrintDocumentTicket, if present, and the document content or reference URL.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><b>ReportDocumentState/ReplyToDocument</b><span class="Apple-converted-space"> </span>is used by the Cloud Print Manager to keep the Cloud Print Service up to date on the progress of the processing of the Job’s Document or that it has reached a terminated state. The current operations are split into a general update and one used after Job creation. Time will tell if both are needed.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt 0.5in; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: -0.5in; "><b>ReportPrinterState <span class="Apple-converted-space"> </span></b>is used by the Cloud Print Manager to keep the Cloud Print Service apprised of its state changes including changes to defaults or capabilities.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; ">The operations are currently modeled as requests from the Cloud Print Manager to the Cloud Print Service. The main reason for this is that in a Cloud environment it is assumed that the Cloud Print Client has network access to the Cloud Print Service and the Cloud Print Manager has network access to the Cloud Print Service. The reverse is not necessarily true. For example a Cloud Print Manager may be behind a firewall. A poll only model between Cloud Print Managers and Cloud Print Services in less than optimal. The Cloud Print Service should be able to send events to Cloud Print Managers (e.g., I have work for you). The Cloud Print Manager would have to be responsible for the establishment of that channel to allow for firewall traversal. An IETF standard, such as XMPP (rfc6120), would probably meet our requirements.<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "> <o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><span style="font-family: Impact, sans-serif; color: navy; ">Peter Zehler</span><span style="color: rgb(31, 73, 125); "><br><br></span><span style="font-size: 10pt; font-family: Tahoma, sans-serif; color: navy; ">Xerox Research Center Webster<br></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">Email:<span class="Apple-converted-space"> </span></span><a href="mailto:Peter.Zehler@Xerox.com" style="color: purple; text-decoration: underline; "><span style="font-size: 10pt; font-family: Arial, sans-serif; color: blue; ">Peter.Zehler@Xerox.com</span></a><span style="color: rgb(31, 73, 125); "><br></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">Voice: (585) 265-8755</span><span style="color: rgb(31, 73, 125); "><br></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">FAX: (585) 265-7441</span><span style="color: rgb(31, 73, 125); "><br></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">US Mail: Peter Zehler</span><span style="color: rgb(31, 73, 125); "><br></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">Xerox Corp.</span><span style="color: rgb(31, 73, 125); "><br></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">800 Phillips Rd.</span><span style="color: rgb(31, 73, 125); "><br></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">M/S 128-25E</span><span style="color: rgb(31, 73, 125); "><br></span><span style="font-size: 10pt; font-family: Arial, sans-serif; color: navy; ">Webster NY, 14580-9701</span><span style="color: rgb(31, 73, 125); "></span><span style="font-size: 12pt; font-family: 'Times New Roman', serif; color: rgb(31, 73, 125); "><o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><o:p> </o:p></div></div><br>--<span class="Apple-converted-space"> </span><br>This message has been scanned for viruses and<span class="Apple-converted-space"> </span><br>dangerous content by<span class="Apple-converted-space"> </span><a href="http://www.mailscanner.info/" style="color: purple; text-decoration: underline; "><b>MailScanner</b></a>, and is<span class="Apple-converted-space"> </span><br>believed to be clean. _______________________________________________<br>cloud mailing list<br><a href="mailto:cloud@pwg.org" style="color: purple; text-decoration: underline; ">cloud@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/cloud" style="color: purple; text-decoration: underline; ">https://www.pwg.org/mailman/listinfo/cloud</a><br></div></blockquote></div><br></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.
</body></html>