On 2013-04-30, at 1:02 PM, William A Wagner <wamwagner at comcast.net> wrote:
> configuration of the Cloud Imaging entity. But in actually providing the imaging services, the Cloud Imaging entity embodies the characteristics of the MFD , what I think is referred to as the System Object itself.
I don't think there is any issue extending the notion of the System Object to encompass "servers" since both the SM and IPP have a long history of supporting "logical" devices and fan-out - the System Object for a Cloud-based implementation might just be a little bigger (more devices/sub-units) but the model still holds.
> The System Control Service aspect would be the way we address creation (which is to say, exposing) and modification of the available services (although there is still the question of creation of the Cloud System Control Service.) I agree that working on a Cloud parallel to the System Control Service would be a good approach to the management of the Cloud accessible imaging services . And I agree that including this aspect would provide a more complete model. I also have concerns about taking on too much right now. But I think it should be considered.
One of my original concerns with making "Registration" out-of-scope was that we were making it impossible to create generic, interoperable solutions/bindings of the model.
By defining a Cloud Imaging Control Service interface/model, we solve the interoperability issues - MFDs and Clients can be pointed to an endpoint URI that uses a standard interface, much like you do today when setting up your email account, and that allows the Client to enumerate and the MFD/CIM to instantiate the available imaging services.
Michael Sweet, Senior Printing System Engineer, PWG Chair
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...