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
--
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/20130408/0bc296c0/attachment-0002.html>