As I indicated, this was a draft for discussion. I am not particularly
convinced that I like all of these descriptions.
But, as I indicated in my comments to the proposed introduction, I am
uncomfortable with the notion of the semantic model defining an interface to
an 'Output Device' which does not contain a Print Service. By my
understanding, the Semantic Model defines the interface between a Client
function and a logical imaging Service. I would extend that to say that
something that accepts that interface IS an imaging service. By saying that
an Output Device (which I understand to represent a physical entity
equivalent to a Print Device) does not contain a Print Service is contrary
to the MFD Model spec definition (which, I admit, I wrote.)
Even by my understanding of RFC 2911 (which is less clear after 14 or so
years), IPP deals with the interface between client software (including a
client component within a print server) and an IPP Printer (which may or
may not be contained in an Output Device. ) Granted, the RFC also indicated
that IPP may or may not be used between an IPP Printer (a logical entity)
and an Output Device (a physical entity, I think). But the software
component in the Output Device is not named, and therefore suggests a
confusing logical to hardware interface.
At any rate, since I am thinking about the MFD Model spec update, I would
like to get this issue resolved to consensus.
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Monday, April 01, 2013 11:36 AM
To: William A Wagner
Cc: cloud at pwg.org
Subject: Re: [Cloud] Cloud Print Manager Operations
On 2013-04-01, at 10:53 AM, William A Wagner <wamwagner at comcast.net> wrote:
I have posted a discussion draft of the new operations for the Cloud Print
Manager to Cloud Print Service interface. These are based on Pete's
original suggestions as modified in our December face-to-face, and I suggest
that the minutes to the meeting be referred to in considering this draft. I
see some differences relative to the IPP SIX draft Mike posted last week.so
these should be resolved. Mike may have developed the ideas further since
the December meeting.
So WRT the list of CPM operations, I *did* tweak some things relative to the
current Cloud Print Requirements and Model:
1. GetFetchablePrintJobs in SM is just Get-Jobs+which-jobs="fetchable" in
IPP; this is consistent with how Get<foo><service>Jobs is mapped in MFD
2. UpdatePrintServiceState in SM became Update-Output-Device-State in IPP;
this is because the Manager is updating the state of the Output Device, not
of the Print Service (the Print Service provides a roll-up/combined state)
3. Added new Get/Set-Output-Device-Attributes IPP operation to query and
provide capabilities and descriptive attributes of the Output Device.
4. Added a new Acknowledge-Identify-Printer IPP operation to relay
Identify-Printer requests from the Client to the Manager.
5. UpdateFetchableJobs is currently called Reset-Fetchable-Jobs in IPP,
although I am fine with either name.
One of the key differences I see between the abstract model in Cloud Print
Requirements and Model and the binding model in IPP Shared Infrastructure
Extensions is that the relationship between the Cloud Print
Service/Infrastructure Printer, Cloud Print Manager/Manager, and Output
Device is explicit and follows the existing SM/IPP model for output device
fanout. IPPSIX allows multiple output devices to be associated with a
single instance of the Cloud Print Service/Infrastructure Printer and uses
an identifier (output-device-uuid) from the Cloud Print Manager/Manager to
identify which output device is being "addressed" or provided.
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...