Subject: [IPP] Simplified Cloud Imaging Diagram for a typical MFD

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Dec 2013 21:06:25 -0500

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

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Wed, 11 Dec 2013 02:43:56 +0000

HI Mike,

Thanks for doing this!

I’ve not personally had a chance to stare at it very hard just yet.  But my one suggestion for the diagram might be to label each of the vertices with a unique letter, and label each of edges with a unique number, so that one can describe a path or an edge / vertex interface in an unambiguous manner.  This could be useful in lieu of our being in one place and all able to “point” at things on a whiteboard or projector screen.

Smith

/**
    Smith Kennedy
    ATB Wireless Architect - PPS
    Hewlett-Packard Co.
*/

---

From: "William A Wagner" <[email-masked]>
Date: Wed, 11 Dec 2013 01:24:58 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Michael Sweet
Sent: Tuesday, December 10, 2013 9:06 PM
To: <[email-masked]>; <[email-masked]>
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?

---

From: Ira McDonald <[email-masked]>
Date: Wed, 11 Dec 2013 08:25:14 -0500

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/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
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 <[email-masked]>wrote:

> 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.
>
> 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.
>
> 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.
>
>
>
> system specific elements accessed via a System Control Service. Am I
> missing something?
>
> Thanks,
>
> Bill Wagner
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Michael Sweet
> *Sent:* Tuesday, December 10, 2013 9:06 PM
> *To:* <[email-masked]>; <[email-masked]>
> *Subject:* [Cloud] Simplified Cloud Imaging Diagram for a typical MFD
>
>
>
> All,
>
>
>
> (When comparing this to the model described in IPPSIX, you'd just remove
> all of the non-print services from the diagram...)
>
>
>
> cloud mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/cloud
>
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 11 Dec 2013 09:04:16 -0500

Bill,

On Dec 11, 2013, at 1:24 AM, William A Wagner <[email-masked]> 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.

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.

> 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.

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.

> 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.

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"?

> 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.

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.

> 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.

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.
 
> 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?

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?)

...

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.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 11 Dec 2013 14:44:35 +0000

All,

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.)

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.

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.

Peter Zehler

Xerox Research Center Webster
Email: [email-masked]<mailto:[email-masked]>
Voice: (585) 265-8755
FAX: (585) 265-7441
US Mail: Peter Zehler
Xerox Corp.
800 Phillips Rd.
M/S 128-25E
Webster NY, 14580-9701

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Sweet
Sent: Wednesday, December 11, 2013 9:04 AM
To: William A Wagner
Cc: <[email-masked]>; <[email-masked]>; Semantic Model 3.0 Workgroup discussion list
Subject: Re: [Cloud] Simplified Cloud Imaging Diagram for a typical MFD

Bill,

On Dec 11, 2013, at 1:24 AM, William A Wagner <[email-masked]<mailto:[email-masked]>> wrote:
Michael,

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.

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"?
<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>

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.

...

---

From: Michael Sweet <[email-masked]>
Date: Wed, 11 Dec 2013 10:07:52 -0500

Randy,

The arrows are mainly there to show which box initiates the communications.  And based on Smith's comments I think I'll just label each of the lines for later references so it truly is just a high-level view without any of the specific details.

On Dec 10, 2013, at 10:31 PM, Randy Turner <[email-masked]> wrote:

> 
> Hi Mike,
> 
> I think it’s a great idea to put together an unambiguous reference diagram like this — It looks like the arrows in the diagram suggest elements of procedure, but I’m assuming that each type of cloud functional procedure description would reference this diagram in order to completely specify “how things work”.  The arrows just emphasize what’s defined in the functional spec.
> 
> R.
> 
> 
> On Dec 10, 2013, at 9:06 PM, Michael Sweet <[email-masked]> wrote:
> 
>> All,
>>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 11 Dec 2013 10:08:21 -0500

Smith,

I like this idea and will update things accordingly.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 11 Dec 2013 11:09:38 -0500

Pete,

> 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 hos…

Absolutely, I just wasn't sure whether the proxy needed to talk to the local System Control Service...

> 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.

Right, however that interface is going to be a lot different than the service-level interfaces shown in the diagram.  Perhaps some sort of the containing box 

> 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.

Right. Again, my focus with this diagram was just to show the typical/common situation. If we can find a way to expand its scope without confusing things too much, all the better.

> 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.

I'd like to come up with a different way to show the relationship between the System Control Service and other services.  And maybe that applies to the interface between the services and physical device/subunits as well? (not a service-level interface and not something we document in the Cloud or Semantic Models...)

> <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>

OK, so do you think we could just leave the system object out of the diagram then?

---

From: "William A Wagner" <[email-masked]>
Date: Wed, 11 Dec 2013 11:22:45 -0500

Randy,

Although they may change as a result of these interchanges, we have been
talking about sequences for several months now and they are plotted in
ftp://ftp.pwg.org/pub/pwg/cloud/wd/wd-cloudimagingmodel10-20131125.pdf. 
Thanks,

