REMINDER to ALL: Cloud Call this afternoon at 3PM ET!
Hi Mike,
Thank you for the comments. Sorry about the typos.
With respect to management capability, I guess I was confused by the "MAY"
operations listed in Table 4 for the Proxy (and I tend to get confused by
the IPP use of "Printer" and "Output Device" terms). By my understanding, an
Output Device may or may not include a Printer Object. But it is not the
(possible) local Printer Object that is the object of Proxy operations such
as "Activate-Printer" and "Shutdown-Printer", which I take as management
operations. Rather these are intended to allow a proxy to control the
Infrastructure Printer? And, since the Proxy presumably interfaces for the
"Output Device", I wonder about operations such as
"Get-Output-Device-Attributes" directed from the Proxy to the Infrastructure
Printer; is this to confirm the information in
"Update-Output-Device-Attributes" by which the Proxy has informed the
infrastructure printer of the output device attributes?
I am concerned that IPP SIX and Model differences may be more inherent than
just nomenclature differences.
On the question of monitoring/accounting, the Model does include Update of
Service Elements, which the set of which elements are included being
determined by the proxy. Service elements could include all of the service
counters. Update Job Status could similarly provide Job progress
information. I do not understand your comment that, in the Model, the
"existence of local Imaging Systems/Services is (currently) hidden" or that
there is a question "the details of how a Proxy tells the Cloud Imaging
System/Services which Imaging System it is representing at any given time".
All messages from the Proxy include the unique identification of the Local
Service relative to the message. And in registering and updating Systems, it
is intended that the values of all elements of the Local system that are to
be made known to the Cloud System are communicated.
Thanks,
Bill W.
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Monday, March 24, 2014 10:20 AM
To: William A Wagner
Cc: cloud at pwg.org
Subject: Re: [Cloud] IPP SIC- Cloud Imaging Model Comparison
Bill,
Thanks for doing this. While there are some typos in there, it generally
covers the differences accurately.
One comment on the basic differences on page 1:
The Cloud Model intentionally avoids any indication that the Cloud Service
can change or configure the Local service in any way; it can only submit
Jobs and monitor status. It appears that IPP-SIX also provides for
management of the local Service by the "infrastructure printer".
IPPSIX doesn't support remote management of local services. It would be
more accurate to say that it allows for remote monitoring/accounting of
individual Output Devices (Imaging Systems in SM parlance), while the
current Cloud Imaging Model only allows for monitoring/accounting of the
combination/collection of Output Devices/Imaging Systems associated with the
Cloud Imaging Service.
Thus, with IPPSIX you can answer the question "How many pages did I print to
the laser printer at 320 Sycamore?", but the Cloud Model cannot because the
existence of local Imaging Systems/Services is (currently) hidden, as are
the details of how a Proxy tells the Cloud Imaging System/Services which
Imaging System it is representing at any given time. I don't know whether
we want to expose those details in the Cloud Imaging Model, as those details
may depend on the binding/implementation - perhaps we may want to include
some discussion about which binding/implementation details are not specified
in the model that need to be?
On Mar 21, 2014, at 4:29 PM, William A Wagner <wamwagner at comcast.net> wrote:
I have posted an operations comparison at
ftp://ftp.pwg.org/pub/pwg/cloud/white/Cloud-IPPSIX_Compare_20140321.docx.
This is intended for discussion at the Monday Cloud Model conference call,
at 3PM ET.
Thanks,
Bill Wagner
_______________________________________________
cloud mailing list
cloud at pwg.orghttps://www.pwg.org/mailman/listinfo/cloud
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140324/808a7325/attachment.html>