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></style></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-family:"Calibri","sans-serif";color:#1F497D'>Hello All,<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Calibri","sans-serif";color:#1F497D'>This discussion is exposing several issues  and questions. I suggest that there should be some consideration of these in the SM meeting as well.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif"'><span style='mso-list:Ignore'>1.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif";color:#1F497D'>Since the PWG has an approved candidate standard that Nancy suggests does not agree with the current schema, which takes precedence? I suggest that any  SM change must be reflected in an errata in the Common Model or specific Service candidate standard, as appropriate.</span><span style='font-family:"Calibri","sans-serif"'><o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif"'><span style='mso-list:Ignore'>2.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif";color:#1F497D'> Has the Get<service>ServiceElements  operation requested elements actually been changed? The Common Model indicates that “</span><span style='font-family:"Calibri","sans-serif"'>Some Services may accept an additional argument in a Get<service>ServiceElements request to further filter the response… The individual Service specifications identify such arguments if any, their effect and whether support is mandatory.”  My interpretation of this is that the Common Model allows the distinction between the SM and IPP operations to be eliminated for a specific Service if the Service Specification so mandates. I do not see this mandate in the FaxOut Service Specification. Should it be there? <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>3.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif";color:#1F497D'>In regard to </span><span style='font-family:"Calibri","sans-serif"'>GetFaxOutServiceElements and GetFaxJobElements as well as other operations (e.g., Activate and Deactivate), the proposed IPP FaxOut  binding  appears to follow IPP Printing rather than the SM FaxOut specification. (i.e., although  the IPP binding may allow specifying groups, it is mandated in the SM) Is this divergence valid? Or, if the differences are necessary, should the SM FaxOut specification </span><span style='font-family:"Calibri","sans-serif";color:#1F497D'>be updated? And if this update violates the Common Model, should that be updated? Essentially, should we be consistent among our standards?<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>4.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif";color:#1F497D'>Returning to the issue of  desired capability, I may have gotten lost, but it appears that three levels of Service capabilities are desired. Is this correct?<o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>a.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif";color:#1F497D'>Currently configured,  provided by </span><span style='font-family:"Calibri","sans-serif"'>Get-Printer-Attributes and (perhaps) by </span><span style='font-family:"Calibri","sans-serif"'>GetFaxOutServiceElements</span><span style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>b.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif";color:#1F497D'>Values that the implementation allows an administrator to configure, provided by </span><span style='font-family:"Calibri","sans-serif"'>Get-Printer-Supported-Values ( I find </span><span style='font-family:"Calibri","sans-serif"'>RFC 3380, 4.3, para 4 totally confusing and suggest that clarification is in order)</span><span style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>c.<span style='font:7.0pt "Times New Roman"'>       </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif";color:#1F497D'>The “</span><span style='font-family:"Calibri","sans-serif"'>original manufacturer xxx-supported values", which depending upon ones interpretation, may not be provided by IPP. The term “default” in the discussion is  unclear. Is the interest in manufacturer default configuration (why?)  or the ‘out-of-box’ capabilities that an administrator could configure?</span><span style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>5.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif";color:#1F497D'>So, whether or not IPP provides  it in </span><span style='font-family:"Calibri","sans-serif"'>Get-Printer-Supported-Values (which seems to depend upon the implementer’s interpretation), it is desired to include in the FaxOut SM a capability to </span><span style='font-family:"Calibri","sans-serif"'>get the full set of supported values for read/write elements.  Although some clarification is necessary, I think that </span><span style='font-family:"Calibri","sans-serif"'>Get<service>ServiceElements/Capabilities may  provide this, as distinguished from Get<service>ServiceElements/Configuration which would correlate with Get-Printer-Attributes.</span><span style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l1 level1 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>6.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif"'>Finally, in addition to the potentially new Get<service>ServiceSupportedElements operation (or whatever to call it) to be added to the FaxOut (and probably other Service SM) specifications,  the discussion  suggested that the SM group add the following:</span><span style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>a.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif"'>Handling of subscriptions</span><span style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 lfo2'><![if !supportLists]><span style='font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>b.<span style='font:7.0pt "Times New Roman"'>      </span></span></span><![endif]><span style='font-family:"Calibri","sans-serif"'>Identify<service>Service</span><span style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoListParagraph style='margin-left:1.0in'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><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"'> Ying Chen [<a href="mailto:chen.nancy5@gmail.com">mailto:chen.nancy5@gmail.com</a>] <br><b>Sent:</b> Thursday, March 07, 2013 5:09 PM<br><b>To:</b> Michael Sweet<br><b>Cc:</b> William A Wagner; <a href="mailto:ipp@pwg.org">ipp@pwg.org</a>; <a href="mailto:mfd@pwg.org">mfd@pwg.org</a><br><b>Subject:</b> Re: [IPP] Re: [MFD] Comments on IPP Faxout Spec w/r SM FaxOut Service<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Mike and Bill,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'd like to point out two things:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>1.  In Bill's #4 regarding SM GetFaxOutServiceElements request, it stated that "t<span style='font-family:"Arial","sans-serif"'>he allowed values for Requested Elements are Service Capabilities, Service Configuration, Service Description, Service Status or DefaultJob Ticket."  These are what specified in the current MFD Common SM 2.0 spec.  However the MFD Schema has evolved since.  The Requested Elements can be any element in the service.  But for operational efficiency, it is recommended to get a larger group element.</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>      I think the MFD Common Semantic Model should be updated accordingly.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>2.  In Mike's response to #5, regarding Get-Printer-Supported-Values -<o:p></o:p></p></div><div><p class=MsoNormal>From rfc3380 page 1,  "The Get-Printer-Supported-Values administrative operation returns values that the IPP Printer will accept for setting its "xxx-supported".  Notice that this operation does not return any "xxx-supported" values that cannot be set by an administrator.  Hence Mike is correct that "use Get-Printer-Supported-Values to get the full set of values that can be configured", but I did not see any semantic in rfc3380 that defines "Get-Printer-Supported-Values returns the original manufacturer xxx-supported values while Get-Printer-Attributes returns the values as configured by the administrator of the printer" as Mike said.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In MFD SM, "xxx-supported" attributes are defined in the "<service>ServiceCapabilities" group element, each elements in this group most of times is either a list of keywords or a range of values between a Lowerbound and Upperbound elements representing the allowed values for the xxx-supported attribute, or a boolean representing whether an attributed is supported or not.  There is a xxx-supported value for every <service>JobTicket element and every <service>JobDocument element.  For example, the JobHoldUntil element in JobTicketCapabilities is a list of keywords: "DayTime" "Evening" "Indefinite" "Night" ...etc, the Priority element has a Lowerbound and Upperbound sub-elements of integer type.  All Capabilities elements in MFD SM are settable by Admin.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Therefore, Mike is correct that there is no element in MFD SM that defines "the original manufacturer xxx-supported values".  I think this set of values are very useful when there is a need to restore <service> attributes to the manufacturer's defaults.  But I don't see the IPP spec (rfc3380) has this set of attributes defined either.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-Nancy<o:p></o:p></p></div><div><p class=MsoNormal>-------------------------------------------<o:p></o:p></p></div><div><p class=MsoNormal>Nancy Chen<o:p></o:p></p></div><div><p class=MsoNormal>Independent contributor, PWG Vice-Chair<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Thu, Mar 7, 2013 at 12:33 PM, Michael Sweet <<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>Bill,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Sorry, finally getting a chance to read through this and respond...<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>On Feb 24, 2013, at 4:50 PM, William A Wagner <<a href="mailto:wamwagner@comcast.net" target="_blank">wamwagner@comcast.net</a>> wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>In pursuing the question about  the SM correlation to Get-Printer-Suppported-Values in table 1, Operations for IPP FaxOut, there appear to be several inconsistencies.<o:p></o:p></span></p></div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>1.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>ValidateFaxOutJob  does not exist. ValidateFaxOutJobTicket is probably intended.<o:p></o:p></span></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>Correct.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>2.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>I find no RestartFaxOutJob in either the SM FaxOut Service or general SM Model. Does the make sense? There is a ResubmitFaxOutJob.<o:p></o:p></span></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>I believe IPP's Restart-Job was never brought into the Semantic Model because of the accounting issues is causes.  I can ban its use in FaxOut, much like we've banned Print-Job and Print-URI, if people prefer...<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>3.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'> The SM FaxOut Service does not appear to differentiate GetFaxOutJobElements from the general Get<service>JobElements, which has an important difference from IPP Get-Job-Attributes.  Unlike the IPP Get-Job-Attributes, the GetFaxOutJobElements request does not specify individual Elements. Rather, the Client requests specific groups of Elements contained within the Job. The allowed values for RequestedElements are Job Receipt, Job Status, or Job Ticket. It is not clearly stated whether the FaxOut follows the Common Semantics (presumably it must) or the IPP printer approach.<o:p></o:p></span></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>I believe this is an artifact of the web services binding; IPP has attribute groups that can be requested (job-template, job-description, etc.) as well as individual named attributes, so I don't think this is an issue.<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>4.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>The SM FaxOut Service does not appear to differentiate GetFaxOutServiceElements from the general Get<service>ServiceElements, which has an important difference from IPP Get-Printer-Attributes. Unlike the IPP Get-Printer-Attributes, the GetFaxOutServiceElements request does not specify individual Elements. Rather, the Client requests specific groups of Elements contained within the Job. The allowed values for Requested Elements are Service Capabilities, Service Configuration, Service Description, Service Status or DefaultJob Ticket. This distinction is not clearly stated.<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>Same comment as for #3.<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>5.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>As follows from item 4, the correlation to  SM Get-Printer-Supported-Values is GetFaxOutServiceElements with values of Service Configuration, Service Description and Service Status (??)<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>No, there is a semantic difference.  Get-Printer-Supported-Values returns the original manufacturer xxx-supported values while Get-Printer-Attributes returns the values as configured by the administrator of the printer - a configuration utility would use Get-Printer-Supported-Values to get the full set of values that can be configured and Get-Printer-Attributes to get the currently configured values.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>What we'd need is (effectively) a <service>DefaultConfiguration group in the Semantic Model to provide the same information.<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>6.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>Comment: - should the SM address subscriptions?<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>I think we need to for Cloud, at least.<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>7.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>ReleaseHeldNewFaxOutJobs does not exist. ReleaseHeldFaxOutJobs ( no 'new') is probably intended.<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>Correct.<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>8.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>Deactivate and Activate were dropped from the SM model. Do we really need these?<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>They are part of IPP already.  <o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>9.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>It might be noted that Startup-Printer correlates to StartupService (FaxOut) of the System Control Service.<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>Done.<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>10.</span><span style='font-size:7.0pt'> </span><span style='font-family:"Arial","sans-serif"'>Neither the SM FaxOut nor Common Semantics include an operation correlating to Reprocess-Job. It is not clear how this would act for FaxOut.<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>Same as for print I'd think - creates a new job as a copy of an existing one.  But ResubmitJob works that way and also accepts a new job ticket, avoiding the race condition for supplying new values before the job starts processing.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Perhaps we should deprecate Reprocess-Job for IPP FaxOut and just have Resubmit-Job?<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>11.</span><span style='font-size:7.0pt'> </span><span style='font-family:"Arial","sans-serif"'>Schedule-Job-After correlates to PromoteFaxOutJob. If the predecessor Job is specified, PromoteFaxOutJob acts the same way as the IPP Schedule-Job-After operation.<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>Done.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>12.</span><span style='font-size:7.0pt'> </span><span style='font-family:"Arial","sans-serif"'>There is no CancelFaxOutDocument in the FaxOut Service just a CancelFaxOutDocuments (note the 's') although the general semantics operations is Cancel<service>Document . Is this an error in the FaxOut Service spec?<o:p></o:p></span></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>Probably.<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>13.</span><span style='font-size:7.0pt'> </span><span style='font-family:"Arial","sans-serif"'>I find no IdentifyFaxOutService under FaxOut, Common Semantics or System Control Service. Should this be added to the SM FaxOut Service (and all other services) or perhaps to System Control Service?<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>It should be part of Common Semantics, with each service getting its own Identify<service>Service operation.<o:p></o:p></p></div><div><div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><div style='margin-left:.5in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>14.</span><span style='font-size:7.0pt'> </span><span style='font-family:"Arial","sans-serif"'>The FaxOut Service identifies the following operations that do not appear in the IPP FaxOut spec:<o:p></o:p></span></p></div><div style='margin-left:1.0in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>a.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>ResubmitFaxOutJob<o:p></o:p></span></p></div><div style='margin-left:1.0in'><p class=MsoNormal><span style='font-family:"Arial","sans-serif"'>b.</span><span style='font-size:7.0pt'>    </span><span style='font-family:"Arial","sans-serif"'>ValidateFaxOutDocumentTicket<o:p></o:p></span></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal>Yes, for some reason I missed adding those two operations to the table. Now added (for the next draft...)<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><o:p> </o:p></p></div><div><p class=MsoNormal>I'll hold off on publishing a new draft until we've had a chance to review the current one, but perhaps we can discuss whether Restart-Job and Reprocess-Job belong in IPP FaxOut, then the next draft will be that much cleaner...<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks!<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal><span style='font-size:13.5pt;font-family:"Andale Mono","serif"'>_________________________________________________________<br>Michael Sweet, Senior Printing System Engineer, PWG Chair<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><br>-- <br>This message has been scanned for viruses and <br>dangerous content by <a href="http://www.mailscanner.info/" target="_blank"><b>MailScanner</b></a>, and is <br>believed to be clean. <o:p></o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'><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><o:p></o:p></p></div><p class=MsoNormal><br><br clear=all><o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>-- <br><b><i><span style='font-family:"Arial","sans-serif"'>Nancy Chen</span></i></b> <o:p></o:p></p></div></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>