attachment-0002
<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;"><div>Daniel,</div><div><br></div><div>Thank you for posting the minutes, some feedback on Copy below (and hoping that I can find time to call in for the next meeting...)</div><div><br></div><div><div>On Jul 2, 2013, at 7:45 PM, Manchala, Daniel <<a href="mailto:Daniel.Manchala@xerox.com">Daniel.Manchala@xerox.com</a>> wrote:</div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal"><o:p><font color="#000000" face="Consolas" size="2">...</font> </o:p></p><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span><!--[endif]-->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.</p></div></div></blockquote><div><br></div>Such as?</div><div><br><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"> Modeling copy as print requires intermediate
image storage from the AddHardCopyDocument to the time the print job is scheduled.</p></div></div></blockquote><div><br></div>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.</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"> 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.</p></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"> The normal
use case for a copy job is the walk up user who is physically present on the device.</p></div></div></blockquote><div><br></div>Right, and that user doesn't care how the printer performs the copy, just that they get the copies they want.</div><div><br><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"> A related issue is that lumping copy in with print diminishes the ability to monitor, manage and charge for copies.</p></div></div></blockquote><div><br></div>Why? Can't we provide Job History for Print Jobs that have a hardcopy document?</div><div><br><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"> More over additional IPP FaxOut and EmailOut (scan elements
/ aspects) are presently adhoc and could be brought into a Copy Service. </p></div></div></blockquote><div><br></div>I'm not sure I understand this comment.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>As a function of normalizing the Semantic Model I think the answer here is to formally define what a hardcopy document is, how hardcopy documents are processed, and what the standard/common elements are for all services that create (scan) them. We then use those common elements and semantics across all services that support hardcopy documents. Once we have done that I believe the perceived necessity of a Copy service will fade away.</div><div><br></div><div><span style="font-family: 'Andale Mono'; orphans: 2; text-align: -webkit-auto; widows: 2;">_________________________________________________________</span></div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; font-family: 'Andale Mono'; 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; ">Michael Sweet, Senior Printing System Engineer, PWG Chair</div></span></span>
</div>
<br><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;}
/* 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.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.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@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:1824932295;
mso-list-type:hybrid;
mso-list-template-ids:2021917748 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><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>