Bill Wagner

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Randy Turner
Sent: Wednesday, December 11, 2013 11:06 AM
To: Michael Sweet
Cc: <[email-masked]>; <[email-masked]>
Subject: Re: [Cloud] Simplified Cloud Imaging Diagram for a typical MFD

Yeah, that label idea will come in handy in future references, and when we
want to talk about sequences.

R.

On Dec 11, 2013, at 10:07 AM, Michael Sweet <[email-masked]> wrote:

> Randy,
> 
> The arrows are mainly there to show which box initiates the
communications.  And based on Smith's comments I think I'll just label each
of the lines for later references so it truly is just a high-level view
without any of the specific details.
>> I think it's a great idea to put together an unambiguous reference
diagram like this - It looks like the arrows in the diagram suggest elements
of procedure, but I'm assuming that each type of cloud functional procedure
description would reference this diagram in order to completely specify "how
things work".  The arrows just emphasize what's defined in the functional
spec.
cloud-based imaging?

---

From: "William A Wagner" <[email-masked]>
Date: Wed, 11 Dec 2013 11:58:21 -0500

Michael and Ira,

I offer the following observation, subject of course to expert comment.

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.

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.

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*. 

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.

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. 

 Thanks, Bill Wagner

From: Michael Sweet [mailto:[email-masked]] 
Sent: Wednesday, December 11, 2013 9:04 AM
To: William A Wagner
Cc: <[email-masked]>; <[email-masked]>; Semantic Model 3.0 Workgroup discussion
list
Subject: Re: [Cloud] Simplified Cloud Imaging Diagram for a typical MFD

Bill,

Michael,

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.

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.

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"?

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.

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.

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?)

...

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.

---

From: "Zehler, Peter" <[email-masked]>
Date: Wed, 11 Dec 2013 20:13:31 +0000

All,
Mike asked "so do you think we could just leave the system object out of the diagram then?".  For this diagram my answer would be yes.

Peter Zehler

From: Michael Sweet [mailto:[email-masked]]
Sent: Wednesday, December 11, 2013 11:10 AM
To: Zehler, Peter
Cc: William A Wagner; <[email-masked]>; <[email-masked]>; Semantic Model 3.0 Workgroup discussion list
Subject: Re: [IPP] [Cloud] Simplified Cloud Imaging Diagram for a typical MFD

Pete,

On Dec 11, 2013, at 9:44 AM, Zehler, Peter <[email-masked]<mailto:[email-masked]>> wrote:
All,

...

1.      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.

---

From: Ira McDonald <[email-masked]>
Date: Wed, 11 Dec 2013 15:46:31 -0500

Hi,

For this diagram, I agree with Pete.  The System object is tucked away
invisible (sort of)
inside the System Control Service.

Cheers,
- Ira

On Wed, Dec 11, 2013 at 3:13 PM, Zehler, Peter <[email-masked]>wrote:

>  All,
>
> Mike asked “so do you think we could just leave the system object out of
> the diagram then?”.  For this diagram my answer would be yes.
>
>
>
> Peter Zehler
>
> Email: [email-masked]
> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>
>
>
>
>
> *From:* Michael Sweet [mailto:[email-masked]]
> *Sent:* Wednesday, December 11, 2013 11:10 AM
> *To:* Zehler, Peter
> *Cc:* William A Wagner; <[email-masked]>; <[email-masked]>; Semantic Model
> 3.0 Workgroup discussion list
> *Subject:* Re: [IPP] [Cloud] Simplified Cloud Imaging Diagram for a
> typical MFD
>
>
>
> Pete,
>
>
>
> 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.)
>
>
>
>  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.
>
>
>
> Right, however that interface is going to be a lot different than the
> service-level interfaces shown in the diagram.  Perhaps some sort of the
> containing box
>
>
>
>  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.
>
>
>
> Right. Again, my focus with this diagram was just to show the
> typical/common situation. If we can find a way to expand its scope without
> confusing things too much, all the better.
>
>
>
>  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.
>
>
>
> I'd like to come up with a different way to show the relationship between
> the System Control Service and other services.  And maybe that applies to
> the interface between the services and physical device/subunits as well?
> (not a service-level interface and not something we document in the Cloud
> or Semantic Models...)
>
>
>
>   ...
>
> 1.      According to the Semantic Model, there is an extensive client
> <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>
>
>
>

---

From: "William A Wagner" <[email-masked]>
Date: Thu, 12 Dec 2013 14:22:11 -0500

All,

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.

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.

1.       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.

2.       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.

3.       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.

4.       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.

a.       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.

b.      Alternatively, we posit some other service  associated with the
Cloud Imaging System that has detailed access to all associated Cloud
Services.

Thanks for your consideration and comments.

Bill Wagner

From: [email-masked] [mailto:[email-masked]] On Behalf Of
William A Wagner
Sent: Wednesday, December 11, 2013 11:58 AM
To: 'Michael Sweet'
Cc: [email-masked]; [email-masked]; 'Semantic Model 3.0 Workgroup discussion
list'
Subject: Re: [Cloud] Simplified Cloud Imaging Diagram for a typical MFD

Michael and Ira,

 Thanks, Bill Wagner

Bill,

Michael,

 

...