attachment
<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)"><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;}
@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;}
@font-face
{font-family:"Andale Mono";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.EmailStyle23
{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><p class=MsoNormal><span style='color:#1F497D'>Michael,<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'>Yes, I don’t think that differs much from what I suggested; regardless of the physical configuration, the diagram indicates that the IPP Server, the Print Services and the output device are conceptually separate entities and the IPP Server and the Print Service comprise the IPP Printer. I think perhaps that point is that there is an IPP Server and there are various imaging services. A single IPP Service should be able to (but may not necessarily) support interfaces to different types of imaging services. One might suggest that referring to an IPP FaxOut Service is inappropriate. Rather, it is a IPP Server that handles IPP FaxOut communications (and perhaps other IPP Imaging communications) and interfaces with a FaxOut Service. <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'>The combination of an IPP Server with a Print Service is an IPP Printer. Is the combination of an IPP Server and a Scan Service an IPP Printer or an IPP Scanner? Is the combination of an IPP Server with multiple imaging services an IPP Printer or an IPP Multifunction?<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'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>Bill Wagner<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></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"'> Michael Sweet [mailto:msweet@apple.com] <br><b>Sent:</b> Friday, January 10, 2014 2:44 PM<br><b>To:</b> William A Wagner<br><b>Cc:</b> Peter Zehler; <ipp@pwg.org>; Semantic Model 3.0 Workgroup discussion list<br><b>Subject:</b> Re: [IPP] Models<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Bill,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The device isn't part of (as in embedded in) the Print Service in IPP, but there is an association between them.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>A single IPP Server *might* be a front-end for multiple services or it might only handle a single server - that's an implementation choice. The point in the IPP model is that the IPP Server is the protocol interface to the underlying service and device(s).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Jan 10, 2014, at 12:02 PM, William A Wagner <<a href="mailto:wamwagner@comcast.net">wamwagner@comcast.net</a>> wrote:<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><p class=MsoNormal><span style='color:#1F497D'>Pete,</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>The configuration of an “ IPP Printer” being composed of an IPP Server and a Print Service follows the diagram in IPP SIX and, indeed, goes back to RFC 2911. Furthermore, the “output device” was not considered part of the IPP Printer. We did not necessarily adhere to this configuration in the MFD model where we defined the Device as representing the hardware implementing the Service, prompting two distinct uses of the word “device”. I think the point of separating the IPP Server and the Print Service was that IPP just defines the IPP interface to the IPP Printer but does not define the form or specifics of the Print Service (one could argue that the Semantic Model does). But the separation is convenient in considering IPP multifunction so that, as you suggest, there is a common IPP front end to potentially multiple imaging services.</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>I am inclined, in the SM3 document, to eliminate the <service> term in defining operations (e.g., Create<service>Job), unless they are service-type specific. The understanding would be that the specific service is in the address. What is your opinion in this?</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Thanks,</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Bill Wagner</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></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"'> Zehler, Peter [<a href="mailto:Peter.Zehler@xerox.com">mailto:Peter.Zehler@xerox.com</a>] <br><b>Sent:</b> Friday, January 10, 2014 9:06 AM<br><b>To:</b> William A Wagner; <a href="mailto:ipp@pwg.org">ipp@pwg.org</a>; 'Semantic Model 3.0 Workgroup discussion list'<br><b>Subject:</b> RE: [IPP] Models</span><o:p></o:p></p></div></div><p class=MsoNormal> <o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Bill,</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></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><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><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><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><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.</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'>Pete</span><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></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><o:p></o:p></p><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></p></div><p class=MsoNormal><span style='color:#1F497D'> </span><o:p></o:p></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</span><o:p></o:p></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><image001.jpg><image002.jpg><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><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'>_______________________________________________<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">https://www.pwg.org/mailman/listinfo/ipp</a><o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p> </o:p></span></p><div><div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Andale Mono","serif";color:black'>_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair<o:p></o:p></span></p></div></div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><o:p> </o:p></span></p></div></div></body></html>