Subject: [IPP] Responses to IPP teleconference comments on IPP Scan

From: "Zehler, Peter" <[email-masked]>
Date: Tue, 30 Sep 2014 12:45:55 +0000

Below are my responses to the “Discussion of IPP Scan” posted in the IPP teleconference meeting minutes.

a. http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20140917.pdf
<PZ>I now have an updated specification http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-20141001.pdf
Please let me know what I should do with the updated specification.</PZ>

b. PWG Formal Vote until October 17, 2014
<PZ>I assume the formal vote continues.</PZ>

c. Editorial comments:
⁃ Add description of multiple document (object) support/creation - artifact of document-format.
<PZ>Added a section in 4.1
“4.1.1 Documents within a Scan Job
From a client’s point of view the number of documents created in a Job is a function of the Scan Service’s capability and the document format of the Output Image.  For example a document format such as JPEG only allows a single image per file.  If a stack of documents are being scanned and the Scan Service supports multi-document jobs, then each JPEG file generated will be associated with a Document within the Scan Job.  If the Scan Service did not support multi-document jobs, then only a single sheet from the stack would be scanned resulting in a single document job.  If that same stack of documents is scanned using a PDF document format, the all the Output Images, regardless of multi-document support, will be in a single PDF file associated with a single Document within the Scan Job.”
</PZ>

⁃ Drop compression-accepted and document-format-accepted from Get-Next-Document-Images; just use the values in the Create-Job request (same for both push and pull scan)
<PZ>deleted</PZ>

⁃ Clarify that output to archives is undefined/out-of-scope
⁃ SM and JDF can do it
<PZ />
⁃ Add "scan to archive formats" is out of scope
<PZ>Added the following to the list of out of scope in section 3.4
“Scan to archive formats (i.e., a single document object referencing a container of multiple files)”
</PZ>
⁃ Be silent about what happens if document-format is an archive format
<PZ />

⁃ Update Get-Next-Document-Images description to mention each call returns a new document object containing one or more complete document images (e.g. a JPEG at a time or a PDF at a time, etc.)
<PZ>
In section 6.1 I changed the description of Get-Next-Document-Images from
“The REQUIRED Get-Next-Document-Images operation allows a Scan Client to retrieve a scanned document from an existing job object. This operation enables pull scanning. The Scan Client specifies the target Scan Job. The Scan Job MUST be in the ‘processing’ or ‘completed’ state. As the scan data becomes available the document content is delivered in the response. To support streaming the Scan Client MUST support the "chunked" Transfer-Encoding in the response”
To
“The REQUIRED Get-Next-Document-Images operation allows a Scan Client to retrieve the scan data from an existing job object. This operation enables pull scanning. The Scan Client specifies the target Scan Job. The Scan Job MUST be in the ‘processing’ or ‘completed’ state. As the scan data becomes available the Scan Job content is delivered in the response. The response’s operational attribute “document-format” indicates the file type of the data.  The document description attribute “document-number” indicates to which document within the job the scan data belongs.  If the document number changes, the previous document is complete.  If the operational attribute “last-document” is true the transfer of all documents within the job is complete. To support streaming the Scan Client MUST support the "chunked" Transfer-Encoding in the response.”

And in section 6.1.2 in the description of “Group 3: Document content” I changed
“The document content is sent in the response as specified in [RFC2910] section 3.1.   Note that the Scan Client MUST be ready to accept a response using the "chunked" Transfer-Encoding.”
To
“The document content, or a portion thereof, is sent in the response as specified in [RFC2910] section 3.1.   Note that the Scan Client MUST be ready to accept a response using the "chunked" Transfer-Encoding.”
</PZ>

Peter Zehler

PARC, A Xerox Company
800 Phillips Rd, 128-27E
Webster NY, 14580-9701
Email: [email-masked]<mailto:[email-masked]>
Office: +1 (585) 265-8755
Mobile: +1 (585) 329-9508
FAX: +1 (585) 265-7441

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Tue, 30 Sep 2014 09:47:26 -0400

Pete,

Thanks for the update.

WRT process, yes we continue the Formal Vote, using the original stable draft you posted.  The discussion during the concall will be recorded as editorial comments for one or more of the votes cast by members, and we can review the outcome of the vote and your changes in response to our comments at the F2F.

On Sep 30, 2014, at 8:45 AM, Zehler, Peter <[email-masked]> wrote:

> Email: [email-masked]

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair