attachment
<div dir="ltr"><div><div><div><div><div>Hi Mike,<br><br></div>I like your drawing and explanations.<br><br></div>But conflating Input/Output Devices with Subunits (non-free-standing components of a Printer, <br>Scanner, Copier, etc.) bothers me. It doesn't cohere w/ the IETF Host Resources and Printer <br>
MIBs or the ISO 10175 DPA model (where subunits are all first-class objects).<br><br></div>I suggest changing the common bottom solid line below Print Service to SCS to a shorter height<br></div>block (than the service blocks) labelled "Shared Subunits (input tray, marker, etc.)" to clarify this<br>
</div><div>distinction.<br><br></div><div>Historical Note:<br><br>In the ISO 10175 DPA model, there is actually a top object of Server. For consistency w/ IETF Host <br>Resources and Printer MIBs, Pete and I renamed it from Server to System when I wrote the WIMS <br>
multifunction schema that Pete mostly adopted into the Semantic Model 2.0 schema. <br><br>The ISO DPA Control operation (all admin ops rolled into one command) has a target of Server <br>(and can startup or shutdown an instance of a Logical Printer).<br>
<br></div><div>Cheers,<br></div><div>- Ira<br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>
Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br>
<a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline">
</div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div>
<br><br><div class="gmail_quote">On Tue, Jan 14, 2014 at 11:46 AM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Smith,<div><br></div><div>The logical extension of the model in RFC 2911 would be this:</div><div><br></div><div><br></div><div><img src="cid:184FA538-BC6A-4779-BE5E-9B13B2F75010@eastlink.ca" width="840" height="403"></div>
<div><br></div><div><br></div><div>The combination of IPP Server and Service is the IPP Printer (object), which is the instance you are addressing using the "printer-uri" attribute. We could generalize IPP Printer (object) by calling it an IPP Service (object), however since the target attribute is "printer-uri" and FaxOut is already using the IPP Printer terminology it may be simpler to document that an IPP Printer may perform functions other than printing. Whether a single IPP Server is used for all Services is an implementation detail we don't need to specify (I could add dotted lined to join each of the IPP Servers if that would be clearer?)</div>
<div><br></div><div>Also, in order to allow device access from multiple services, I opted to show the services interfacing (loosely) with devices through an arbitration layer - this should allow pretty much any implementation while showing that devices (and subunits) may be shared between services.</div>
<div><br></div><div>Thoughts?</div><div><br></div><div><br><div><div class="im"><div>On Jan 10, 2014, at 3:37 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:</div>
<br></div><blockquote type="cite"><div style="word-wrap:break-word"><div class="im">So something more like this? <div><br></div></div><div><span><PastedGraphic-4.png></span></div><div><div class="h5"><div><br></div>
<div><br></div><div>The label “IPP Printer” was intended to convey that it was an IPP Printer Object.<div><br><div>
Smith<br><br><br>
</div>
<br><div><div>On 2014-01-10, at 12:46 PM, Michael Sweet <<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>> wrote:</div><br><blockquote type="cite">
<div style="word-wrap:break-word">Smith,<div><br></div><div>The IPP model defines a IPP Printer as the IPP Server + Service combination. So in your diagram having a shared IPP Server the interfaces with one or more services is a valid architecture, but the interior boxes should be the Print Service, Scan Service, FaxOut Service, etc. and not "IPP Printer" (which is the whole box).</div>
<div><br></div><div><br></div><div><div><div>On Jan 10, 2014, at 12:20 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:</div><br><blockquote type="cite">
<div style="word-wrap:break-word">Greetings,<div><br></div><div>For what it is worth, Pete’s description mirrors my own perception of the IPP object relationship. Graphically, this is how I understand the relationship between the “Printer objects” and the “server” to exist, at least in terms of IPP:</div>
<div><br></div><div><span><PastedGraphic-2.png></span></div><div><br></div><div>Pete, when you say “The Service URL identifies the service type”, do you mean that the resource path in a URL defines the service type? If so, I’m not sure that is guaranteed to be true. For instance “<a>ipp://myhost.pwg.org/ipp/fax”</a> could be “Fax” but could be anything. PWG 5100.15 says that an IPP FaxOut service MUST be at /ipp/fax but nothing prevents a single-function printer from having a conventional “Print” service at “/ipp/fax”. It seems that inspection of the “ipp-features-supported” is the way that one knows what service “type” is at a particular resource path.</div>
<div><br><div>
<div style="font-family:Arial;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">
Smith<br><br>/**<br> Smith Kennedy<br> ATB Wireless Architect - PPS<br> Hewlett-Packard Co.<br>*/<br><br><br></div>
</div>
<br><div><div>On 2014-01-10, at 7:06 AM, Zehler, Peter <<a href="mailto:Peter.Zehler@xerox.com" target="_blank">Peter.Zehler@xerox.com</a>> wrote:</div><br><blockquote type="cite"><div link="blue" vlink="purple" style="font-family:ArialMT;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" lang="EN-US">
<div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">Bill,<u></u><u></u></span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">
<span style="color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">I’m a little confused on what you have labeled as an IPP Server and IPP Printer. My view is that an IPP Server is what you have labeled as IPP Printer. It contains the required protocol stacks, resources and service instances. I have always understood an IPP Printer to be an instance of a Print Service. This would map to a Virtual Printer in ISO 10175 DPA.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">I have assumed that there would be a single IPP stack implementation (i.e., IPP Server in your first diagram) that would front end the service instances. Each service instance would be referenced by its unique URL (e.g., same URI Scheme, hostname and port, different paths) Implementers are free to do things differently but I assume the intent of the IPP specification would be to multiplex all the IPP Services over a single port (i.e., 631)<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">I agree that we could have used generic verbs but once we finished print we were stuck with the names of the verb. Since IPP uses an enumeration we can reuse the enumeration across the services. In the semantic model the operation does not really identify the service type. The Service URL identifies the service type. The operation names are simply service specific aliases for a common semantic operation. We could have opted for a generic name but we went with a naming convention instead.<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)">Pete<u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div><div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">
<span style="font-family:Impact,sans-serif;color:navy">Peter Zehler</span><span style="color:rgb(31,73,125)"><br>
<br></span><span style="font-size:10pt;font-family:Tahoma,sans-serif;color:navy">Xerox Research Center Webster<br></span><span style="font-size:10pt;font-family:Arial,sans-serif;color:navy">Email:<span> </span><a href="mailto:Peter.Zehler@Xerox.com" style="color:purple;text-decoration:underline" target="_blank">Peter.Zehler@Xerox.com</a></span><span style="color:rgb(31,73,125)"><br>
</span><span style="font-size:10pt;font-family:Arial,sans-serif;color:navy">Voice: <a href="tel:%28585%29%20265-8755" value="+15852658755" target="_blank">(585) 265-8755</a></span><span style="color:rgb(31,73,125)"><br></span><span style="font-size:10pt;font-family:Arial,sans-serif;color:navy">FAX: <a href="tel:%28585%29%20265-7441" value="+15852657441" target="_blank">(585) 265-7441</a></span><span style="color:rgb(31,73,125)"><br>
</span><span style="font-size:10pt;font-family:Arial,sans-serif;color:navy">US Mail: Peter Zehler</span><span style="color:rgb(31,73,125)"><br></span><span style="font-size:10pt;font-family:Arial,sans-serif;color:navy">Xerox Corp.</span><span style="color:rgb(31,73,125)"><br>
</span><span style="font-size:10pt;font-family:Arial,sans-serif;color:navy">800 Phillips Rd.</span><span style="color:rgb(31,73,125)"><br></span><span style="font-size:10pt;font-family:Arial,sans-serif;color:navy">M/S 128-25E</span><span style="color:rgb(31,73,125)"><br>
</span><span style="font-size:10pt;font-family:Arial,sans-serif;color:navy">Webster NY, 14580-9701</span><span style="color:rgb(31,73,125)"></span><span style="font-size:12pt;font-family:'Times New Roman',serif;color:rgb(31,73,125)"><u></u><u></u></span></div>
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span style="color:rgb(31,73,125)"> </span></div></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">
<span style="color:rgb(31,73,125)"> </span></div><div><div style="border-style:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;padding:3pt 0in 0in"><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">
<b><span style="font-size:10pt;font-family:Tahoma,sans-serif">From:</span></b><span style="font-size:10pt;font-family:Tahoma,sans-serif"><span> </span><a href="mailto:ipp-bounces@pwg.org" style="color:purple;text-decoration:underline" target="_blank">ipp-bounces@pwg.org</a><span> </span>[<a href="mailto:ipp-bounces@pwg.org" style="color:purple;text-decoration:underline" target="_blank">mailto:ipp-bounces@pwg.org</a>]<span> </span><b>On Behalf Of<span> </span></b>William A Wagner<br>
<b>Sent:</b><span> </span>Thursday, January 09, 2014 12:57 PM<br><b>To:</b><span> </span><a href="mailto:ipp@pwg.org" style="color:purple;text-decoration:underline" target="_blank">ipp@pwg.org</a>; 'Semantic Model 3.0 Workgroup discussion list'<br>
<b>Subject:</b><span> </span>[IPP] Models<u></u><u></u></span></div></div></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">
I am unclear on a Semantic Model configuration issue, which also may relate to IPP multifunction. The Semantic Model assumes that communication is from client to service. But in our operations, we identify the Service (e.g., CancelFaxInJob), which should not be necessary if the operation is directed to the service. On the other hand, depending upon where you want to put the transport address boundary, it is reasonable to think of operations being directed to the MFD, which corresponds to the System, in which case the service should be identified. Of course, this is inadequate if there are multiple services of a given type in the same system. Bottom line, should operations identify the Service type?<u></u><u></u></div>
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">With respect to IPP, should the multi service configuration look like A or B below? (or perhaps something else entirely?) Again, the modeling question is whether the service identification is included in the operation.<u></u><u></u></div>
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span><image001.jpg></span><span><image002.jpg></span><u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">
IPP Multifunction A IPP Multifunction B<u></u><u></u></div>
<div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">Thanks,<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">
Bill Wagner<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
</div>_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org" style="color:purple;text-decoration:underline" target="_blank">ipp@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/ipp" style="color:purple;text-decoration:underline" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
</div></blockquote></div><br></div></div>_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br><a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
</blockquote></div><br><div>
<span style="border-collapse:separate;font-family:'Andale Mono';border-spacing:0px"><span style="border-collapse:separate;font-family:'Andale Mono';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;border-spacing:0px"><div style="word-wrap:break-word">
_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></div></blockquote></div><br></div></div></div></div></div></blockquote></div><div><div class="h5"><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:'Andale Mono';word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:'Andale Mono';word-spacing:0px"><div style="word-wrap:break-word">
_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></div></div></div><br>_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br></blockquote></div><br></div>