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 14 (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: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;}
@font-face
{font-family:Impact;
panose-1:2 11 8 6 3 9 2 5 2 4;}
@font-face
{font-family:"Andale Mono";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
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.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.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;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
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">All,<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";color:#1F497D">The thing that confused me about the diagram was the dotted line from the Proxy to the Local System Control Service. It is my view that the Local System Control
Service is just another service hosted on the MFD. (Yes I know that an implementation could host the services outside the MFD but from a functional view they are hosted on the MFD.)
<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";color:#1F497D">One difference I see with a Local System Control Service is that in addition to interactions with the Physical Device it would also interact with the other
hosted services. It must do so in order to control the other service and to access the other services instrumented data. The other difference between the Local System Control Service and other hosted services is that the Local System Control Service would
have an unfiltered view of the devices subsystems. The other devices would have a service specific view of the subsystems (e.g., Print Service does not present the scanner subunit). Of course this difference would not be obvious from the diagram. While
not included in this discussion the Physical Device could easily be replaced by a Physical Device Proxy and the model hold together.<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";color:#1F497D">I would replace the lower portion of Mike’s diagram with something similar to the following diagram. I also added a comment to #3 below.<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";color:#1F497D"><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";color:#1F497D"><img width="512" height="338" id="Picture_x0020_1" src="cid:image001.jpg@01CEF655.98C76320"></span><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";color:#1F497D"><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>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Impact","sans-serif";color:navy">Peter Zehler</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
<br>
</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:navy">Xerox Research Center Webster<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Email:
<a href="mailto:Peter.Zehler@Xerox.com">Peter.Zehler@Xerox.com</a></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Voice: (585) 265-8755</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">FAX: (585) 265-7441</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">US Mail: Peter Zehler</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Xerox Corp.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">800 Phillips Rd.</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">M/S 128-25E</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Webster NY, 14580-9701</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">
</span><span style="color:#1F497D"><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>
<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> Wednesday, December 11, 2013 9:04 AM<br>
<b>To:</b> William A Wagner<br>
<b>Cc:</b> <cloud@pwg.org>; <ipp@pwg.org>; Semantic Model 3.0 Workgroup discussion list<br>
<b>Subject:</b> Re: [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">Bill,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Dec 11, 2013, at 1:24 AM, William A Wagner <<a href="mailto:wamwagner@comcast.net">wamwagner@comcast.net</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Michael,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"> </span><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</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.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">True, but since we had our discussion in Monday's Cloud concall I felt it might be useful to expose it, at least for a "big picture" diagram. And this *does* mirror the IPP model diagrams in RFC 2911 and IPPSIX (figures 1 and 3) where
a local print service is connected to the IPP Server or IPP Proxy. IPP Server + Print Service == IPP Printer.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I made the line dotted mainly because we hadn't defined a concrete relationship - the proxy might get a list of services to register from the local system control service *or* it might get it from another source (web interface, etc.), which
gets it from the local system control service. Architecturally we may not care beyond the fact that the Semantic Model defines the local system control service in the model for an imaging device/system - that is something we should probably decide on and
document in the Cloud model.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">3.<span style="font:7.0pt "Times New Roman"">
</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 (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><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Adding the system object to the diagram would probably be useful. I'm not sure how we would show connections *to* this object, or whether we should (for purposes of simplifying the diagram) just update the system control service boxes
to be "system control service and system object"?<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><PZ>The System Object is a construct created and maintained by the Local System Control Service just as the Print Service Object is created and maintained by
the Local Print Service. Some of the attributes from the System Object are obtained from the Physical Device, other attributes are obtained from the other Local Services, and some are properties specific to the instance of the Local System Control Service.
I do not see any conflict in the other Hosted Services presenting information (e.g., System UUID, physical location) that is “owned” by the Local System Control Service as long as the values are consistent.</PZ><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">4.<span style="font:7.0pt "Times New Roman"">
</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.
</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Ira made some good comments, but I'll add one: you'll notice that the proxy is only connected to services. Only the local services are connected to the physical device. I believe that both mirrors our discussions and matches the Semantic
Model and IPP notions of separation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">5.<span style="font:7.0pt "Times New Roman"">
</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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I should probably remove all of the operation names from the diagram and add letter/number identifiers (as Smith has suggested). I shows "ListAllServices" as the most likely operation a client would use in order to discover which imaging
services are available, in preparation for creating a job, etc. on a specific service. Clearly the client would be able to perform any supported operation of the system control service, and I agree IdentifyDevice is one of the expected operations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif""> </span><br>
<br>
<o:p></o:p></p>
<div>
<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?</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal">Actually, I believe the bottom half of the diagram looks a lot like Figure 6 of MFD Common Model (PWG 5108.1), just turned on its side and combining the marker and scanner subunits as the "physical device" (also a SM term that is shared
with IPP - perhaps you would prefer "Multifunction Device" or "Multifunction Device/Subunits" here?)<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">Please remember: Semantic Model came from IPP. While some of the terminology was changed in the move to support multifunction services, and some of the responsibilities are moved around (i.e. system control service), the overall model remains
the same. The IPP Printer is an IPP Server talking to an Imaging Service, just as a web service binding using the Semantic Model schema and WSDL files is an XML-RPC server talking to an Imaging Service. In both cases the imaging services are talking to the
hardware subunits (as needed) with implementation-defined coordination with the System Control Service.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Andale Mono","serif";color:black">_________________________________________________________<br>
Michael Sweet, Senior Printing System Engineer, PWG Chair<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</body>
</html>