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/20130401/588558e0/attachment-0002.html>