Ira,
On 2013-04-30, at 12:42 PM, Ira McDonald <blueroofmusic at gmail.com> wrote:
> Hi Mike,
>> Excellent idea.
>> Re-using SM2.0 SCS and extending it for Cloud and Software Defined Network
> environments makes much more sense.
>> I agree with all of your suggestions for exposing OutputDevice (noting
> that for Scan and FaxIn we need the corresponding InputDevice).
I used the term "Output Device", but in the Semantic Model/Cloud Imaging Model terminology I probably really should use "Imaging Device". Output Device is an IPP-ism but my intent is to identify an imaging device regardless of the usage (input or output).
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - TCG Embedded Systems Hardcopy SG
> 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: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 Tue, Apr 30, 2013 at 11:44 AM, Petrie, Glen <glen.petrie at eitc.epson.com> wrote:
> Hi Mike,
>>>> Good idea. See comments below.
>>>> Glen
>>>>>> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of Michael Sweet
> Sent: Tuesday, April 30, 2013 4:58 AM
> To: cloud at pwg.org> Cc: mfd at pwg.org> Subject: [Cloud] Some random thoughts about the Cloud Imaging (Control?)Service
>>>> All,
>>>> At yesterday's conference call we talked about the Cloud Imaging Service as a front-end or "meta" service that provided a coherent view of all MFD services registered with a Cloud Imaging Manager/Imaging Device. This service necessarily would need to be able to report all of the service endpoints, names, and types so that a Client or Cloud Imaging Manager would know which services were provided/registered and where, very much like the SM System Control Service.
>>>> 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:
>>>> [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).
>>>> 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.
>>>> [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. 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.
>>>> 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.
>>>> [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.
>>>> 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
>>>> [gwp] can you elaborate some more.
>>>>>> 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.
>>>> [gwp] What types of remote management?
>>>> In addition to the Cloud Imaging Manager operations, there are a number of additions I think we should make to the existing SM interface as well, which would affect *all* SM services:
>>>> 1. Provide a way to get Imaging Device specific elements; in IPPSIX this is the new Get-Output-Device-Attributes, which returns the Printer attributes associated with a given device UUID - this is the converse of the Set-Output-Device-Attributes operation that is sent by the Manager to update/set the current configuration/capabilities of the device.
>>>> 2. Add elements to enumerate the Imaging Devices associated with a service; for IPPSIX I just added parallel attributes called device-uuid, device-uuid-assigned, and device-uuid-supported.
>>>> 3. Add elements to the Job and Document status groups that show the state on the Imaging Device assigned to that Job or Document. In IPPSIX these are the output-device-document-state, output-device-document-state-message, output-device-document-state-reasons, output-device-job-state, output-device-job-state-message, and output-device-job-state-reasons attributes.
>>>> All of the new Imaging Device elements and operations would probably remain optional for non-Cloud usage (implementations/administrators get to choose whether this information is exposed, just as in SM 1.0), but for Cloud I think we have to expose it in order to support the Cloud Imaging Service - Cloud Imaging Manager interface.
>>>> Finally, if the Cloud Imaging Service *is* a superset of the SM System Control Service, it might make sense to change the name to Cloud Imaging Control Service. That would express the hierarchy and heritage in (hopefully) a less confusing way:
>>>> [gwp]
>>>> Client <------> Cloud Provider
>> |
>> /------/
>> |
>> +----------> Cloud Imaging Control Service for MFD #1
>> | | |
>> | \ +------ Cloud Print Service -\ <<< Not available to this User
>> | \---> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
>> | +------ Cloud Scan Service --/
>> |
>> +----------> Cloud Imaging Control Service for MFD #2
>> | | |
>> | \ +------ Cloud Print Service -\
>> | \---> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
>> | +------ Cloud Scan Service --/ <<< Not available to this User
>> |
>> ...
>> |
>> +----------> Cloud Imaging Control Service for MFD #n
>> | |
>> \ +------ Cloud Print Service -\
>> \---> +------ Cloud FaxOut Service -+ <----- Cloud Imaging Manager
>> +------ Cloud Scan Service --/ <<< Not available to this User
>>>> 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.
>>>>>> Client <------------> Cloud Imaging Control Service for MFD #14
>> |
>> +-----> Cloud FaxOut Service -+<----- Cloud Imaging Manager
>>>> OR
>>>> Cloud Imaging Control Service for MFD #14
>> |
>> Client <-------------------> Cloud FaxOut Service -+<----- Cloud Imaging Manager
>>>>>>>>>> Client -------> Cloud Imaging Control Service
>> | |
>> +----------> +------ Cloud Print Service -\
>> | +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
>> \ +------ Cloud Scan Service --/
>> \ |
>> \ +------ Cloud Print Service -\
>> \-------> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
>> +------ Cloud Scan Service --/
>> |
>> ...
>> |
>> +------ Cloud Print Service -\
>> +------ Cloud FaxOut Service -+<----- Cloud Imaging Manager
>> +------ Cloud Scan Service --/
>>>> Thoughts?
>>>> _________________________________________________________
> 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.
>>> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>> _______________________________________________
> cloud mailing list
>cloud at pwg.org>https://www.pwg.org/mailman/listinfo/cloud>>
_________________________________________________________
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...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20130502/456b8047/attachment-0002.html>