Michael,
I know that I, in my text, occasionally have confused the terms Service and
System. Also, as you have indicated, my reference to current Client-Service
operations is confusing. But I am unclear on what your objection is. I have
not suggested that the Proxy request either system elements (aside from an
identification of supported services) or service elements from the Cloud
(although one could argue that some Clou Ststus information may be useful at
the Proxy/device).
So let me outline why I feel that both System Element Update and Service
Element Update are necessary both for registration and update. First, it was
my understanding that, although we talk about Device registration, since the
owner may limit what services and what elements of each service are to be
made accessible, it is actually Services that are registered (although
certain device/system elements must also be communicated.) Second, I sought
to follow precedent, and make Proxy initiated messages correspond to
responses from appropriate Client initiated messages. So, for example,
A tangential discussion! The GetSystemElements operation may need some
clarification from the Semantic Model Group. In System Object and System
Control Service Semantics, GetSystemElements can refer to elements directly
under the System Element: SystemConfiguration, SystemDescription, and
SystemStatus (and possible Services). This was my intent with Update System
Elements. However, at least my reading of the Schema Graphics, suggests that
the operation could request elements of specific services. I would request
that the SM group clarify this.
Back to main discussion.
1. The Update System Elements is necessary to inform the Cloud System
at least of SystemDescription and SystemStatus. One can argue whether System
Configuration is significant at this point since I believe we agreed that
Service Configuration is the determining factor in what is accessible. By
the way, when the Get System Elements operation is clarified in SM, it may
include the ability to list Services, in which case the Identify Services
operation is unnecessary.
2. We have already established that Update Service is necessary to
provide information on Service Capabilities, Service Configuration,
Service Description and Service Status. On Service registration, this
operation can reasonably be used to restrict what elements within these
element groups are not accessible to the Cloud Service by not including
them.
I would argue that the Proxy must provide some Service elements as well as
some System (i.e. device) elements during registration. How else would an
owner limit service capabilities that are made accessible to the Cloud
Service?
I find the need for Set Service Device, Update Service Device State and Get
Service Device Elements, or at least their names, confusing. Do these
refer to a Service or a Device (System). I realize (at least to me) there
are semantic differences between print oriented IPP and the semantic model.
Update Service Elements , which includes both Service Description
(read-write) and Service Status (read-only) elements would seem to be
sufficient for informing the Cloud Imaging Service of Device information.
Update Service Elements would do likewise for the Service. Since Service
(and System) Status includes all of the counters, metric information is also
as accessible as the Proxy which to make it.
Thanks,
Bill Wagner
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Monday, July 22, 2013 8:35 AM
To: William A Wagner
Cc: cloud at pwg.org
Subject: Re: [Cloud] Minutes posted from today's Cloud Imaging WG conference
call
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: <mailto:cloud-bounces at pwg.org> cloud-bounces at pwg.org [mailto:cloud-
<mailto:bounces at pwg.org> bounces at pwg.org] On Behalf Of Michael Sweet
Sent: Monday, July 15, 2013 4:25 PM
To: <mailto:cloud at pwg.org> 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>
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
<mailto:cloud at pwg.org> cloud at pwg.org
<https://www.pwg.org/mailman/listinfo/cloud>
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/acf42867/attachment-0002.html>