Bill,
On Mar 24, 2014, at 11:53 AM, William A Wagner <wamwagner at comcast.net> wrote:
> ...
> 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?
That is certainly one possible use case. Another is to allow the Proxy to determine what information the Infrastructure Printer so it can generate a minimal Update-Output-Device-Attributes request, as major capability changes might interrupt job processing in the Infrastructure Printer.
However, I mainly have it there because a) it is a valid Client operation for monitoring/accounting already and b) it doesn't make sense to allow the Proxy to set the values but not get them.
> I am concerned that IPP SIX and Model differences may be more inherent than just nomenclature differences.
There are certainly some differences in detail and scope, but so far I don't see any semantic issues - the IPP binding of the Cloud Model necessarily exposes some IPPisms, but as long as we make it clear in the Cloud Model that this is allowed/expected then we can focus on the higher-level compatibility between the two - job processing, state management, etc.
> 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.
The operations include a ServiceUUID value, but it isn't clear to me whether that is the Cloud Imaging Service UUID (as the target of the operation) or the identifier of the local Imaging System or Service. Looking at the existing SM operations, it would seem that the target is implied in the model but uses ServiceUUID as the identifier for a SM Service. Maybe all that is needed is a different element name (ProxiedServiceUUID? DeviceServiceUUID? ProxiedObjectUUID? ImagingUUID? RemoteUUID?) with a matching definition to clarify what is being identified?
But like I said, the Proxy can provide all of the details to the Cloud Imaging Service but there is no way for the Client to ask for just those elements that correspond to a given local Imaging System or Service - you just get the roll-up counters of all proxied systems/services when you ask for the counters. What is needed is the equivalent of the IPPSIX Get-Output-Device-Attributes operation.
> 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.org>https://www.pwg.org/mailman/listinfo/cloud>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140324/3f634d37/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/cloud/attachments/20140324/3f634d37/attachment.p7s>