Hi,
A clarification about the way Pete and I envisioned the containment in
the Semantic Model.
An Imaging System *can* be a set of one or more Imaging Services
hosted on a general purpose application server (that also hosts other
unrelated applications). That's the typical case for an intermediate
spooler that forwards jobs to downstream devices.
An Imaging Device is *always* a physical device that *always* hosts
an Imaging System (in a dedicated manner).
So, an Imaging Device *always* contains an Imaging System, but an
Imaging System *may* not be hosted by an Imaging Device.
This has an impact on the scope of an Imaging System Control Service
(i.e., you can reboot the SCS and its child Imaging Services, but you
may *not* be able to reboot the enclosing application server device).
>From ISO 10175 DPA: a Logical Printer is simply a service; a Physical
Printer is always a device.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto: blueroofmusic at gmail.com
Winter 579 Park Place Saline, MI 48176 734-944-0094
Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
On Wed, Dec 11, 2013 at 1:24 AM, William A Wagner <wamwagner at comcast.net>wrote:
> 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
>>>> _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20131211/9cf34397/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/9cf34397/attachment.png>
