attachment-0002
<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 14 (filtered medium)"><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:Consolas;
panose-1:2 11 6 9 2 2 4 3 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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.apple-style-span
{mso-style-name:apple-style-span;}
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.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle24
{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;}
/* List Definitions */
@list l0
{mso-list-id:629480289;
mso-list-type:hybrid;
mso-list-template-ids:-621522068 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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'>Hi,<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'>I was recently asked a question about RFC 2707 (Job MIB 1.0) and when I pulled up the document, I found the following text on the first page:<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'>“IESG Note<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'> This MIB module uses an unconventional scheme for modeling management information (on top of the SNMP model) which is unique to this MIB. The IESG recommends against using this document as an example for the<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'> design of future MIBs.<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 "Printer Working Group" industry consortium is not an IETF working group, and the IETF does not recognize the Printer Working Group as a standards-setting body. This document is being published solely to provide <o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'> information to the Internet community regarding a MIB that might be deployed in the marketplace. Publication of this document as an RFC is not an endorsement of this MIB.”<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'>I think that Pete makes a good observation in his point #1 that as an IEEE-ISTO standards body, the PWG does need to consider carefully the potential deprecation of an existing PWG standard in favor of handling the same task in a totally new way rather than a deprecation due to the publishing of a new updated version of a specification that obsoletes the previous version.<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'>Best Regards,<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'>/Paul<o:p></o:p></span></p><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>--</span><span style='font-size:12.0pt;font-family:"Times New Roman","serif";color:#1F497D'><o:p></o:p></span></p></div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>Paul Tykodi<br>Principal Consultant<br>TCS - Tykodi Consulting Services LLC<br><br>Tel/Fax: 603-343-1820<br>Mobile: 603-866-0712<br>E-mail: <a href="mailto:ptykodi@tykodi.com">ptykodi@tykodi.com</a></span><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'><br></span><span style='font-size:10.0pt;font-family:"Arial","sans-serif";color:#1F497D'>WWW: </span><span style='font-size:10.0pt;font-family:"Courier New";color:#1F497D'><a href="http://www.tykodi.com/" target="_blank"><span style='font-family:"Arial","sans-serif"'>http://www.tykodi.com</span></a></span><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"'> mfd-bounces@pwg.org [mailto:mfd-bounces@pwg.org] <b>On Behalf Of </b>Zehler, Peter<br><b>Sent:</b> Wednesday, July 03, 2013 2:08 PM<br><b>To:</b> Michael Sweet<br><b>Cc:</b> mfd@pwg.org; Manchala, Daniel<br><b>Subject:</b> RE: [MFD] Meeting Minutes: IEEE/ISTO – PWG/Semantic Model Working Group, 1 July 2013<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><span style='color:#1F497D'>All,<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'>My position on the Copy Service is<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>1)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>The PWG has published a standard specification for the Copy Service (PWG 5108.04). As a standards organization I believe it is not in the best interest of the PWG to decide that a specification approved more than two years ago is no longer relevant and that furthermore there is a completely new way to implement the feature.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>2)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>The PWG published a standard specification for Imaging System Counters (PWG5106.1 – 2007) and an associated MIB (PWG5106.3 – 2008) include the Copy Service.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>3)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>From the beginning of the SMv2( aka MFD) work the goal was to model user facing services of MFDs. Copy is a distinct user facing feature of an MFD.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>4)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>There was a need for remote service, device, and job management capabilities so that administrators, operators, and end users can monitor their health and status. In addition, there is a need for remote job submission capabilities so that operators and end users can create sophisticated jobs (e.g., with image enhancement, image transformation, etc.) without necessarily depending entirely on local console interfaces (which may have limited functionality). <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>5)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>These objectives above are of particular importance in light of today’s move towards mobile device centric network interactions.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>6)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>There are still companies out there that have products that allow very complex copy job construction in a production/demand-print environment. Simply specifying a document to be sourced from a scanner instead of passing it by value (i.e., AddDocument) or reference (i.e., SendUri) is not sufficient.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>7)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>AddHardCopyDocument initiates an immediate document data transfer (i.e., “MUST be prepared to add Document Data from the identified input to the identified Job”). The operation is analogous to SendUri operation in that the data is not appended to the network operation. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>8)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'> AddHardCopyDocument can only be used on a Job that has not been closed. Only closed Jobs are available for scheduling and allowed to move to the processing state.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>9)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>There are real world use cases that require site specific policy to be applied to Copy, Scan, Print and Fax. The existing PWG model is structured to facilitate this service level control.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>10)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>Customers in managed environments want to the usage counters from a MIB, a Service Interface and an invoice all agree with regards to what they are being charged.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>11)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>There are deployments that charge differently for Copy Jobs then they do for Print Jobs. Separate services keeps this simple.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>12)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>In managed environments queues need to be run out before another queue is allowed to be processed. In those environments a Print Service is Paused until the printing completes. The Copy Service can then be Resumed allowing those jobs to be handled. Then the Copy Service is Paused and a Print Service is Resumed. This is a real world scenario that is extremely complicated by mashing together Copy and Print into a single service.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>13)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>All Services that have hardcopy input should be normalized before SMv2 is published.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>14)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>There are optimizations that are available to an implementation of a Copy Service that is not available to and implementation of a Print Service in some environments. The effect of merging these two services could be accomplished by hiding the internal Print and Copy queues behind a network Print Service. I do not think that complexity should be forced on an MFD in exchange for reduced control and monitoring and abandoning a standard that is being used in products today.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo2'><![if !supportLists]><span style='color:#1F497D'><span style='mso-list:Ignore'>15)<span style='font:7.0pt "Times New Roman"'> </span></span></span><![endif]><span style='color:#1F497D'>I personally don’t like AddHardCopyDocument as a Print Service operation. I view Print as images in and impressions out. The submission is always an electronic document or a reference to one. I prefer copy as its own service and not a modified Print Job or a composite job modeled as Scan to Print. I may not like AddHardCopyDocument as a Print Service operation but I would not strenuously object to its optional inclusion. But that operation would be used during Job Creation just as the other Add operations are now.<o:p></o:p></span></p><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></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: </span><a href="mailto:Peter.Zehler@Xerox.com"><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Peter.Zehler@Xerox.com</span></a><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'><o:p> </o:p></span></p></div><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 [<a href="mailto:msweet@apple.com">mailto:msweet@apple.com</a>] <br><b>Sent:</b> Wednesday, July 03, 2013 12:03 PM<br><b>To:</b> Zehler, Peter<br><b>Cc:</b> Manchala, Daniel; <a href="mailto:mfd@pwg.org">mfd@pwg.org</a><br><b>Subject:</b> Re: [MFD] Meeting Minutes: IEEE/ISTO – PWG/Semantic Model Working Group, 1 July 2013<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Pete,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><div><p class=MsoNormal>On Jul 3, 2013, at 10:55 AM, Zehler, Peter <<a href="mailto:Peter.Zehler@xerox.com">Peter.Zehler@xerox.com</a>> wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:Consolas;color:black'>...</span><o:p></o:p></p></div></div></div></div></blockquote><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Jul 2, 2013, at 7:45 PM, Manchala, Daniel <<a href="mailto:Daniel.Manchala@xerox.com">Daniel.Manchala@xerox.com</a>> wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:10.0pt;font-family:Consolas'>...</span> <o:p></o:p></p><p class=MsoListParagraph style='text-indent:-.25in'>1.<span style='font-size:7.0pt'> </span>Do we need to have a separate Copy Service? The reason to have a separate Copy Service is that there are hardware optimizations that take place in a copy job that are not available to print.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Such as?<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><PZ>Scanning image into a proprietary format that is device specific. Vendors may wish to keep details of such a format private. There are optimizations that might be used for the transfer channel between the scanning subunit and the marker subunit. Several steps in the print service can be eliminated.</PZ></span><o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>How does adding a hardcopy document to a print job prevent any of those optimizations from happening?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The hardcopy document can be represented internally in any format by the implementation - this is part of the existing model.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The implementation controls the transfer channel between the scanning subunit and the marker subunit. Nothing in the model (or my proposed addition to Print to support the copy use case) would prevent the imaging device from using a proprietary format, optimized transfer channel, or magic pixie dust to optimize that imaging path, even on devices that support spooling of multiple jobs.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So which steps are we eliminating by using a Copy service vs. a Print service that supports hardcopy documents?<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><div><div><p class=MsoListParagraph style='text-indent:-.25in'>Modeling copy as print requires intermediate image storage from the AddHardCopyDocument to the time the print job is scheduled.<o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Why? For a Printer that only allows a single job at a time (the vast majority of printers), AddHardcopyDocument could stream the image data from the scanner to the print engine just as if a Client was streaming via Send-Document. No intermediate storage is required.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><PZ>There are many printers that support queuing multiple jobs at a time. There are printers capable of processing multiple jobs at a time. Don’t take a proven scalable model and protocol and constrain its capability based on a subset of the market. Adding a Hard Copy Document to a job does not require streaming the image data to the print engine. I see nothing in the model or protocol from allowing the addition of documents to a pending or pending-held job. Keep in mind that an open job (i.e., no CloseJob operation received) cannot be the scheduled or be the currently active job. Also keep in mind that AddHardCopyDocument is an illegal operation on a closed job.</PZ> </span><o:p></o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>OK, so going back to my last point about defining what a hardcopy job is, what is wrong with defining a document object that has a reference to an internal resource (the scanner) that is resolved (scanned) when it goes into the processing state? This matches what we do for printing with URIs, doesn't require a document to be added to a closed job, and allows the implementation to determine when the hardcopy document is scanned and either stored or streamed to the marker subunit?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I am by no means trying to constrain the model - I actually want printers to be MORE capable, not less - but am rather trying to simplify and unify support for hardcopy documents in the model, something that we have (thus far) shoved off into the corner as an edge case that effectively needs special software and works in slightly different and incompatible ways.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So please consider the following: rather than assuming the only way to support the copy use case is with a first class Copy service, let's revisit hardcopy documents *first* and come up with a consistent model to support them for all services that can use them.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>That will yield a more consistent and feature-rich interface for Scan, FaxOut, and EmailOut. It may also make the decision of whether we need a first-class Copy service more clear.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>And certainly if a Printer *does* support spooling of multiple jobs a Copy service job will wait in queue just as effectively as a Print service job - again, I don't see the need to force intermediate storage of the scanned document, it would just be an implementation choice.<span style='color:#1F497D'> <PZ>A Copy Service Job does not wait as effectively in a print Service queue. A copy job is constructed at the device meaning the documents within the job are added during the construction of the job. There are MFDs that provide a very rich set of document assembly choices for copy jobs. It is not always just putting a page on the platen and pressing copy. Even if intermediate storage is not required there are reasons stated above and below to treat a copy job as a copy job and not some modified print job. /></span><o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Again, I haven't read anything that would preclude the Print service performing all of the functions of the Copy service.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'> <o:p></o:p></p><div><div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoListParagraph style='text-indent:-.25in'>A copyjob does not suffer that sub-optimal image flow construct. Users are very familiar with copy and would be confused with a copy job showing up in a print queue.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>More confused than seeing their print job wait for an unknown reason? Both Print and Copy use the marker, but if somebody is making 100 copies of a 50 page presentation the user sending a print job could be waiting for a long time wondering why their job isn't printing. If instead they see a print job in the queue (for the copy) they will understand why their job isn't printing.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><PZ>Why would a JobStateReason of ‘JobQueueForMarker’ be any more confusing than ‘PrinterStopped’ when there is a paper jam. Naturally the Client software would present that to the user in an understandable format. Sooner or later there will have to be a service to show user’s the unified view of the MFD. Why shouldn’t a user be able to see a unified queue of all the jobs on an MFD?</PZ></span><o:p></o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>No reason, it is just that much more work for the Client to do if there is this extra service that sort-of works like the others, puts things in different places, and has no documents. Copy has been as a special-case service that has to do things differently, yet when you look at what the Copy service does it isn't clear why this has to be so.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><div><div><p class=MsoListParagraph style='text-indent:-.25in'>The normal use case for a copy job is the walk up user who is physically present on the device.<o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Right, and that user doesn't care how the printer performs the copy, just that they get the copies they want.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><PZ>Printers don’t perform copies, MFDs or Copiers do. The workflow at the device may be quite different when trying to copy on an inactive device or on a device that is currently printing a job. There may also be differences when trying to print pictures from a SD memory card versus copying a picture. User’s don’t care how an MFD does anything, they just want their output. But service provider do care how the jobs and services are represented in the model. </span><o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>A user *might* call it a copier. I don't know that anyone makes the distinction of "MFD" or "MFP" - I'm in the printing engineering department of Apple and *we* just say "I'll make a copy at the printer."<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So my use of casual terminology aside, you are very effectively making MY point - hardcopy documents are not currently represented in the model. In FaxOut we added Add<service>HardcopyDocument to represent hardcopy documents in FaxOut jobs, and in Copy we waved our hand and said "these are not the documents you are looking for".<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>We absolutely need to be able to represent hardcopy documents in the model. They are not currently represented. Once we *do* represent them we can support directly them in the Print, Scan, FaxOut, and EmailOut services - at that point does it still make sense to have a separate Copy service? Maybe so, maybe not. I just don't think it is a foregone conclusion that one *is* absolutely required. And if we *do* end up with a Copy service, it should have jobs with one or more (hardcopy) document objects, just like the other services.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><div><div><p class=MsoListParagraph style='text-indent:-.25in'>A related issue is that lumping copy in with print diminishes the ability to monitor, manage and charge for copies.<o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Why? Can't we provide Job History for Print Jobs that have a hardcopy document?<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><PZ>It certainly complicates the ability to pause/resume and enable/disable individual services.</span><o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>How?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If you are using the Copy service as a way to provide access control (disable copy service, nobody can copy from the Imaging Device?) then I suggest that we work in IDS to define proper access control mechanisms.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> It makes it more complicated to check to see if a service is available.</span><o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Again, are you trying to query an access control policy? Or supported operations (copy disabled means Add<service>HardcopyDocument is not supported)?<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>It makes it more difficult to establish policy for users a specific service. There are real world needs to independently control printing and copying and faxing on an installed MFD.</span><o:p></o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Agreed. But having implemented arbitrarily complex ACLs for CUPS, I don't think separate functional services are necessarily the answer. But I *do* think that the current Copy service model isn't the answer.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'> It will break the existing Standardized Imaging System Counters and associated MIB standards.</PZ></span><o:p></o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>How so? The system-level (SystemTotals) counters don't break out Copy counts, just total impressions and so forth. The Job MIB and various counters are broken out by service types (and not necessarily services - for example FaxIn vs. NetworkFaxIn, which are both supported by the single FaxIn service).<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><div><div><p class=MsoListParagraph style='text-indent:-.25in'>More over additional IPP FaxOut and EmailOut (scan elements / aspects) are presently adhoc and could be brought into a Copy Service. <o:p></o:p></p></div></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I'm not sure I understand this comment.<o:p></o:p></p></div><div><p class=MsoListParagraph><span style='color:#1F497D'><PZ>Adding a hardcopy document should be consistent across the services that deal with hard copy input (e.g., scan, faxout, copy).</PZ></span><o:p></o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>I'm in 100% agreement.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'> <o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The current CopyInTicket and CopyOutTicket try to overload the processing intent for both input and output. This makes it impossible for a generic print client to initiate a copy - fairly extensive modifications are necessary. FaxOut and EmailOut, in comparison, require only modest changes to add UI to specify the destination of the fax or email, and optionally UI to support selection of a hardcopy document instead of a local document or accessible URL.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><PZ>A generic Print Client should not be initiating a copy.</span><o:p></o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Because???<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>(how many smart phone/tablet applications are there from every printer vendor that allow you to print, scan, fax, copy, etc.?)<br><br><o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'>Print Job certainly cover the output side (i.e., Print), but it does not cover the input side (i.e., Scan). I disagree that the only changes to print for fax or email are limited to the selection of the hardcopy document. Certainly a low-end implementation could do that. Higher end clients would want the ability to correct things like brightness, contrast, and sharpness.</PZ></span><o:p></o:p></p></div></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Sure, but that is all common to scanning - something that a client will likely want to do with a multifunction Imaging Device. And something that presumably will be done using common code in the client to support Imaging Devices.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>If we implement Copy through the Print service with AddHardcopyDocument, the same print client and UI for Print, FaxOut, and EMailOut can be reused, the user can monitor both print and copy jobs in one place/queue, and the Imaging Device has one less service to maintain separately with slightly different semantics from the others.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><PZ>Print, Scan, Copy, FaxIn, and FaxOut are different and should be handled separately. EmailIn and EmailOut are an awful lot like FaxIn and FaxOut and since I have seen no strong pull for them I’ll ignore them for now. If the objective is to have an MFD client then one solution would be to implement a unifying view into the services. Another solution would be to extend 5108.06 to provide a unified queue with the usual queue operations. I see no reason to abandon the model or to try and shoehorn separate services into one. The Service, Job, and Document objects are similar enough to provide a unified view. </span><o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>We can argue whether the same UI gets used for print, fax, email, etc., but that's not my specific focus. Underneath the UI, the same code ends up getting used (to generate the paged data, to talk to the local service(s), to talk to the Imaging Device), and generally the HI guys want to present a similar user experience for dealing with documents and Imaging Devices.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm not arguing for a single meta service that does everything. Nor am I arguing for a single UI to support all functions of an Imaging Device. Rather, I am arguing for a consistent, well-defined model of Imaging Devices that can be implemented and interoperable, without a lot of special casing.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Maybe we need a Copy service, maybe we don't. But if we do, it should be consistent with the rest of the job-based services.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>There *are* some elements from CopyInTicket that are not present in InputElements/input-attributes - this I noted in the current IPP FaxOut specification. But the current SM FaxOut specification only allows specification of InputSource, which is clearly deficient.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#1F497D'><PZ>This is a good opportunity to normalize the specification of hard copy input document processing.</PZ></span><o:p></o:p></p></div></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal>Again, we're in 100% agreement here.<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><span style='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-family:"Times New Roman","serif"'><o:p> </o:p></span></p></div><p class=MsoNormal><span style='font-size:12.0pt;font-family:"Times New Roman","serif"'><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. <o:p></o:p></span></p></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>