Mike,
You stated, with respect to my contention that a device accepting and
responding to IPP operations includes an embedded IPP Printer:
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.
Although I remain uncomfortable with this concept from the SM viewpoint,
the figure in section 2.1 of RFC 2911 indicates (with the 'any') that an
output device without an IPP Printer could accept an IPP Interface. So I
will not argue this further with respect to IPP. You wrote further:
Basically, if the output device does not accept IPP requests (i.e. it just
acts as a client to the Infrastructure Printer/Cloud Print Service) then it
isn't an IPP Printer with an IPP Server and Print Service, it is *just* an
IPP Manager.
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.
Now, I'll grant that most of the time an output device will have an embedded
IPP Printer (IPP Server + Print Service) and the Print Service will also
back the IPP Manager, but I've worked with enough printers over the years to
know that dumb printers that rely on an external servers/services are a
common occurrence on both extremes of the printer hardware spectrum.
No argument there. And indeed, because "most of the time an output device
will have an embedded IPP Printer", I felt that defining the Cloud Printing
Model in terms of "situations where the Output Device is not network
accessible to the Service" is confusing and misleading. Rather, since I
think we agree that the output device may or may not include an embedded IPP
printer, I suggested that the intent is to define an interface that is
functionally equivalent to a subset of existing IPP requests, but that is
initiated from the output device side (but not necessarily the output device
which is why the model defines a Cloud Print Manager, which serves,
potentially among other things, as a Output Device Client.) I am confused
by your response that:
Actually, no, I don't think we are defining anything of the sort. We have a
very specific model whose scope is the interface between the Output Device
and Print Service. Defining a Print Service to Client interface would
involve a completely different set of operations and is out of scope for the
chartered work.
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?
Finally, the SM was initially derived from IPP and although the model has
been extended ahead of IPP in some areas (and IPP goes beyond the model in
others) I think it important to not have them diverge in common semantics.
Whereas it is quite valid to have a non-IPP but SM compliant Print Service,
and reasonable to have IPP operations that go beyond what is in the SM,
equivalent features should be handled in the same way.
Thanks,
Bill Wagner
--
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/mfd/attachments/20130406/5917f720/attachment-0002.html>