attachment
<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi Mike,<br><br></div>I agree with everything you said, including your diagram clarification<br></div>for Devices and Subunits. In SM, Services do expose their associated<br>
</div>Subunits (we only partially do this in IPP Logical Printer at present), but<br></div>SCS actually controls the Subunits and their contained in the System<br></div>object.<br><br></div>Although I see the point of keeping "printer-uri" as the service endpoint,<br>
</div>I'm still sort of in favor of a new first-class IPP System object that is the<br></div>endpoint for System Control Service (using "printer-uri" and "printer-xxx"<br>attributes as appropriate). This seems a bit more intuitive, because<br>
</div>SCS is *not* just another Job service, but is strictly a Management<br></div>service.<br><br></div>My point with the ISO DPA and WIMS history was just to clarify the<br></div>where the terminology intersects.<br><br>
</div>So, a question. Can an implementation of SCS (at some "ipp/ipps"<br></div>URI endpoint) also accept Print commands at the same endpoint?<br></div>I suggest yes, but could be argued out of this. It partly has to do with<br>
</div>finding roll-up usage counters for all service instances from the SCS<br></div>somewhere on an IPP system.<br><br></div>Cheers,<br></div>- Ira<br><br></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 1:03 PM, 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">Ira,<div><br></div><div><div><div class="im"><div>On Jan 14, 2014, at 12:30 PM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><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></div></div></blockquote><div><br></div></div><div>Devices are directly addressable in IPP (and the Semantic Model) to support fan-out, while subunits are not (subunits get used/addressed as a side effect of intent), so it is important to show devices in the diagram. How about:</div>
<div><br></div><div> -- -- Arbitrated Device/Subunit Access -- -- -- -- -- -- -- -- -- -- -- -- -- --</div><div><br></div><div> +- Device -+ +- Device -+ +- Device -+</div><div> | Subunits | | Subunits | ... | Subunits |</div>
<div> +----------+ +----------+ +----------+</div><div><div><div><br></div><div>We can reference RFC 3805 for the definition of the different subunits, and we have already exposed some of them in the various IPP extensions (printer-supply, printer-input-tray, printer-output-tray, etc.)</div>
<div><br></div><div><br></div></div></div><div class="im"><blockquote type="cite"><div dir="ltr"><div>Historical Note:</div><div><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>
</div></div></blockquote><div><br></div></div></div>For Semantic Model the Object and Service are defined as separate entities, e.g., System Object and System Control Service. But IPP defines the combination of the IPP Server and Service as a combined IPP object, e.g. IPP Printer object is the IPP Server and Print Service, IPP System object would be the IPP Server and System Control Service, etc. I don't think there is a fundamental difference in the models that needs to be reconciled, just some words to document the difference in terminology and diagrams.</div>
<div><br></div><div>If we choose to make a distinction, the rightmost IPP Printer in my diagram could just be changed to IPP System. But I think we should still use a "printer-uri" attribute to target the System Control Service, reusing as much as possible from RFC 2911.</div>
<div class="im"><div><br></div><div><span style="font-family:'Andale Mono';text-align:-webkit-auto">_________________________________________________________</span><br><div><span style="border-collapse:separate;font-family:'Andale Mono';border-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">
Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br></div></div></div></blockquote></div><br></div>