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; ">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; 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>