attachment-0002
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><base href="x-msg://31/"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><div><div><div><p class=MsoNormal><span style='color:#1F497D'> Mike,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>You stated, with respect to my contention that a device accepting and responding to IPP operations includes an embedded IPP Printer:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div></div></div><blockquote style='margin-left:30.0pt;margin-right:0in'><div><div><div><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Although I remain uncomfortable with this concept from the SM viewpoint, </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> 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:</span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p></div></div></div></blockquote><div><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='text-indent:.5in'>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.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>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.<o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-left:.5in'>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.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>No argument there. And indeed, because “</span>most of the time an output device will have an embedded IPP Printer”, <span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I felt that defining the Cloud Printing Model in terms of</span><span style='font-size:11.0pt'> “</span>situations where the Output Device is not network accessible to the Service” <span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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: </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div></div><p class=MsoNormal style='margin-left:.5in'>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The charter for the IPP SIX effort is “ </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Bill Wagner<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p></div></div><br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.
</body></html>