Pete,
I like the direction of this draft, some quick comments (we can go into detail at the next concall, Nov 18th):
- (Editorial) All of the tables seem to be using the IEEE paragraph style; just re-style using Normal to get the proper row spacing…
- I think we want a new operation code for Get-Next-Scan-Document rather than re-using the Send-Document op code. Op codes are cheap and these operations have completely different semantics (different direction of data flow, etc.) Also, given our renaming of AddHardcopyDocument to AddDocumentImages for SM 3.0 and IPP FaxOut, I suggest the name Get-Document-Images for IPP Scan.
- For Get-Next-Scan-Document/Get-Document-Images, I think we want the document-format-accepted attribute from IPPSIX in the request - that will allow the Client to specify the formats it is able to consume, and the scanner can (re)package the document images up as appropriate. The document-format should be part of the response as well. The order of document-format-accepted values specifies the Client’s preferred format… Alternately we could add document-format-accepted to the Create-[Scan-]Job request - that might be more consistent and allow a spooling service to pre-fetch the document images in the preferred format. (I’d still put the document-format in the Get response…)
- Regarding note 1 on page 20, we deprecated Restart-Job, Purge-Jobs, and Reprocess-Job because of the accounting issues; I think the “Resubmit-Job” operation here is a typo (the operation is listed in the table, and 0x002c is “Reprocess-Job” - same bug is in IPP FaxOut...)
- Create[-Scan]-Job: Should add (optional) destination-uris to the operation attributes group; if omitted, creating a pull job…
- We should sync up input-attributes from FaxOut with this spec; in particular:
— None of the input-xxx attributes are defined in RFC 2911…
— input-color-entry was simplified to input-color-mode in FaxOut. If we want to provide greater control over the representation of colors then I suggest we re-use the pwg-raster-document-type-supported keywords; we certainly can’t use the old SM Scan keywords as-is since IPP keywords are hyphenated-lowercase instead of TitleCase. However, I personally feel that input-quality + input-color-mode are enough to cover 1-bit, 8-bit, and 16-bit grayscale and 24-bit or 48-bit RGB color; I’m not aware of any scanners that can produce an actual CMYK separation image (all of them convert from RGB) so there seems little point in supporting CMYK explicitly.
— input-compression-quality-factor is very JPEG-specific. While I understand the motivation for such an attribute, I question whether we need/want a JPEG quality control vs. providing guidance on using input-quality to set baseline JPEG quality factor values (or use it to choose between JPEG/JBIG vs. Flate compression) (alternately maybe we could use MIME media type parameters to specify the file format options?)
On Nov 5, 2013, at 12:51 PM, Zehler, Peter <Peter.Zehler at xerox.com> wrote:
> All,
> I have posted an initial version of “IPP Scan Service” . Please add IPP Scan to the agenda of the next IPP teleconference.
>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-201301105.pdf>http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-201301105.pdf>>ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-201301105.docx>http://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippscan10-201301105.docx>> Peter Zehler
>> Xerox Research Center Webster
> Email: Peter.Zehler at Xerox.com> Voice: (585) 265-8755
> FAX: (585) 265-7441
> US Mail: Peter Zehler
> Xerox Corp.
> 800 Phillips Rd.
> M/S 128-25E
> Webster NY, 14580-9701
>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20131105/3db9dece/attachment.html>