Bill,
On 2013-04-06, at 12:58 PM, William A Wagner <wamwagner at comcast.net> wrote:
> ...
> No argument that if it does NOT accept IPP requests, it does NOT constitute an IPP Printer. I am not sure why I would call something that does NOT accept IPP requests an IPP Manager.
A Manager is a CLIENT, not a SERVER. It does not accept requests, it sends them.
> The charter for the IPP SIX effort is “ define new IPP operations and attributes to support the use of IPP in shared infrastructure environments, designed [sic] based on abstract operations defined in the Cloud Print Requirements and Model developed in the Cloud Imaging WG”. I see nothing about the interface between the Output Device and Print Service and it was my understanding that we have carefully avoided this since this may very well be a proprietary and perhaps an internal interface. You have stated that “Service <-> Output Device interface has never been defined” ; do I understand your statement to mean that the IPP SIX effort is to define it?
It defines one possible interface whose purpose is to specifically allow a IPP Printer to relay print jobs to an Output Device using IPP operations initiated from the Output Device/IPP Manager.
>
_________________________________________________________
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/20130406/edbd4138/attachment-0002.html>