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 <Peter.Zehler at xerox.com> wrote:
> 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: Peter.Zehler at Xerox.com> Office: +1 (585) 265-8755
> Mobile: +1 (585) 329-9508
> FAX: +1 (585) 265-7441
>
_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140930/874024af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4881 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20140930/874024af/attachment.p7s>