attachment-0002
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Randy,<div><br></div><div>That's one of the reasons I specifically mentioned remote management as out-of-scope.</div><div><br></div><div>As for "realtime status information", we do actually need to provide that from the Cloud Imaging Manager, which is why a partial/efficient update interface is a design requirement. In the context of the subunit status and configuration information, a Cloud Imaging Manager might provide incremental updates of the marker supply values (several integers), media load information, and so forth as the values change. But we would not expect the Cloud Imaging Manager to upload all of the SM elements whenever a single element changes...</div><div><br></div><div><br><div><div>On 2013-04-30, at 3:48 PM, Randy Turner <<a href="mailto:rturner@amalfisystems.com">rturner@amalfisystems.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>If the group of information obtained through the interface is "static" (non-dynamic, rarely if ever changing), then that would be preferable - you really don't want a bunch of realtime status information flying over the internet to the cloud if you can help it. I don't believe the SM System Control service was designed with the "cloud" in mind, so implementers should take this into account (i.e., just because an interface is there, doesn't mean it's appropriate in every implementation). The same can be said of other system control service functionality or behavior that may not be appropriate in a cloud situation.<div><br></div><div>R.</div><div><br><div><div>On Apr 30, 2013, at 11:59 AM, Michael Sweet <<a href="mailto:msweet@apple.com">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Randy,<div><br></div><div>Since the proposed interface already provides a composite view of the subunit state/configuration reported by the Cloud Imaging Manager, I don't think it would be a stretch to have the Cloud Imaging Control Service report the roll-up view, much like the SM System Control Service already does.</div><div><br></div><div>But definitely #4 is out of scope for this round...</div><div><br></div><div><br><div><div>On 2013-04-30, at 2:39 PM, Randy Turner <<a href="mailto:rturner@amalfisystems.com">rturner@amalfisystems.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div>Hi Mike (and everyone else)<div><br></div><div>I think the main advantages to your approach are #1 and #2 -- to preserve simplicity, I would defer #3 and #4 -- I think the imaging provider should be kept as simple as possibly, with as much device complexity probably isolated to the manager portion of our model (or basically as far down our model hierarchy as possible)</div><div><br></div><div>Randy</div><div><br><div><div>On Apr 30, 2013, at 4:57 AM, Michael Sweet <<a href="mailto:msweet@apple.com">msweet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">All,<div><br></div><div>At yesterday's conference call we talked about the Cloud Imaging Service as a front-end or "meta" service that provided a coherent view of all MFD services registered with a Cloud Imaging Manager/Imaging Device. This service necessarily would need to be able to report all of the service endpoints, names, and types so that a Client or Cloud Imaging Manager would know which services were provided/registered and where, very much like the SM System Control Service.</div><div><br></div><div>I've been thinking some more about that and I think the Cloud Imaging Service *is* basically a SM System Control Service with additions to support the interface with the Cloud Imaging Manager. There are several advantages to this approach:</div><div><br></div><div>1. A System Control Service provides operations for creating new services, providing a way for us to define registration of new Cloud Imaging Managers/Imaging Devices with the Cloud Provider, something that we had previously tabled as out-of-scope. IMHO, this makes for a much more compelling model that has a chance of basic interoperability from the initial configuration of the Imaging Device.</div><div><br></div><div>2. A System Control Service provides a common interface for Clients to enumerate the available services they are interested in, vs. using a different interface depending on whether Cloud or local devices were being accessed.</div><div><br></div><div>3. A System Control Service provides a view of all subunits managed by its services; this opens up some interesting managed service options that would otherwise need to be handled through other, proprietary means</div><div><br></div><div>4. A System Control Service would allow us to address remote management of Imaging Devices (vs. services), although I believe we should still keep this out-of-scope for the 1.0 document.</div><div><br></div><div>In addition to the Cloud Imaging Manager operations, there are a number of additions I think we should make to the existing SM interface as well, which would affect *all* SM services:</div><div><br></div><div>1. Provide a way to get Imaging Device specific elements; in IPPSIX this is the new Get-Output-Device-Attributes, which returns the Printer attributes associated with a given device UUID - this is the converse of the Set-Output-Device-Attributes operation that is sent by the Manager to update/set the current configuration/capabilities of the device.</div><div><br></div><div>2. Add elements to enumerate the Imaging Devices associated with a service; for IPPSIX I just added parallel attributes called device-uuid, device-uuid-assigned, and device-uuid-supported.</div><div><br></div><div>3. Add elements to the Job and Document status groups that show the state on the Imaging Device assigned to that Job or Document. In IPPSIX these are the output-device-document-state, output-device-document-state-message, output-device-document-state-reasons, output-device-job-state, output-device-job-state-message, and output-device-job-state-reasons attributes.</div><div><br></div><div>All of the new Imaging Device elements and operations would probably remain optional for non-Cloud usage (implementations/administrators get to choose whether this information is exposed, just as in SM 1.0), but for Cloud I think we have to expose it in order to support the Cloud Imaging Service - Cloud Imaging Manager interface.</div><div><br></div><div>Finally, if the Cloud Imaging Service *is* a superset of the SM System Control Service, it might make sense to change the name to Cloud Imaging Control Service. That would express the hierarchy and heritage in (hopefully) a less confusing way:</div><div><br></div><div><br></div><div> Client -------> Cloud Imaging Control Service</div><div><div> | |</div><div> +----------> +------ Cloud Print Service -\</div><div> | +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager</div><div> \ +------ Cloud Scan Service --/</div></div><div><div> \ |</div><div> \ +------ Cloud Print Service -\</div><div> \-------> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager</div><div> +------ Cloud Scan Service --/</div></div><div><div> |</div><div> ...</div><div> |</div><div> +------ Cloud Print Service -\</div><div> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager</div><div> +------ Cloud Scan Service --/</div></div><div><br></div><div>Thoughts?</div><div><br></div><div><div>
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; 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; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</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.
</div>
_______________________________________________<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">https://www.pwg.org/mailman/listinfo/cloud</a><br></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.
</div>
_______________________________________________<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">https://www.pwg.org/mailman/listinfo/cloud</a><br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; 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; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; 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; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></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.
</div>
_______________________________________________<br>cloud mailing list<br><a href="mailto:cloud@pwg.org">cloud@pwg.org</a><br>https://www.pwg.org/mailman/listinfo/cloud<br></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; 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-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; 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-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</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>