attachment-0002
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Glen,<br><br></div><div>Comments inline...</div><div><br>On 2013-04-30, at 11:44 AM, "Petrie, Glen" <<a href="mailto:glen.petrie@eitc.epson.com">glen.petrie@eitc.epson.com</a>> wrote:<br></div><blockquote type="cite"><div class="Section1"><div><font color="#000000">...</font>
</div>
<div>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:
12.0pt">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:<o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="3" color="blue" face="Times New Roman"><span style="font-size:12.0pt;color:blue"> </span></font></p>
<p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue">[gwp] I like your name "Cloud
Imaging Control Service" (CICS). I am assuming, for the
simplest case (no fan-out), there is one CICS for each MFD (or if you like
Device Manager).</span></font></p></div></div></blockquote><div><br></div>Right.<div><br><blockquote type="cite"><div class="Section1"><div><p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue"><o:p></o:p></span></font></p>
<p class="MsoNormal"><span style="font-size: 12pt; font-family: 'Times New Roman'; ">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.</span></p></div>
<div>
<p class="MsoNormal"><font size="3" color="blue" face="Times New Roman"><span style="font-size:12.0pt;color:blue"> </span></font></p>
<p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue">[gwp] I don't understand the concept of the
CICS "creating new services". I thought that when an MFD is registered
with the Cloud Provider; it will now be the CICS that is "created"
and that the CICS will already know or poll the MFD for the supported (sub-)services
of the MFD.</span></font></p></div></div></blockquote><div><div>My thought was this: the Cloud Provider sets up the Cloud Imaging Control Service (probably when the User/Owner creates an account with them, or as part of a larger "always on" service supported by the Cloud Provider where account creation gives you limited access), and the Cloud Imaging Manager "registers" by starting Cloud Print/Scan/etc. Services through the CICS. Starting services is already something that is defined by the SM System Control Service.</div></div><div><br></div><div>Remember, the CICS doesn't talk to the MFD or the CIM, the CIM talks to the CICS. Having the CIM start the individual services gives the MFD owner control over which services are provided via the Cloud, and conversely the CICS can control which services it allows the CIM to start.</div><blockquote type="cite"><div class="Section1"><div><p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue">These CICS sub-services (print, fax, etc) would be to be advertised
the same way Transform Service would provide a list of its (managed)
sub-services. I believe the PWG should table, for a later
time, any activity that defines or creates an entity "… providing a
way for use to define registration of …." We already have lot
to handle already and individual Cloud Providers will have their own method and
processes for registration. Defining an MFD common
registration process can be done later and independent of the current work.</span></font></p></div></div></blockquote>Understand, one of the reasons I am so keen on having a Cloud version of the SM System Control Service is that it solves the "how do I instantiate/discover a Cloud XXX Service" problem without defining the implementation of the overall Cloud solution (the registration/account creation "problem").</div><div><br></div><div>So my goal is not to define Registration but Service Instantiation/Discovery. The creation/registration of a CICS is out-of-scope - for the purposes of the Cloud Imaging Model we can say it is pre-existing/provided by the Cloud. But that pre-existing CICS allows the CIM to start whatever services it wants to provide and the Clients to determine which services are available via the CICS.</div><div><blockquote type="cite"><div class="Section1"><div><p class="MsoNormal"><span style="font-size: 12pt; font-family: 'Times New Roman'; ">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.</span></p></div><div>
<p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue"> </span></font></p>
<p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue">[gwp] I understood that Users are
associated with Cloud Services via a registration process provided by the Cloud
Provider and not by Clients. Thus, the CICS, at registration,
enumerates the available sub-services to the Cloud Provider Registration
Process; during registration, the Owner defines which sub-services are
available for use and to whom. When a specific User registers with the
Cloud Provider or at some later date; it is the Cloud Provider Registration
Process that lists the available services that the specific User can be
associated with. It would then be the Cloud Provider that will provide
the list of available services to the Client. Once the User has
selected a services, the Cloud Provider invokes the correct CICS with the
identified sub-services being requested.</span></font></p></div></div></blockquote></div><div>We have been using "Association" for Users/Clients and "Registration" for MFDs/CIMs. And conceptually a CICS is always running (or appears so) without requiring additional, out-of-band communication with the Cloud Provider after the initial out-of-band association/registration that creates the CICS.</div><div><br></div><div><blockquote type="cite"><div class="Section1"><div><p class="MsoNormal"><span style="font-family: 'Times New Roman'; font-size: 12pt; ">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</span></p></div>
<div>
<p class="MsoNormal"><font size="3" color="blue" face="Times New Roman"><span style="font-size:12.0pt;color:blue"> </span></font></p>
<p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue">[gwp] can you elaborate some more.</span></font></p></div></div></blockquote><div>Supply levels, alerts, input and output trays, page counters, etc. Basically all of the status groups in the Semantic Model - read-only since my focus is on monitoring and not on remote-control/management.</div><div><br></div><blockquote type="cite"><div class="Section1"><div><p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue"><o:p></o:p></span></font></p>
<p class="MsoNormal"><span style="font-size: 12pt; font-family: 'Times New Roman'; ">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.</span></p></div><div>
<p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue"> </span></font></p>
<p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue">[gwp] What types of remote management?</span></font></p></div></div></blockquote><div><br></div>For example, adding or removing MFD services that are available via the Cloud, changing default and supported settings on the MFD (e.g. forcing duplex, limiting the list of media that is available), managing description elements (name, location, organization, etc.), and so forth.</div><div><br></div><div>(basically everything that CWMP is trying to do)</div><div><br><blockquote type="cite"><div class="Section1"><div><p class="MsoNormal"><font size="3" color="blue" face="Cambria"><span style="font-size:
12.0pt;font-family:Cambria;color:blue"><o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:
12.0pt"> ...</span></font><span style="color: blue; font-family: 'Courier New'; font-size: 12pt; "> </span></p></div><div>
<p class="MsoNormal"><font size="3" color="blue" face="Courier New"><span style="font-size:12.0pt;font-family:"Courier New";color:blue">Once the Clients
selects the (Sub-)Service then question is whether the client goes through the
CICS or communicates directly with sub-service. Either way would be
ok; just need to decide.</span></font></p></div></div></blockquote><div><br></div>Both, actually. To the CICS to find the service the Client is interested in, and to the Service itself to submit jobs, monitor jobs, etc. The Client could, of course, cache the Service information and/or discover it through other means.</div><div><br></div><div>(this mirrors how Clients do things locally)</div><div><br></div><div><blockquote type="cite"><div class="Section1">
</div>
</blockquote></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>