attachment-0002
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://31/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Bill,<div><br><div><div>On 2013-04-05, at 4:04 PM, William A Wagner <<a href="mailto:wamwagner@comcast.net">wamwagner@comcast.net</a>> wrote:</div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; "><font color="#000000">...</font><span style="font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(31, 73, 125); "> </span></div><div style="font-family: 'Times New Roman', serif; font-size: 12pt; margin: 0in 0in 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">could exist without an embedded IPP Printer. But I still have difficulty with the notion that software in a device that accepts and responds to IPP operations is something other than an IPP Printer or that, from a Semantic Model viewpoint, an MFD or Print Device which accepts and responds to the SM-defined print service operations from a Client function does not embed a Print Service.</span></div></div></div></blockquote><div><br></div><div>OK, so what I've said is this:</div><div><br></div></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><div>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.</div></div></div></blockquote><div><div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="font-family: 'Times New Roman', serif; font-size: 12pt; margin: 0in 0in 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">We can avoid the question in the Cloud Printing Model by noting that we wish to use the semantic model elements in the User Client to Cloud Server interface because it is a well established interface that has proven effective. We would also like to use this interface in the Cloud Print Server to end destination interface. However, for various reasons, the Cloud Print Server may not be able to access to the destination device. Therefore, we define a set of operations which a function at the destination can initiate to effect the same information communication that the Cloud Print Server would if it were able. We name this function the Cloud Print Manager.</span></div></div></div></blockquote><div><br></div>I understand why you might want to approach defining the abstract Cloud Print model this way. However, for purposes of the IPP binding of that model, I prefer to actually define how the pieces all fit together in order to have something that can be directly implemented.</div><div><br></div><div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="font-family: 'Times New Roman', serif; font-size: 12pt; margin: 0in 0in 0.0001pt; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">That is, by concentrating on enabling the communication, either in general terms for the semantic model or specifically for IPP, and the fact that in Cloud Printing (and possibly in other circumstances) there are factors that interfere with what may be called a forward communication path, we can address a solution to the communication problem and avoid the point of contention. Actually, we may consider that we are defining a ‘reverse’ interface that could be used in any case where IPP (or more generally, SM compatible) communication cannot be initiated by a User Client (or equivalent) function. This alternate interface could be used, conceivably when a Print Service is behind a firewall with respect to a User Client, without the need for postulating any Cloud Print Server (although there would have to be some way of alerting the Print Service Client to start communication)</span></div></div></div></blockquote><div><br></div></div>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...</div><div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></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>