attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Pete,<div><br><div><div>On Jan 10, 2014, at 9:06 AM, Zehler, Peter <<a href="mailto:Peter.Zehler@xerox.com">Peter.Zehler@xerox.com</a>> wrote:</div><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Impact;
        panose-1:2 11 8 6 3 9 2 5 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri","sans-serif";
        color:windowtext;}
span.EmailStyle20
        {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]-->
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1"><p class="MsoNormal"><span style="color:#1F497D">Bill,<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D">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.</span></p></div></div></blockquote><div><br></div>RFC 2911 says an IPP Printer is the combination of IPP Server and Print Service.</div><div><br></div><div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal"><span style="color:#1F497D">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)</span></p></div></div></blockquote><div><br></div>Well, IPP is layered over HTTP, so technically an IPP Server could/would multiplex based on the URI, and in fact can have multiple URIs (and port numbers, schemes, hostnames/addresses, etc.) for the same service.</div><div><br></div><div>Whether the same IPP Server is used for all the services is an implementation choice, and in fact there are many Apache httpd-based IPP solutions out there where httpd handles the incoming requests but separate service handlers do the IPP layer.</div><div><span style="color: rgb(31, 73, 125); font-family: Calibri, sans-serif; font-size: 11pt;"> </span><br><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal"><span style="color:#1F497D">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.<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p><p class="MsoNormal"><span style="color:#1F497D">Pete<o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p>
<div><p class="MsoNormal"><span style="font-family:"Impact","sans-serif";color:navy">Peter Zehler</span><span style="color:#1F497D"><br>
<br>
</span><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:navy">Xerox Research Center Webster<br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Email:
<a href="mailto:Peter.Zehler@Xerox.com">Peter.Zehler@Xerox.com</a></span><span style="color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Voice: (585) 265-8755</span><span style="color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">FAX: (585) 265-7441</span><span style="color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">US Mail: Peter Zehler</span><span style="color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Xerox Corp.</span><span style="color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">800 Phillips Rd.</span><span style="color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">M/S 128-25E</span><span style="color:#1F497D"><br>
</span><span style="font-size:10.0pt;font-family:"Arial","sans-serif";color:navy">Webster NY, 14580-9701</span><span style="color:#1F497D">
</span><span style="font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F497D"><o:p></o:p></span></p><p class="MsoNormal"><span style="color:#1F497D"> </span></p>
</div><p class="MsoNormal"><span style="color:#1F497D"> </span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> <a href="mailto:ipp-bounces@pwg.org">ipp-bounces@pwg.org</a> [<a href="mailto:ipp-bounces@pwg.org">mailto:ipp-bounces@pwg.org</a>]
<b>On Behalf Of </b>William A Wagner<br>
<b>Sent:</b> Thursday, January 09, 2014 12:57 PM<br>
<b>To:</b> <a href="mailto:ipp@pwg.org">ipp@pwg.org</a>; 'Semantic Model 3.0 Workgroup discussion list'<br>
<b>Subject:</b> [IPP] Models<o:p></o:p></span></p>
</div>
</div><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">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?<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">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.<o:p></o:p></p><p class="MsoNormal"><span><image001.jpg></span><span><image002.jpg></span><o:p></o:p></p><p class="MsoNormal">IPP Multifunction A IPP Multifunction B<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal">Thanks,<o:p></o:p></p><p class="MsoNormal">Bill Wagner<o:p></o:p></p><p class="MsoNormal"><o:p> </o:p></p><p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
_______________________________________________<br>ipp mailing list<br><a href="mailto:ipp@pwg.org">ipp@pwg.org</a><br>https://www.pwg.org/mailman/listinfo/ipp<br></blockquote></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; "><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></body></html>