attachment
<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.5pt;
font-family:Consolas;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.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;}
--></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=MsoPlainText>Pete,<o:p></o:p></p><p class=MsoPlainText>Thanks for the correction. A few items for clarification to see if I got it right. I would very much appreciate either agreement with or correction of my interpretation.<o:p></o:p></p><p class=MsoPlainText> 1. Hardcopy document refers just to the material that is being scanned and has no other correlation to Digital Document. For example, conceivably, a set of pages from multiple books could be scanned with the image data ultimately appearing in a single document. Alternatively, multiple pages for a single hardcopy document could be scanned and appear as multiple Digital Documents.<o:p></o:p></p><p class=MsoPlainText> 2. Image refers to the content in a specified scan region of a hardcopy document. Unless the scanner is set up to combine the data from multiple scanned images, an image cannot refer to more than the content of one sheet side. Therefore, for example, a scan job concerned with multiple pages of a hardcopy document will contain multiple images.<o:p></o:p></p><p class=MsoPlainText> 3. There is a 1:1 relationship between Digital Documents and files, in that each Digital Document is formatted and stored as a separatefile.<o:p></o:p></p><p class=MsoPlainText> 4. In general, the relationship of images to digital documents is format (and perhaps implementation) specific. If the 'document-format-accepted' is a document format such as PDF, there may be multiple images per document. If 'document-format-accepted' is an image format such as JPEG or GIF, each image is more likely a separate digital document.<o:p></o:p></p><p class=MsoPlainText> 5. In IPP Scan Push mode, all Digital Documents produced in a Job are scanned and formatted in the same way and stored to the same destination(s), as specified in the CreateJob.<o:p></o:p></p><p class=MsoPlainText> a. If the job produces multiple digital documents, the destination is a directory with each Digital Document being a separate file in that directory. <o:p></o:p></p><p class=MsoPlainText> b. If the job produces a single document, the specified destination is of the file.<o:p></o:p></p><p class=MsoPlainText> 6. In IPP Scan Push mode, the client may specify multiple destinations.<o:p></o:p></p><p class=MsoPlainText> 7. In IPP Scan Pull mode, each digital document produced by a job is sent back to the client in response to a GetNextDocumentImage request from the Client. Each document may contain data from a single image or from multiple images. There may be multiple documents as part of a single job. <o:p></o:p></p><p class=MsoPlainText> a. Unlike in Push mode, the Compression Accepted and Document Format Accepted may be separately specified in each <u>GetNextDocumentImage request.</u> <u>(I find this rather odd – especially since each such request does not necessarily correspond to either a Document or an image. )<o:p></o:p></u></p><p class=MsoPlainText> b. The mode of operation of GetNextDocumentImage depends upon whether Wait Mode is agreed upon. In Wait mode, data is sent as it becomes available and can be accepted. If not in Wait mode (or if Wait mode is interrupted or timed out) , the client must issue a GetNextDocumentImage for each buffer’s-worth of data.<o:p></o:p></p><p class=MsoPlainText> 8. This mode of transfer suggests that GetNextDocumentImage does not refer either to getting an Image or getting a Document, it just pulls data in a mode determined by the Wait mode. That data may be formatted into one or more Digital Documents, depending on format and contents.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I also understand that you suggest that the Scan Service in SM3 be changed to agree with IPP Scan.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Many thanks,<o:p></o:p></p><p class=MsoPlainText>Bill Wagner<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<br>From: Zehler, Peter [mailto:Peter.Zehler@xerox.com] <br>Sent: Friday, September 26, 2014 9:20 AM<br>To: William A Wagner; 'Michael Sweet'<br>Cc: ipp@pwg.org; cloud@pwg.org<br>Subject: RE: IPP Scan question.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>All,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>IPP Scan can support multiple document jobs. There are attributes that allow the printer to declare that capability ( "multiple-document-jobs-supported") as well as operational attributes ("document-number", "last-document") to segment the data pulled from the scan service into multiple files (i.e. one file per document, number of images in a file is format and implementation specific). During the prototype I used a scanner that emitted JPG or PDF. When loading a stack of media into the ADF each image acquisition resulted in an image. The number of documents objects generated was dictated by output file type. In the IPP binding I limited the file to document object association to 1 to 1. I did not want to deal with the complexities of associating multiple files with a single document object. The abstract MFD Scan model did allow multiple files per document.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Running a stack of paper using JPG as the " document-format-accepted" resulted in a multiple files each of which was associated with a single document. Running that same stack of paper using PDF as the "document-format-accepted" resulted in a single multipage file associated with a single document. From the client perspective using Get-Next-Document-Images behaved a bit different for each job. With the JPG output the responses had a document number that changed throughout the scan job retrieval. The number of responses with the same document number varied based on the complexity of the image. Each time the document number changed, the output file is closed and a new one is opened. The last Get-Next-Document-Images for the last document in the job set the "last-document" to true. In a push job version of this scan job, the same number of files are created at the destination. With the PDF output the responses had a document number remained the same throughout the scan job retrieval. When the last Get-Next-Document-Images for the job had the "last-document" to true, the output file was closed. In a push job version of this scan job, one file was created at the destination.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The MFD Scan model was created with the idea that the same protocol would be used locally or remotely. Therefore the was considerable more control over the behavior of the scanner itself. The IPP Scan service simplified a number of aspects to address the 98% needs for network scanning in a mobile environment. I expect the MFD Scan service would be adjusted to better reflect implementation experience within the PWG (i.e., IPP Scan) and in the industry (e.g., WS-Scan, UPnP Scan, vendor specific scan).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Peter Zehler<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>PARC, A Xerox Company<o:p></o:p></p><p class=MsoPlainText>800 Phillips Rd, 128-27E<o:p></o:p></p><p class=MsoPlainText>Webster NY, 14580-9701<o:p></o:p></p><p class=MsoPlainText>Email: <a href="mailto:Peter.Zehler@Xerox.com"><span style='color:windowtext;text-decoration:none'>Peter.Zehler@Xerox.com</span></a><o:p></o:p></p><p class=MsoPlainText>Office: +1 (585) 265-8755<o:p></o:p></p><p class=MsoPlainText>Mobile: +1 (585) 329-9508<o:p></o:p></p><p class=MsoPlainText>FAX: +1 (585) 265-7441<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<o:p></o:p></p><p class=MsoPlainText>From: William A Wagner [<a href="mailto:wamwagner@comcast.net"><span style='color:windowtext;text-decoration:none'>mailto:wamwagner@comcast.net</span></a>]<o:p></o:p></p><p class=MsoPlainText>Sent: Thursday, September 25, 2014 2:15 PM<o:p></o:p></p><p class=MsoPlainText>To: 'Michael Sweet'<o:p></o:p></p><p class=MsoPlainText>Cc: Zehler, Peter; <a href="mailto:ipp@pwg.org"><span style='color:windowtext;text-decoration:none'>ipp@pwg.org</span></a>; <a href="mailto:cloud@pwg.org"><span style='color:windowtext;text-decoration:none'>cloud@pwg.org</span></a><o:p></o:p></p><p class=MsoPlainText>Subject: RE: IPP Scan question.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Michael,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Thank you for your response.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>1. I agree that Figure 3 of the MFD Scan spec definitely indicates that there can be multiple images in one scan document; I do not see where it indicates that there cannot be multiple documents is a job. Furthermore, Figure 4 of that same document (with the associated text) definitely states that, for a multi-document Job, " Job object contains multiple Document objects. Each Document can have a different set of processing parameters."<o:p></o:p></p><p class=MsoPlainText>And further that the Scan Service semantic model may allow the End User to specify a multi-document Job as a service output. If we have intentionally decided to not consider multi-document jobs in IPP, that should be made clear. I think it is to be determined if we decide to eliminate them from the SM3. (Incidentally, I do not see a compelling Use Case for multi-document Scan Jobs, although some may exist.)<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>2. I get your explanation that Get-Next-Document-Images refers to multiple images of a document, and that "last-document" refers to the last image of a document. But these are names are misleading. Do we use 'Images' to refer to anything other than 'Document Images'?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I apologize for not commenting on the IPP Scan document earlier, but I think the one document per job characteristic, despite what one might expect from the names, should be made more clear. Also, as you suggest, the fact that for Pull Scan, the GetNextDocumentImages can redefine Compression Accepted and Document Format Accepted for each image of potentially multiple images document.<o:p></o:p></p><p class=MsoPlainText>Thanks,<o:p></o:p></p><p class=MsoPlainText>Bill Wagner <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<o:p></o:p></p><p class=MsoPlainText>From: Michael Sweet [<a href="mailto:msweet@apple.com"><span style='color:windowtext;text-decoration:none'>mailto:msweet@apple.com</span></a>]<o:p></o:p></p><p class=MsoPlainText>Sent: Thursday, September 25, 2014 9:12 AM<o:p></o:p></p><p class=MsoPlainText>To: William A Wagner<o:p></o:p></p><p class=MsoPlainText>Cc: Zehler, Peter; <a href="mailto:ipp@pwg.org"><span style='color:windowtext;text-decoration:none'>ipp@pwg.org</span></a>; <a href="mailto:cloud@pwg.org"><span style='color:windowtext;text-decoration:none'>cloud@pwg.org</span></a><o:p></o:p></p><p class=MsoPlainText>Subject: Re: IPP Scan question.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Bill,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> On Sep 21, 2014, at 9:50 AM, William A Wagner <<a href="mailto:wamwagner@comcast.net"><span style='color:windowtext;text-decoration:none'>wamwagner@comcast.net</span></a>><o:p></o:p></p><p class=MsoPlainText>wrote:<o:p></o:p></p><p class=MsoPlainText>> ...<o:p></o:p></p><p class=MsoPlainText>> It is also clear from the IPP Scan specification GetNextDocumentImages<o:p></o:p></p><p class=MsoPlainText>operation that a scan job can have multiple documents.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I don't think these are multiple document objects, however.<o:p></o:p></p><p class=MsoPlainText>Get-Next-Document-Images is a convenient way to pull one or more images/pages from the scanner, but from the point of view of the model they are part of one document object and would be delivered (in the case of push<o:p></o:p></p><p class=MsoPlainText>scan) as a single file.<o:p></o:p></p><p class=MsoPlainText> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> The Cloud conference call comment is that FetchJob (corresponding to <o:p></o:p></p><p class=MsoPlainText>> Destination, DestinationAccesses, and InputElements for Scan with no<o:p></o:p></p><p class=MsoPlainText>need to have a FetchDocument operation. This suggests that there is but one document (possibly with multiple destinations) in a Scan Job.<o:p></o:p></p><p class=MsoPlainText>Alternatively, it may be that the Input Parameters and Destinations for each one of multiple documents are defined in the CreateJob. This seemes inconsistent with the general Imaging Service model.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>In the case of Scan, the CreateScanJob operation is instantiating a single scan job containing a single document object that may have multiple digital representations (e.g. PDF, TIFF, etc.) of the same images. Figure 3 on page<o:p></o:p></p><p class=MsoPlainText>22 of the MFD Scan spec seems pretty clear on that point. This is similar to how the Copy and FaxIn services work (single document jobs).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Print, FaxOut, and Transform can support multiple digital document inputs (and thus multiple document objects).<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I think the only inconsistency here is that some job services support multiple document objects and some don't. But I don't think that hurts the overall model - just something worth pointing out.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>(and perhaps as well worth considering/mentioning that most Print and FaxOut service implementations only support single document jobs...)<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> The IPP Scan specification definitely refers to multiple documents in <o:p></o:p></p><p class=MsoPlainText>> one<o:p></o:p></p><p class=MsoPlainText>scan job. However, Figure 1 can be interpreted to mean that the only operation necessary for Scan is a CreateJob, with GetNextDocumentImages necessary if it is a Pull Scan Job. Indeed, InputAttributes is defined to be in the CreateJob request as well as are the Job Template attributes defining destination; but it does not appear that different InputAttributes and/or destinations can be specified for different documents.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I think the choice of reusing the "last-document" operation attribute in the response of Get-Next-Document-Images operation is causing confusion here. It really is (semantically) "last-document-image".<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Pete, do you think this is worth an editorial change before publication, either the attribute name or the description ("indicating that the last document IMAGE has been reached")?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> [Also, Compression Accepted and Document Format Accepted are defined <o:p></o:p></p><p class=MsoPlainText>> in CreateJob, but also in GetNextDocumentImages for Pull Scans. Can it <o:p></o:p></p><p class=MsoPlainText>> be assumed that requests in GetNextDocumentImages takes precedence?]<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I think this needs some clarification - you put those in Create-Job for a Push Scan and in Get-Document-Images for a Pull Scan.<o:p></o:p></p><p class=MsoPlainText> <o:p></o:p></p><p class=MsoPlainText>> Do I correctly understand that, although there may be multiple <o:p></o:p></p><p class=MsoPlainText>> documents<o:p></o:p></p><p class=MsoPlainText>in a scan job, they must all have the same InputAttributes and the same destination(s)? An alternate approach might have been to send a SetDocumentAttributes sent for each document to be scanned, which contained the input parameters and destination for each specific document/image file; that would have been consistent with the Model.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Currently you scan whatever is at the input source and send it to the<o:p></o:p></p><p class=MsoPlainText>destination(s) or pull the images with Get-Next-Document-Images. The only way to break things up is to create multiple jobs and specify the number of images for each job in the "input-images-to-transfer" member attribute.<o:p></o:p></p><p class=MsoPlainText> <o:p></o:p></p><p class=MsoPlainText>> For Cloud, we need to decide whether we should reflect the Semantic <o:p></o:p></p><p class=MsoPlainText>> Model<o:p></o:p></p><p class=MsoPlainText>(with which we should bet be consistent) or the IPP Scan Binding. Or do we need to change the semantic model?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>The intent is that IPP Scan would update the SM definition of SM Scan, since SM Scan doesn't deal with Pull Scan.<o:p></o:p></p><p class=MsoPlainText> <o:p></o:p></p><p class=MsoPlainText>> Also, a few minor editorial comments/questions I had while looking up<o:p></o:p></p><p class=MsoPlainText>stuff.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> 1. Table 1 lists Get-Next-Document-Images and<o:p></o:p></p><p class=MsoPlainText>refers to PWG 5100.SCAN. I take it that this means to have the specification refer to itself, but it is confusing even if the proper number is inserted. Better to refer to the internal paragraph.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Agreed.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> 2. Figure 1 refers to the operation as<o:p></o:p></p><p class=MsoPlainText>GetNextDocumentImage rather than GetNextDocumentImages<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> 3. In para 7.1.1, under Group 2: Job Template<o:p></o:p></p><p class=MsoPlainText>Attributes is a reference to section 8.28.1.7.2. There is no such section (should it be 8.2?)<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> 4. Although the text makes a distinction between<o:p></o:p></p><p class=MsoPlainText>Print Jobs and Scan Jobs, section 8.2.1.1 refers to a Print Job.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Thanks for catching these!<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>_________________________________________________________<o:p></o:p></p><p class=MsoPlainText>Michael Sweet, Senior Printing System Engineer, PWG Chair<o:p></o:p></p></div></body></html>