Bill,
I am OK with adding "upstream" as an adjective here to differentiate between the Infrastructure Printer/Cloud Print Service and any IPP Printer/Print Service embedded in the Output Device.
That along with the added figures should be enough to make everything clear...
On Apr 8, 2013, at 11:39 AM, William A Wagner <wamwagner at comcast.net> wrote:
> Mike,
>> OK, you are defining an IPP Manager as an entity that sends IPP requests, distinguished from the RFC2911 defined IPP Client (i.e., software controlled by an end user to send IPP requests to an IPP Printer; or the print server component that sends IPP requests to either an output device or another "downstream" print server) in that it sends IPP requests to an IPP Printer to relay print jobs to an Output Device.
>> I have no problem with that (although my wording might be a bit rough).
>> I guess that I have been unclear in my objection. My discomfort is in the wording :
> “…when the Output Device is not network accessible to the Printer…” (in SIX)
> and
> “…Output Devices that operate separately from the corresponding Service. “ (in the Cloud Model Intro)
> Because, these statements may be taken to not include the case where the Output Device embeds an IPP Printer or Print Service, which will be a common case.
>> Perhaps, paralleling the use of “downstream” in RFC2911, we could modify the wording to:
> “…when the Output Device is not network accessible to an “upstream” Printer…” (in SIX)
> and
> “…Output Devices that operate separately from an “upstream” Service. “ (in the Cloud Model Intro)
>> At any rate, I think we have batted this about enough.
> Thanks,
>> Bill Wagner
>> From: Michael Sweet [mailto:msweet at apple.com]
> Sent: Saturday, April 06, 2013 5:33 PM
> To: William A Wagner
> Cc: cloud at pwg.org; mfd at pwg.org> Subject: Re: [Cloud] Cloud Print Manager Operations
>> 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
>
_________________________________________________________
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/20130415/d6c1d2f1/attachment-0002.html>