attachment
<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi,<br><br></div>A clarification about the way Pete and I envisioned the containment in <br>the Semantic Model.<br></div><br></div>An Imaging System *can* be a set of one or more Imaging Services<br>
</div>hosted on a general purpose application server (that also hosts other<br></div>unrelated applications). That's the typical case for an intermediate<br></div>spooler that forwards jobs to downstream devices.<br>
<br></div>An Imaging Device is *always* a physical device that *always* hosts <br>an Imaging System (in a dedicated manner).<br></div><br></div>So, an Imaging Device *always* contains an Imaging System, but an<br></div>Imaging System *may* not be hosted by an Imaging Device.<br>
<br></div>This has an impact on the scope of an Imaging System Control Service<br></div>(i.e., you can reboot the SCS and its child Imaging Services, but you<br></div>may *not* be able to reboot the enclosing application server device).<br>
<br></div><div>From ISO 10175 DPA: a Logical Printer is simply a service; a Physical<br></div><div>Printer is always a device.<br><br></div>Cheers,<br></div>- Ira<br><div><div><div><div><div><div><div><div><div><div><br>
</div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>
Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br>
<a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline">
</div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div>
<br><br><div class="gmail_quote">On Wed, Dec 11, 2013 at 1:24 AM, William A Wagner <span dir="ltr"><<a href="mailto:wamwagner@comcast.net" target="_blank">wamwagner@comcast.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Michael,<u></u><u></u></span></p><p class="MsoNormal">
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Thank you for the diagram. Some observations, rather that objections, particularly in areas that appear different from the model and diagram we had previously agreed to and that seem inconsistent with the Semantic Model.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><span>1.<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">We had avoided showing the interface between the proxy and local services, although the intention in defining the Proxy->Cloud operations was that the Proxy could communicate with the local services using the standard client-imaging service operations.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><span>2.<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">But having shown these connections, I wonder about the dotted line from the proxy to the Local System Control Service. I would expect that the Proxy acts as a proxy for the Local System Control Service to the same extent that it acts for the imaging services.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><span>3.<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">According to the Semantic Model, there is an extensive client interface to the System Control Service that provides access to both System Control Service elements and System Object elements (</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">SystemConfiguration, SystemDescription, and SystemStatus). However, the diagram shows no System Object either at the Cloud Level or the Local level (“Imaging System” in the lower right hand corner not withstanding.) The sort of information that a User might want to know about the physical location of the “device” (however one may wish to define it) is in the System Description. The UUID for the imaging device is the System UUID. I suggest that, as in the previous diagram, there is both a Cloud Imaging System and, if we are showing things beyond the Proxy, a Local Imaging System.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><span>4.<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">The diagram does not clear up the difference between a IPP Physical Device and a Semantic Model Device. By the SM definition definition, the Imaging Services are physically embodied within one or more physical devices. In most cases ( and certainly for a basic MFD), the Imaging System represents the elements of the Device and the System Control Service provides access to the values of these elements. Therefore, in an SM based model, I suggest that there are no lines from Imaging Services to the Device. Indeed, after the last Cloud call, I am eliminating all reference to “Device” as an actor in the cloud specification, in favor of System. <u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><span>5.<span style="font:7.0pt "Times New Roman""> </span></span></span><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">You presented a good argument for making IPP Identify Printer a service operation, primarily by stating that a normal user would be using a connection to a Imaging service not the System Control Service. I am unsure of the intent or limitations of the Client to Cloud System Control Service path shown in the diagram (is ListAllServices the only operation allowed?) However, although discovery is nominally of Imaging Services, it seems that the in the Semantic Model physical elements of interest in discovery should be accessed via the System Control Service, suggesting that a normal client should have at least read access to the System Control Service. It would seem reasonable that it could also trigger an Identify via this path.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">So, the diagram appears to reflect a IPP model using IPP terminology and does not reflect the Semantic Model of a System containing Services with system specific elements accessed via a System Control Service. Am I missing something?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Thanks,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif"">Bill Wagner<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:cloud-bounces@pwg.org" target="_blank">cloud-bounces@pwg.org</a> [mailto:<a href="mailto:cloud-bounces@pwg.org" target="_blank">cloud-bounces@pwg.org</a>] <b>On Behalf Of </b>Michael Sweet<br>
<b>Sent:</b> Tuesday, December 10, 2013 9:06 PM<br><b>To:</b> <<a href="mailto:cloud@pwg.org" target="_blank">cloud@pwg.org</a>>; <<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a>><br><b>Subject:</b> [Cloud] Simplified Cloud Imaging Diagram for a typical MFD<u></u><u></u></span></p>
</div></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">All,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Because we seem to be tripping over differences in terminology and our collective "big picture" of how cloud-based imaging is supposed to work, I put together the attached simplified diagram for a typical MFD that is registering Print, Scan, and FaxOut with a public cloud. Each of the local services is "connected" to a corresponding service in the cloud. I have purposely not included any fan-out in the diagram in order to focus our discussions on this simplified model. We can expand our discussions once there is agreement on the simplified model/diagram.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">(When comparing this to the model described in IPPSIX, you'd just remove all of the non-print services from the diagram...)<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thoughts? Does this roughly match everyone's internal picture of cloud-based imaging?<u></u><u></u></p></div><div><p class="MsoNormal">
<u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p>
</div><div><p class="MsoNormal"><img src="cid:image001.png@01CEF5F8.C66E1240" height="820" width="622"><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">_______________________________________________________________<br>
Michael Sweet, Senior Printing System Engineer, PWG Chair<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div><br>_______________________________________________<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" target="_blank">https://www.pwg.org/mailman/listinfo/cloud</a><br>
<br></blockquote></div><br></div>