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=Windows-1252">
<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:Impact;
panose-1:2 11 8 6 3 9 2 5 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 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.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-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">My comments are inline below.<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:
<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"><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""> mfd-bounces@pwg.org [mailto:mfd-bounces@pwg.org]
<b>On Behalf Of </b>Michael Sweet<br>
<b>Sent:</b> Wednesday, July 03, 2013 9:15 AM<br>
<b>To:</b> Manchala, Daniel<br>
<b>Cc:</b> mfd@pwg.org<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>
<div>
<p class="MsoNormal">Daniel,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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...)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">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;color:black">...</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"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Such as?<o:p></o:p></p>
<p class="MsoNormal"><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><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<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"><o:p> </o:p></p>
</div>
<p class="MsoNormal">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"><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>
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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. /><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</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"><o:p> </o:p></p>
</div>
<p class="MsoNormal">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"><span style="color:#1F497D"><PZ>Why would a JobStateReason of ‘</span><span style="color:#1F497D">JobQueueForMarker</span><span style="color:#1F497D">’ 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><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<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"><o:p> </o:p></p>
</div>
<p class="MsoNormal">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"><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. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<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"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Why? Can't we provide Job History for Print Jobs that have a hardcopy document?<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><PZ>It certainly complicates the ability to pause/resume and enable/disable individual services. It makes it more complicated to check to see if a service is available. 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. It will break the existing Standardized Imaging System Counters and associated MIB standards.</PZ><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<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"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I'm not sure I understand this comment.<o:p></o:p></p>
</div>
<div>
<p class="MsoListParagraph" style="margin-left:0in"><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><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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"><span style="color:#1F497D"><PZ>A generic Print Client should not be initiating a copy. 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><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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>
<p class="MsoNormal"><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.
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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>
<p class="MsoNormal"><span style="color:#1F497D"><PZ>This is a good opportunity to normalize the specification of hard copy input document processing.</PZ><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Andale Mono","serif"">_________________________________________________________</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Andale Mono","serif";color:black">Michael Sweet, Senior Printing System Engineer, PWG Chair<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><br>
<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>