Michael,
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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
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?
Thanks,
Bill Wagner
From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of
Michael Sweet
Sent: Tuesday, December 10, 2013 9:06 PM
To: <cloud at pwg.org>; <ipp at pwg.org>
Subject: [Cloud] Simplified Cloud Imaging Diagram for a typical MFD
All,
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.
(When comparing this to the model described in IPPSIX, you'd just remove all
of the non-print services from the diagram...)
Thoughts? Does this roughly match everyone's internal picture of
cloud-based imaging?
_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20131211/ca9085d7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 92710 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/cloud/attachments/20131211/ca9085d7/attachment.png>
