Mike,
I think the figure in RFC 2911, page 10 needs to be viewed in conjunction
with the figure in section 2.1, which deals with the relation of IPP to the
Printer Object and the output device. This second diagram makes clear that
the Client to Printer interface is IPP, but that the Printer to Output
device interface is 'any', possibly-- IPP. This could be taken in support of
your statement that the "Service <-> Output Device interface has never been
defined." Unfortunately, the diagram does not show an IPP interface in an
IPP Printer to IPP Printer (or Print Server to Print Service) communication,
although it is alluded to in the text in terms of a client function added to
the print server.
Your contention that an IPP Printer could have a thin connection to an
output device, and perhaps even that that connection could use IPP, may be
supported in RFC 2911. I agree that an output device could exist without an
embedded IPP Printer. But I still have difficulty with the notion that
software in a device that accepts and responds to IPP operations is
something other than an IPP Printer or that, from a Semantic Model
viewpoint, an MFD or Print Device which accepts and responds to the
SM-defined print service operations from a Client function does not embed a
Print Service.
We can avoid the question in the Cloud Printing Model by noting that we
wish to use the semantic model elements in the User Client to Cloud Server
interface because it is a well established interface that has proven
effective. We would also like to use this interface in the Cloud Print
Server to end destination interface. However, for various reasons, the Cloud
Print Server may not be able to access to the destination device. Therefore,
we define a set of operations which a function at the destination can
initiate to effect the same information communication that the Cloud Print
Server would if it were able. We name this function the Cloud Print Manager.
That is, by concentrating on enabling the communication, either in general
terms for the semantic model or specifically for IPP, and the fact that in
Cloud Printing (and possibly in other circumstances) there are factors that
interfere with what may be called a forward communication path, we can
address a solution to the communication problem and avoid the point of
contention. Actually, we may consider that we are defining a 'reverse'
interface that could be used in any case where IPP (or more generally, SM
compatible) communication cannot be initiated by a User Client (or
equivalent) function. This alternate interface could be used, conceivably
when a Print Service is behind a firewall with respect to a User Client,
without the need for postulating any Cloud Print Server (although there
would have to be some way of alerting the Print Service Client to start
communication),
Thanks,
Bill Wagner
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Monday, April 01, 2013 2:18 PM
To: William A Wagner
Cc: cloud at pwg.org
Subject: Re: [Cloud] Cloud Print Manager Operations
Bill,
On 2013-04-01, at 1:21 PM, William A Wagner <wamwagner at comcast.net> wrote:
...
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.
RFC 2911 has the following ASCII art diagram on page 10:
| --+
+--------+--------+ |
| IPP Server | |
+--------+--------+ |
| |
+-----------------+ | IPP Printer
| Print Service | |
+-----------------+ |
| --+
+-----------------+
| Output Device(s)|
+-----------------+
Basically, an IPP Printer is an IPP Server and Print Service that talks to
one or more Output Devices. Contrast this with the two forms of the model
described in section 4.2 of IPPSIX (I should probably include figures for
this...):
IPP MANAGER AS THIN GATEWAY
---------------------------
| --+
+--------+--------+ |
| IPP Server | |
+--------+--------+ |
| |
+-----------------+ | IPP Infrastructure Printer
| Print Service | |
+-----------------+ |
| --+
|
...
|
| --+
+------+------+ |
| IPP Client | | IPP Manager w/o Local Print Support
+------+------+ |
| --+
|
+---------+---------+
| Output Device(s) |
+-------------------+
IPP MANAGER AS FULL PRINT SERVICE
---------------------------------
| --+
+--------+--------+ |
| IPP Server | |
+--------+--------+ |
| |
+-----------------+ | IPP Infrastructure Printer
| Print Service | |
+-----------------+ |
| --+
|
| +-------------+
... |Local Clients|
| +------+------+
| |
| | --+
+------+------+ +------+------+ |
| IPP Client | | IPP Server | |
+------+------+ +------+------+ |
| | | IPP Manager w/Local Print
Support
+------+---------------+------+ |
| Print Service | |
+-------------+---------------+ |
| --+
+---------+---------+
| Output Device(s) |
+-------------------+
The Manager is an IPP Client that acts as a gateway/proxy for getting jobs
to the Output Device(s), and providing status and configuration back towards
the client. It *may* also be an IPP Server to service local clients.
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.)
Not necessarily, since the Service <-> Output Device interface has never
been defined. One could argue that a thin gateway protocol between the
Service and Output Device is 100% in agreement with the Semantic Model and
IPP: an Output Device with a (thin) IPP Manager component and no local IPP
Printer component need not have its own Semantic Model/IPP Print Service -
it can use the IPP Infrastructure Printer/Cloud Print Service to provide
that functionality, and this is no different from a local printer that is
hosted by a PC or other print server.
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.
It actually suggests nothing since (at the time, and even today) the
interfaces between Print Service and Output Device vary widely, i.e., "magic
happens", and all we care about is the information transferred and
operations performed.
Nothing in the current definition of the Cloud Print Manager/IPP Manager
requires a local Print Service since the Manager's primary role is as a
Client and not a Server. We've already defined the Server role...
_________________________________________________________
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/20130405/424d7c4b/attachment-0002.html>