attachment
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1440682321;
mso-list-type:hybrid;
mso-list-template-ids:1807370694 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Michael,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></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.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><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.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><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.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><span style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><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"'><o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><span style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><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. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><span style='mso-list:Ignore'>5.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Bill Wagner<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></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"'> cloud-bounces@pwg.org [mailto:cloud-bounces@pwg.org] <b>On Behalf Of </b>Michael Sweet<br><b>Sent:</b> Tuesday, December 10, 2013 9:06 PM<br><b>To:</b> <cloud@pwg.org>; <ipp@pwg.org><br><b>Subject:</b> [Cloud] Simplified Cloud Imaging Diagram for a typical MFD<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>All,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></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...)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thoughts? Does this roughly match everyone's internal picture of cloud-based imaging?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><img width=622 height=820 id="_x0032_2D3A232-E2F4-4DEB-B045-BA564E05CB6B" src="cid:image001.png@01CEF5F8.C66E1240"><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>_______________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></body></html>