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;}
@font-face
{font-family:"Andale Mono";}
/* 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.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle24
{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;}
@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;}
@list l1
{mso-list-id:1719628497;
mso-list-type:hybrid;
mso-list-template-ids:725807446 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1: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="2050" />
</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'>Happy New Year! We have a Cloud WG conference call scheduled for Monday 6 January at 3 PM ET. There was some interesting traffic on the mail list last month, but unfortunately no resolution to the impasse that we seem to have arrived at. We cannot seem to get past the description of operations and I have concluded that this is a problem with the model itself in that it is not consistent with the structure that the IPP WG has in mind. Since, so far as I understand, IPP has not really addressed the concept of an Imaging System and perhaps thinks it unnecessary even for entities performing multifunction services. The model I proposed (and which appeared to be accepted) is system oriented in that information common to multiple services was provided through the system but information specific to a service (such as job specific information) was provided by the corresponding service.<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 have no wish to impose a particular model upon the group, but I cannot continue with the specification without a model approach that the working group and I understand. I proposed an approach last month (below), to which I have received no response. This would eliminate all System communication (and mention) with respect to using Imaging Services via the Cloud (I have updated the diagram). Since this would be a major rewrite of the specification ( and all of the sequence diagrams). I would not proceed with his approach without active working group consensus.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I suggest that establishing a model approach, either based on what I propose or some other ideas, be the subject of Monday’s conference call. Based on consensus (or lack of same, or lack of comment), we can decide whether continue this project is warranted.<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'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Bill Wagner<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><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"'> William A Wagner [mailto:wamwagner@comcast.net] <br><b>Sent:</b> Thursday, December 12, 2013 2:22 PM<br><b>To:</b> 'Michael Sweet'<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><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'>My intention is to determine how (and whether) to proceed with the Cloud Model specification. It is apparent that there was some basic difference in my approach and IPP SIX, and in attempting to address specific comments (such as the name and content of what is now GetSystemNotification), I was just hiding the inconsistency.<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 propose a few points to revise the Cloud Specification in way that it will not raise IPP objections. If these can be resolved, I will proceed with the Cloud document.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><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";color:#1F497D'>The model deals with use of the Imaging Services, not with administration/management/maintenance. Or, if communication for administration/management/maintenance must be addressed, it be in a separate section.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><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";color:#1F497D'>Eliminate all reference to Device (whatever its meaning). All specified communication is to Services from Proxies or Clients. Necessary information relating to physical entities is obtained via Services. I would like to retain System as an element that contains Services that are somehow related in that the SystemControlService is aware of them.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><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";color:#1F497D'>Although we should understand how communication from Proxy to the Local Services could be conducted using the standard network interface identified in the Semantic Model, defining that communication is not a part of the Cloud Imaging Model and is not in the specification. It might provide the basis for a useful white paper.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><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";color:#1F497D'>In an attempt to define a more efficient Proxy-Cloud communication, the current Cloud Imaging specification provides for registering and maintaining communication on System basis (via the Proxy and the CloudSystemControl Service) as well as on an Imaging Service basis. The idea was to communicate information common to multiple Services just once rather than for each Service. I proposed this expecting some objection. But the comments just acted to overload this communication with information that a SystemControlService would not normally have. That is, the Proxy has the ability to aggregate and communicate information from all local Services; it is perhaps unreasonable to add this requirement to the CloudSystemControlService to the extent that it knows, for example, what Jobs are canceled, etc.<o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>a.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The model can be simplified to just deal with imaging services. The Proxy does not register the Local System with the CloudSystemControlService nor does it communicate with the CloudSystemControlService. Information for each Local Service is communicated to the corresponding Cloud Service independently via the Proxy. The Proxy must periodically query each Cloud Service with a GetFetchableJobs, and probably with a channel check and a check for canceled jobs. GetSystemNotifications goes away, at least for non-management functions.<o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo2'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>b.<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Alternatively, we posit some other service associated with the Cloud Imaging System that has detailed access to all associated Cloud Services.<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'>Thanks for your consideration and comments.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Bill Wagner<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><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">cloud-bounces@pwg.org</a> [<a href="mailto:cloud-bounces@pwg.org">mailto:cloud-bounces@pwg.org</a>] <b>On Behalf Of </b>William A Wagner<br><b>Sent:</b> Wednesday, December 11, 2013 11:58 AM<br><b>To:</b> 'Michael Sweet'<br><b>Cc:</b> <a href="mailto:cloud@pwg.org">cloud@pwg.org</a>; <a href="mailto:ipp@pwg.org">ipp@pwg.org</a>; '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><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Michael and Ira,<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 offer the following observation, subject of course to expert comment.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The IPP multifunction approach is evolving from IPP where there was just one type of service and the client dealt just with a Printer Object, that it accessed via a print service. Any necessary information about the physical “output” device came though the Service connection. I am not sure how IPP multifunction will evolve, but it could also have the normal user deal with just the service he is interested in and any necessary information about the “endpoint” comes though the Service connection. The IPP “System Control Service” would then be devoted to monitoring and management of the “Imaging System” and any physical components that were a part of it.<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'>True, the Semantic Model evolved from IPP. But the current version of the Semantic Model specifically addressed an MFD, considering how to handle multiple types of imaging services. So the Printer became expanded to an Imaging System and a System Control Service was defined to provide access to System Elements. I have perhaps overstressed the “Imaging System” and, as Ira points out, the system may not relate to a device in the case of a distributed . Perhaps the basic imaging services user need never even be aware that there is a system.<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'>So, if I drop my MFD mindset, a reasonable network model has the Imaging Services User just accessing the desire imaging service. Access to the System Control Service is limited to supervisory/management/maintenance users. As far as the basic User is concerned, there is no Imaging System and no *Imaging Device*; there are Services and elements in the Service provide information on the location of the endpoint, the IPP *physical device*. <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'>However, for practical purposes, there may still be justification for the Proxy to access the Cloud System Control Service (or some other Cloud-based component) that can provide/accept summary information for/from the Proxy just as the Proxy can provide summary information for the Local Services. The alternative, which would be simpler but involve more traffic, would be for the Proxy to just communicate with each Cloud Service independently.<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'>So, the diagram would show the both Cloud and local Services (including System Control Service) as being within Imaging Systems and the Proxy would interface with each Cloud Service and each local service. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> Thanks, Bill Wagner<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><img border=0 width=702 height=654 id="Picture_x0020_0" src="cid:image002.jpg@01CF07C5.EA361B80" alt="Basic Model 2.jpg"></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><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"'> Michael Sweet [<a href="mailto:msweet@apple.com">mailto:msweet@apple.com</a>] <br><b>Sent:</b> Wednesday, December 11, 2013 9:04 AM<br><b>To:</b> William A Wagner<br><b>Cc:</b> <<a href="mailto:cloud@pwg.org">cloud@pwg.org</a>>; <<a href="mailto:ipp@pwg.org">ipp@pwg.org</a>>; 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 lfo4'><![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 style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo4'><![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 style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo4'><![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></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 lfo4'><![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 style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo4'><![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 style='margin-bottom:12.0pt'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> </span><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";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>