Bill,
On 2013-07-19, at 4:29 PM, William A Wagner <wamwagner at comcast.net> wrote:
> As I generate a Registration section for the Cloud Imaging Model, I would like to verify my understanding of the decisions made at Monday's meeting.
>> 1. The Device Owner, operating through the Cloud Imaging Device Proxy that provides the cloud interface for the device, registers the device and the device services he wishes to make available to the Cloud Imaging System. He may desire to block access to specific Device elements and Service elements. In response to information provided by the Device owner to the Proxy:
> a. The proxy provides Device registration information with an initial Update System Elements message to the Cloud System Control Service. This message provides information on all System Elements of the Device that are to be made known to the Cloud Imaging System. It corresponds to a response to a current Get System Elements message with all elements identified.
> b. The Proxy identifies the Device Services that are to be accessible to the Cloud Imaging System by sending an Identify Services message to the Cloud System Control Service. This corresponds to a response to a current List Services operation.
> c. The proxy identifies the elements of each Device Imaging Service that are to be made available to the corresponding Cloud Imaging Service by sending an initial Update Service Elements to an Owner-identified corresponding imaging service of the target Cloud Imaging System. This corresponds to a response to a current Get Service Elements operation.
I'm still not comfortable with the reference to Get Service Elements here. The proxy is providing Device Elements, not Service Elements. The Cloud Imaging Service "owns" its Service Elements, while the Proxy is providing the Device Elements used by that Service. Yes, the Imaging Service will reflect the Device Elements in the Service Elements reported by Get Service Elements, but that is an indirect mechanism, much as Status group elements cannot be set directly but reflect the state of a Service, Job, or Document.
Since the Proxy is registering the Imaging Device with a Cloud Imaging Service, we need to have a new operation (a la IPPSIX) called Set Service Device Elements that is used to set all of the READ-WRITE elements associated with the Imaging Device and a second operation called Update Service Device State that sets any of the READ-ONLY elements associated with the Imaging Device.
You can choose whether to also provide a Get Service Device Elements operation in Cloud Imaging - we have it in IPPSIX to allow for collection of metrics, etc. for specific Imaging Devices.
> 2. Once Device and Service registrations are complete, the Proxy will maintain contact with the Cloud System Control Service and the registered Imaging services, updating System and Service Elements and checking Cloud Imaging Services for jobs.
> Note:
> 1. It was decided that:
> a. Devices and Service are registered, not subunits
> b. Device Services can only be registered with corresponding Cloud Imaging Services
> c. Therefore: a Device subunit cannot be made accessible to a Cloud Imaging Service unless that subunit is configured as part of a Device Imaging Service that is registered with the Cloud Imaging Service. For example, a Cloud FaxIn Service can not use a marking engine in a Print Device unless that marking engine is also configured as part of a FaxIn service that is registered with the Cloud FaxIn Service. (This seems an unfortunate limitation to me.)
> 2. It was agreed that the Owner will want to place restrictions on:
> a. Who can use the device, with respect to one or more of the following:
> i. User ID, possibly including results of authentication
> ii. Geographical or network typological origin of the user
> iii. Payment or credit
> iv. Any one of various other conditions
> b. What services a user can use
> c. When each user can use what services (e.g., Print and Hardcopy Fax and Email only during working hours; FaxIn, EmailIn to storage all the time)
> d. Degree of use (e.g., max number of copies)for each particular user and Service
> e. Probably other conditions
> The owner will communicate with the Cloud Imaging System with an “access list” to identify these User rights and restrictions. This process is out of scope for the Cloud Imaging Model.
>> I would appreciate confirmation or correction of this understanding.
> Thanks,
> Bill Wagner
>>> -----Original Message-----
> From: cloud-bounces at pwg.org [mailto:cloud-bounces at pwg.org] On Behalf Of Michael Sweet
> Sent: Monday, July 15, 2013 4:25 PM
> To: cloud at pwg.org> Subject: [Cloud] Minutes posted from today's Cloud Imaging WG conference call
>> All,
>> I have posted the minutes to today's Cloud Imaging WG conference call to:
>>ftp://ftp.pwg.org/pub/pwg/cloud/minutes/cloud-concall-minutes-20130715.pdf>> Our next conference call will be on July 29, 2013 at 3pm ET.
>> _________________________________________________________
> 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.
>> _______________________________________________
> 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/20130722/c4342ffa/attachment-0002.html>