[MFD] Re: [Cloud] Some random thoughts about the Cloud Imaging (Control?)Service

[MFD] Re: [Cloud] Some random thoughts about the Cloud Imaging (Control?)Service

[MFD] Re: [Cloud] Some random thoughts about the Cloud Imaging (Control?)Service

Ira McDonald blueroofmusic at gmail.com
Tue Apr 30 16:53:54 UTC 2013


Hi,

Oops - I meant Scan and *FaxOut* of course (for the scanner
input device).

Cheers,
- Ira





On Tue, Apr 30, 2013 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).
>
> 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* <http://www.mailscanner.info/>, and
>> is
>> believed to be clean. ****
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
>> is
>> believed to be clean.
>>
>> _______________________________________________
>> cloud mailing list
>> cloud at pwg.org
>> https://www.pwg.org/mailman/listinfo/cloud
>>
>>
>

-- 
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/mfd/attachments/20130430/3e61c54c/attachment-0002.html>


More information about the mfd mailing list